Kaffe 0.84/JIT on netbsd-m68k (long)

[Ignatios Souvatzis]

Gordon wrote:
> [I wrote: ]
> > Yes :-), but also on the 68030. 256 bytes of I-Cache can be very much.
> 
> Yes, all self-modifying code should definitely flush the I-cache.
> 
> > I never understood why the sig-trampoline code gets away without doing this.
> 
> We are guaranteed that I-cache holds nothing from user-space at the
> time the signal trampoline code is copied out.  Does that answer?
oh... errr, yes.

> Hmmm... Looks like that _cachectl code should be copied into
> libgcc2.a (well, into libc in our case):

Yes, I was about to propose the same.
 
> It would be nice if we could let a simple "trap #2" do the job of
> flushing the I-cache as needed for self-modifying code to work.
> That's what "trap #2" does on SunOS (their dynamic linker uses it).

Hm,  I dont think so.

We already provide (at least on Amiga) this COMPAT_SUNOS trap #2 emulation,
but it is NOT desirable to be the primary method to use for native code.

On 68040 and 68060, the data caches are big enough to make interupt latency
long enough to limit serial speed for some hardware. Thats why a cheap "flush
all", at least using the flush-all instruction, should not be used.

The ___cachectl() trap uses address base and length to selectively flush
the needed regions, and provides for a hook to make this always work pagewise
or even linewise, if interupt latency should demand this for certain machines
or configurations.

> Also it was implemented as a "fast trap" (no "rei" check, just rte)
> so we could do the same and let both our executables and SunOS
> enjoy the availability of a very cheap I-cache flush.

I wouldn't object to make trap12 a fast trap.
> 
> BTW, we no longer use "trap #2" for kernel breakpoints, so we
> could now easily let it mean "flush the I-cache".  Good idea?
> 

Uhm, at least the NetBSD/Amiga trap#2 handler seems to mention trace trap
usage; is this comment not true?

Regards,
	Ignatios
	(btw: maybe we should take the Kaffe list off this thread?)