Duane Rettig  <duane@franz.com> wrote:
+---------------
| I still believe that the wisest thing that the lisp community can ask
| of hardware and operating system vendors is fast user-level trap
| capability; with fewer registers saved and fewer cycles between the
| trap and the return from the trap.  Such a feature would be much more
| likely to be widely used than cdr-coding, even in lisp systems.
+---------------

Anybody remember the DEC PDP-10 (and DECsystem-20)?!? A certain number
of instructions were left unspecified, or rather, were specified as
"traps" in the architecture.  Half of them were used for kernel calls,
but the other half of these "Unimplemented User Operations", or UUOs
as they were know, trapped to user-mode instead. ISTR you could get
the ill-mem-ref & arithmetic overflows to trap to user too, through
a kernel trampoline, but I could be mistaken about that part.

Or consider the AMD Am29000 family architecture, which used *extremely*
light-weight trampolines on some traps to handle them in user mode --
specifically, the ASSERTs in the register-window code that triggered
"spills & fills".  If the address of the user-mode trap handler was
kept in a kernel register (which is was, for the spill-fill handler),
the trampoline only cost you a couple of cycles. E.g., the entire
kernel code for the "spill" trap trampoline:

	uspilltrap:
		mfsr    tpc, PC1                ; save return address
		mtsr    PC1, uspill             ; "branch"
		add     tav, uspill, 4          ; (sequential fetch)
		mtsr    PC0, tav                ; "branch" completely
		iret

Now the instructions which caused these traps were a set of "assert"
instructions that said one register was {EQ,NE,GT,LT,GE,LE} than another,
and the third arg was the trap vector number. These could very easily
be adapted to use for Lisp...


-Rob

-----
Rob Warnock, 31-2-510		rpw3@sgi.com
Network Engineering		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		PP-ASEL-IA
Mountain View, CA  94043