_LP64 and vm defines

[steve goldman]

[ I orginally sent this to internal Sun hotspot-dev alias even though it 
was more appropriate for here. Old habits and such... ]

I was surprised yesterday with an episode with the use of _LP64. In the 
i486/amd64 register change I found that in the register_<cpu> files that 
_LP64 was not defined. I got around that by testing AMD64 (which in fact 
may have been more appropriate) but was mystified by the lack of _LP64 
in a LP64 build.

It turns out that with some investigating by Tom that if you don't 
include certain standard include files (say stdio.h) that even if you do 
CC -xarch=amd64 or -xarch=v9 you don't get _LP64 defined. The 
"register_" files are so simple that they don't do the prerequisite 
includes. In my case I was lucky in that the lack of the define caused a 
compile error. We might not always be so lucky since we don't really 
control _LP64.

This has me thinking that hotspot should really not be using _LP64 at 
all. I'm kind of queasy about the build process defining it since it 
would seem to be the prerogative of the compiler/standard include files 
(though the adlc build does).

I was wondering if maybe we should use a hotspot specific define like 
VM64 or some such. As far as _LP64 in the vm I think we don't reall care 
about "L64" but really only "P64" since we should be using intptr_t's to 
hold pointers as integers. Though I wouldn't be surprised if we had 
latent bugs in the regard. The use of something like VM64 might be 
trickier yet with a compressed oop jvm, I don't know.

Another issue is the AMD64 define and possibly the IA32 define. There 
are a few places that do "defined(IA32) || defined(AMD64)" that would 
really seem to mean "defined(X86)" and that there are rare cases where 
AMD64 would really mean "defined(X86) && defined(VM64)" instead of just 
"defined(VM64)".

-- 
Steve