Kaffe 0.84/JIT on netbsd-m68k (long)

[Gordon W. Ross]

> From: Ignatios Souvatzis <is@jocelyn.rhein.de>
> Date: Thu, 5 Feb 1998 22:56:04 +0100 (MET)

> > 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.

Is it necessary to flush the D-cache to make I-cache see what has
been written as data by the CPU?  (I'm not familiar with 040/060).
If not, then trap #2 should just flush the I-cache (not the D-cache)
so it can be a short-cut specifically for self-modifying code.

> 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.

Right, _cachectl() is a full, general purpose cache flush API,
and I would not propose to change or eliminate that.

> > 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.

In that case, it should not go all the way up to sys_machdep.c
and so on...  (SunOS trap 2 doesn't even do a register save.)

> > 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?

It was true with the old gdb, which used trap #2 for breakpoints.
After discussions here some time ago, I made gdb use trap #15 so
we could get by with less "hair" in the locore trap handlers.
(Trap #15 is the most common m68k breakpoint, i.e. SunOS.)  As
a result, trap #2 should now come in only from SunOS binaries.

It would be nice if we could avoid using trap #2 for anything
other than what SunOS used it for (I-cache flush) so we don't
have to get fancy with per-emulation decisions in the handler.

Gordon