Subject: Re: RFC: Change SWI number base?
To: Ben Harris <bjh21@netbsd.org>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm
Date: 01/04/2002 12:15:36
> > 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...