yup,
My first attempt to fix this was to change the way the internal java
stack was organised. stack items are 64 bits wide ( due to pointers )
rather than doubled and longs, which on a 32 bit world occupy 2 stack
slots. So while i can store a double, long, and a pointer into a 64 bit
alpha stack item, the jvm still wants to work in 32bit/slot/stack item
mode, and will allocate 2 items for a double, and long.
Seemed simple enough at first, just fix all the code to accept 64
bit stack items. EXCEPT, it seems that the java byte-code also wants to
load, and store on 32bit offsets on the stack. fudge, and that caused
all sorts of phase problems with method calls. so had to drop the
effort, as it appears it will never work.
So I went back to assembler.
after that one finds out that the load double, and load float machine
instructions have to match the call stack signature - more work. And now
that I am writing this, i have to check be sure that double/float
returns from JNI are also stored properly.
I should have this v10 of the alpha jdk avail by late afternoon.
gat
Brett W Vasconcellos wrote:
> I have a native method:
>
> public native void foo(int a, double b, double c);
>
> When I call it: foo(2, 600, 32000) from Java,
> C reports a=2, b=600, but c=2.38778e-314.
> Let me know if you can't reproduce it.
>
> Brett
