Background

The Acorn Archimedes operating system RISC OS is built from a kernel and a collection of software components called relocatable modules. Its native bitmap format is the sprite.

SpriteExtend

RISC OS’s most fundamental sprite handling routines live alongside other VDU functionality within the OS kernel. However, that’s not enough to support all of the required sprite operations. A support module called SpriteExtend enters the fray: it hooks into the OS and steps in when required to implement the extended OS_SpriteOp operations.

Now, SpriteExtend is a bit of a meta beast. You might expect it to be straightforward and only provide the set of routines implementing the extended sprite operations. It does for many of them, but it also contains a sprite plotting routine generator. A sort of specialised compiler that can generate any required sprite plotting routine. This is required because RISC OS is very flexible with its bitmap handling. Across the range of RISC OS hardware you can have 1, 2, 4, 8, 16 or 32bpp screen modes (plus variants for different pixel formats). Sprites can be in any of these modes (plus extra formats like CMYK) and any of these sprites can draw into any screen mode. The combinatorial explosion of to’s and from’s would require hundreds of routines to be written and so is better served with a generalised routine generator.

It Gets Funner

SpriteExtend is a RISC OS module; modules have traditionally been written in ARM assembly language. If you want to write a module in C you compile your code in a special compiler mode (which makes it position independent, hence relocatable) then use a tool called CMHG (bless you) to generate a module header. Once linked, that binds the lot together into a useful modular blob.

But SpriteExtend’s maintainers didn’t go down the straight C module route: it’s still an assembly module, yet the sprite plotting routine generator is written in C. C compiled code assumes the presence of a runtime, so SpriteExtend contains just enough of the C runtime code to support the generator. And that C code? It directly generates machine code. It’s a JIT.

So: an assembly module houses a C routine which generates, then executes, machine code.

And this is why at the top of one of the main source files it says DANGER 10000 VOLTS: … and later on, when it got even scarier, that was supplemented by a BEWARE 20000 VOLTS: … warning.

One Last Thing

Oh yeah, did I mention that SpriteExtend also has a realtime JPEG renderer in it?

The Aristocrats.