> > While on the subject of SWI numbers, did we reach a decision on support
> > for SWI calls from Thumb code?  Thumb is limited to 256 SWI values, so it
> > might make sense for us to switch to using SWI 0, r0=syscall across the
> > board when we jump to ELF.
> 
> Why?  What's wrong with keeping the ARM veneers as they are, and just
> making the Thumb veneers indirect through SYS_syscall when they need to
> (or even all the time, which would make SYS.h easier to write).
> 
> Remember, using SYS_syscall all the time will change a typical veneer
> from:
> 
> 	swi	SYS_foo
> 	bcs	__cerror
> 	mov	pc, lr
> 
> to:
> 
> 	str	r3, [sp, #-4]!
> 	mov	r3, r2
> 	mov	r2, r1
> 	mov	r1, r0
> 	mov	r0, #SYS_foo
> 	swi	SYS_syscall
You've missed the stack pop...

> 	bcs	__cerror
> 	mov	pc, lr

Yes, but at the other end, we currently have to read the instruction, 
extract the call number, test whether it is zero (and if so do some 
shuffling), check the range and then switch to the call value.  If we 
*know* that a netbsd-elf image always puts the syscall number in r0, then 
we can eliminate all of the decoding and skip straight to the range check.

So we pay a small price in the userland code for a large performance gain 
inside the kernel...