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

The kernel will still need to do all the range checking, so the gain is
minimal.  An alternative solution (for thumb) is to put the syscal number
in the 16bit word following the 'swi 0' instruction.  The kernel then has
to increment the user pc before returning from the SWI. Giving you:

    swi   0
    .word SYS_foo
    bcs   __cerror
    mov   pc,lr

(except they are ARM insts, not thumb ones...)
If you don't want to modify the user PC, reorder the instructions, eg:

    swi    0
    movcc  pc,lr
    b      __cerror
    .word  SYS_foo

        David