Addressing the end-of-life of AArch32 (Rev #26)

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

Relevant specifications

DDI0847 – The ARMv8 architecture reference manual (A profile)
DDI0608 – The ARMv9 supplement to DDI0847

Relevant forum threads

No more big 32-bit cores for RISC OS from 2022
What would AArch64 BASIC look like?
ARMv8 support
Secondary relevance: Could you run on an Apple MacMini and RISC OS on hypervisor

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

The opcode under AArch32 has space for a 24 bit immediate value which encodes the call number, for a total of 16M possible unique values, though in practice some of the number space is used to encode other information such as bit 17 holding the non-error returning ‘X’ flag.

The opcode under AArch64 has a reduced size 16 bit immediate value, for a total of 64k possible unique values, which clearly is insufficient to directly encode all of the currently circulated allocations.

Despite the reduced number space, this does encompass the high value OS SWI block from &00 to &1FF. Since the advent of split I+D caches with the StrongARM is has not been convenient to dynamically generate supervisor call opcodes without incurring a cache flush penalty, and the strong recommendation has been to call OS_CallASWI or OS_CallASWIR12 instead. This indirect method, passing the call number via a register which is then passed for despatch via an OS SWI could be used to allow existing SWI allocations to be retained regardless of the instruction set in use.

Programmers in C will be used to using the _swix() and _swi() functions which are already indirect calling methods, and programmers in BASIC use SYS which the interpreter can change to an indirect call as required.

Register widths

Whereas current in AArch32 R0-R15 are 32 bits wide, and therefore can address any location in the 4GB of logical address space, with AArch64 the general purpose register bank can be viewed either as X0-X30 (64 bits each) or W0-W30 (32 bits each). The AArch64 program counter is not directly visible.

Therefore, the AArch32 register bank could be viewed as a subset of the AArch64 register bank, in that parameters passed to a SWI executed as an AArch32 instruction could be losslessly passed to an AArch64 RISC OS kernel for handling by sign or zero extending as appropriate.

Note that in a mixed AArch32/AArch64 system it is not guaranteed whether the narrower 32 bit registers (containing the SWI’s parameters) are zero extended when entering the AArch64 exception handler. The AArch64.CallSupervisor pseudo code in the ARMv8 architecture reference manual is the clearest place to follow this through AArch64.TakeException you get to AArch64.MaybeZeroRegisterUppers where the loop to clear is conditional on ConstrainUnpredictableBool.

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

OS_SpriteOp 52 and OS_SpriteOp 56 and OS_SpriteOp 65

• When a Colour Mapping Descriptor is used in R7 the block passed contains a 32b workspace and function pointer
• Pixel translation tables for 4k/32k/64k colours have a 32b table pointer trapped between two ‘32K.’ or ‘32K+’ guard words

Econet

• Immediate operation Econet_JSR branches to a 32b address received via Econet, optionally to AArch32 code that follows it in the immediate buffer.
• This is true of both the Econet (native) and NetI (over IP)

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

FileCore_MiscOp 6 (Read processed FileCore_Create block)

• Although it returns a copy of the FileCore_Create block which only uses offsets, and therefore is in itself OK assuming the maximum module size isn’t changed, this SWI has turned the 32b offsets into absolute addresses.

FileCore_DiscOp[64]

• Scatter lists are pairs of 32b memory/disc addresses

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

Drag An Object

DragAnObject_Start

• The register block pointed to by R2 (loaded into registers for the renderer) assumes 4B per register

Task Manager

TaskManager_EnumerateTasks

• The returned block for each task includes a 32b pointer to the task name

Territory Manager

Territory_Register

• This SWI expects a table of 32b function pointers to communicate with the territory

DMA Manager

DMA_RegisterChannel

• The 5 word block in R4 contains function pointers to 5 control routines for the channel

DMA_QueueTransfer

• The scatterlist of transfers provided include 32b logical address/length pairs

Colour Picker

ColourPicker_OpenDialogue

• The colour picker block at +4 includes a 32b pointer to the dialogue title

Remote Printer Support

RemotePrinterSupport_EnumerateUSBPrinters?

• The returned linked list of printer descriptors is linked via 32b pointers

Mime Map

MimeMap_Translate?

• For output type MMM_TYPE_DOT_EXTNS the result is an array of pointers to extensions, where the pointers are limited to 32b

SharedSound

SharedSound_InstallHandler

• Passes a fill handler table which contains 2×32b function pointers to fill routines

SharedSound_InstallDriver

• Passes a driver table which contains 6×32b function ti driver routines

PCI

PCI_ReadInfo

• Some returned items (10, 16) are pointers in a 32b address space, the SWI is modelled on Podule_ReadInfo? which is similarly affected

CompressPNG

CompressPNG_Start?

• Parameter items 1 (add text comment), 5 (add palette data), 6 (add transparency data) include 32b pointers to the respective item

URL

URL_ParseURL

• Returns a block of 10×32b pointers at R5 to the elements of the broken down URL

SDIODriver

SDIO_Op

• When bit 26 is set uses a scatter list of pairs of 32b memory/disc addresses, like FileCore

PDumperSupport

PDumperSupport_Claim?/PDumperSupport_Free?/PDumperSupport_Find?

• The pointer to an anchor word in R0 is actually a 32b linked list pointer, though the list format isn’t publically documented so could be changed to a larger pointer with minimal impact

VideoOverlay

VideoOverlay_MapBuffer

• Returns a buffer list in R0 which includes 32b logical addresses in the block

SharedCLibrary

SharedCLibrary_LibInit[_A|_R|Module|APCS_32|ModuleAPCS_32]

• All affected in as far as the stubs supplied in R0 are 32b per entry and encoded as a MOV pc,#0 instruction, which are then changed to LDR pc,table_entry_N after init (OK since AArch64 instructions are 32b as well), but the table_entry_N which follows only has space for 32b branch addresses.

Resolver

Resolver_GetHost? and Resolver_GetHostByName?

• Return a hostent structure containing arrays of pointers, and pointers to the host name which are 32b in size

ATA (aka SATADriver)

ATA_Op

• Uses 32b address/length pair scatter lists in R3, like FileCore

ATA_PacketOp?

• Uses 32b address/length pair scatter lists in R3, like FileCore

USBDriver

USBDriver_RegisterBus

• Uses a table of method pointers in R0 when the host controller registers with the USB stack

USBDriver_InsertTransfer

• Takes a pointer to a usbd_xfer structure which includes a number of 32b pointers

USBDriver_TransferComplete

• Takes a pointer to a usbd_xfer structure which includes a number of 32b pointers

USBDriver_ScheduleSoftInterrupt

• Takes a pointer to a usbd_bus structure which includes a number of 32b pointers

DCI drivers (Ether, PPP, EconetA)

Driver Information Blocks (DIB) include pointers to the name, address, module, and location which are 32b in size and surrounded by other structure members. Pointers to DIBs also appear in registers for Service_DCIFrameTypeFree and Service_DCIDriverStatus.

The transmit SWI also uses an mbuf chain which has 32 bit linked list pointers in it (see notes on MBuf Manager).

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.

* AcornHTTP * AcornSSL * ADFS * ATAPI * BCMSupport * BlendTable * BootFX * Buffer Manager * CDFS, CDFSDriver * ColourTrans * CompressJPEG * DDEUtils * Debugger * DeviceFS * DHCP * Dialler * DOSFS * DragASprite * DrawFile * FilerAction * Filter Manager * Font Manager * Free * Freeway * FrontEnd * FSLock * GPIO * Hourglass * IIC * Internet (Socket) * InverseTable * Joystick * JPEG

* MakePSFont * NetFS * NetMonitor * NetPrint * NetTime * NFS * Parallel Device Driver * PDriver * PDumper * Portable Manager * RamFS * RedrawManager * ResourceFS * RTC * RTSupport * ScreenBlanker * ScreenFX * ScreenModes * SCSIFS, SCSIDriver * SDFS * ShareFS * ShellCLI * SMP * Sound (Level 1), Sound (Level 2) * Sound Control * Squash * SuperSample * TaskWindow * Toolbox * URI * VCHIQ * VFPSupport * ZLib

Changes to service calls

Survey of affected existing service calls

Assuming a register widening solution is adopted as for SWIs, 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 service calls for places where this technique is used in order to see how widespread a problem it might be.

Service_ResourceFSStarting &60

As noted above, a ResourceFS file block includes a 32b offset.

Service_PagesUnsafe &8E

The limitation of a 32b address in the page block already causes a problem with systems whose physical memory map has memory above 4GB. For this Service_PagesUnsafe64 has been introduced.

Service_PagesSafe &8F

The limitation of a 32b address in the page block already causes a problem with systems whose physical memory map has memory above 4GB. For this Service_PagesSafe64 has been introduced.

Service_EnumerateNetworkDrivers &9B

The linked list of DIBs assumes a link pointer fits into a 32b value in memory.

Service_StatisticsEnumerate &A1

The linked list of statistics providers assumes a link pointer fits into a 32b value in memory.

Service_USB &D2

Subreason 1 uses a linked list of USB service call blocks which assume a link pointer fits into a 32b value in memory.

Service_Hardware &D9

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

Service_DrawObjectRender &45540

The render state block pointed to by R2 contains a number of 32b limited pointers.

Service_DrawObjectDeclareFonts &45541

The font state block pointed to by R2 contains a number of 32b limited pointers.

Service calls surveyed where none are affected

The following list service call ranges which have been checked but which don’t have any potential pointer issues. Modules which don’t implement any service calls are not listed here.

* ADFS (&10800) * SCSI (&20100) * Wimp (&400C0) * NetPrint (&40200) * Toolbox (&44EC0) * SDIODriver (&81040) * IIC (&81100) * Window (&82880) * URL (&83E00)

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.

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.

Devices registered via the list in R1 to DeviceFS_Register include a 32b offset to the device name as the first word of the buffer. This limits the string to be within ±2GB of the block.

Toolbox Res files include 32b offsets (to the body, strings, etc) some of which are relocated when the Res file is loaded into absolute addresses.

Mbuf Manager works with mbctl and mbuf structures, these contain both 32b function pointers and linked list pointers.

Execution formats

AIF and DebugAIF

The AIF format has always included a flags word, with a small number of valid values allocated by Acorn or Arm for their use. Following dialogue with Arm there are still plenty of spare flag bits. Therefore, a flag bit can be allocated to denote the code was intended to be run on a 64 bit version of the OS and rejected on 32 bit versions.

In addition, the first few words are expected to be a limited subset of AArch32 instructions (B, BL, MOV) to add confidence to the decision.

Binaries with load/execution addresses

Plain binaries which are *Run and rely on the 32b load and execution addresses held in the RISC OS file attributes would either require a change to the FileCore logical format to support longer attributes, or be unsupported (the use of load/execution addresses has been deprecated for some time), or be limited to loading into the low 4GB of the memory map as presently.

Utilities

Utilities run in User mode after being loaded into the RMA. The kernel currently runs utilities without type checks since in User mode any undefined instruction can only cause inconsequential damage. An optional “32OK” signature appended to the image is used by Aemulor to suppress its emulation, so precedent exists for adding “64OK” to denote the change of instruction set. Heuristics to detect AArch32 opcodes are likely to lead to false matches due to the AArch64 opcodes overlapping.

Relocatable modules

Since RISC OS 5 the module header has included a flags word to provide for future changes. Therefore, a flag bit can be allocated to denote the code was intended to be run on a 64 bit version of the OS, rejected on 32 bit versions.

In addition, the first few words are expected to be a limited subset of AArch32 instructions (B, BL, MOV) to add confidence to the decision.

Podule loader

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.

Implementation progress

Phase	Status	Completion	Latest updates
Conceptual design	In progress	5%	10-Apr-2021 Document updated (see history) 01-Aug-2021 Document updated (see history) 18-Apr-2022 Document updated (see history) 19-May-2022 Document updated (see history)
Mock ups/visualisation	-	-	-
Prototype coding	-	-	-
Final implementation	-	-	-
Testing/integration	-	-	-

Document history

v1.00 – 10-Apr-2021

• Outline added

v1.01 – 01-Aug-2021

• SWI and service call sections expanded

v1.02 – 18-Apr-2022

• Links to ARM ARM and most relevant forum threads added
• Notes on register widths and SWI immediate constants added
• Section headings for executable formats added (and moved podule loaders into it)

v1.03 – 19-May-2022

• Expanded the executable formats section