m68k: getting there - slowly

[Kiyo Inaba]

I know you are in vacation right now, but anyway...

I'm currently trying to merge your (and others') comments to be
submitted as a patch.

>First, my previously posted FLUSH_DCACHE is broken.  I currently have it as:

For the time being, I have no 68040 based machine, and I omit this
from the first submission. Actually, I have (or bought) one 68040
based Mac, but till the weekend, I have no time to install linux
or netbsd on it:-)

>Now for the new stuff: sysdepCallMethod for NetBSD is broken.  It currently
>reads:

Partially yes, and partially no.
Let me describe, based on your comment.

>There are two problems with this code:
>
>1. Registers d2-d7/a2-a5 are clobbered by JIT-generated code, but are not saved
>   here.  GCC puts automatic variables in registers, and expects them to
>   survive function calls.  In particular, the `success' variable tested at
>   line 464 of classMethod.c is clobbered.  This is why the static class
>   constructor of java.lang.Runtime() "fails".

True. That is the main problem why pizza does not work. But the
work around is simple. Just compile everything without any
optimization. I've posted a progress report to the Kaffe porting
database.

>2. At no point is the location of the arguments indicated to the JIT code.
>   We build an argument vector in the automatic variable `extraargs', but
>   we don't pass its address to the called code, so I'm not sure how the code
>   can ever find it.

Well...
You are right that 'extraargs' is not passed, EXPLICITLY...
The magic is, when a function is called via 'sysdepCallMethod',
the callee assumes "arguments are on stack". On the other hand,
'sysdepCallMethod' macro does not push any arguments on stack,
explicitly. So the callee fetches the arguments from the closest
local variables. In this case, it is 'extraargs' array, built
on top of stack. I stole this idea from some other port (may
be i386) and works fine for m68k.

# This magic is fully CPU and compiler dependent.

>Given the extreme disparity between this code and the Linux version, my next
>step would be to figure out the calling conventions for JIT code (is this on
>the kaffe.org site somewhere?) and rewrite this function from scratch.

I am currently planning reverse side :-)
I know JIT version works (in some sense) for netbsd, and modify
linux version to be as close as netbsd's. A Mac-IIci (which is
68030 based machine) waits for me for this specific purpose. 

>Enough for now.  Hopefully Kiyo can do something with this.  At 2 hours per
>compile, it must be painful on that 3/260.

That's why the cross compilation is the must for m68k people :-)

Kiyo