Kaffe 0.84/JIT on netbsd-m68k (long)
is at jocelyn.rhein.de
Wed Feb 4 14:11:13 PST 1998
> At 22:39 Uhr +0100 03.02.1998, Ignatios Souvatzis wrote:
> >Ok. JIT compilation sound like creation of 68k code on-the-fly. Did you add
> >the correct cachectl() pseudo-syscalls, to synchronize the I-cache with the
> >D-cache? If no, look at
> > src/gnu/usr.bin/ld/arch/m68k/mdprologue.S
> >it should contain what you need.
> I hacked the asm code snippet in (gcc inline assembler is ugly as hell) and
> Kaffe 0.84 JIT compiles & runs "HelloWorldApp" now. =8)
> On the other hand...
> The JIT code (#define'd in jit.h) calls __clear_cache() from libgcc.a. The
> comment says...
> /* On the 68040 (and 060 I presume) we need to flush the instruction
Yes :-), but also on the 68030. 256 bytes of I-Cache can be very much.
I never understood why the sig-trampoline code gets away without doing this.
> cache before running new code. Stupidly, Motorola made cpush a
> privledged instruction, so we have to get operating system help
> for this. Naturally, there is no standard there.
Yes. I had to look at this for nested function trampoline stuff (see below),
and every OS has its own convention.
> We are partially rescued by gcc, which must be taught how to do this
> in order to build bound-function trampolines. This works at least
> for A/UX, Linux and NeXT. The rest of you with 040's should
> consider fixing gcc, as you are broken there too.
> For those with 020's and 030's, this is effectively a no-op. */
> #define FLUSH_DCACHE(beg, end) __clear_cache((beg), (end))
> -- Is this always a no-op for NetBSD/m68k?
The one I'm thinking of used to be up to NetBSD-1.2G, corresponding to
up to gcc-18.104.22.168. Actually, it did some jmp tricks I never understood.
gcc in the 1.3 release is fixed by importing the relevant parts of
Note that flushing the D-cache is NOT enough. You need to invalidate the
I-cache, too. THe code actually used by gcc does this.
On 68020 and 30, you only need to invalidate the i-cache, as the d-cache
is not there or write-through, respectively.
> Is the routine from
> arch/m68k/mdprologue.S globally available?
err... at least, it should be in dynamically loaded programs, as ld.so is
using it when patching shared library references..
> >From looking in gcc/libgcc2.c, there seem to be more preprocessor symbols
> than actual code so I don't exactly get what's going on. But I didn't see
> any obvious function call or trap there.
You should make sure to have 22.214.171.124, at least. 126.96.36.199 had NOT valid code
for 68040 and 60. We imported those parts of 188.8.131.52 during the early
1.3 release branch time, just to fix that bug.
More information about the kaffe