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