[kaffe] cray int size problem

[Dalibor Topic]

Hi Eric,

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 
specific sizes. 
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#85587

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 
look at:

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#51035

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 ;)

cheers,
dalibor topic