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

[bugzilla-daemon at webkit.org]

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

--- Comment #43 from Keith Miller <keith_miller at apple.com> ---
Comment on attachment 371945
  --> https://bugs.webkit.org/attachment.cgi?id=371945
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?

I was thinking more that we could have both the platform specific name and an independent name.

>>> 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.

I meant more that the consumer macro could just take x0 and do any part of the n() macro they want.

-- 
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/20190613/5e40fe47/attachment.html>