UAL support/migration

What are ROOL’s thoughts on adopting the UAL assembler syntax? I’m not suggesting that we switch to UAL outright, but there are some areas where I think it would be preferable for us to standardise on using UAL. Specifically, the VFP & Advanced SIMD instructions.

Although there are non-UAL mnemonics available for the VFP instructions, there aren’t any available for the NEON instructions. So if we used non-UAL for VFP then it would be a major headache for anyone wanting to write NEON-enhanced VFP code, since for each instruction they’d have to check whether it’s VFP or NEON and then use the appropriate mnemonic/syntax. Using UAL for the VFP instructions would also make it very easy for people to identify which code is for the FPA and which is for VFP/NEON.

Of course there are a couple of hiccups with using UAL, in that there’s no UAL equivalent of FLDMX/FSTMX due to the instructions being deprecated. So if we needed to support those we’d have to provide them in non-UAL form.

For C compilers I think you might be forced to support the non-UAL forms of the VFP instructions, just to allow any existing code to be compiled. But for BASIC’s assembler I think things would be a lot simpler if we only supported UAL for VFP. Similarly, the Debugger should give UAL disassembly of VFP instructions (perhaps with the non-UAL form as an option, if people will find it useful).

Thoughts?

Using UAL for the VFP instructions would also make it very easy for people to identify which code is for the FPA and which is for VFP/NEON.

OK, forget that. For some reason I thought that all the FPA instructions started with ‘F’, but that clearly isn’t the case.

Similarly, the Debugger should give UAL disassembly of VFP instructions (perhaps with the non-UAL form as an option, if people will find it useful).

Also it turns out that the Debugger does already support disassembly of some VFP instructions, using the non-UAL form. But since the OMAP3 is the first RISC OS machine to use VFP, I don’t think it will be too big a deal if we decide to change VFP disassembly to be UAL format by default.

There’s rather more to UAL than just the mnemonics used for VFP/SIMD instructions, as I discovered when updating decaof. There are things like “MOV r0,r0,LSL #1” is now preferred to be disassembled as “LSL r0,r0,#1” or “LSL r0,#1”, which looks odd to those of use with years of ARM coding experience.

For the record, with decaof the solution I chose was to leave the command line behaviour to output pre-UAL versions of instructions, in case anyone is postprocessing the output, and to add a ’-u’ switch to enter UAL mode. Then on the frontend user interface, I enabled UAL by default. Instructions with no pre-UAL form are always dissasembled in UAL form and vice versa. FPA instructions are always disassembled in pre-UAL form because of the ambiguity of a “PLS” suffix if UAL-style condition code is permitted.

I’m still considering what to do on the assembler side. Long term, I think the writing is on the wall for the ARM instruction set and we will eventually be forced to transition to Thumb (the Cortex-M series already drops the ARM instruction set, and only does Thumb). A Thumb assembler requires a switch to specify whether UAL is in use or not because the same assembler syntax represents different instructions under UAL or pre-UAL mode, unlike in ARM where it’s possible to accept either representation. At the moment I’m leaning towards using the same switch in ARM mode, but having it emit warnings if it sees a UAL instruction in pre-UAL mode or vice versa. This would permit a two-step migration as first we transitioned the code base to UAL syntax, component by component, and only then switch it to assemble Thumb rather than ARM.

There’s rather more to UAL than just the mnemonics used for VFP/SIMD instructions, as I discovered when updating decaof. There are things like “MOV r0,r0,LSL #1” is now preferred to be disassembled as “LSL r0,r0,#1” or “LSL r0,#1”, which looks odd to those of use with years of ARM coding experience.

Yes, it does feel a bit horrible in places :( But with the VFP instructions I think it’s a good thing, since it makes it clear that the VFP and SIMD instruction sets are directly related to each other, and helps reduce the number of mnemonics to learn.

Long term, I think the writing is on the wall for the ARM instruction set and we will eventually be forced to transition to Thumb

And before that happens we’ll have the fun of trying to support multi-core Cortex-A9’s!

There’s rather more to UAL than just the mnemonics used for VFP/SIMD instructions, as I discovered when updating decaof. There are things like “MOV r0,r0,LSL #1” is now preferred to be disassembled as “LSL r0,r0,#1” or “LSL r0,#1”, which looks odd to those of use with years of ARM coding experience.

Yes; with disassemblers, you have to make a choice (or have a setting, like you have in DecAOF), but with assemblers, it’s no big deal to support LSL, etc., as they are just aliases to corresponding MOV instructions, so extASM supports the alternative shift mnemonics.

However, other things require larger changes, like supporting both the form LDMEQFD (pre-UAL) and LDMFDEQ (UAL) syntaxes. As mentioned in a recent mail to Jeffrey, extASM presently only supports the pre-UAL version of such instructions where the condition code field could be located in two different places, as supporting both would result in a significant increase in complexity of the instruction parsing in extASM (you no longer knew for sure where the (optional) condition code could be found), for little perceived gain, at least for now.

However, should a need for supporting both forms arise, for example for compatibility with source code for ObjAsm and the BASIC assembler, this issue could be revisited.

I’m still considering what to do on the assembler side. Long term, I think the writing is on the wall for the ARM instruction set and we will eventually be forced to transition to Thumb (the Cortex-M series already drops the ARM instruction set, and only does Thumb).

If that happens, I’ll likely stop writing assembly code. Period.

So far, I’ve been able to live with the loss of some of the consistency and elegance of the original instruction set, in return for a more powerful instruction set (in particular VFP/NEON), so I’ve felt that has been a net gain. As for performance, there may or may not be a higher performance with Thumb (depending on cache issues), but it’s being advertised as resulting in higher code density, in exchange for some reduced performance, and higher code density is rather irrelevant when using the ARM as a desktop computer (like we do). What we need is more performance, not less.

...And before that happens we’ll have the fun of trying to support multi-core Cortex-A9’s!

For anyone interested in this, a public Technical Reference Manual for OMAP4 will be available soon.

From the OMAP overview at that page:

• 2x ARM Cortex A9 @ 1GHz+
• Available on PandaBoard this fall
• Features
  • Video
    • 1080p Encode / Decode all codecs
  • Audio
    • ARM based encode and decode
  • GFX
    • IMG SGX 540
    • 3430: ~30M Poly, 1435M Pix, 4.9G Flops

This sounds very promising. :)

One of the areas where the BeagleBoard has been lacking has been the screen resolution, but the HD capable OMAP4 should take care of that. :)

It would also mean that I’d be able to use my 24” LCD screen at its native HD resolution… :) That is, if or when we get RISC OS working on the PandaBoard…

By the way, I recently bought that monitor specifically for the BeagleBoard, since my current one didn’t have HDMI input, and currently, I’m only able to run it with about 1280×720 on the BeagleBoard (or 2/3 of the available resolution).