On Fri, 4 Jan 2002, Richard Earnshaw wrote:

> > Long ago, Acorn decreed that the top four bits of a (24-bit) SWI number
> > should indicate which operating system the SWI was for.  RISC OS set this
> > field to 0, and RISC iX set it to 8.  Later, Linux used 9, and ARM use F
> > for OS-independent SWIs.  Until now, NetBSD/arm has used 0, but I'd like
> > to change this.
[...]
> This sounds like a sensible idea, though I wouldn't have thought it was
> necessary to make emulations work (I'd be surprised if this is how FreeBSD
> and Linux emulations work on other NetBSD platforms).  Surely we need to
> know what we are emulating as we start to exec a new binary.  Once that
> has been determined (via the files magic number, I would have thought), we
> can remember this and use it to control SWI interpretation.

Indeed, but emulating things like Linux in the kernel is relatively easy,
since most of the syscalls have a 1:1 mapping to NetBSD ones.  Mapping
RISC OS SWIs is harder, and hence probably better done in user space (with
the kernel just seeing a normal NetBSD process).  This is how Riscose does
things, and I believe it's how Wine works too.

> 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
	bcs	__cerror
	mov	pc, lr

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>