Documentation Enquiry

In the notes for SWI decoding ( https://www.riscosopen.org/wiki/documentation/pages/SWI+Introduction#Allocate )it is stated that the OS Flag bits must be zero (currently) for RISC OS..

This suggests all RISC OS SWI’s lie below (2^{20)=&100000 , however it is stated elsewhere in the same section of the documentation that only SWI’s above (2}22)=&400000 are actually available for third party use.

What is the actual situation, (as I am sure I must be misreading something in the documentation)?

I hold my hands up, it is an error that I introduced. I’ve just fixed the document with the correct informtion.

You are correct that all SWI numbers are below 2²⁰. Third party SWIs are above &40000 (not &400000). This now matches up with the 32-bit SWI definition table, where its states that third party SWI have bit 19 set (2¹⁹ = &40000).

By the way, I would be interested to know how you got on reading the document. Did you find it read well? Explain things okay? Any improvements you can think, please let me know. Feedback is most welcome.

Thanks for the clarification.

So far I am finding the documentation remarkably clear, but that’s mainly because I’ve previously encountered the original PRM’s as well as reference documentation for various other versions of BBC BASIC (and related hardware). At least the RISC OS API is straightforward compared to Win32, or MS-DOS style interrupts..

The reason I asked is because some developers are considering an ARM port of ReactOS ( which is based on the NT architecture) and I had considered asking them to use SWI numbers (in respect of thier kernels syscall interface IIRC) that were not currently in use by RISC OS. ( The suggestion would have been to make the ReactOS SWI’s use an appropriate allocation of the OS flag bits… ). This would in my view make the possibility of future inter-operability more likely..

The thing I’ve not found yet though is a description of the ‘executable’ object formats used by RISC OS and the Procedure Call standard used in 32bit ARM. (These are presumably documented somewhere though…)

One thing to point out with SWIs is that sometime ago Linux changed from using SWI numbers encoded in the instruction to using SWI numbers passed in a register. I’m not sure of the full specifics, but I think the main (or only?) reason they changed was to increase performance. The way RISC OS does it worked well 20 years ago, but isn’t so useful now when we have split instruction & data caches – each SWI call under RISC OS will needlessly pollute the data cache because the SWI dispatcher must load and examine the instruction to get the SWI number from it. Changing to a SWI dispatcher that reads the SWI number straight from a register fixes that problem.

So although I’m not sure how feasible it would be to have interoperability between ReactOS and RISC OS code, I’d recommend that for performance reasons they went with the Linux style SWI dispatcher. But – should interoperability someday become possible – they should use a SWI number which won’t ever get used under RISC OS (i.e. by changing the OS flag bits). That way if ReactOS ever has to run RISC OS code it can switch at runtime to a different SWI dispatcher that examines the instruction to work out the SWI number, falling back on the value passed in the register if a ReactOS SWI is detected.

I’m not sure if the same thing is possible with Linux; it might be that they’ve just used SWI &0 for everything.

The thing I’ve not found yet though is a description of the ‘executable’ object formats used by RISC OS and the Procedure Call standard used in 32bit ARM. (These are presumably documented somewhere though…)

For executable formats, the majority of programs will be AIF (Acorn Image Format) or modules. GCC 4 has also brought ELF and shared library support, so expect that to grow in popularity.

The procedure call standard currently in use by most compiled programs is APCS 32; but I have seen some recent musings on the GCC mailing list that they might switch to the more Linuxy GNU ARM EABI (which AFAIK gets rid of the mostly useless support for chunked stacks, freeing up more registers for general purpose usage).

ROL’s downloadable RISC OS 3 PRMs and the Iyonix 32bit site are probably the best place to start for details regarding the formats that are currently used by RISC OS.

I’m not sure what model ReactOS is using currently, but it’s source is open for inspection.

The main ReactOS site is here : www.reactos.org with it’s source code repository(webview) here:http://svn.reactos.org/svn/reactos/

BTW For rather complex reasons, if you’ve worked on Risc OS Open, you shouldn’t submit any code to ReactOS.

I had a poke around the ReactOS code. I think they’re using SWI numbers in the RISC OS manner (number embedded in instruction), starting from 0.

The interesting bit of source is here: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/arm/ particularly http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/arm/usercall.c?revision=36880&view=markup

KiSystemService is what gets called from the SWI handler.

I’ve just started a thread: http://www.reactos.org/archives/public/ros-dev/2010-January/012818.html

If they’re amenable, what OS number should we offer them? Are these recorded in the allocations database? I don’t know if it’s worth reserving an OS number or few and subdividing them, since 16 isn’t a large number of OSs and many Unix-like OSs don’t need 2^20 syscalls each.

BTW, what are the licensing problems?

(BTW I am only a close observer of ReactOS, I am not linked with the project in any manner…)

On your last point Theo: http://www.reactos.org/en/dev_legalreview.html If that’s what you were relating to..

Yeah, that certainly looks like they’re using embedded SWI numbers.

Also I’m not too worried if my involvement with ROOL will prevent me from working on ReactOS – helping to port Windows to ARM is practically treason anyway ;)

I don’t know if it’s worth reserving an OS number or few and subdividing them, since 16 isn’t a large number of OSs and many Unix-like OSs don’t need 2^20 syscalls each.

It’s probably worth doing that at some point, yes – assuming you can find someone to coordinate SWI superchunk use with all the different OS developers. AFAIK ARM aren’t in the business of dictating who gets to use what SWI numbers, but then again I haven’t really looked into it.