of course, if you're going to pass syscall arguments in registers (and
do the syscall.c-equivalent in hand-massaged assembler) you might find
that you'll get a bigger *system* performance gain (at least on "CISC"
systems like the i386 and m68k) by using a more RISC-like calling
convention with the first few arguments in registers..

Looking at NetBSD's sys/arch/i386/i386/trap.c, I see all sorts of
baggage in syscall() which could be taken out of the fast path without
tremendous difficulty (albeit with a fair amount of rototilling in the
rest of the system..)

The one pervasive change you need is that the syscall "trap number"
needs to be available to the syscall functions themselves.

here's a short list:
	1) ibcs2 emulation "high" syscall conversion.
		this could be handled in the "syscall out of range" code 
		for the ibcs2 emulation.
	2) indirect syscalls  (SYS_syscall, SYS___syscall)
		do the work in a new `sys_syscall' and you save a
		couple branches on all non-indirect syscalls at the
		cost of an extra stack frame of depth in indirect
		syscalls.
		Even better, nothing in i386 user-space seems to generate
		SYS_syscall any more..
	3) argument munging for linux emulation
	4) errno mapping on return: shouldn't this be done in the
	   emulations?
	5) there are three sets of "see if we need to do work 
	before returning to user mode on syscall return" code:
		- posting signals 
		- forcing a context switch 
		- posting AST's 
	(the last, as best I can tell, just forces you to call trap()
	again which does nothing except force you back through
	userret() again..)
	
	Do we really need to do all three?
	6) vm86 mode special cases..
	7) Both KTRACE *and* SYSCALL_DEBUG instrumentation points..

					- Bill