Norcroft 64

I think the most realistic approach, given our limited resources, is 2.

That’s very true, but if ROOL is set on supporting AArch64, it would be better to restrict the scope to just supporting alternate architectures, given that introducing a 64-bit address space doubles the complexity for application authors without offering much benefit.

It takes about two seconds further thought to realise that this means waving goodbye to the entire existing API (how do you do SWI on a machine that may not have such a thing, and/or different registers?), and with it, pretty much all software.

This feels like something that would only be an issue for calling SWIs in AArch64 assembler programs. For C and BASIC, the change in how SWIs are called would be hidden behind the standard library functions, similarly to how syscall works on Linux.

True, but look at it like this: Would developers be expected to supply multiple variants of all applications for x86 and ARM machines?

The question I probably should have asked is “Will the ARM32 emulator be supplied as a core operating system component, or will it be a third-party product like Aemulor?” Because if it isn’t guaranteed, then it’ll be necessary to provide builds of every application for every supported application to ensure that it’ll work out of the box. This is plausible on Linux because building from source is commonplace and pre-built components are supplied by the distro maintainers and not the authors, but neither of those really apply to RISC OS.

Is it possible to have a 32/64 bit neutral program?

It is, you are hard pressed to know if you are using 32 or 64 bit Python on Linux or Windows. Python can use a pickling format for saving data which can read it back correctly even on a different architecture, similar to BBC BASIC’s PRINT# and INPUT# which could be made to be 32/64 aware (it can already handle float conversion between the 5 byte and 8 byte variants). Where things would fall down for BASIC is all programs directly accesses OS APIs via SWI calls which are strictly 32 bit only, where as Python always interfaces with the OS via function calls in to modules, variants of which take care of the architectural differences. BASIC could emulate 32 bit calls on 64 bit, in the same way the 8 bit MOS CALLs are emulated on RISC OS, but that’s not 32/64 bit neutral and will be a barrier to moving to 64 bit native (as if there weren’t enough already).