Subject: Re: Q: ARM32 ABI
To: None <port-arm32@NetBSD.ORG>
From: Godmar Back <gback@cs.utah.edu>
List: port-arm32
Date: 06/04/1998 21:36:29
 Hi,

and thanks to everybody who replied.  

I finally figured it out.  As you pointed out, I had got bitten by the 
big-endian fp word issue.  For those interested in Kaffe, a preliminary port 
should be made available by tomorrow morning at 
ftp://ftp.transvirtual.com/pub/kaffe/, look for kaffe-snap.  Note that this
version doesn't support AWT yet and that, for licensing reasons, you must
get your own Sun 1.1.x classes.zip file from elsewhere.

[A bit development history:  Funny enough, I noticed that I could pass
double values properly when I would switch them.  So I thought: weird,
but if that's what it takes...   However, I kept getting these format
violations in the Java libraries.  After thinking about it,  I realized
that I'm probably reading the double constants wrong, which is why switching
"fixed" it.  I had observed that gcc naturally doesn't switch anything before
passing it to a function.  So, getting rid of the switch where I call native
code and adding a switch where I read the words in fixed that.  As for the
doubleToLongBits routine, it must switch them as well, because the long
long is in little-endian word order.  Then it all worked ;-)]


Unfortunately, the preemptive user-mode thread package I had written
doesn't quite work, which might be a bug unrelated to the arm32 specific
code, but I'd like to ask a quick question anyway:

* Kaffe uses a conservative garbage collector that checks the stack of a
  thread for pointers.  I am using setjmp/longjmp for thread switching.
  I determine the lower end of the active area of a thread's stack (which 
  needs to be scanned) by reading out jmpbuf[23] from the jmpbuf in which
  I save the thread's state, which contains the stack pointer. 
  This procedure works on most architectures--does anybody see or know
  anything in the calling conventions or in NetBSD's implementation of 
  setjmp/longjmp that would prevent that from working on the arm32?


Thanks,

	Godmar

[ps: also, does anybody have an autoconf macro that would test for the
fp order weirdness?]