Raspberry Pi RISC OS System Programming Book

Use assembler functions or inline assembler to call the SWIs directly. On the Arc this was the fastest way, but I think it’s generally frowned upon nowadays as it can thrash the data cache a bit and result in worse performance than _swix() (This is down to the way the kernel has to examine the instruction to determine the SWI number. With _swix() and _kernel_swi() there’s only ever one SWI instruction which gets used for all SWIs, but with assembler there’s obviously one per SWI number, or potentially one per SWI call if you use inline assembler)

Far be it from me to be anywhere near smart enough to disagree with you – but could I please ask you to justify the statement that calling SWIs directly is “bad”?

You are correct in that calling SWIs the RISC OS way thrashes the data cache, basically because the OS needs to load the instruction as data (not as code) to see what the SWI number is.¹
The thing I don’t get is why _swix() is better. As I understand it, _swix(), and _kernel_swi(), call OS_CallASWIR12. Fair enough.

However, the OS needs to load the SWI in any case to know it is the CallASWI SWI; and since this is the cache-thrash, surely it doesn’t matter if it is CallASWI or any other SWI being called – the damage has been done.

The SWI handler, in Kernel.s.Kernel, does this (from line 577):

LDR     r11, [r14, #-4]         ; extract SWI number to r11
MRS     r12, SPSR               ; r12 = saved PSR
BIC     r11, r11, #&FF000000    ; (ordering to prevent interlocks)

So… Why is calling SWIs directly frowned upon? By my understanding of this, the SWI is always read by loading the instruction as data. However as CallASWI is decoded (line 735/737), the SWI number is fudged appropriately (function at line 780/787), then we are thrown back into the dispatch again for the SWI proper (line 590).
By this reckoning, direct SWIs would be the quickest method, né?²

For the purposes of the book, however, it is much less grief to call _swix(). ;-) I have written software where all the SWI calls were assembler veneers to the SWIs, basically ‘cos I like writing ARM code. However I think the amount of work that it took (a lot) over the time saved on calls to _kernel_swi() doesn’t necessarily justify the effort.

¹ Not teaching you to suck eggs ;-) it is for others reading who might not know why; this is why Linux on ARM no longer uses SWIs by number, instead SWI &0 is always called and the number is provided in a register (R7?), so the instruction read doesn’t need to be done… SWI was a brilliant idea, but it lives in a time before processors had caches, certainly before the instruction and data caches were separated.

² “né” (said like neck) is a Japanesism for when you are asking a question, but expecting an affirmative response.

You are correct in that calling SWIs the RISC OS way thrashes the data cache, basically because the OS needs to load the instruction to see what the SWI number is. The thing I don’t get is why _swix() is better

It’s because there’s only one implementation of _swix(). This means there’s only one SWI instruction, and subsequently only one address which the kernel needs to read from to get the SWI number. This means there’ll only be one cache line needed to hold that address. The more code that uses _swix(), the greater the chances are that the next time a SWI is called (via _swix()) the D-cache will still contain the _swix() SWI number – thereby avoiding the CPU having to stall while performing a main memory access. With other approaches (worst-case being inline assembler, where you’d have one SWI instruction for each piece of code you want to call a SWI from) there’d be many more addresses for the kernel to have to load from, and as a consequence if you were to call lots of SWIs in a sequence the D-cache could quickly fill up with cache lines containing nothing but SWI numbers. This is great if you’re planning on continuing to call those SWIs, but not so great if you want to switch to doing something memory-intensive where you’d much rather prefer the D-cache to contain the data you’re working on.

Note that machines with unified caches aren’t immune to the problem. They won’t suffer from the kernel having to stall in order to read the SWI instruction (because executing the instruction will have already caused it to be loaded into the cache), but they can still suffer from D-cache pollution if SWIs are called from lots of different places. they will still suffer from SWI instructions (or any type of code at all) forcing data out of the cache.

I’ll admit I’m not sure how much of an impact this has on code execution. It’s probably only noticeable on machines with terrible memory buses (e.g. standard StrongARM RiscPC), or in extreme cases where you’re expecting a throughput of millions of SWIs per second.

“né” (said like neck) is a Japanesism for when you are asking a question, but expecting an affirmative response.

Rhetorical questions. Questions to which you already know the answer but you ask to make a point.

The more code that uses _swix(), the greater the chances are that the next time a SWI is called (via _swix()) the D-cache will still contain the _swix() SWI number – thereby avoiding the CPU having to stall while performing a main memory access.

Interesting idea, using a single address. That said, I looked at specs for my iPad’s A5 SoC (I’d imagine the ARM part to be “typical”) and it has a 32K instruction cache, and a 32K data cache. So isn’t this question more or less moot for anything other than an idling system? Plus the number of SWIs called by the Wimp (not to mention other parts of the OS) is scary. All of these will be likewise affected. Let’s not even think about what happens when tasks are paged in/out. ;-)

I have to admit to being sceptical about theoretical claims rather than empirical timings of SWI/swix strategies.

While on the one hand one does litter the D-cache with SWI instructions to enable them to be decoded, any other method falls foul of the ARM’s limited range of immediate constants…

This means there’s only one SWI instruction, and subsequently only one address which the kernel needs to read from to get the SWI number.

This isn’t the whole picture – how did that SWI number get to be in that “one address”? It had to be put there, having been got from somewhere else. Now some SWI numbers may happen to be immediate constants, and perhaps the compiler makes others out of a couple of immediate constants… but maybe it just loads it out of memory somewhere and you have another useless cacheline fetched.

I’ll admit I’m not sure how much of an impact this has on code execution.

And whatever impact it is found to have will be massively dependent on platform and memory map details. Cache coherency is not straightforward in non-trivial programs, so I’d hesitate to recommend any particular strategy with the promise that It Will Always Be Fastest.

In other words, use what is most convenient, and in assembler that’s certainly plain old SWIs.

Now some SWI numbers may happen to be immediate constants, and perhaps the compiler makes others out of a couple of immediate constants… but maybe it just loads it out of memory somewhere and you have another useless cacheline fetched.

…? Isn’t a SWI number always encoded in to the instruction itself? Or are you referring to synthesising a SWI instruction?

While we’re talking about SWIs, what’s this?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0290g/ch02s08s13.html

It says that SVC was formerly SWI, but then it says:
The SVC handler reads the opcode to extract the SVC function number. A SVC handler returns by executing the following instruction, irrespective of the processor operating state:
MOVS PC, R14_svc
This action restores the PC and CPSR, and returns to the instruction following the SVC.

That’s like the old 26 bit behaviour. Has this been reintroduced with the ARM11, or am I looking at Thumb code?

I always liked the STMFD R13!, {....,PC}^ to restore registers, status, and exit…in one instruction. It’s a shame that something was not devised to replace it when PC and PSR split up.

PS – to me, SVC is a processor mode, so if you don’t mind, I’m going to keep calling it SWI. ;-)

Now some SWI numbers may happen to be immediate constants, and perhaps the compiler makes others out of a couple of immediate constants… but maybe it just loads it out of memory somewhere and you have another useless cacheline fetched.

…? Isn’t a SWI number always encoded in to the instruction itself? Or are you referring to synthesising a SWI instruction?

I’m think he’s talking about the SWI number that’s passed to OS_CallASWI, although the wording of his post makes it sound a bit like he’s talking about synthesising the SWI instruction (which is of course how _kernel_swi()/_swix() worked before OS_CallASWI was introduced).

So basically: Although the OS_CallASWI instruction may stay in the data cache, there’s also likely to be a bit of code elsewhere which uses LDR to load the SWI number into a register before calling OS_CallASWI. So it doesn’t reach the holy grail of only needing one D-cache line to call any number of SWIs. But, if you consider that the C compiler will have grouped any immediate constants together into literal pools, there’s a chance that the D-cache line containing the SWI number also contains several other useful bits of data, so there should still be a lower percentage of wasted D-cache space than with calling SWIs directly.

That’s like the old 26 bit behaviour. Has this been reintroduced with the ARM11, or am I looking at Thumb code?

MOVS PC,Rxx (and LDMFD Rxx,{...,PC}^) are perfectly valid in 32bit mode, as long as you’re running in a CPU mode which has an SPSR register. They have the action of loading the PC with the indicated value, and loading the PSR with the contents of the SPSR. E.g. when the CPU executes a SWI instruction it copies the PSR into SPSR_svc and the return address into R14_svc just before it switches to SVC mode and jumps to the SWI vector. So executing MOVS PC,R14 would both branch back to the return address and restore the PSR to the state it was in when the SWI was called.

There are two main reasons MOVS PC,R14 and friends are effectively banned from use in ordinary programs:

1. Applications run in user mode, which doesn’t have an SPSR register. Issuing MOVS PC,R14 from a mode which doesn’t have an SPSR is unpredictable (although by the nature of “unpredictable” instructions, not all CPU models will behave the same and some might execute the instruction without any catastrophic side effects)
2. The CPU only automatically updates the SPSR when a SWI instruction, interrupt, etc. occurs. A simple BL instruction won’t update it, unlike in 26bit mode where the PSR flags would always get copied into R14. So if you’re writing a module running in SVC mode then using MOVS PC,R14 to return from a subroutine would be a bad idea as it could return to a completely different CPU mode.

So executing MOVS PC,R14 would both branch back to the return address and restore the PSR to the state it was in when the SWI was called.
[…]
The CPU only automatically updates the SPSR when a SWI instruction, interrupt, etc. occurs. A simple BL instruction won’t update it, […] using MOVS PC,R14 to return from a subroutine would be a bad idea as it could return to a completely different CPU mode.

Ah, I see now. MOVS (etc) still does what they used to, but only at kernel level code – such as returning from exceptions and the like. Anything less would not set the flags accordingly so these instructions cannot be used in the (historically) expected manner.

I hope the spelling on the website does not leak into the book. Remember that kernel has no a in it.

Apart from one prominent exception: http://en.wikipedia.org/wiki/KERNAL

VFP Context Switching
Just looking at this chapter in the book now. Is there a list of key points that need to be made? I have done a bit of an intro into what context switching is and also outlined (probably quite basically) the VFP Module and the provision of the SWIs therein. This is probably at the very top end of the target audience of the book, but I am keen to include it as a ‘hot topic’ at present.

Kernal/Kernel
I can think of a few other instances of where it was an ‘a’ as well, but it’s and ‘e’ in this context (sic) , so thanks Gavin for pointing that out!

You are welcome. I am pretty arrogant ( and usually correct :) in matters of spelling and grammar, and I have had lots of experience in helping authors of books about programming tidy up their prose. The first book I did this for was Aake Wikstroem’s Introduction to Programming using Standard ML and more recently the first edition of Roberto Ierusalimschy’s Programming in Lua.

I am certainly interested in reading about context switching and VFP. In fact if RISC OS on the RPi is to be exploited properly by young programmers this topic will be very useful.

pretty arrogant

Not to be confused with “petty error grant” ;-)

*SOUNDGAIN
Is there an equivalent SWI to perform this function?
(Despite me searching high and low and finding nothing, if its probably right under my nose – but then I have a big nose.)

SoundGain is not in the PRM. Which module provides it?

Maybe SoundDMA. (New in 4.39, Where did *SoundGain come from ?)

Yes, it’s SoundDMA which provides *SoundGain.

There isn’t a SWI to control it, and there aren’t any CMOS bytes to store the value either – it gets reset to 0 on each boot.

Vector Floating Point
Delving back into VFP and context switching.

Just wondered is there any kernel support for printing floating point numbers, ie some form of OS_ConvertVFP to convert a Dx or Sx register value into a string for printing? Ditto in reverse?

Just wondered is there any kernel support for printing floating point numbers, ie some form of OS_ConvertVFP to convert a Dx or Sx register value into a string for printing? Ditto in reverse?

Unfortunately not, but it’s probably something we should consider adding.

If using VFPSupport_ calls to check and then create context is it still a requirement to turn the coprocessor on/off or does VFPSupport_CreateContext etc do this automatically? If it is still a requirement what is the correct order of calls in and out?

VFPSupport handles enabling/disabling the coprocessor as appropriate. Any code people have to manually enable the coprocessor is obsolete and should be deleted (it could interfere with VFPSupport’s operation)

How do I opt-in to Thumb code using the BBC BASIC Assembler?
I can achieve it from Linux using GCC using the BX instruction to perform an indirect-jump+1 call, where indirect-jump is the location of the start of the Thumb code.
Thanks, Bruce