Addressing the end-of-life of AArch32 (Rev #9, changes)

Showing changes from revision #8 to #9: Added | Removed | Changed

Goals

The release in 2011 of architecture ARMv8 added a whole new instruction set called AArch64 with wider 64b register bank, and renamed what was previously referred to as the ARM instruction set (which RISC OS uses) as AArch32. The AArch64 instructions are not binary compatible with the older ones.

To date, the ARMv8 targets RISC OS supports have been fortunate in still containing an implementation of AArch32 for backwards compatibility, allowing it to run and entirely ignoring the AArch64 aspects. As at 2020 it was becoming clear that Arm intended to wind down ARMv7 and earlier (fewer than 50% of the cores available to license would run that way) to focus on their ARMv8 offerings, of which many dropped AArch32 support entirely.

In April 2021 the ARMv9 architecture was announced with AArch32 relegated to being a license option, in much the same way that 26 bit mode became an option in ARMv4 rarely taken up.

This proposal identifies aspects of RISC OS that will require attention in order to migrate away from AArch32, to help making design decisions, and ultimately a route to implementing changes to ensure there are chips in future to run on.

Existing documentation

Terminology

The AArch32 is the family of instructions with 32 bit wide integer registers addressing up to 2 ³² bytes of memory, and also includes the 26 bit addressing mode too.
The AArch64 is the family of instructions with 64 bit wide integer registers addressing up to 2 ⁶⁴ bytes of memory.

Detail

Changes to SWIs

Reduction in SWI number space

Register widths

Survey of affected existing SWIs

Assuming a register widening solution is adopted, the only places where the size of a pointer is of concern is where the pointer is passed in via a parameter block held in memory. This section surveys the core module SWIs for places where this technique is used in order to see how widespread a problem it might be.

OS (Kernel and FileSwitch)

OS_Word 0 (Read line)

• Subreason has 2 byte pointer to the input buffer. This SWI is already of limited use on 32b memory map as the buffer must reside between &8000 and &FFFF
• No changes proposed

OS_Word 16? (Econet transmit)

• Has (unaligned!) 4 byte pointers to start/end of data
• Currently translated by BBCEconet into the corresponding Econet SWIs

OS_Word 17? (Econet open or receive)

• Has (unaligned!) 4 byte pointers to start/end of data
• Currently translated by BBCEconet into the corresponding Econet SWIs

OS_Word 21 (Define pointer shape)

• Has 4 byte pointer to pointer shape data

OS_Word 22 (Write screen base address)

• Has 4 byte pointer to screen

OS_FSControl 26 (Copy objects)

• Optional information descriptor in R8 has 4 byte pointer to a buffer

OS_ChangeEnvironment handler 6 (Error handler)

• The block has a 32b PC at offset 0

OS_ChangeEnvironment handler 7 (Callback handler)

• The block has space for 16×32b register dump

OS_ChangeEnvironment handler 8 (BreakPoint handler)

• The block has space for 16×32b register dump

OS_ReadArgs

• The output buffer uses 32b pointers to parsed args

OS_DelinkApplication and OS_RelinkApplication

• Vector buffer uses 12 bytes per vector
• The format is opaque to the caller but internally the address of the vector routines are stored as 3×4 byte parameters

OS_HeapSort[32]

• Pointer arrays for sort type >= 2 are 32b each

OS_ReadMemMapEntries and OS_SetMemMapEntries and OS_FindMemMapEntries

• The logical address in the returned table is 32b

OS_Memory 0 (General page block operations)

• The page block uses 32b logical address

OS_IICOp

• Block word 1 is a pointer to the buffer to transfer, but is 32b

OS_Hardware

• The HAL device descriptors include several absolute function pointers and pointers to description strings which are 32b

Econet

Immediate operation Econet_JSR branches to a 32b address received via Econet, optionally to AArch32 code that follows it in the immediate buffer.

Window Manager

Wimp_AutoScroll

• The state change handler at block + 24 uses a 32b function pointer to a routine

Wimp_DragBox

• Drag types 8-11 have 32b function pointers to user routines at block + 40 onwards

Wimp_Poll 13 (Pollword non-zero)

• The poll block includes a 32b pointer to the pollword at block + 0

Wimp icon blocks include 32b pointers to sprite areas or validation strings overloaded with the 12 byte icon data.
Wimp menu blocks can include a 32b pointer to a submenu at offset +4 of the menu item data.

Sound (Level 0)

Sound_Configure

• The first 4 words of the Channel Handler (R3) are absolute pointers to tables and routines
• The first word of the Scheduler (R4) is a pointer to the scheduler code

Podule Manager

Podule_ReadInfo?

• Some returned quantities (1, 4, 8, 9, 13, 14, 15, 18, 19, 20, 23, 24, 25, 29) are pointers in a 32b address space

FPEmulator

FPEmulator_Abort

• The register dump pointed to by the returned R0 assumes a 32b integer register set.

FileCore

Unsure – FileCore_MiscOpTODO 6 (Read processed FileCore_Create block)

Draw

Draw path block code 1 is a 32b continuation path block pointer. There are plenty of spare code numbers to assign a new one for 64b pointers.

MessageTrans

MessageTrans_MakeMenus

• A 32b submenu pointer appears in the menu block as noted for the Window Manager’s menu blocks

Extension modules where no SWIs surveyed are affected

The following list modules which have been checked but whose SWIs don’t have any potential pointer issues. Modules which don’t implement any SWIs, such as application modules, are not listed here.

• IIC
• NetPrint
• ADFS, RamFS, NetFS, NFS, ResourceFS
• Debugger
• ShellCLI
• Hourglass
• SuperSample
• FilerAction
• Sound (Level 1), Sound (Level 2)
• Font Manager
• ColourTrans
• SCSIFS, SCSIDriver
• CDFS, CDFSDriver
• PDumper
• Internet (Socket)
• DragASprite
• Filter Manager
• DDEUtils
• Squash
• Parallel Device Driver

Implications on other in-memory formats

The SWIs OS_File and OS_GBPB include some subreasons which deal with load and execution addresses. These are currently 32b quantities, albeit deprecated in use. Various places store these as 32b quantities for example: in the extended attributes of a ZIP file, in file server messages, in the directory entries of FileCore discs.

The SWI OS_FSControl 12 (Add FS) and OS_FSControl 35 (Add image FS) pass a pointer to a FileSwitch FS Information Block which includes 32b offsets to functions to implement a filing system. Provided modules are not expanded beyond their existing maximum size of 64MB these 32b offsets will suffice because they are relative to the module base address.

The SWI OS_SpriteOp doesn’t make use of absolute addresses in memory. Provided sprites are not expanded beyond their existing maximum size of 2GB these 32b offsets will suffice because they are relative to the sprite area base.

Podule loaders have 4xAArch32 instructions and an optional “32OK” signature at the start. Since AArch64 instructions are also 32b in size, and the signature could be changed, should there be an ARMv8+ machine with a podule bus, this can be accommodated.

The 4 word MessageTrans block is opaque to the caller, so while it may contain a pointer, its layout could be changed without impacting clients.

The SWI ResourceFS_RegisterFiles includes a block with a 32b offset to the next item to add in the chain, however that still allows blocks to be kept ±2GB apart.

Changes to service calls

Document history

v1.00 – 10-Apr-2021

• Outline added