RISC OS

and the 26-bit question

What's the problem? (a brief history)

With this arrangement, it was possible to have a 26-bit address space, capable of accessing up to 64MBytes of memory. At the time, this was considered a lot, but with the advent of the ARM6, memory had become a much cheaper commodity, and so a 32-bit mode was introduced, with a separate register to store the processor flags in. Existing applications could still run because the processor could be put into a special 26-bit mode, where the program counter reflected the processor status bits, as in the ARM 2.

Since RISC OS uses the 26-bit program counter, applications also use this mode of operation, as RISC OS does not support any kind of mode switching. Only the FIRQ vector operates in 32-bit mode.

As 32-bit mode is generally more desireable (you get up to 4GBytes of memory space), future processors will not have the 26-bit mode as an option. This means that RISC OS will not work on the future processors.

What's the solutions

1. Use another OS
   This would mean that the current applications would not run on the new OS, and development for RISC OS would just dwindle.
2. Rewrite RISC OS
   This would be a mammoth job - and the existing applications would have to be rewritten (or possibly just recompiled).
3. Create some code convertor
   This would convert 26-bit applications into 32-bit applications. There are some problems with this, as discussed below.
4. Emulate 26-bit operation
   This would be slow, but as processors get faster, the emulation speed would increase.
5. Have two processors
   There would be one fast processor which would perform 32-bit mode operations, and one slower processor that could do some 32-bit mode operations, but also 26-bit mode operations. This would increase the cost of machines, and timing would have to be carefully judged, but it is not impossible. This is not discussed here, but can be later on...

A code convertor

Consider the ARM instruction :
  MOVS   pc,lr
This becomes the hexadecimal sequence 0xE1B0F00E. If an automatic convertor saw this instruction, it would convert it into whatever instruction performed the same function as that when it was running under 26-bit (a possible method is discussed below).

Now, if you had a block of raw data, and one of the words in the raw data just so happened to be 0xE1B0F00E, then that instruction would also be changed.

There is the possibility of checking around that instruction, to see if it looks like it is code, but even that can fail:

init
  STMFD  r13!,{r14}
  MOV    r0,#0
  LDR    r1,count
loop
  BL     debug_routine
  SUBS   r1,r1,#1
  BPL    loop
  LDMFD  r13!,{pc}^
count
  DCD    128
debug_routine
 [ debug=1
  SWI    XDebug_Code
 ]
  MOVS   pc,lr
data
  DCD    0

  ANDEQ   r0,r0,r0,LSL#1
  MOVS    pc,lr
  ANDEQ   r0,r0,r0

jump_table
  DCD    t_code1-t_start
  DCD    t_code2-t_start
init
  ADR    r0,jump_table		; r0 is pointer to the vector table
  ADR	 r1,t_start		; r1 is the pointer to the code start
  MOV    r2,#1			; r2 is the vector number
  BL	 jump_vector
; ...
jump_vector
  STMFD  r13!,{r14}
  LDR	 r0,[r0,r2,LSL#2] 	; read the vector offset
  MOV    lr,pc			; 'Fake' a BL-type instruction
  ADD	 pc,r0,r1		; and jump to it
vector_return			; This is where the vector returns
  MOVVC  r0,#0                  ; Clear r0 if no error
  LDMFD	 r13!,{pc}^
; ...
t_start
; ...
data1
  DCD	 0
t_code2
  MOVS   pc,lr
data2
  DCD	 0
;...

The emulation option

This solution is to emulate 26-bit mode from within a 32-bit mode. There are two ways of doing this, one is a standard emulation, the other I'm calling the "Code Lookahead Optimal Emulator" (or CLOE), which will be discussed later.

In standard emulation, the processor would 'pretend' to have 15 registers, and one program counter. Some of these may have a direct relationship with the actual registers (ie. they would not be virtual registers), but others may be virtual registers - the program counter being one of those.

For each instruction, the emulator would work out what the instruction did, and would perform it on its set of registers. This would be quite slow (it would be good performance if a 20:1 ratio could be achieved), but the 26-bit programs would work. When a SWI is called, control is passed from the emulator to the OS, and when the SWI returns, the emulator resumes. However, parts of the OS may still be 26-bit and hence use the emulator...

Code Lookahead Optimal Emulator

init
  MOV	 r0,#0
  MOV	 r1,#8
  MOV	 r7,#32
loop
  ADR    r2,text
  BL	 print_text
  SUBS   r7,r7,#1
  BGT	 loop
  SWI	 XOS_Exit
print_text
  STMFD  r13!,{r0-r2,lr}
  MOV	 r0,r2
  SWI	 XOS_Write0
  LDMFD	 r13!,{r0-r2,pc}^

• Branch
• Branch and link
• Any instruction which reads the PC's status bits
• Any instruction which modifies the PC
• One of the CLOE SWI calls
• Any SWI that would cause the program to exit

init
  MOV	 r0,#0
  MOV	 r1,#8
  MOV	 r7,#32
loop
  ADR    r2,text
  SWI    CLOE_branch_link	; This is the new instruction
;  BL     print_text		; This was there
  SUBS   r7,r7,#1
  BGT	 loop
  SWI	 XOS_Exit
print_text
  STMFD  r13!,{r0-r2,lr}
  MOV	 r0,r2
  SWI	 XOS_Write0
  LDMFD	 r13!,{r0-r2,pc}^

CLOE then looks up the original instruction, and then decides that the following needs to take place:

• R14 becomes the old program counter, with the status register
• The program counter becomes the location of print_text;

init
  MOV	 r0,#0
  MOV	 r1,#8
  MOV	 r7,#32
loop
  ADR    r2,text
  SWI    CLOE_branch_link
  SUBS   r7,r7,#1
  BGT	 loop
  SWI	 XOS_Exit
print_text
  STMFD  r13!,{r0-r2,lr}
  MOV	 r0,r2
  SWI	 XOS_Write0
  SWI    CLOE_pull_stack	; Another new instruction
;  LDMFD  r13!,{r0-r2,pc}^	; This was the old one

init
  MOV	 r0,#0
  MOV	 r1,#8
  MOV	 r7,#32
loop
  ADR    r2,text
  SWI    CLOE_branch_link
  SUBS   r7,r7,#1
  SWI    CLOE_branch		; Note that it's not SWIGT
;  BGT    loop                  ; This is the old instruction
  SWI	 XOS_Exit
print_text
  STMFD  r13!,{r0-r2,lr}
  MOV	 r0,r2
  SWI	 XOS_Write0
  SWI    CLOE_pull_stack

After the final CLOE_branch has failed, CLOE recognises SWI XOS_Exit, and this would return back to the 32-bit OS.

There is one problem with CLOE - code which checks itself against modification. This would have to be addressed...

OS considerations

There are four main ways ARM code can get executed:

1. Applications (filetype 0xff8)
2. Utilities (filetype 0xffc)
3. Relocatable modules (filetype 0xffa)
4. Vectors (hardware and software)

In order to allow 32-bit operations of the OS, the kernel would have to be written in 32-bit, and switch between 32-bit and 26-bit modes on the processor. To distinguish between 26-bit versions of the above, and 32-bit versions, different file-types/SWIs could be used:

1. App32
2. Util32
3. RMA32
   *RMLoad32 etc.
4. SWI XOS_Claim32, XOS_CallAfter32 etc.

Finally...