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
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
