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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 13 04:32:03 PDT 2019


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

--- Comment #46 from Paulo Matos <pmatos at igalia.com> ---
(In reply to Paulo Matos from comment #44)
> (In reply to Keith Miller from comment #43)
> > I meant more that the consumer macro could just take x0 and do any part of
> > the n() macro they want.
> 
> That is a great suggestion. It will, hopefully, simplify a bunch of things.
> Will get to it!

I was thinking a bit more about this and the issue is that sometimes the registername is the same as the enumerator identifier but that is not always the case. So while we can leave it to the consumer macro to create the register namespace identifier, as in ARM64Registers::x0, we still need to have the name as an argument at which point you need to write it like:

macro(x0, "x0", 0, 0) \
macro(x1, "x1", 0, 0) \
macro(x2, "x2", 0, 0) \
...

But then if you want to simplify this, you introduce a helper macro n to do:
#define n(id) id, #id

and write it as:
macro(n(x0), 0, 0) \
...

and as soon as this happens you need all the macro forwarding things.

At this point, I think the pain of writing the name even when it's the same as the identifier is less than having all the macro forwarding stuff which hurts legibility. 

So, in my next proposal I will simplify the macro stuff by removing the macro forwarding work and the n/nn helpers and write down the name explicitly even when that matches the identifier.

-- 
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/6d68b8d4/attachment-0001.html>


More information about the webkit-unassigned mailing list