Subject: Re: RFC: Change SWI number base?
To: None <Richard.Earnshaw@arm.com>
From: Ben Harris <firstname.lastname@example.org>
Date: 01/04/2002 12:05:41
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
mov pc, lr
str r3, [sp, #-4]!
mov r3, r2
mov r2, r1
mov r1, r0
mov r0, #SYS_foo
mov pc, lr
Ben Harris <email@example.com>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>