Linux Port

Aarch32 is supported in the application layer (EL0)
- so the 32-bit code is running natively..

SWIs are trapped and re-directed..

I see…so if future ARM chips will drop that Aarch32 application layer support the apps won’t run anymore at all with the Linux Port or an emulation layer will jump in ?

When there is no Aarch32, QEmu is used so will run anywhere that can run QEmu.

In the meantime, work could be done to improve performance of QEmu

and also work done to port RISC OS over to 64-bits…. if ABI ILP32 is used for c code…

Something like https://wiki.debian.org/Arm64ilp32Port

I used ILP32 for something a long time ago, can’t remember for the life of me what, but I’m not sure what advantage it would bring to running RISC OS under QEmu.

It would allow any RISC OS C code to be compiled into aarch64, but keeping the same pointer size

I think it should be possible to cross-assemble the 32-bit asm into 64-bit asm using some sort of pre-processor…
- made easier by keeping pointers 32-bit

Not saying it wouldn’t need (a lot of) work
- but it does seem like a way to get to aarch64 RISC OS

So, you end up with something that can run on a 64-bit only CPU, w/o using QEmu
- so, should be faster..

(but is restricted to 32-bit addressing – which I doubt would be a practical restriction)

I think it should be possible to cross-assemble the 32-bit asm into 64-bit asm using some sort of pre-processor…

I’m far from convinced this is even theoretically possible, short of said pre-processor using some pretty clever AI to divine the purpose of each section of code and then recreate the function using the different instruction set. That clever AI is certainly beyond my capabilities. Divining the purpose of sections of code is not beyond me, nor I’m sure beyond others who could do it more quickly than I could – but the volume of such code is far too great for me or any likely team.

Even if such a project were feasible, it would surely be better to convert the code to C (or some other higher level language) than to any particular assembly language.

Well, I think it’s not as bad as all that…

- the Arm64 has 31 (ish) 64-bit registers and the Arm32 15 (ish) 32-bit registers…
- so, you can map the Arm32 ones into the Arm64 regs more or less directly
- handling PC appropriately..

SWIs would be handled though a vector table probably..

Many of the instructions have a fairly straight forward mapping from Arm32 to Arm64
- and conditional Arm32 instructions could be parsed into a separate equivalents

Anyway, it’s what binary JIT compilers do on-the-fly
- so, it must also be possible from the source assembler…

it would surely be better to convert the code to C

So very much this. If we translate assembler to assembler, we’d be needing to fiddle every time the underlying architecture changes…in case nobody has noticed 😋, ARM changes stuff in backwards breaking ways – this isn’t the x86 world, your latest ARMv9 chip doesn’t boot up thinking it’s an 8MHz ARM2…

I agree, a re-write in C would be better….

but if you were meaning a translation from Arm32 into C equivalent statements, then I agree, that could also work, even if the code might be horrible to look at…
- and the compiler would then have job of optimizing the register mapping etc..

I did ask ChatGPT to have a go and it did a fairly reasonable job (to my untrained eye!)

As a quick trial, I asked ChatGPT to have a go at some asm from the RISC OS Basic:

Original:

FNTRC   TST     R5,#&80
        BNE     ESCAPE
        TST     R5,#&8000
        MOVEQ   PC,R14
        LDR     R5,[ARGP,#TRCNUM]
        TST     R5,#TFP                ;check proc/fn trace bit
        MOVEQ   PC,R14
        STMFD   SP!,{R0,R4,R14}
        LDR     R0,[ARGP,#TRACEFILE]
        CMP     R0,#0
        BLEQ    TRCSTART
        TEQ     R10,#TPROC
        BNE     FNTRC1
        MOV     R0,#"P"
        BL      CHOUTTRACE
        MOV     R0,#"R"
        BL      CHOUTTRACE
        MOV     R0,#"O"
        BL      CHOUTTRACE
        MOV     R0,#"C"
        B       FNTRC2
FNTRC1  MOV     R0,#"F"
        BL      CHOUTTRACE
        MOV     R0,#"N"
FNTRC2  BL      CHOUTTRACE
        MOV     R0,R3
        BL      CHOUTTRACE
FNTRC3  TEQ     R4,AELINE
        BEQ     FNTRC4
        LDRB    R0,[R4],#1
        BL      CHOUTTRACE
        B       FNTRC3
FNTRC4  TEQ     R10,#TPROC
        BL      TRCEND
        LDMFD   SP!,{R0,R4,PC}

(from https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/BASIC/-/blob/master/s/Funct)

ChatGPT’s transliteration:

FNTRC   TST     W5, #0x80
        B.NE    ESCAPE
        TST     W5, #0x8000
        CSEL    PC, X30, PC, EQ  ; Conditional select
        LDR     W5, [XARGP, #TRCNUM]
        TST     W5, #TFP
        CSEL    PC, X30, PC, EQ
        STP     X0, X4, [SP, #-16]!
        STP     X14, XZr, [SP, #-16]!  ; Store link register
        LDR     X0, [XARGP, #TRACEFILE]
        CMP     W0, #0
        B.LE    TRCSTART
        TST     W10, #TPROC
        B.NE    FNTRC1
        MOV     W0, #'P'
        BL      CHOUTTRACE
        MOV     W0, #'R'
        BL      CHOUTTRACE
        MOV     W0, #'O'
        BL      CHOUTTRACE
        MOV     W0, #'C'
        B       FNTRC2
FNTRC1  MOV     W0, #'F'
        BL      CHOUTTRACE
        MOV     W0, #'N'
FNTRC2  BL      CHOUTTRACE
        MOV     X0, X3
        BL      CHOUTTRACE
FNTRC3  TST     W4, AELINE
        B.EQ    FNTRC4
        LDRB    W0, [X4], #1
        BL      CHOUTTRACE
        B       FNTRC3
FNTRC4  TST     W10, #TPROC
        BL      TRCEND
        LDP     X0, X4, [SP], #16
        LDP     X14, XZr, [SP], #16   ; Load link register
        RET

Points to note:

Not that I think ChatGPT can be relied upon, but it can give some useful info and ideas about how to handle various issues..

Anything that can confuse TEQ with TST needs to go in the bin!

it can give some useful info and ideas about how to handle various issues

On the contrary, what it looks as though it does is fix the easy parts (possibly correctly, I’ve not checked), and leaves the parts that require an understanding of what’s going on at a higher level of abstraction in a complete mess. Which is exactly the parts that I can’t see how to write an automatic translator for too.

I think the required preprocessor here is a human.

I think the required preprocessor here is a human.

My thunk almost exactly. Quite a few very patient humans more like?

Anything that can confuse TEQ with TST needs to go in the bin!

Fair enough! But if you were writing a parser, it would just use the right instr, right?

On the contrary, what it looks as though it does is fix the easy parts (possibly correctly, I’ve not checked), and leaves the parts that require an understanding of what’s going on at a higher level of abstraction in a complete mess. Which is exactly the parts that I can’t see how to write an automatic translator for too.

In this example, which bits of higher level abstraction are going astray?

I’m not proposing using ChatGPT by the way.. just using it to show the equivalence of (many) ARM32/ARM64 instrs…
- and possibly highlight problem areas…
(for my better understanding thereupon)

it would just use the write instr, right?

Where there’s a right instruction, of course you’d use it. Often you’d need two or more instructions – and unless you’re going to produce very inefficient code, even more often you’d want to spot where you could merge two or more instructions into one or two. That’s nasty enough.

The thing that would worry me most is spotting where there are implicit addresses that you’d only know about if you could see what the original author of the code wrote, that just isn’t there in a disassembly.

The thing that would worry me most is spotting where there are implicit addresses that you’d only know about if you could see what the original author of the code wrote, that just isn’t there in a disassembly.

Yes, but I’m suggesting translating from the Source…

BASIC is peculiar in the RISC OS source for its lack of use of macros, being a Sophie thing. We used macros far more extensively elsewhere.

How does that help or hinder the translation process?
- I think it just means you need to get the macros translated to arm64 correctly..

The RPi 5 overclocks quite well. Runs stable @2.9GHz.

Compiles a Rpi rom in about 3mins.

HAL-based system (Linux HAL PSR Manipulation) tested at Thu,02 Nov 2023.18:10:37
Filing system: IXFS$.HardDisc4.Public.benchmarks
Graphics Resoloution: 1920x1080, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                  8640991    4858%
Memory - Multiple register transfer                       168561  104050%
Rectangle Copy - Graphics acceleration test                 2489    1028%
Icon Plotting - 16 colour sprite with mask                 33090    1654%
Draw Path - Stroke narrow line                             27934    1790%
Draw Fill - Plot filled shape                              31321    2146%
Draw Render - Render draw file                             14840    1637%
HD Read - Block load 8MB file                            1038194   34815%
HD Write - Block save 8MB file                            214741    7061%
FS Read - Byte stream file in                                344     166%
FS Write - Byte stream file out                              235     122%

I think for a straight translation from 32 bit to 64 bit we’d be flying into a maelstrom of difficulties. What exactly gets stacked given the differences, how the many conditionals are handled, and of course the big lurking fact that we’re ultimately going to have to accept partial solutions to only use 32 bit registers and addressing, or switch to 64 bit. All of those, and the other dozen or so things I’m too tired to think of, will turn a “simple translation” into a nightmare.

I’m not proposing using ChatGPT by the way..

Good. Because ChatGPT is what one uses when they don’t understand the code or what it’s actually doing and they’re hoping for an easy solution.
There isn’t one.

just using it to show the equivalence of (many) ARM32/ARM64 instrs…

Just out of interest, have you tried IA64? MIPS? RISC-V? I kind of imagine these days architectural differences are simply variations on much the same idea.
(although, speaking personally, I really hope IA64 isn’t too much like x86, because x86 was ugly-as-hell to look at and worse to try to read, especially if you had to toss in the demented segmentation nonsense at the same time and deal with braindead written in fugly)

How does that help or hinder the translation process?

Can’t help but think that AI is failing if it can’t read chunks of code in assembler, and output something that sort of does the same thing in C.
And no, I don’t mean ChatGPTs blind idiot translations, I mean at a block level, not line by line.

Because, I’m sorry, but so much water has passed under this bridge that it’s eroded away the fountains and the bridge has collapsed…
…I cannot believe that anybody is actually contemplating any sort of “translation” of RISC OS into any processor specific assembly language.

We’re in this mess exactly because it’s a massive pile of machine code. If it becomes a different pile of machine code….well, then that’s two messes.