Re: CMUCL's kernel requirements

[Alessandro.Forin@SPICE.CS.CMU.EDU]

This is a quickie while going into a day-long meeting, I might have
a better answer later.

> - The signal generated by a protection violation are different.  I can
> compile lisp for either signal number, but not both at the same time.

I do not remember what this was/is, anyways what the latest kernel does is
the only correct thing to do.  Anything else is a bug.

> - We have to be able to frob the state in the sigcontext and then continue
> are random signals, especially protection violations.

Some text must be missing here.  I'll look more carefully, but no bells
ringing.  Restoring the floating state requires explicitly reloading
the FPA status register (there is some libc function for doing this I
forgot which one, something with an "fpc" in the name).

> - Support in the VM for cache flushing.  (Assuming we are using it
> correctly.  The Sparc port seems to be working without any cache flushing,
> so I don't know what's going on.)

All current Sparcs have a common I&D cache, which creates no coherency
problems.  Future Sparcs (e.g. the Viking chip from Sun) do have
separate I&D caches, and will have the same problem that mips has.
Yes you are handling the cache right, we made sure of that.

I have done a fair amount of work to tune the VM system to the heavy
paging required by lisp, I suspect most of it cannot be retrofitted
to the ancient VM code mja is still stuck with.

sandro-