SizeCoding - User contributions [en]

RISC OS on ARM based CPUs

2020-09-29T20:12:31Z

Kuemmel:

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Code Tricks ==
=== Cheap Absolute Value ===
Usually calculating ABS() would look like this in ARM (of course the cmp could be omitted if a preceding instruction triggered the flags already).
<syntaxhighlight lang="gas">cmp r0,#0
rsblt r0,r0,#0</syntaxhighlight>
and in Thumb
<syntaxhighlight lang="gas">cmp r0,#0
it lt
rsblt r0,r0,#0</syntaxhighlight>
If your routine is okay with a small deviation (this variant will form a negative value using the formulae ABS(x) = -x - 1) this can be done by just one instruction (ARM). Hint taken from Coder's Revenge 06/96 disc mag.
<syntaxhighlight lang="gas">eor r0,r0,r0,asr#31</syntaxhighlight>
In Thumb this would need 2 instructions so I skip that here.
=== Clamping ===
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:

Example 1 - All values < 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movlt r0,#0 // r0<0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">bic r0,r0,r0,asr#31</syntaxhighlight>
Example 2 - All values >= 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movge r0,#0 // r0>=0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">and r0,r0,r0,asr#31</syntaxhighlight>
Example 3 - All values <= -1 should be -1
<syntaxhighlight lang="gas">cmn r0,#1 // r0 ? -1
mvnle r0,#0 // r0<=-1 => r0=-1</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">orr r0,r0,r0,asr#31</syntaxhighlight>
All of those simplifications can be coded in Thumb, too, but would need also two instructions each and therefore end up with the same size, so I skip that here.
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:
=== Limiting values to byte or halfword ===
It might be a trivia but could be overlooked. If you would want to limit a register to byte or halfword in thumb mode you would want to do
<syntaxhighlight lang="gas">and r0,r0,#0xff // limit to byte
and r1,r1,#0xffff // limit to halfword (it's impossible to assemble this as 0xffff is out of range)</syntaxhighlight>
...but the first one assembles to 4 bytes and the later one isn't even possible to assemble (it's doable with the 4 byte instruction <code>bfc r1,16,16</code> or two shift instructions). But we are lucky and the extending instructions come in handy to do the job with just 2 byte instructions each:
<syntaxhighlight lang="gas">uxtb r0,r0 // unsigned byte extend to word = limit to byte
uxth r1,r1 // unsigned halfword extend to word = limit to halfword </syntaxhighlight>

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

Codepressor also supports Thumb executables, both, if the thumb trigger is set within the code or as shown above set within the filesystem. Future versions might also have thumb decompression routines to make the files even shorter. At the time of writing the decompression routines are written in normal ARM code.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

RISC OS on ARM based CPUs

2020-09-29T20:11:32Z

Kuemmel:

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Code Tricks ==
=== Cheap Absolute Value ===
Usually calculating ABS() would look like this in ARM (of course the cmp could be omitted if a preceding instruction triggered the flags already).
<syntaxhighlight lang="gas">cmp r0,#0
rsblt r0,r0,#0</syntaxhighlight>
and in Thumb
<syntaxhighlight lang="gas">cmp r0,#0
it lt
rsblt r0,r0,#0</syntaxhighlight>
If your routine is okay with a small deviation (this variant will form a negative value using the formulae ABS(x) = -x - 1) this can be done by just one instruction (ARM). Hint taken from Coder's Revenge 06/96 disc mag.
<syntaxhighlight lang="gas">eor r0,r0,r0,asr#31</syntaxhighlight>
In Thumb this would need 2 instructions so I skip that here.
=== Clamping ===
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:

Example 1 - All values < 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movlt r0,#0 // r0<0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">bic r0,r0,r0,asr#31</syntaxhighlight>
Example 2 - All values >= 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movge r0,#0 // r0>=0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">and r0,r0,r0,asr#31</syntaxhighlight>
Example 3 - All values <= -1 should be -1
<syntaxhighlight lang="gas">cmn r0,#1 // r0 ? -1
mvnle r0,#0 // r0<=-1 => r0=-1</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">orr r0,r0,r0,asr#31</syntaxhighlight>
All of those simplifications can be coded in Thumb, too, but would need also two instructions each and therefore end up with the same size, so I skip that here.
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:
=== Limiting values to byte or halfword ===
It might be a trivia but could be overlooked. If you would want to limit a register to byte or halfword in thumb mode you would want to do
<syntaxhighlight lang="gas">and r0,r0,#0xff // limit to byte
and r1,r1,#0xffff // limit to halfword (it's impossible to assemble this as 0xffff is out of range)</syntaxhighlight>
...but the first one assembles to 4 bytes and the later one isn't even possible to assemble (it's doable with the 4 byte instruction <code>bfc r1,16,16</code> or two shift instructions). But we are lucky and the extending instructions come in handy to do the job with just 2 byte instructions each:
<syntaxhighlight lang="gas">uxtb r0,r0 // unsigned byte to halfword = limit to byte
uxth r1,r1 // unsigned halfword extend to word = limit to halfword </syntaxhighlight>

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

Codepressor also supports Thumb executables, both, if the thumb trigger is set within the code or as shown above set within the filesystem. Future versions might also have thumb decompression routines to make the files even shorter. At the time of writing the decompression routines are written in normal ARM code.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

RISC OS on ARM based CPUs

2020-09-29T20:09:22Z

Kuemmel: some tricks added

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Code Tricks ==
=== Cheap Absolute Value ===
Usually calculating ABS() would look like this in ARM (of course the cmp could be omitted if a preceding instruction triggered the flags already).
<syntaxhighlight lang="gas">cmp r0,#0
rsblt r0,r0,#0</syntaxhighlight>
and in Thumb
<syntaxhighlight lang="gas">cmp r0,#0
it lt
rsblt r0,r0,#0</syntaxhighlight>
If your routine is okay with a small deviation (this variant will form a negative value using the formulae ABS(x) = -x - 1) this can be done by just one instruction (ARM). Hint taken from Coder's Revenge 06/96 disc mag.
<syntaxhighlight lang="gas">eor r0,r0,r0,asr#31</syntaxhighlight>
In Thumb this would need 2 instructions so I skip that here.
=== Clamping ===
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:

Example 1 - All values < 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movlt r0,#0 // r0<0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">bic r0,r0,r0,asr#31</syntaxhighlight>
Example 2 - All values >= 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movge r0,#0 // r0>=0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">and r0,r0,r0,asr#31</syntaxhighlight>
Example 3 - All values <= -1 should be -1
<syntaxhighlight lang="gas">cmn r0,#1 // r0 ? -1
mvnle r0,#0 // r0<=-1 => r0=-1</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">orr r0,r0,r0,asr#31</syntaxhighlight>
All of those simplifications can be coded in Thumb, too, but would need also two instructions each and therefore end up with the same size, so I skip that here.
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:
=== Limiting values to byte or halfword ===
It might be a trivia but could be overlooked. If you would want to limit a register to byte or halfword in thumb mode you would want to do
<syntaxhighlight lang="gas">and r0,r0,#0xff // limit to byte
and r1,r1,#0xffff // limit to halfword (it's impossible to assemble this as 0xffff is out of range)</syntaxhighlight>
...but the first one assembles to 4 bytes and the later one isn't even possible to assemble (it's doable with the 4 byte instruction <code>bfc r1,16,16</code> or two shift instructions). But we are lucky and the extending instructions come in handy to do the job with just 2 byte instructions each:
<syntaxhighlight lang="gas">uxtb r0,r0 // limit to byte
uxth r1,r1 // limit to halfword (it's impossible to assemble this as 0xffff is out of range)</syntaxhighlight>

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

Codepressor also supports Thumb executables, both, if the thumb trigger is set within the code or as shown above set within the filesystem. Future versions might also have thumb decompression routines to make the files even shorter. At the time of writing the decompression routines are written in normal ARM code.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Main Page

2020-09-17T08:17:46Z

Kuemmel:

== Welcome to SizeCoding.org! ==

'''SizeCoding.org is a wiki dedicated to the art of creating very tiny programs for most popular types of CPUs. As sizecoding is also popular on other hardware we recently opened the website for other plaforms as well, check the links below.'''

By "very tiny programs", we mean programs that are '''256 bytes or less in size''', typically created by members of the [https://en.wikipedia.org/wiki/Demoscene demoscene] as a show of programming skill. The size of these tiny programs is measured by their total size in opcode bytes, and are usually presented as executable .COM files to be run in pure DOS, a DOS VM running inside another operating system, or an emulator that can run DOS such as DOSBox.

'''Despite their tiny size, these programs are able to produce amazing graphical displays, playable games, and sometimes music.''' There are even some surprisingly effective programs in under '''16 bytes''', such as [https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ a maze generator in 10 bytes], a [[Paint16b|mouse-driven paint program in 16 bytes]], and an [[M8trix_8b|"Enter the Matrix" screensaver]] in only 8 bytes.

'''The intent of this wiki is to teach x86 assembler programmers the various techniques used to create tiny demoscene intros.''' While these techniques can be used for other applications (boot sectors, BIOS and firmware code, etc.), the information presented here is firmly oriented towards the demoscene. Practicality and common sense are sometimes thrown out the window just to shave a single byte -- consider yourself warned.

This wiki is divided into the following major sections for x86:

*'''[[Getting Started]]''' - What do you need to know before starting your first tinyprog?

*'''[[Techniques|Tips, Tricks, and Techniques]]''' - The meat of the wiki. Lists of small opcodes, default environment settings, size optimization basics, and a ton of random tips.

*'''[[Case Studies]]''' - Analysis of existing award-winning tiny programs, with comments on what choices were made and why.

*'''[[Resources|Additional Resources]]''' - Discussion threads, competitions, repositories, and other external references that can aid you in your quest.

For other platforms check out the sections here:

*'''[[Linux]]''' - Sizecoding on linux platforms.
*'''[[RISC OS on ARM based CPUs]]''' - Create your tiny intro on ARM hardware on RISC OS.
*'''[[ARM based CPUs]]''' - Other ARM Based Plaforms (Gameboy Advance, etc.)
*'''[[Motorola 68k based CPUS]]''' - Start Sizecoding on your Atari ST or Amiga.
*'''[[6502 based CPUs]]''' - Commodore 64, Atari XE/XL, Atari 2600, Atari Lynx, etc.
*'''[[Z80 based CPUs]]''' - For all your ZX Spectrum, Amstrad CPC, etc. sizecoding needs

RISC OS on ARM based CPUs

2020-09-17T08:17:05Z

Kuemmel:

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Code Tricks ==
=== Cheap Absolute Value ===
Usually calculating ABS() would look like this in ARM (of course the cmp could be omitted if a preceding instruction triggered the flags already).
<syntaxhighlight lang="gas">cmp r0,#0
rsblt r0,r0,#0</syntaxhighlight>
and in Thumb
<syntaxhighlight lang="gas">cmp r0,#0
it lt
rsblt r0,r0,#0</syntaxhighlight>
If your routine is okay with a small deviation (this variant will form a negative value using the formulae ABS(x) = -x - 1) this can be done by just one instruction (ARM). Hint taken from Coder's Revenge 06/96 disc mag.
<syntaxhighlight lang="gas">eor r0,r0,r0,asr#31</syntaxhighlight>
In Thumb this would need 2 instructions so I skip that here.
=== Clamping ===
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:

Example 1 - All values < 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movlt r0,#0 // r0<0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">bic r0,r0,r0,asr#31</syntaxhighlight>
Example 2 - All values >= 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movge r0,#0 // r0>=0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">and r0,r0,r0,asr#31</syntaxhighlight>
Example 3 - All values <= -1 should be -1
<syntaxhighlight lang="gas">cmn r0,#1 // r0 ? -1
mvnle r0,#0 // r0<=-1 => r0=-1</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">orr r0,r0,r0,asr#31</syntaxhighlight>
All of those simplifications can be coded in Thumb, too, but would need also two instructions each and therefore end up with the same size, so I skip that here.

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

Codepressor also supports Thumb executables, both, if the thumb trigger is set within the code or as shown above set within the filesystem. Future versions might also have thumb decompression routines to make the files even shorter. At the time of writing the decompression routines are written in normal ARM code.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

RISC OS on ARM based CPUs

2020-07-14T09:15:21Z

Kuemmel: Code Tricks added

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Code Tricks ==
=== Cheap Absolute Value ===
Usually calculating ABS() would look like this in ARM (of course the cmp could be omitted if a preceding instruction triggered the flags already).
<syntaxhighlight lang="gas">cmp r0,#0
rsblt r0,r0,#0</syntaxhighlight>
and in Thumb
<syntaxhighlight lang="gas">cmp r0,#0
it lt
rsblt r0,r0,#0</syntaxhighlight>
If your routine is okay with a small deviation (this variant will form a negative value using the formulae ABS(x) = -x - 1) this can be done by just one instruction (ARM). Hint taken from Coder's Revenge 06/96 disc mag.
<syntaxhighlight lang="gas">eor r0,r0,r0,asr#31</syntaxhighlight>
In Thumb this would need 2 instructions so I skip that here.
=== Clamping ===
Clamping towards zero or similar code cases can be optimized in the same way. Here are 3 examples also from Coder's Revenge 06/96:

Example 1 - All values < 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movlt r0,#0 // r0<0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">bic r0,r0,r0,asr#31</syntaxhighlight>
Example 2 - All values >= 0 should be 0
<syntaxhighlight lang="gas">cmp r0,#0 // r0 ? 0
movge r0,#0 // r0>=0 => r0=0</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">and r0,r0,r0,asr#31</syntaxhighlight>
Example 3 - All values <= -1 should be -1
<syntaxhighlight lang="gas">cmn r0,#1 // r0 ? -1
mvnle r0,#0 // r0<=-1 => r0=-1</syntaxhighlight>
can be done by
<syntaxhighlight lang="gas">orr r0,r0,r0,asr#31</syntaxhighlight>
All of those simplifications can be coded in Thumb, too, but would need also two instructions each and therefore end up with the same size, so I skip that here.

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

Codepressor also supports Thumb executables, both, if the thumb trigger is set within the code or as shown above set within the filesystem. Future versions might also have thumb decompression routines to make the files even shorter. At the time of writing the decompression routines are written in normal ARM code.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

RISC OS on ARM based CPUs

2020-07-12T10:19:41Z

Kuemmel:

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

Codepressor also supports Thumb executables, both, if the thumb trigger is set within the code or as shown above set within the filesystem. Future versions might also have thumb decompression routines to make the files even shorter. At the time of writing the decompression routines are written in normal ARM code.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

RISC OS on ARM based CPUs

2020-07-11T08:55:26Z

Kuemmel: typo

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

At the time of writing it doesn't work with Thumb code when the standard trick that is mention above is used to specify the execution address of the intro in the filing system. So for now you would have to skip that and invest 4 bytes at the start of your intro to make it compressible with Codepressor:
<syntaxhighlight lang="gas">adr pc,thumb+1
.thumb
thumb:</syntaxhighlight>
This will trigger Thumb mode manually within your code. <code>adr pc,thumb+1</code> is a pseudo-instruction that tries to produce a single add or sub instruction to load the address, in that case here it'll be assembled to <code>sub pc,pc,#3</code>.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Main Page

2020-07-11T08:54:24Z

Kuemmel:

== Welcome to SizeCoding.org! ==

'''SizeCoding.org is a wiki dedicated to the art of creating very tiny programs for most popular types of CPUs. As sizecoding is also popular on other hardware we recently opened the website for other plaforms as well, check the links below.'''

By "very tiny programs", we mean programs that are '''256 bytes or less in size''', typically created by members of the [https://en.wikipedia.org/wiki/Demoscene demoscene] as a show of programming skill. The size of these tiny programs is measured by their total size in opcode bytes, and are usually presented as executable .COM files to be run in pure DOS, a DOS VM running inside another operating system, or an emulator that can run DOS such as DOSBox.

'''Despite their tiny size, these programs are able to produce amazing graphical displays, playable games, and sometimes music.''' There are even some surprisingly effective programs in under '''16 bytes''', such as [https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ a maze generator in 10 bytes], a [[Paint16b|mouse-driven paint program in 16 bytes]], and an [[M8trix_8b|"Enter the Matrix" screensaver]] in only 8 bytes.

'''The intent of this wiki is to teach x86 assembler programmers the various techniques used to create tiny demoscene intros.''' While these techniques can be used for other applications (boot sectors, BIOS and firmware code, etc.), the information presented here is firmly oriented towards the demoscene. Practicality and common sense are sometimes thrown out the window just to shave a single byte -- consider yourself warned.

This wiki is divided into the following major sections for x86:

*'''[[Getting Started]]''' - What do you need to know before starting your first tinyprog?

*'''[[Techniques|Tips, Tricks, and Techniques]]''' - The meat of the wiki. Lists of small opcodes, default environment settings, size optimization basics, and a ton of random tips.

*'''[[Case Studies]]''' - Analysis of existing award-winning tiny programs, with comments on what choices were made and why.

*'''[[Resources|Additional Resources]]''' - Discussion threads, competitions, repositories, and other external references that can aid you in your quest.

For other platforms check out the sections here:

*'''[[RISC OS on ARM based CPUs]]''' - Create your tiny intro on ARM hardware on Risc OS.
*'''[[Motorola 68k based CPUS]]''' - Start Sizecoding on your Atari ST or Amiga.
*'''[[6502 based CPUs]]''' - Commodore 64, Atari XE/XL, Atari Lynx, etc.
*'''[[Z80 based CPUs]]''' - For all your ZX Spectrum, CPC, Gameboy, etc. sizecoding needs

Risc OS on ARM based CPUs

2020-07-11T08:53:00Z

Kuemmel:

== Why ARM and why on RISC OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn RISC PC. All those home computers were run by RISC OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast RISC OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run RISC OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in RISC OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does RISC OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in RISC OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in RISC OS (&8000 is the general start address for executables in RISC OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on RISC OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our RISC OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 RISC OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on RISC OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The RISC OS sound system by j. Lesurf].

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

At the time of writing it doesn't work with Thumb code when the standard trick that is mention above is used to specify the execution address of the intro in the filing system. So for now you would have to skip that and invest 4 bytes at the start of your intro to make it compressible with Codepressor:
<syntaxhighlight lang="gas">adr pc,thumb+1
.thumb
thumb:</syntaxhighlight>
This will trigger Thumb mode manually within your code. <code>adr pc,thumb+1</code> is a pseudo-instruction that tries to produce a single add or sub instruction to load the address, in that case here it'll be assembled to <code>sub pc,pc,#3</code>.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for RISC OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Main Page

2020-07-11T08:49:42Z

Kuemmel:

== Welcome to SizeCoding.org! ==

'''SizeCoding.org is a wiki dedicated to the art of creating very tiny programs for most popular types of CPUs. As sizecoding is also popular on other hardware we recently opened the website for other plaforms as well, check the links below.'''

By "very tiny programs", we mean programs that are '''256 bytes or less in size''', typically created by members of the [https://en.wikipedia.org/wiki/Demoscene demoscene] as a show of programming skill. The size of these tiny programs is measured by their total size in opcode bytes, and are usually presented as executable .COM files to be run in pure DOS, a DOS VM running inside another operating system, or an emulator that can run DOS such as DOSBox.

'''Despite their tiny size, these programs are able to produce amazing graphical displays, playable games, and sometimes music.''' There are even some surprisingly effective programs in under '''16 bytes''', such as [https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ a maze generator in 10 bytes], a [[Paint16b|mouse-driven paint program in 16 bytes]], and an [[M8trix_8b|"Enter the Matrix" screensaver]] in only 8 bytes.

'''The intent of this wiki is to teach x86 assembler programmers the various techniques used to create tiny demoscene intros.''' While these techniques can be used for other applications (boot sectors, BIOS and firmware code, etc.), the information presented here is firmly oriented towards the demoscene. Practicality and common sense are sometimes thrown out the window just to shave a single byte -- consider yourself warned.

This wiki is divided into the following major sections for x86:

*'''[[Getting Started]]''' - What do you need to know before starting your first tinyprog?

*'''[[Techniques|Tips, Tricks, and Techniques]]''' - The meat of the wiki. Lists of small opcodes, default environment settings, size optimization basics, and a ton of random tips.

*'''[[Case Studies]]''' - Analysis of existing award-winning tiny programs, with comments on what choices were made and why.

*'''[[Resources|Additional Resources]]''' - Discussion threads, competitions, repositories, and other external references that can aid you in your quest.

For other platforms check out the sections here:

*'''[[Risc OS on ARM based CPUs]]''' - Create your tiny intro on ARM hardware on Risc OS.
*'''[[Motorola 68k based CPUS]]''' - Start Sizecoding on your Atari ST or Amiga.
*'''[[6502 based CPUs]]''' - Commodore 64, Atari XE/XL, Atari Lynx, etc.
*'''[[Z80 based CPUs]]''' - For all your ZX Spectrum, CPC, Gameboy, etc. sizecoding needs

Main Page

2020-07-11T08:48:42Z

Kuemmel:

== Welcome to SizeCoding.org! ==

'''SizeCoding.org is a wiki dedicated to the art of creating very tiny programs for most popular types of CPUs. As sizecoding is also popular on other hardware we recently opened the website for other plaforms as well, check the links below.'''

By "very tiny programs", we mean programs that are '''256 bytes or less in size''', typically created by members of the [https://en.wikipedia.org/wiki/Demoscene demoscene] as a show of programming skill. The size of these tiny programs is measured by their total size in opcode bytes, and are usually presented as executable .COM files to be run in pure DOS, a DOS VM running inside another operating system, or an emulator that can run DOS such as DOSBox.

'''Despite their tiny size, these programs are able to produce amazing graphical displays, playable games, and sometimes music.''' There are even some surprisingly effective programs in under '''16 bytes''', such as [https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ a maze generator in 10 bytes], a [[Paint16b|mouse-driven paint program in 16 bytes]], and an [[M8trix_8b|"Enter the Matrix" screensaver]] in only 8 bytes.

'''The intent of this wiki is to teach x86 assembler programmers the various techniques used to create tiny demoscene intros.''' While these techniques can be used for other applications (boot sectors, BIOS and firmware code, etc.), the information presented here is firmly oriented towards the demoscene. Practicality and common sense are sometimes thrown out the window just to shave a single byte -- consider yourself warned.

This wiki is divided into the following major sections for x86:

*'''[[Getting Started]]''' - What do you need to know before starting your first tinyprog?

*'''[[Techniques|Tips, Tricks, and Techniques]]''' - The meat of the wiki. Lists of small opcodes, default environment settings, size optimization basics, and a ton of random tips.

*'''[[Case Studies]]''' - Analysis of existing award-winning tiny programs, with comments on what choices were made and why.

*'''[[Resources|Additional Resources]]''' - Discussion threads, competitions, repositories, and other external references that can aid you in your quest.

For other platforms check out the sections here:

*'''[[RISC OS on ARM based CPUs]]''' - Create your tiny intro on ARM hardware on Risc OS.
*'''[[Motorola 68k based CPUS]]''' - Start Sizecoding on your Atari ST or Amiga.
*'''[[6502 based CPUs]]''' - Commodore 64, Atari XE/XL, Atari Lynx, etc.
*'''[[Z80 based CPUs]]''' - For all your ZX Spectrum, CPC, Gameboy, etc. sizecoding needs

Floating-point Opcodes

2020-07-09T11:51:50Z

Kuemmel: FPU trick added

The [https://en.wikipedia.org/wiki/Floating-point_unit FPU] offers a lot of complex and powerful floating-point operations, like <code>SIN</code>, <code>COS</code>, <code>ATAN</code>, <code>SQRT</code>, etc. ([http://www.website.masmforum.com/tutorials/fptute/appen1.htm SIMPLY FPU] by Raymond Filiatreault has a compact overview of all FPU commands for the curious.) Use of the FPU can drastically increase what you can do in a tiny production while simultaneously keeping code size down. All x86 CPUs can use the FPU, although older CPUs (80486sx and earlier) need the FPU physically installed in the FPU socket.

This guide assumes intermediate to advanced-level proficiency with sizecoding.

== FPU Basics ==

Usage and communication with the FPU is quite uncommon and takes a bit to get used to, so we'll start with a simple example. This is what [[Output#Basic_Animation_and_user_interaction|our code example]] looks like originally:

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get column in AH
add ax,di ; offset by framecounter <-- REPLACE THIS WITH FPU CODE
xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

and this is how the code looks if we replace the instruction with FPU code :

<syntaxhighlight lang="nasm">cwd ; "clear" DX for perfect alignment
mov al,0x13
X: int 0x10 ; set video mode AND draw pixel
mov ax,cx ; get "column" in AX

fninit ; init FPU first
mov [si],ax ; write first addend to a memory location
fild word [si] ; F(pu) I(nteger) L(oad)D a WORD from memory location to the FPU stack
mov [si],di ; write second addend to a memory location
fiadd word [si] ; Directly add the word in the memory location to the top FPU stack
fist word [si] ; F(pu) I(nteger) ST(ore) the result into a memory location
mov ax,[si] ; Get the word from the memory location into AX

xor al,ah ; the famous XOR pattern
and al,32+8 ; a more interesting variation of it
mov ah,0x0C ; set subfunction "set pixel" for int 0x10
loop X ; loop 65536 times
inc di ; increment framecounter
in al,0x60 ; check keyboard ...
dec al ; ... for ESC
jnz X ; rinse and repeat
ret ; quit program</syntaxhighlight>

(Obviously that made the program bigger instead of smaller, but the point of this exercise is to illustrate how to work with the FPU.) Looking at our changes, you get a sense of what usual interaction with the FPU is:
# <code>F(N)INIT</code>: Initialize the FPU
# transfer values from CPU registers to memory location(s)
# transfer values from memory location(s) onto FPU stack
# do the actual calculations using the FPU (more on this soon)
# transfer result from the FPU stack into memory location(s)
# transfer result from memory location(s) back into registers

That is a lot of extra code for a single integer addition, but that's a simple example; ''once more complex floating point operations are involved, it starts to pay off.''

== Optimizing with the FPU ==

=== Distance function example ===

For more advanced FPU operation, let's start from scratch with an unoptimized program which plots the distance of each pixel to the screen center as color, in 49 bytes.

[[File:Distance to center example.png|thumb|Distance to center]]

<syntaxhighlight lang="nasm">push 0a000h
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
fninit ; -
; it's useful to comment what's on the
; stack after each FPU operation
; to not get lost ;) start is : empty (-)
X:
xor dx,dx ; reset the high word before division
mov bx,320 ; 320 columns
mov ax,di ; get screen pointer in AX
div bx ; construct X,Y from screen pointer into AX,DX
sub ax,100 ; subtract the origin
sub dx,160 ; = (160,100) ... center of 320x200 screen
mov [si],ax ; move X into a memory location
fild word [si] ; X
fmul st0 ; X²
mov [si],dx ; move Y into a memory location
fild word [si] ; Y X²
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp word [si] ; -
mov ax,[si] ; get the result from memory
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

A few words on this :
* The FPU registers (st0, st1, ...) are organized as a stack. When you load something to the FPU, everything else will be moved one location further away from the top (implicitly!) Some FPU instructions work only on the top, other allow the explicit parametrization with arbitrary FPU registers.
* Depending on what you do, sometimes <code>F(N)INIT</code> can be omitted. Real hardware will refuse to work more often than emulators, but it's always worth the try.
* Accessing memory (size) efficiently can be a real pain. The safest way is to reference absolute memory locations (f.e <code>[1234]</code>) but that's two bytes more per instruction than referencing memory with <code>[BX]</code>, <code>[SI]</code>, <code>[BX+SI]</code>, <code>[BP+DI]</code>, <code>[BP+SI]</code>, <code>[DI]</code> or <code>[BX+DI]</code>. When working with FPU and this ''classic'' approach of FPU communication, you have to design your codeflow to have one or some of these locations available.
* Accessing the memory is always with regard to the segment register <code>DS</code> unless you perform segment overrides. When accessing memory with <code>[BP+??]</code> be aware that the memory is accessed with regard to the segment register <code>SS</code> (see [https://courses.engr.illinois.edu/ece390/books/artofasm/CH04/CH04-2.html#HEADING2-35 Register Indirect Addressing Modes])
* There are a few conventions which help you identify FPU commands. "i" stands for integer (WORD or DWORD), "p" means "pop stack afterwards", so <code>FST</code> means just "store" while <code>FISTP</code> means "store as integer, then pop the stack"

=== Stack addressing, "Rrrolas Trick", alignment optimization, Aspect Ratio ===

Now let's unleash the state of the art sizecoding arsenal onto this, to bring it down to 37 bytes (40 bytes with aspect correction)

[[File:Distant to center optimized.png|thumb|Distance to center : optimized]]

<syntaxhighlight lang="nasm">push 0a000h - 70 ; modified to center to 160,100
aas ; aspect ratio constant part
pop es ; get start of video memory in ES
mov al,0x13 ; switch to video mode 13h
int 0x10 ; 320 * 200 in 256 colors
X:
mov ax,0xCCCD ; perform the famous...
mul di ; ... Rrrola trick =)
sub dh,[si] ; align vertically
pusha ; push all registers on stack
fild word [bx-8] ; X
fmul st0 ; X²
fild word [bx-9] ; Y X²
fmul dword [bx+si] ; aspect ratio correction
fmul st0 ; Y² X²
fadd st0,st1 ; Y²+X²
fsqrt ; R
fistp dword [bx-5] ; -
popa ; pop all registers from stack
stosb ; write to screen (DI) and increment DI
jmp short X ; next pixel</syntaxhighlight>

The resulting image is almost identical to to the former. Let's go through this step by step:

* <code>push 0a000h - 70</code>
Instead of aligning horizontally with <code>sub dx,160</code> we can code this implicitly by moving our segment register ten units - that is 10 * 16 = 160 pixels - to the left (see [https://en.wikipedia.org/wiki/X86_memory_segmentation#Real_mode Real Mode Addressing]). With further multiple subtraction of 20 units - that is 320 pixels, we can shift the visible screen towards the top, to finetune vertical alignment. As long as this shift is no more than 4 lines ''( 65536 / 320 - 200 = 4,8 )'' there is no further visual impact.
* <code>aas</code>
This is the high byte of a constant, placed in a way that <code>[SI]</code> or <code>[BX+SI]</code> resolves to ~1.24 when read as 32bit float. The last byte of segment <code>ES</code> is also of importance. Check yourself with the [http://www.h-schmidt.net/FloatConverter/IEEE754.html IEEE 754 Converter]
* <code>mov ax,0xCCCD</code> & <code>mul di</code> (The "Rrrola trick")
Instead of constructing X and Y from the screen pointer <code>DI</code> with <code>DIV</code> you can get a decent estimation with multiplying the screen pointer with <code>0xCCCD</code> and read X and Y from the 8bit registers <code>DH</code> (+DL as 16bit value) and <code>DL</code> (+AH as 16bit value). The idea is to interpret <code>DI</code> as a kind of 16 bit float in the range <code>[0,1]</code>, from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results in the row before the comma, and again as a kind of a float, the column after the comma. The representation <code>0xCCCD</code> is the nearest rounding of 204,8 * 256 ( = 52428,8 ~ 52429 = 0xCCCD). As long as the 16 bit representations are used, there is no precision loss.
* <code>sub dh,[si]</code>
The instruction at <code>[SI]</code> is <code>push <word></code> and has the opcode <code>0x68</code> which is 104 in decimal. Combined with the fine tuned vertical alignment above ( ~4 lines) this results in (virtually) subtracting 100 for perfect vertical alignment. This is one byte shorter than <code>sub dh,100</code>.
* <code>pusha / popa</code>
Instead of going the ''classical'' way of communicating with the FPU, we push all the registers, read/write values with memory addressing to/from the FPU, then pop all registers again. This works when <code>DS</code> = <code>SS</code> and <code>SP</code> is "close enough" to <code>BX</code> (initially zero and kept that way) to allow <code>[BX+<signed byte>]</code> addressing. It comes with the special benefit of implicit 8bit shifts. One serious drawback is loss of precision, since the registers <code>DL</code> and <code>AH</code> "lose connection" when using <code>PUSHA</code> (see the order of registers : [http://x86.renejeschke.de/html/file_module_x86_id_270.html PUSHA/PUSHAD documentation]
*<code>fild word [bx+<signed byte>]</code> & *<code>fistp dword [bx+<signed byte>]</code>
This is the so called "stack addressing". We assume that <code>BX=0</code> and <code>SP=0xFFFE</code> at start, so we know where the registers are in memory after <code>pusha</code> (AX at [BX-4], CX at [BX-6] etc.). It's important to realize that we work with signed 16 bit values now, in the full range of [-32768,32767]. That is also why we need <code>DWORD</code> when storing the result : <code>sqrt(x²+y²)</code> exceeds the signed 16bit range for quite some value pairs. Note that there are already implicit 8bit shifts (bx-9,bx-5)
*<code>fmul dword [bx+si]</code>
With the "Rrrola" trick above, we have the row number to be 204 at maximum, but also the column can't be greater than 256. This results in a wrong aspect ratio, but it can almost completely be fixed with this two byte instruction (+ one byte for the <code>AAS</code> instruction) : 256 * 1,24 = 317,44 which is quite close to 320. If aspect ratio is of no meaning to the desired effect, this three bytes can be shaved off.

=== The "Tunnel" ===

Now let's add some features:
* extract angle as opposed to the distance and combine both
* reverse divide the distance to create the "tunnel" effect
* animate with smooth steps along the distance
* improve on the colors with subselecting from the standard palette
* quit the program on ESC

This results in the following program with a size of 63 bytes :

[[File:Tunnel effect neontube.png|thumb|tunnel effect neontube]]

<syntaxhighlight lang="nasm">push 0xa000 - 10 - 3 * 20 ; video base - 3.5 lines
or al, 0x13 ; mode 13h = 320 x 200 in 256 colors
pop es ; get aligned video memory base
int 0x10 ; switch videomode
X:
sub dh, [si] ; vertical alignment
pusha ; push all registers on stack
fild word [bx-9] ; fpustack : x
fild word [bx-8] ; fpustack : y x
fpatan ; fpustack : arc
fst st1 ; fpustack : arc arc
fcos ; fpustack : cos(arc) arc
fimul dword [si] ; fpustack : l*cos(arc) arc
fidiv word [bx-8] ; fpustack : l*cos(arc)/x arc
fiadd word [bp+si] ; fpustack : l*cos(arc)/x+offset arc
fistp dword [bx-7] ; fpustack : arc
fimul word [byte si+val] ; fpustack : scaled_arc
fistp word [bx-5] ; fpustack : -
popa ; pop all registers from stack
xor al, cl ; XOR scaled_arc with distance
and al, 16 + 8 + 2 ; sub selecting palette part
stosb ; writing to screen
mov ax, 0xCCCD ; Performing the famous
mul di ; Rrrola trick
jo X ; next frame check
add word [bp+si], byte 23 ; change offset smoothly
in al, 0x60 ; check for ...
dec ax ; ...ESC key
jnz X ; otherwise continue
ret ; quit program
val: dw 6519 ; n = 160 * 256 / pi / 2 ; 0x1977</syntaxhighlight>

Many other tiny tunnel effects have been coded, so it is highly recommended to check out the documented source code of [http://web.archive.org/web/20050216133244/http://www.farb-rausch.de/ryg/tunnel.asm "Constant Evolution" by ryg/Farbrausch] and the [http://www.pouet.net/prod.php?which=29412 "Heart shaped tunnel" from Lord Kelvin], both with a size of 64 bytes. While "Constant Evolution" takes a slightly different route than the example here (''classic'' FPU communication, ''classic'' X Y construction, sqrt(x²+y²) instead of using <code>fcos</code>+<code>fimul</code>), "Heart shaped tunnel" uses no FPU at all.

The takeaways from this example are:

* Loading a constant from the code with some degrees of freedom
<code>fimul dword [si]</code> multiplies with a 32 bit integer dividend for the tunnel effect. The highest byte of this constant points to our code, to the opcode from <code>or al, 0x13</code>. This instruction puts <code>0x13</code> into <code>al</code>, and since there a lot of possibilities to achieve this, there is a direct way of changing the appearance of the tunnel with changing this instruction to one of the following : <code>mov al,0x13</code>, <code>add al,0x13</code>, <code>xor al,0x13</code>, <code>adc al,0x13</code>, <code>sbb al,0xED</code> or <code>sub al,0xED</code>. In this special case, the instruction can also be swapped with <code>pop es</code> to gain a further degree of freedom.

* normal loading of a constant which can't be reused as opcode
Although it's the ultimate goal to not even use a single extra byte for constants, sometimes the required sequence simply does not appear in the code. In this case, a constant is needed to convert the angle from the range [-pi,pi] to the color space in a way that no gaps appear while stepping from 359° to 0°. In the last line at <code>val:</code> the value <code>160</code> in the comment is 32 * 5 where 5 is number of "spiral arms" the tunnel effect has. The 8bit shift (*256) is to increase precision. It turns out that 16bit precision is enough to get a decent "gap closer" for values obtained by <code>fpatan</code>.

* operating directly on an indirect memory location without offset
The location <code>[bp+si]</code> is used as animation variable, while both participatory registers are kept fixed (the value is <code>0x0A??</code> and therefor way above our code). Since we work with 16bit values and the top 8bit are the measurement in pixels, the instruction <code>add word [bp+si], byte 23</code> allows for sub pixel precision in animation, while occupying 3 bytes of space. Depending on the target hardware, this value 23 can be increased/decreased to achieve faster/smoother animation.

* Optimizing the check for the next frame
Normally, there is a check like <code>test di,di</code> with direct consecutive branch necessary. The used approach allows for direct branching after <code>mul di</code> with <code>jo</code>, since the overflow flag is always but twice triggered for a frame. This saves two bytes, but also requires adjustment of the animation constant, because the animation constant is also added twice. A further benefit is that in one of these two cases, <code>AX</code> is zero which save a further byte on the following ESC check (<code>dec ax</code> instead of <code>dec al</code> )

=== Size optimizing the "Tunnel" ===

Now if we abandon all the comfort, alignment, smoothness and convenience, and optimize this straight for size, we end up with a 52 byte version. This does not include the possible exclusion of color tuning (2 bytes), after all the effect is supposed to look at least somewhat appealing ;)

[[File:Neontube 52b optimized.png|thumb|Neontube 52b optimized]]
<syntaxhighlight lang="nasm">mov al,0x13 ; mode 13h = 320 x 200 in 256 colors
int 0x10 ; switch videomode
X:
or al, [bp+si] ; *illusion* - executed ONCE
xor al, 0x68 ; *illusion* - executed ONCE
mov dx, 0x79F ; *illusion* - executed ONCE
pusha ; push all registers on stack
fild word [bx-9] ; x
fild word [bx-8] ; y x
fpatan ; arc
fst st1 ; arc arc
fcos ; cos(arc) arc
fimul dword [si] ; l*cos(arc) arc
fidiv word [bx-8] ; l*cos(arc)/x arc
fistp dword [bx-4] ; arc
fimul word [bx] ; scaled_arc
fistp word [bx-5] ; -
popa ; pop all registers from stack
sub ah, [bp+si] ; animation along distance
xor al, ah ; XOR scaled_arc with distance
and al, 16 + 8 + 4 ; sub palette selection
stosb ; write to screen, advance DI
mov ax, 0xCCCD ; the famous
mul di ; Rrrola trick
jmp short X-1 ; *ODD* jump into "int 0x10"
</syntaxhighlight>

Since this code contains an "odd jump" into the middle of the instruction <code>int 0x10</code> it helps to disassemble the code from address <code>0x103</code> on, until both code pathes realign at <code>pusha</code> :
<syntaxhighlight lang="nasm">adc [bp+si],cl ; decrement framecounter
add dh,[si] ; vertical alignment
push word 0x9FBA ; video base - 3.5 lines
pop es ; get aligned video memory
; continues with "pusha"</syntaxhighlight>

Like before the <code>mul di</code> instruction triggers the overflow flag - and the carry flag - always but twice per frame. <code>CL</code> remains <code>0xFF</code> unchanged from start, so <code>adc [bp+si],cl</code> effectively decrements the framecounter twice per frame.

The dividend for scaling the arc is now taken from the location <code>[bx]</code>, which is <code>0x20CD</code>. Calculating the number of "spirals" backwards from this number (*pi*2/256/32) gives about 6.44 which is close enough to 6.5, so that the visual gap in the top is almost not recognizable - besides from the miscoloring which can be fixed by removing the 16 from <code>and al, 16 + 8 + 4</code>.

It's noteworthy that the location <code>[si]</code> does not contain a good offset anymore, since <code>push <word></code> moved away from the top, to help create *illusion* code that not only realigns soon in the second code path but also does not modify registers and memory environment in a hindering way (only <code>AL</code> and <code>DX</code> are modified)

The takeaway here is to study the modbytes of instructions that are very likely to appear in tiny intros, as well as using their constants as code. <code>int 0x10</code> will almost always be in your code, so there is always <code>adc byte[??], 8bit_reg</code> too in between.

Finally, you might have noticed that these tunnels don't "spin". For the cost of two bytes this can be easily added. <code>add al, [bp+si]</code> before applying XOR in the last example would offset the <code>arc</code> with the framecounter and produce a spinning effect. For a coherent visual experience the sub palette selection must be changed to <code>and al, 8 + 4</code>, too.

== FPU Tricks ==

=== Comparing 2 float numbers on the FPU ===

Sometimes when doing fpu algebra, you need to compare 2 float numbers using the FPU (for example when calculating an intersection between a point and an object).

To do so will take a few steps:
<syntaxhighlight lang="nasm">
fcomp ; compare the contents of ST0 and ST1
fstsw ax ; copy the fpu flags to ax (ah)
sahf ; copy the contens of AH register to the CPU-flags
jb inside ; you can now check the cpu flags and jump accordingly
</syntaxhighlight>

If a Pentium Pro instruction set is available or emulated (Real DOS setups or Dosbox-X), you can also use the FCOMI instruction instead to do the same thing, which saves a few bytes:

<syntaxhighlight lang="nasm">
fcomip
jb inside
</syntaxhighlight>

=== Truncate float numbers / get fractional part ===
May be you would want to have the truncated number of your floating point value for some purpose or you would want the fractional part. In that case an instruction comes in handy that was added quite late to the FPU. It came with the SSE3 insutrction set and is called <code>fisttp</code> (Store Integer with Truncation).

To get the fractional part you can do it like this:
<syntaxhighlight lang="nasm">
fild st0 ;duplicate your number => st0=f, st1=f
fisttp dword[si] ;INT(f) - store truncated value somewhere in memory
fild dword[si] ;load truncated value
fsubp st1,st0 ;calculate f-INT(f)
</syntaxhighlight>
Generally it's shorter and faster than fiddling arount with rounding mode and <code>frndint</code>.

=== Simple Floor Casting ===
Another classic effect that works well with the FPU is a simple Perspective Floor Caster.
While this effect can also be achieved with just CPU code, using the FPU gives a bit finer control over things like camera height and other things.

Here is the basic code for the effect as used in e.g. [https://www.pouet.net/prod.php?which=85681 Rush, by: Marquee Design].

[[File:Fpu_floor.png|thumb]]
<syntaxhighlight lang="nasm">
fninit
fild word [bx-8] ; load y-value
fidiv word [viewheight] ; scalingvalue/height to plane
fabs ; abs(y)
fild word [bx-9] ; x abs(y)
fdiv st1 ; x/abs(y) abs(y)
fistp word [bx-4] ; store U (plane x) to ax
fidivr word [floorval] ; 32767/abs(y)
fist word [bx-6] ; store V (plane y) to cx
</syntaxhighlight>

The following constants are used in the above calculation:
<syntaxhighlight lang="nasm">
floorval dw 32767
viewheight dw 10
</syntaxhighlight>

Needless to say, the code above is simplified and unoptimised or educational purposes.
It can be optimised further using various tricks mentioned above and integrated easily into already existing FPU calculations for example to save space.

Risc OS on ARM based CPUs

2020-07-07T08:59:10Z

Kuemmel: Section on compression added

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our Risc OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Compression ==

Due to the overhead of a decompression-routine, compressing your intro would start making sense from a level of may be 512 Byte and for sure when you aim coding an intro >=1 Kbyte.

Luckily we already have a tool for that. That is the absolute and untyped file compressor called Codepressor originally developed by Pervect/Topix, now updated and maintained by Phlamethrower. Check out this [http://www.phlamethrower.co.uk/riscos/cpress.php Link] to get the latest version. It contains different compression algorithms and will try all of them and choose the best finally.

The usage is quite straight forward. Just let the filer see the application and type in the command line
<code>codepressr <filename_in> <filename_out></code>
to compress your intro. As an example the intro [https://www.pouet.net/prod.php?which=85044 'blury'] was compressed from 966 to 832 Bytes.

At the time of writing it doesn't work with Thumb code when the standard trick that is mention above is used to specify the execution address of the intro in the filing system. So for now you would have to skip that and invest 4 bytes at the start of your intro to make it compressible with Codepressor:
<syntaxhighlight lang="gas">adr pc,thumb+1
.thumb
thumb:</syntaxhighlight>
This will trigger Thumb mode manually within your code. <code>adr pc,thumb+1</code> is a pseudo-instruction that tries to produce a single add or sub instruction to load the address, in that case here it'll be assembled to <code>sub pc,pc,#3</code>.

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-07-06T12:52:45Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

[[File:edgedancer.png]]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

[[File:elsecaller.png]]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our Risc OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

[[File:3dball.png]]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

File:3dball.png

2020-07-06T12:51:36Z

Kuemmel: png version

png version

File:3dball.gif

2020-07-06T12:44:18Z

Kuemmel: 3dball pic

3dball pic

File:Elsecaller.png

2020-07-06T12:43:56Z

Kuemmel: elsecaller pic

elsecaller pic

File:Edgedancer.png

2020-07-06T12:40:11Z

Kuemmel: edgedancer pic

edgedancer pic

Risc OS on ARM based CPUs

2020-07-06T12:29:18Z

Kuemmel: Link Update

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our Risc OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[https://developer.arm.com/documentation/qrc0006/e/ Thumb 16-bit Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0001/m ARM and Thumb-2 Instruction Set Quick Reference Card]

[https://developer.arm.com/documentation/qrc0007/e Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-07-06T12:23:44Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions and their variations (saturating, narrowing, widening,...) is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our Risc OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-07-06T12:22:30Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels (datatype <code>u8</code> = unsgined 8 Bit integer) from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our Risc OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-07-06T12:20:08Z

Kuemmel: VFP/NEON section extended

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (<code>r0...15</code>, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (<code>s0...s31</code>), 32 64-Bit multi purpose or double precision registers for SIMD (<code>d0...d31</code>), and 16 128-Bit multi purpose registers for SIMD (<code>q0...q15</code>). All those registers are mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==
VFP and NEON are basically the FPU and the SIMD (single instruction, multiple data) extension of the ARM instruction set. VFP works with 32 single (32 Bit) and double precision (64 bit) floating point registers (<code>s0...s31</code>,<code>d0...d31</code>).

NEON uses the same register set regarding <code>d0...d31</code> and adds the 128 Bit sized <code>q0...q15</code> registers. It can use and operate with multiple integer data types (8,16,32,64 Bit signed and unsigned) and single precision floating point (32 Bit) numbers. It's also possible to use an indexed register like d0[0], e.g. for multiplying multiple data in a register by a single scalar from another register (like <code>vmul.f32 q0,q1,d4[0]</code> => multiply each of the 4 single floats in q1 by single float d4[0] and place results in q0).

Another feature is to have instructions that saturate the results, which is quite useful when working with colouring. So e.g. <code>vqadd.u8 q0,q1,q2</code> would add 4 true colour RGB pixels from q1 to the ones in q2. If an overflow occurres the value would be saturated to 255.

The pure amount of available NEON instructions is quite huge, make sure to check the links below to read up on that. Like explained before the register set of VFP and NEON and the registers sets themselves are mapped on each other. So modifying <code>s0</code> would result in modifying the low 32 Bits of <code>d0</code> and <code>q0</code>.

Before we can use the VFP/NEON unit within our Risc OS code we need to invest some bytes in requesting a so called VFPContext for initialization. To do so with ARM code that would look like this.

<syntaxhighlight lang="gas">mov r0,#3+(1<<31)
mov r1,#32 //request full set of 32 VFP/NEON registers
mov r2,#0
swi VFPSupport_CreateContext</syntaxhighlight>Further documentation on the SWI VFPSupport_CreateContext can be found [https://www.riscosopen.org/wiki/documentation/show/VFPSupport_CreateContext here]

The same in THUMB-2:
<syntaxhighlight lang="gas">movs r1,#32
lsls r0,r1,#26 //reuse r1
adds r0,r0,#3 //r0=3+(1<<31)
movs r2,#0
movw r10,#0x8ec1
movt r10,#0x5
swi OS_CallASWI //needed due to swi number >0xff</syntaxhighlight>

The major interest on using NEON is speed (for floats and integers) and working with floats in general, not so much size, as like shown above the setup consumes some bytes. If your code doesn't need floats and the speed is good enough there might not be much need for using NEON. You will find also a small amount of parallel arithmetic and saturating capable instructions for normal ARM integer code in the instruction set. But as shown in Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]...that wouldn't be probably possible without NEON in that size/speed.

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-20T19:56:06Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-19T07:15:25Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* 256 colour modes have a full size RGB (8 Bit each value) palette compared to DOS (6 Bit)
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:49:12Z

Kuemmel: /* Code Examples - Simple sizecoding framework and output to screen */

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:47:19Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged)</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:46:47Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 (r3 is only shifted for the add and remains unchanged after)//syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:45:27Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4 without changing r3</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:44:11Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:43:05Z

Kuemmel: More stuff on conditional execution in ARM and THUMB-2

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next instruction. You can continue endlessly with conditional instructions until the code executes an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this by the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0,r1
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0, r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (only partly relevant to tiny intro sizecoding) ? ===
* an FPU (like x87) with trigonometric or logarithmic functions
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:35:11Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
The conditional execution in ARM mode isn't limited to the next intruction. You can basicall continue endlessly to make the following instructions also conditional until you have an instruction that triggers the flags like e.g. <code>cmp</code> or an instruction with the suffix <code>s</code> added like e.g. <code>adds r0,r1,r2</code>.

When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>it</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this with the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0, r1
subgt r0, r0, r1
suble r1, r1, r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0, r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:31:11Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>
When it comes to THUMB mode unfortunately only branches are conditional. But with THUMB-2 the <code>IT</code> instruction was introduced with that up to 4 following instructions can be conditional. Some code from the ARM Information center explains this with the GDC algortithm (Greatest Common Divisor).

ARM (16 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0, r1
subgt r0, r0, r1
suble r1, r1, r0
bne gcd</syntaxhighlight>
THUMB-2 (10 Bytes)
<syntaxhighlight lang="gas">gcd:
cmp r0, r1
ite gt
subgt r0,r0,r1
suble r1,r1,r0
bne gcd</syntaxhighlight>
=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T19:19:29Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsr#4 //if r0>r1 then r0 = r2 + r3>>4</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T12:27:54Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#4 //if r0>r1 then r0 = r2 + r3<<4</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shl eax,4
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T12:15:14Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#4 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shl eax,4
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address stored in the filesystem as an attribute) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T12:12:57Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#4 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shl eax,4
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode for the resulting executable in general you can conveniently set the first Bit of the start address (executeables in Risc OS have a load address and a start address) by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T12:06:17Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#4 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip
mov eax,edx
shl eax,4
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB/THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode in general you can conveniently set the first Bit of the start address by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-18T11:59:46Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#4 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip:
mov eax,edx
shl eax,4
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode in general you can conveniently set the first Bit of the start address by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-17T19:22:28Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#2 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip:
mov eax,edx
shl eax,2
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode in general you can conveniently set the first Bit of the start address by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress...by now check out the source code of Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-17T19:19:22Z

Kuemmel:

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#2 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip:
mov eax,edx
shl eax,2
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode in general you can conveniently set the first Bit of the start address by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-17T19:17:53Z

Kuemmel: Risc OS ByteBeat added

== Why ARM and why on Risc OS ? ==

x86 and CPUs based on ARM architecture are the two major CPU architectures of modern times, the later one especially for any kind of mobile devices. Back in the 80's ARM was founded to power the successor of the BBC Micro. Most popular and known may be is the Acorn Archimedes range (1987) and the Acorn Risc PC. All those home computers were run by Risc OS, a unique operating system for ARM cpu's.

Nowadays due to the work of a few enthusiast Risc OS is still in development and you can run it on popular single-board computers. Especially recommended and cheap is the Raspberry Pi range. So the fastest cpu to run Risc OS natively at the time of writing is an overclocked RPi4 at 2147 Mhz.

Actually I'm not aware if Android or an kind of Linux would be a better platform for sizecoding on ARM hardware. Just proof us wrong and write to us about it.

=== What does ARM offer compared to x86 ? ===
If you come from x86 coding on ARM will be a very different experience, as that architecture never had any inherited obstacles from an 8 or 16 Bit age. It was purely RISC and 32 Bit from the beginning regarding instruction set and register size. Over the years a lot of enhancements took place. In general you got:
* 16 full size 32-Bit registers (r0...15, usually: r13: stack pointer, r14: link register, r15: program counter)
* VFP/NEON(SIMD) units with 32 32-Bit single precision registers (s0...s31), 32 64-Bit multi purpose or double precision registers for SIMD (d0...d31), and 16 128-Bit multi purpose registers for SIMD (q0...q15). All those registers are fully mapped on each other
* THUMB/THUMB-2 instruction set (especially useful regarding sizecoding)

...and of course the single commands in general are very different to x86...some things might be familiar, some are not at all...over the years the ARM instruction set became quite huge. Nowadays there's hardware integer divide, various SIMD approaches in either ARM or NEON instructions. Just regarding the FPU it still lacks trigonometric and other fancy instructions compared to x87. There is a so called FPEmulator in Risc OS for taking care of that, but that's rather slow as implemented by software and not available for THUMB/THUMB-2. By now though it might be an option for e.g. precalc when you use the Basic Assembler from RISC OS.

The size of the instructions is always 4 Bytes, only THUMB offers a limited instruction set with a length of 2 Bytes.

That may sound as a bit of a handicap regarding size coding and for some tasks that is definitely true. For others it's not due to the things even one instruction can do (e.g. conditional execution and shifts for free). The following shows an example:

ARM (8 Bytes)
<syntaxhighlight lang="gas">cmp r0,r1 //compare r0 with r1
addhi r0,r2,r3,lsl#2 //if r0>r1 then r0 = r2 + r3<<2</syntaxhighlight>

x86 (11 Bytes)
<syntaxhighlight lang="NASM">cmp eax,ebx
jna skip:
mov eax,edx
shl eax,2
add eax,ecx
skip:</syntaxhighlight>

=== What does Risc OS offer for sizecoding ? ===
* more or less easy access to common screen modes
* all screen modes have a linear frame buffer, no 16Bit screen banks limit like on DOS
* convenient access to operating system/kernel routines (so called SWI's (SoftWare Interrupt), comparable to 'int' on x86).
* up to date 16-Bit sound system, for e.g. generating bytebeat based stuff
* built in BBC Basic including an Assembler

=== What does it lack (but mostly not relevant to tiny intro sizecoding) ? ===
* no multicore support
* no shader access or any kind of OpenGL or DirectX
* lack of software development in general, so web browsing is there but a bit limited

== Code Examples - Simple sizecoding framework and output to screen ==
So what would a common intro framework look like ? For now we will use the gnu assembler to assemble our code, as the built in BASIC Assembler doesn't support THUMB code.

Before we start with the actual code it's best to define some of the mentioned SWI's for OS interaction by their number. Here's a list of some basic ones.
<syntaxhighlight lang="NASM">.set OS_ScreenMode, 0x65
.set OS_RemoveCursors, 0x36
.set OS_ScreenMode, 0x65
.set OS_ReadVduVariables, 0x31
.set OS_ReadMonotonicTime, 0x42
.set OS_ReadEscapeState, 0x2c
.set OS_Exit, 0x11
.set OS_CallASWI 0x6f
</syntaxhighlight>

So for a basic intro loop in THUMB-2 this would look like

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#0 //reason code to set screen mode by number
movs r1,#13 //screen mode 13 = 320x256 256 colours
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
yloop:
movs r1,#320 //screen x
xloop:
adds r3,r1,r0 //p = x+timer
eors r3,r3,r2 //p = (x+timer) xor y
strb r3,[r7],1 //plot result as byte (with standard palette)
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 52 Bytes.

As you can see for setting the screen mode you can rely on smaller old school modes with up to e.g. 800x600x256 colours by just choosing a mode by a number (listed here: [https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes Screen Modes]). After you set the screen mode you got to read it's start address by the OS_ReadVduVariables, as that is not a fixed address. On one specific device it should work to read that address and finally hardcode this address into your code, but then of course you would be restricted to your device (e.g. a RPI4 shows different results than a RPI3 for the same screen mode).

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85682 Edgedancer]

If you want to go for true colour it's a bit more complex. The probably shortest way is to use the option to kind of upgrade those old school screen modes by a string using reason code 15 of the SWI ([https://www.riscosopen.org/wiki/documentation/show/OS_ScreenMode Check out this link for further information]). That would look like this code snippet:

<syntaxhighlight lang="gas">.syntax unified
.thumb //assemble using thumb mode
movs r0,#15 //reason code to request screen mode by string
adr.n r1,mode_string //pointer to string
swi OS_ScreenMode //set screen mode
adr.n r0,screen_address //address of input block to read screen mode address
movs r1,r0 //address of output block where screen mode address is stored
swi OS_ReadVduVariables //read and write screen mode address from/to blocks

mainloop:
ldr.n r7,screen_address //read screen address
swi OS_ReadMonotonicTime //get OS timer to r0
movs r2,#255 //screen y
ands r0,r0,r2 //get lowest byte of timer
lsls r0,r0,#8 //create 'B' for RGB from timer
yloop:
lsls r4,r2,#16 //create 'R' for RGB from y
orrs r4,r4,r0 //combine 'R' and 'B'
movs r1,#320 //screen x
xloop:
lsrs r3,r1,#1 //x>>1 for 'G' as x>256
orrs r3,r3,r4 //finalize RGB value
stmia r7!,{r3} //store true colour pixel and increment address
subs r1,r1,#1 //dec x
bne xloop
subs r2,r2,#1 //dec y
bge yloop
swi OS_ReadEscapeState //ESC pressed ?
bcc mainloop
swi OS_Exit //if yes exit to OS

.align 2 //align
mode_string:
.string "13 C16M" //screen mode string (terminated by 0) => 13 = 320*256 C16M = true colour
screen_address:
.word 148 //input block to read screen address
.word -1 //request block needs to be terminated by -1</syntaxhighlight>

This assembles to 68 Bytes.

An intro showing that technique is e.g. Exoticorn's [https://www.pouet.net/prod.php?which=85683 Elsecaller]

Another approach is to read the current screen mode, as most users would run in 1920x1080x32Bit anyway and not even set the screen mode, which also makes the intro independent of the resolution:

An intro showing that technique is e.g. Kuemmels's [https://www.pouet.net/prod.php?which=85284 Risc OS 3dball]. In a later upgrade to that intro you can also see the combined use of THUMB-2 and NEON within the code which lead to a reduction in code size from the initial non-THUMB version of around 44 Bytes. For more insights and requirements of the use of VFP/NEON check out the section below.

To trigger the THUMB mode in general you can conveniently set the first Bit of the start address by the following command on the command line in Risc OS (&8000 is the general start address for executables in Risc OS). The best way to do so is to use a batch file for that, as shown in most of the above mentioned intros:

<code>SYS "OS_File",1,"filename",&8000,&8001,,19</code>

Regarding THUMB mode on Risc OS in general there's a small thing to address. A very ancient module has to be removed from the OS, otherwise it crashes your code. By today that bug is still not fixed. The modules names is "SpecialFX" and needs to be removed by "rmkill SpecialFX" on the command line or by any batch file as shown in the intro links from above.

To exit your intro and go back to the desktop you simple use the shown SWI OS_Exit. If you didn't change the mode you got to use e.g. the SWI "OS_NewLine" to re-trigger desktop redraw. Of course all of those can be omitted if your tiny intro compo rules allow you too...

== Code Examples - Using VFP/NEON code ==

...work in progress

== Code Examples - Sound output by interrupt driven bytebeat ==

For basic sound output the principle of a so called timer based bytebeat could be used. For further reference check out this thread on pout
[https://www.pouet.net/topic.php?which=8357&page=1 Experimental music from very short C programs]. I took an example bytebeat from rrrola (shortened by ryg).

To achieve that we need to set up an interrupt handler to take care of a timed output to the systems sound buffer. Here comes a bit of an obstacle. The SWI's for that purpose have a number that exceeds 0xff which would be fine for normall ARM code but not for THUMB. So here we've got to use the <code>SWI OS_CallASWI</code> to call those SWI's indirectly. The SWI number to be called has to be set in r10. As we need 3 different SWI's for that in total (install handler, sample rate, remove handler) and those SWI's are within a short range of numbers we can save some bytes by just add/sub an offset for the other calls. Check out the code here:
<syntaxhighlight lang="gas">.syntax unified
.thumb
//--- set up shared sound interrupt handler ---------------
adr.w r0,soundcode+1 //+1 as code address for interrupt routine needs to be in thumb state also
movs r2,#0 //immediate handler
adr.n r3,soundhandler_title
str r2,[r3] //dummy title string
movw r10,#0xb440
movt r10,#0x6 //install XSharedSound handler (SWI 0x6b440)
swi OS_CallASWI
mov r4,r0 //backup handler number (r0 gets corrupted by SharedSound_SampleRate)
mov r1,#8000*1024 //sample rate *1024
add r10,r10,#6 //XSharedSound_SampleRate (SWI 0x6b446)
swi OS_CallASWI
sub r10,r10,#5 //prepare r10 for XSharedSound_RemoveHandler (SWI 0x6b441) on exit later
//--- main intro loop -------------------------------------
mainloop:
//any graphics code or whatever would be here
swi OS_ReadEscapeState
bcc mainloop
mov r0,r4 //restore handler number
swi OS_CallASWI //Remove XSharedSound handler
swi OS_Exit
//--- interrupt routine/sound generation ------------------
// r1 -> base of buffer, r2 -> end of buffer, r6 = 8.24 fractional step
// ByteBeat formula is = t*(0xca98>>(t>>9&14)&15)|t>>8
soundcode:
push {r0-r7,LR}
lsrs r6,r6,#8 //adjust fractional step
ldr.n r0,soundtimer //t = soundtimer
soundloop:
lsrs r5,r0,#16 //adjust timer for bytebeat
movw r7,#0xca98 //bytebeat multi constant
lsrs r4,r5,#9 //t>>9
and r4,r4,#14 //(t>>9)&14
lsrs r7,r7,r4 //0xca98>>(t>>9)&14
and r7,r7,#15 //(0xca98>>(t>>9)&14)&15
muls r7,r5,r7 //t*((0xca98>>(t>>9)&14)&15)
orr r7,r7,r5,lsr#8 //t*(0xca98>>(t>>9&14)&15)|t>>8
lsls r7,r7,#8 //8Bit => 16Bit sound
orr r7,r7,r7,lsl#16 //mono => stereo copy
stm r1!,{r7} //store sound word
adds r0,r0,r6 //inc timer by fractional step
cmp r1,r2 //check if buffer filled
bne soundloop
adr.n r4,soundtimer
str r0,[r4] //save timer...no pc relative str in Thumb...
pop {r0-r7,PC}
//--- data ----------------------------------------------
.align 2
soundhandler_title:
soundtimer:</syntaxhighlight>
This assembles to 96 Bytes.

There are other ways to do sound on Risc OS, but those were not evaluated at the time of writing. Also BBC Basic has ways to create sounds by note or frequency (Link is [http://www.riscos.com/support/developers/bbcbasic/part2/sound.html here]). Check out the Sound SWI calls in Detail here [https://www.riscosopen.org/wiki/documentation/show/Sound%20SWI%20Calls Sound SWI Calls]. Some further insights on the sound system can be found here [http://jcgl.orpheusweb.co.uk/temp/ROSSDocument.pdf The Risc OS sound system by j. Lesurf].

== Resources ==

=== Links on the OS ===

[https://www.riscosopen.org/content/ RISC OS Open - Home of the current OS version, documentation on the OS (e.g. SWI's) and discussion forum]

[https://www.riscosdev.com/direct/ RISC OS Direct - Easy installation package for Risc OS and all needed sizecoding tools for your Raspberry Pi including !GCC (includes gnu assembler) and !StrongED (most popular text editor)]

=== Links on ARM coding ===

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0006e/QRC0006_UAL16.pdf Thumb 16-bit Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf ARM and Thumb-2 Instruction Set Quick Reference Card]

[http://infocenter.arm.com/help/topic/com.arm.doc.qrc0007e/QRC0007_VFP.pdf Vector Floating Point Instruction Set Quick Reference Card]

[https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf NEON Programmer's Guide]

[http://www.keil.com/support/man/docs/armasm/armasm_dom1361289850039.htm Instruction Set Overview]

[http://community.arm.com/groups/processors/blog/2010/03/17/coding-for-neon--part-1-load-and-stores Coding for NEON - Part 1 - load and stores]

[http://community.arm.com/groups/processors/blog/2010/05/10/coding-for-neon--part-2-dealing-with-leftovers Coding for NEON - Part 2 - dealing with leftovers]

[http://community.arm.com/groups/processors/blog/2010/06/28/coding-for-neon--part-3-matrix-multiplication Coding for NEON - Part 3 - matrix multiplication]

[http://community.arm.com/groups/processors/blog/2010/09/01/coding-for-neon--part-4-shifting-left-and-right Coding for NEON - Part 4 - shifting left and right]

[http://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors Coding for NEON - Part 5 - rearranging vectors]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Condition Codes 1: Condition Flags and Codes]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-2-conditional-execution Condition Codes 2: Conditional Execution]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-3-conditional-execution-in-thumb-2 Condition Codes 3: Conditional Execution in Thumb-2]

[https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-4-floating-point-comparisons-using-vfp Condition Codes 4: Floating-Point Comparisons Using VFP]

Risc OS on ARM based CPUs

2020-06-16T19:34:56Z

Kuemmel: /* Links on the OS */

Risc OS on ARM based CPUs

2020-06-16T19:34:36Z

Kuemmel: /* Links on the OS */

Risc OS on ARM based CPUs

2020-06-16T19:33:25Z

Kuemmel:

Risc OS on ARM based CPUs

2020-06-16T19:31:28Z

Kuemmel:

Risc OS on ARM based CPUs

2020-06-16T17:32:25Z

Kuemmel:

Main Page

2020-06-16T17:24:12Z

Kuemmel:

== Welcome to SizeCoding.org! ==

'''SizeCoding.org is a wiki dedicated to the art of creating very tiny programs for the 80x86 family of CPUs. As sizecoding is also popular on other hardware we recently opened the website for other plaforms as well, check the links below.''' By "very tiny programs", we mean programs that are '''256 bytes or less in size''', typically created by members of the [https://en.wikipedia.org/wiki/Demoscene demoscene] as a show of programming skill. The size of these tiny programs is measured by their total size in opcode bytes, and are usually presented as executable .COM files to be run in pure DOS, a DOS VM running inside another operating system, or an emulator that can run DOS such as DOSBox.

'''Despite their tiny size, these programs are able to produce amazing graphical displays, playable games, and sometimes music.''' There are even some surprisingly effective programs in under '''16 bytes''', such as [https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ a maze generator in 10 bytes], a [[Paint16b|mouse-driven paint program in 16 bytes]], and an [[M8trix_8b|"Enter the Matrix" screensaver]] in only 8 bytes.

'''The intent of this wiki is to teach x86 assembler programmers the various techniques used to create tiny demoscene intros.''' While these techniques can be used for other applications (boot sectors, BIOS and firmware code, etc.), the information presented here is firmly oriented towards the demoscene. Practicality and common sense are sometimes thrown out the window just to shave a single byte -- consider yourself warned.

This wiki is divided into the following major sections for x86:

*'''[[Getting Started]]''' - What do you need to know before starting your first tinyprog?

*'''[[Techniques|Tips, Tricks, and Techniques]]''' - The meat of the wiki. Lists of small opcodes, default environment settings, size optimization basics, and a ton of random tips.

*'''[[Case Studies]]''' - Analysis of existing award-winning tiny programs, with comments on what choices were made and why.

*'''[[Resources|Additional Resources]]''' - Discussion threads, competitions, repositories, and other external references that can aid you in your quest.

For other platforms check out the sections here:

*'''[[Risc OS on ARM based CPUs]]''' - Tired of x86 ? Create your tiny intro on ARM hardware on Risc OS.

Main Page

2020-06-16T17:23:39Z

Kuemmel:

== Welcome to SizeCoding.org! ==

'''SizeCoding.org is a wiki dedicated to the art of creating very tiny programs for the 80x86 family of CPUs. As sizecoding is also popular on other hardware we recently opened the website also for other plaforms, check the links below.''' By "very tiny programs", we mean programs that are '''256 bytes or less in size''', typically created by members of the [https://en.wikipedia.org/wiki/Demoscene demoscene] as a show of programming skill. The size of these tiny programs is measured by their total size in opcode bytes, and are usually presented as executable .COM files to be run in pure DOS, a DOS VM running inside another operating system, or an emulator that can run DOS such as DOSBox.

'''Despite their tiny size, these programs are able to produce amazing graphical displays, playable games, and sometimes music.''' There are even some surprisingly effective programs in under '''16 bytes''', such as [https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ a maze generator in 10 bytes], a [[Paint16b|mouse-driven paint program in 16 bytes]], and an [[M8trix_8b|"Enter the Matrix" screensaver]] in only 8 bytes.

'''The intent of this wiki is to teach x86 assembler programmers the various techniques used to create tiny demoscene intros.''' While these techniques can be used for other applications (boot sectors, BIOS and firmware code, etc.), the information presented here is firmly oriented towards the demoscene. Practicality and common sense are sometimes thrown out the window just to shave a single byte -- consider yourself warned.

This wiki is divided into the following major sections for x86:

*'''[[Getting Started]]''' - What do you need to know before starting your first tinyprog?

*'''[[Techniques|Tips, Tricks, and Techniques]]''' - The meat of the wiki. Lists of small opcodes, default environment settings, size optimization basics, and a ton of random tips.

*'''[[Case Studies]]''' - Analysis of existing award-winning tiny programs, with comments on what choices were made and why.

*'''[[Resources|Additional Resources]]''' - Discussion threads, competitions, repositories, and other external references that can aid you in your quest.

For other platforms check out the sections here:

*'''[[Risc OS on ARM based CPUs]]''' - Tired of x86 ? Create your tiny intro on ARM hardware on Risc OS.

Risc OS on ARM based CPUs

2020-06-16T17:20:12Z

Kuemmel: Added Risc OS section