Re: [kaffe] cray int size problem
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 == 0x0001 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
Re: [kaffe] More on Cobalt and Error message
Allen Gwinn wrote: This was with 1.1.0: java_lang_ClassLoader.h java/lang/ClassLoader ../kaffe/kaffeh/kaffeh -classpath ../libraries/javalib/Klasses.jar.bootstrap -o java_lang_Cloneable.h java/lang/Cloneable ../kaffe/kaffeh/kaffeh -classpath ../libraries/javalib/Klasses.jar.bootstrap -o java_lang_Compiler.h java/lang/Compiler ../kaffe/kaffeh/kaffeh -classpath ../libraries/javalib/Klasses.jar.bootstrap -o java_lang_Double.h java/lang/Double ../kaffe/kaffeh/kaffeh -classpath ../libraries/javalib/Klasses.jar.bootstrap -o java_lang_Float.h java/lang/Float make[2]: *** [stamp-h0all] Error 136 make[2]: Leaving directory `/home/sites/home/users/admin/kaffe-1.1.0/include' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sites/home/users/admin/kaffe-1.1.0/include' make: *** [all-recursive] Error 1 Weird, I see we had that one before. I was not able to find any useful information on Error 136, and I grepped through GNU make 3.80 sources quite a bit. So let's start with small things first: I assume that a cobalt raq-2 is a mips-linux system, right? Is OS 4.0 a Cobalt specific linux distribution? Does upgrading to latest GNU make (3.80) fix the problem? cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe/Ant hangs
Jaco Greeff wrote: Perhaps its an output buffering problem? What's happening to the stdout/stderr output from the make? Might well be. The make writes tons of messages to stdout/stderr. At the point of the hang everything (including the output) just stops. I would love to get more of a clue and give some better feedback, just not sure how to approach this one to get a decent report/resolution. what happens when you redirect the output away from std* ? cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] New server is up
Jim Pick wrote: Hi, I think we're back... The motherboard on our server died suddenly late on Monday night, and I had to scramble to figure out what was wrong and basically build a new server. I ripped the old server out yesterday morning, got the parts yesterday evening, and I managed to get it all assembled and put back into the colo today (I had to take the day off work). Tell me if you see any problems... hopefully this doesn't become an annual ritual. :-) Thanks for getting everything up again so quickly. Works like a charm, as far as I can tell. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] New server is up
Dalibor Topic wrote: Jim Pick wrote: Hi, I think we're back... The motherboard on our server died suddenly late on Monday night, and I had to scramble to figure out what was wrong and basically build a new server. I ripped the old server out yesterday morning, got the parts yesterday evening, and I managed to get it all assembled and put back into the colo today (I had to take the day off work). Tell me if you see any problems... hopefully this doesn't become an annual ritual. :-) Thanks for getting everything up again so quickly. Works like a charm, as far as I can tell. cheers, dalibor topic Me too! Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe/Ant hangs
Dalibor Topic wrote: Jaco Greeff wrote: Perhaps its an output buffering problem? What's happening to the stdout/stderr output from the make? Might well be. The make writes tons of messages to stdout/stderr. At the point of the hang everything (including the output) just stops. I would love to get more of a clue and give some better feedback, just not sure how to approach this one to get a decent report/resolution. what happens when you redirect the output away from std* ? I will try that over the weekend. Initially I thought it might be that I'm running out of disk space (at least that is what I thought this morning) that breaks the build. Cleaned up an additional 2GB and can safely rule that option out. In addition I'll also try 1.0.7 over the weekend, with that version I could kill and typically on the second try it succeeded. Running the CVS version (a week old now, updated today as well) doesn't seem to complete. So in short, I have some thing to try with and play, which might result in some better info. Frustrating if the only report I can give at this point is it doesn't work, doesn't help anybody. Greetings, Jaco ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Statically compiling Kaffe for MIPS
I have noticed in libnative.la it sets the variable dependency_libs. For my intel static build this points to an empty directory, but for the mips build it points to the directory /opt/hardhat/devkit/mips/lexra_fp_be/target/usr/lib which contains many libraries; there is not enough space for them all on the target! Any help with getting this to work would be much appreciated. As Dalibor has already noted, the unmodified 1.0.7 sources will not get you a functioning MIPS kaffe, even for dynamic builds, and you need to get either my patch to 1.0.7 or use a later source release. Note also that the MIPS JIT3 code remains slightly broken despite my best efforts, so you need to build it intrp. From the directory path you refer to above, I cannot help but wonder if you're using a Lexra processor. If you are, note that the Lexra CPUs do not implement the full MIPS instruction set. Specifically, they don't have the instructions for handling unaligned access to data - which is something that a Java virtual machine has to do a lot of the time. If you've got a Linux environment tailored for Lexra, you would need to have the kernel properly set up to emulate the missing instructions. Lastly, I will point out that simply executing the kaffe binary has never worked for me - one needs to have the environment set up correctly, as make check does for the purposes of regression testing, and make install does for the purposes of a real installation. I don't have access to my Linux box at the moment, but I believe that there is a script included to allow kaffe to be invoked without havint been installed, and you should be using that rather than invoking kaffe-bin directly. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe/Ant hangs
Dalibor Topic wrote: Jaco Greeff wrote: Perhaps its an output buffering problem? What's happening to the stdout/stderr output from the make? Might well be. The make writes tons of messages to stdout/stderr. At the point of the hang everything (including the output) just stops. I would love to get more of a clue and give some better feedback, just not sure how to approach this one to get a decent report/resolution. what happens when you redirect the output away from std* ? I will try that over the weekend. Initially I thought it might be that I'm running out of disk space (at least that is what I thought this morning) that breaks the build. Cleaned up an additional 2GB and can safely rule that option out. In addition I'll also try 1.0.7 over the weekend, with that version I could kill and typically on the second try it succeeded. Running the CVS version (a week old now, updated today as well) doesn't seem to complete. So in short, I have some thing to try with and play, which might result in some better info. Frustrating if the only report I can give at this point is it doesn't work, doesn't help anybody. Greetings, Jaco ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Bug in Kaffe 1.0.7
Hi there! I´ve found a bug in Kaffe 1.0.7 (sorry, was not ablt to test 1.1.0) related to Calendar: Dont know if its fixed, so please could you verify this bug on 1.1.0 Calendar c = Calendar.getInstance(); int week = c.get(Calendar.WEEK_OF_YEAR); Week is to low compared with the sun-jvm and my paperbook-calendar, it should be exactly 1 higher. E.G. In the real week 29 kaffe tells me its week 28. Hope that helps! Mfg Clemens Eisserer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] rmi support
Hai Does kaffe support rmi applications?If yes,are there any special steps to run the rmi applications in kaffe. Thank you Ram = C.Kalyan Ram 2221,S St Apt #23,Lincoln NE-68503 Email:[EMAIL PROTECTED] Ph:(402)742-9671 University Of Nebraska-Lincoln __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
