Request for review (L): 6797305: Add LoadUB and LoadUI opcode class
John Rose
John.Rose at Sun.COM
Mon Mar 2 09:34:39 PST 2009
On Mar 2, 2009, at 2:30 AM, Christian Thalinger wrote:
> - Similar to the one above for $mem, e.g. $mem$$Address$high, for long
> memory accesses. Currently I'm using:
Do be careful with the high/low terminology! That had gotten us into
"endian" portability problems.
I suggest sticking to first/second, which unlike high/low
unambiguously refer to the lower address and the higher address. Of
course, ADLC can make high/low be aliases for second/first on little
endian systems and first/second on big endian systems. Even better
would be avoiding high/low, because in different contexts those words
can seem to refer to arithmetic significance or memory order, and only
on little-endian systems do those concepts (accidentally) align. When
talking about arithmetic significance, msw/lsw is probably better than
high/low.
For register contents, we already use high/low in some places, and it
twists around our endian story, causing bugs when the system is
changed. Those points are (loosely speaking) portability problems
embedded in the system due to early sloppiness, since HotSpot was
originally an x86-only system. Let's make it better over time.
The "gold standard" would be to use a single terminology for word
pairs that is consistent across memory and register values. Since
memory values are copied around in the JVM more than they are used for
2s-complement arithmetic, first/second is far more helpful than msw/
lsw. And high/low is just ambiguous.
-- John
P.S. Someone might point out that registers don't live in memory, so
my concern for using first/second for them is over-scrupulous. They'd
be wrong, since the register allocator uses a common linearly
addressed model for both machine registers and stack slots. This
linear model is, in turn, used by the vframe code, which is
responsible for unpacking and packing between stack frames and
registers and heap structures. Adapter generation code also uses the
unified numbering. Thus, registers, stack slots, and heap values are
all manipulated in a common framework. The system goes slowly insane
if you try to use different ordering conventions for those different
categories of storage. Please trust me when I say we don't want to go
there again.
More information about the hotspot-compiler-dev
mailing list