Basic internals

I’m not really sure what Richard’s trying to achieve here. Here’s some background:

On the old architecture 2 ARMs on which RISC OS was originally developed, all addresses (code and data) were only 26 bits wide, so there were only 2^24 possible word-aligned addresses. Addresses of 64 MB (&04000000) or above simply weren’t valid. When the B and BL instructions were defined, they were allocated 24 bits to specify the address, meaning that you could branch anywhere in the entire address space. These could have just been the absolute address of the destination, but with some forethought, Acorn chose to encode the address as an offset from the current program counter – making the (then far-off) transition to a 32-bit address space much easier. To avoid having to generate exceptions from a B or BL instruction, and to allow all 2^24 encodings to do something useful whatever address you start from, the offset did have a modulo 2^26 applied to it.

On 32-bit ARMs, B and BL are subtly different. Clearly, when there are 2^30 possible destination words, they won’t fit into the available 24 bits in the instructions any more. Instead of the offset being added modulo-2^26 to the PC, it is instead treated as a signed integer, sign-extended to 32 bits, and then added to the 32-bit PC.

As you can see, therefore, the change to how BASIC processes the target address for a B or BL has changed to match the operation of the B or BL instruction. RISC OS 5 is a 32-bit OS, so it makes sense for it to treat address arguments to B or BL instructions with 32-bit semantics.

It sounds as though you’re asking for a SWI to change BASIC’s behaviour back to 26-bit semantics for B and BL. My first reaction is that it feels out of place: BASIC has had many extensions over the years, and none of them have been achieved via SWIs. Further, it’s unclear to me how you would identify which instance of BASIC you wish the option to apply to – I hope you’re not suggesting it to be a system-wide setting.

I also don’t understand what it is that you’re trying to achieve. It sounds like you are trying to give certain destination addresses special meanings – but all possible settings of the offset field in a B or BL instruction have always been valid instructions (in both 26-bit and 32-bit modes, if you branch off the top or bottom of the address space, the modulo 2^26 or 2^32 respectively gives you a valid address).

On top of this, if you really did want to achieve what “BL somewhere” used to do, you could always write

EQUD &EB000000 + (((somewhere-P%-8) >>> 2) AND &FFFFFF)

Assuming you are trying to implement some form of dynamic linking, I think it would be informative to investigate how the C library stubs had to change for 32-bit compatibility. In 26-bit days, the stubs could implement branches from the application slot to the SharedCLibrary by use of a table of BL instructions. In the 32-bit world, this technique no longer works in general, since the SharedCLibrary is in ROM at &FCxxxxxx, and applications are down at &0xxxxxxx, beyond the 32 MB range of B and BL. Instead, the stubs now use a pair of tables of words: the first contain

LDR pc, [pc, #size_of_table-8]

Hi Ben, what I’m trying to do is to get an old riscos 5 module which started its life as an Arthur module (ros 2,3 on the way) to work in a supportable way so that I can build a lot of old apps without having to modify the sources before 32 biting them – as I want to ensure the build process produces the same code as when it was originally built and as I change it. It was converted to ros 5.x in 2003/2004 and worked correctly then. The code sequence mentioned earlier which checks the range has broken the primary function. If you want more details my emal address is riscos_basic (at) rknet (dot) demon (dot) co (dot) uk. As I don’t want to give details in the open.
I am aware of the progression of the arm instruction set – the simplest solution to my problem would be for the basic range check to be modified to -32mb to +64mb or even -32mb to +32mb & +60mb to +64mb. If this check was system wide while the basic file was assembling (as each session has a start & end command) the chance of an issue is ~0 as we managed without the check for more than 20years.