[Webkit-unassigned] [Bug 198604] Refactoring of architectural Register Information

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=198604

--- Comment #34 from Paulo Matos <pmatos at igalia.com> ---
(In reply to Keith Miller from comment #33)
> Comment on attachment 371945 [details]
> Post-1 Review Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=371945&action=review
> 
> > Source/JavaScriptCore/assembler/ARM64Registers.h:31
> > +#define REGISTER_NAMESPACE ARM64Registers
> 
> I think this can just be a using RegisterNames = ARM64Registers; 
> 
> Then any user can just assume all registers are under the generic
> RegisterNames namespace.
> 

Not sure I understand the suggestion here.
You mean, removing the platform dependent namespace name and making the namespace platform independent in both assembler/<arch>Assembler.h and elsewhere?

> > Source/JavaScriptCore/assembler/ARM64Registers.h:55
> > +    macro_forward(macro, n(x0), 0, 0)                           \
> 
> Why do we need to have the macro_forward? Can't the consumer macro do any of
> the things n() does? Seems like that would be cleaner.

Yes, we can expand n() manually and avoid it but n() serves as a helper so that we don't need to write:
macro(x0, ARM64Registers::x0, "x0", 0, 0)

Once we use 
macro(n(x0), 0, 0)

then we need to use the macro_forward as a trick to force the preprocessor to split the macro arguments. Further to that, if we are on MSVC like Chris suggested we also need the EXPAND_ARGS macro helper.

If people find it better to avoid the helpers and just call the macro with all the arguments, thereby avoiding the helper issues, I can do the change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190612/33452559/attachment.html>