Subject: Re: RFC: Change SWI number base?
To: Ben Harris <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 01/04/2002 10:28:47
> 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.
> My main reason for wanting this change is to make it sensibly possible to
> do RISC OS binary emulation. Riscose is a project to do this, and it
> relies on a process's being able to trap RISC OS SWIs called from its own
> address space, and remap them into Unix system calls. Obviously, this is
> a lot easier if RISC OS and native SWIs don't overlap.
> The actual changes required to implement this change are minimal.
> syscall() would need to allow the new SWI base alongside the old, and
> lib/libc/arch/arm/SYS.h would need to be changed to generate the new one.
> Obviously to allow RISC OS emulation, a process would need some means to
> switch off support for the old base, but this isn't so immediately
> Anyone have any objection to this? If not, we just need to pick a base to
> use. I'm not sure if anyone's still allocating them, but if not, I'd
> propose B (for BSD, of course).
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.
As to the number, I've no idea if anyone is officially allocating them --
I'm fairly sure we don't. Maybe someone at RISCOS Ltd, or someone at PACE?
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.