[kaffe] cray int size problem
robilad at kaffe.org
Fri Jul 25 02:50:02 PDT 2003
Eric Denman wrote:
> i'm another person working on the GW effort to port kaffe to a Cray
> SV-1, and have a question about some JIT details.
> on cray, all datatypes except chars are 8 bytes. for instance, ints and
> longs are 8 bytes. however, in gtypes.h, it seems that kaffe requires
> either int or long to be 4 bytes (as evidenced by this line:)
> #error "sizeof(int) or sizeof(long) must be 4"
the Java Language Specification requires that some datatypes be of
Kaffe tries to 'guess' the appropriate native C types for the respective
java types. It becomes problematic when there is no large enough C
primitive type to hold a Java primitive type, for example no 64 bit
integer to hold a Java long. The other way around it shouldn't be very
problematic, you'll just have to fulfil the constraints imposed to you
by the signed two's-complement representation of smaller types. Take a
Following from that is, for example, that you need to make sure that all
your 16-bit-but-embedded-in-64-bit integers with the same 16 bits
compare equal, etc. I assume that the quickest way to do that is to
'normalize' the inputs and the results of integer operations, i.e. to
set all leading bits to 0 if the integer is positive, or to set them to
1 if it's negative.
> My question is whether this is a serious requirement: if we change this
> line, will we be breaking other things?
Unless you make sure that all embedded integer operations retain the
same semantics as with smaller bit lengths, chances are you will ;)
Take the 0x00FF0001 == 0x00000001 example from above. If your embedded
integer is 16 bits, the leading FF should not matter in the comparison.
> also, on an relatively unrelated note, there are quite a few instruction
> formats on the cray that take up 48-bits. However, most existing 64-bit
> ports we're looking at only use 32-bit (LOUT). There is no macro for
> 48-bit assignment.
> this is the existing line in kaffe/kaffevm/jit3/funcs.c :
> #define LOUT (*(uint32*)&codeblock[(CODEPC += 4) - 4])
> is there any inherent problem with simply defining our own macro like this:
> #define LQOUT (*(uint64*)&codeblock[(CODEPC += 6) - 6])
> we would have to make sure our shifting details are correct, but i think
> that the extra space will simply be overwritten by the next statement
> that is translated.
I don't see a problem there, as long as you define another macro, and
add a comment why it's there ;)
More information about the kaffe