Sizecoding Wiki for Risc OS/ARM

Recently I started adding a section on sizecoding for Risc OS/ARM to the sizecoding.org site. Your can find the wiki here. Historically the webpage was dedicated to x86, but recently we opened sections for lots of platforms. Of course sizecoding is a kind of niche ;-) and I cite the founder of the page: Also, don’t assume sizecoding is normal — shaving bytes is a black art that should be kept far, far away from normal programming targets. People sizecode for fun, not profit!

Any comments/additons welcome…it’s just a start for now, also for people who come from other platforms and more things should be covered (e.g. palette generation, more tricks,…)

May be somebody has some collection rusting on his webpage of some small ARM code hacks, just tell me and I’ll add links or code.

Any comments/additons welcome

• Everyone will tell you, it’s “RISC OS”, not “RiscOS” (despite what the sources say!).

• It’s perhaps worth mentioning that R13-R15 are not “usually”, they are. Of course one can make other use of R13 and R14 (only R15 is unchangeable), but this must be done with care. For instance you can’t store a temporary value in R14 and BL to a bit of code…

• No mention of the status register (it’s separate these days), not to mention changes to private versions for privileged modes, plus the banked registers. This may have application if you’re using IRQ code in a demo.

• There is a huge difference between the hardware FPU (VFP/NEON) and FPEmulator. FPE is an entire, compete, emulation of a mid 80s style floating point processor. It provides eight FP registers (F0 to F7) which fit into the standard IEEE FP definitions (single precision, double precision, etc). All the s/d/q register stuff does not apply. Don’t mix the two up.
  For demo code in 2020, probably best to forget that FPE entirely.

• For precalc, BASICVFP exists, it might work out faster to use regular BASIC non-integer calculations and let it be handled via the native FPU? Unless you mean precalc within the executable at runtime, in which case your example method of using VFP directly is the most logical.

• If writing code in C, GCC can use VFP. The DDE compiler, currently, cannot. This may have a notable speed impact.

Thanx for the hints. Fixed the RISC OS thingy already ;-)

Regarding the precalc, the main disadvantage to x87 is that we don’t have native SIN,COS,ATAN,etc.,even in the VFP. So for that I think it is still interesting to use the FPEmu (what I should cover at some time on the page). The idea would be to do some precalc in normal ARM state using FPEmu commands and after that switch to Thumb state within the executable.

I’m confused. The linked page consistently says ‘RISC OS’ and the ‘view history’ page doesn’t show any edits. Did it really say ‘RiscOS’ before?

Yup, kind of. It said “Risc OS” not “RiscOS”, you can see it here

the ‘view history’ page doesn’t show any edits.

This seems to be a feature of that wiki. I tried a random different page, no edits. Hmmm…
[edit: and there’s a Recent Changes that does show what’s changed… <shrug>]

we don’t have native SIN,COS,ATAN,etc.,even in the VFP.

That’s not the RISC way. It would probably take a chunk of silicon to do something that can be synthesised using simpler instructions.

The idea would be to do some precalc in normal ARM state using FPEmu commands and after that switch to Thumb state within the executable.

Using what in Thumb code? Because FP values in FPE and VFP aren’t directly compatible. Not even the standard IEEE types – because the byte order in the word is the other way around.

This might be part of what’s blocking Norcroft/DDE from supporting VFP – all code that handles FP values (consider printf and all the built-in FP functions) would potentially need to be duplicated in order to have a version that supports VFP while still be capable of catering for all of the existing FPE-using code.

…you could create a SIN/COS/ATAN-whatever lookup table in memory (saved as integers) with FPEmu what would be accessible later on also from your Thumb code. Those lookup tables were the common thing for e.g. “plasma” routines.

For “normal” ARM code in my ancient CodeCraft#3 invitro I used FPEu to calc some sinus movement of the whole screen even within the main routine. As It’s only one value calculated per frame it was fast enough.

Uh, about that wiki… The 6502’s registers are not IX and IY.
They’re called that on the Z80 because they’re intended to be used as index registers (what the ‘I’ implies), but on the 6502, that’s all you have aside from the Accumulator. It’s just X and Y.

I’ll forward that to the other author…may be copy/paste error, everything except x86 is still work at progress. At least for C64 I know for sure it was called X and Y like you said.

This seems to be a feature of that wiki. I tried a random different page, no edits. Hmmm…
[edit: and there’s a Recent Changes that does show what’s changed… ]

At least in this case, I think it’s because he’s renamed the page: It’s seeing it as a new page with no history.

Edit: Actually, both pages still exist! So it is a new page from the wiki’s perspective!