ARMv6v7 Basic Assembler support (kind of...)

(What I am proposing is the implementation of native support for post-ARMv5 (ie. post-IYONIX pc machines, essentially) instructions within the BASIC assembler)

I eventually started this on Easter Sunday and it’s taken the better part of 5 days’ work, but I believe it’s all done now. Everything in Issue C.c of the ARM ARM that wasn’t already implemented, so y’all had better write some interesting programs with it now! ;)

I’ve tested everything interactively as I’ve gone along, but shall now put together a regression test to be committed with the source changes. Some of you may object to the coding style I’ve used, but since it needed to be woven into the existing scalar code (unlike VFP/NEON which can be considered separate), I think it’s important to keep the coding style/formatting consistent. I have, however, commented the additions and some of the original code, as well as making a few small performance tweaks here and there to eliminate stall cycles.

A couple of points: New instructions follow the UAL syntax described in the ARM ARM, specifically the condition code – where permitted – follows the complete opcode, unlike the pre-UAL convention (eg. LDMDB). Obviously I can’t change the existing instructions without breaking everything!

The NOP instruction now has a different preferred encoding (not MOV R0,R0), but I have left it untouched so as not to change the binary output of current source. BTW, it tickles me that ARM’s NOP instruction is conditional :)

I’ve not attempted to implement any of ExtBASICasm’s directives/pseudo-instructions (yet); I may look at these later, after the v6/v7 stuff is completed. I’ve exposed one fault and a couple of omissions in the Debugger module’s disassembler which I shall look at before that.

Best regards…

I’ve not attempted to implement any of ExtBASICasm’s directives/pseudo-instructions (yet);

There is a bottle of something nice in it. ;-)

Make that two bottles!

@Adrian: Great to hear that ! I’ll adapt my test code from my examples for my library based solution by tomorrow and provide a link.

I guess now we got to wait for a ROM update to test it by ourselfs ? Just someone give a note when it’s there (for me needs to be either for Panda or RPI2)…

Great to hear that ! I’ll adapt my test code from my examples for my library based solution by tomorrow and provide a link.

What would be really useful would be a test application that compares the assembled binary from your library with the direct output from the updated assembler, as verification of my changes. I’ve been checking everything against the Debugger disassembler output to date, and the ARM ARM documentation, obviously, but very few of the instructions have been checked for functional correctness (ie. by executing them) and that would be quite a lot of work for many of them.

I’ve yet to look at your test code in depth, so do not yet know how feasible that is, though.

New instructions follow the UAL syntax described in the ARM ARM, specifically the condition code – where permitted – follows the complete opcode, unlike the pre-UAL convention (eg. LDMDB). Obviously I can’t change the existing instructions without breaking everything!

Hmm, that’s going to get pretty clunky pretty quickly in use I think. The VFP extensions bent the ARM syntax a little where required to fit in with the existing style (and tokeniser) so it would seem reasonable to have the scalar instructions follow the pre-UAL layout to fit in with the existing opcodes. One less thing to have to explain to users.

Or, at the very least, have the round trip from BASIC→Debugger→BASIC work so you can match them up without having to mentally transform everything (also handy to copy & paste back into your sources after poking opcodes manually!).

… so it would seem reasonable to have the scalar instructions follow the pre-UAL layout to fit in with the existing opcodes. One less thing to have to explain to users.

I would have thought that having to explain to users that they need to use the obsolete pre-UAL syntax would be a harder job, considering that any ARM documentation made in recent years will be using the UAL syntax, and I’d expect most example code people will be finding elsewhere would be UAL as well. Remember that VFP is (mostly) using the UAL syntax/mnemonics, so the precedent is already set!

Perhaps we need an OPT flag to control whether UAL or pre-UAL syntax is in use?

Or, at the very least, have the round trip from BASIC→Debugger→BASIC work so you can match them up without having to mentally transform everything

That’s what I have done (/tried to do). The Debugger modules does disassemble older instructions in the pre-UAL form, eg. ADDEQS R0,R1,R2 and the newer ones in UAL syntax, eg. SASXEQ R0,R1,R2. The only place where I’ve implemented pre-UAL syntax is with some extensions to LDR/STR such as LDREQSHT R0,[R1] because there’s an obvious relationship to the existing LDR/STR instructions, including LDREQT R0,[R1], and it’s not a new opcode/instruction per se.

So, it’s as clean as I can make it without breaking things, but I am inclined to agree with Jeffrey that there should perhaps be an OPT which switches it to full UAL compliance, moving forwards.

On a related point, the BASIC assembler traditionally faults the presence of ‘#’ when it is expecting only a constant, and does not need to decide between a register number and a constant. UAL permits assemblers to treat the ‘#’ as either optional or mandatory in this case, but not prohibited, so I’ve implemented it as optional in the newly-added instructions.

There should perhaps be a ‘Thumb(2)’ OPT flag as well, ultimately, although I’m not sure how much use it would really get, and I’m certainly not volunteering to implement all of that right now :) I do rather enjoy working on the BASIC module, but don’t use that as an excuse to bombard me with requests!

@Adrian: Here’s my example code Link . The RGB thingy tests 3 different instructions and the Divide the integer div instructions (IGEPv5/RPI2 only). This now should run without my library if the basic assembler unerstands the mnemonics.

Regarding functional correctness we just need lots of basic assembler coders (what is a rare species ;-)) acutally using the instructions. Of course a test suite would be nice to have, but I guess that’s even more work than getting the implementation done.

I remember (Jeffrey can tell…) that I found a lot of bugs within the VFP/NEON encoding just the hard way…when some computations didn’t do what they should the only explanation was a wrong encoding while still not reporting any kind of error. But on the other hand the ARMv6/v7 instructions are not as tricky as VFP/NEON.

The RGB thingy tests 3 different instructions and the Divide the integer div instructions (IGEPv5/RPI2 only). This now should run without my library if the basic assembler unerstands the mnemonics.

Thanks for that. Both assemble without error, and ‘the RGB thingy’ runs without any obvious over/underflow artefacts, so I suspect it’s fine. I don’t yet have a working setup with hardware divide, so cannot run the other test fully.

I have just committed (/tried to commit) the changes to BASIC and a simple preliminary test app, so you should be able to try it yourself soon, hopefully. The modified BASIC module has also been used to build a complete ROM for the IYONIX pc, and to assemble a 26-bit wordprocessor I wrote when I was at school ( 64KB of handcoded assembly language) and that compares bit-exact with the original binary, so I’m reasonably confident….but I’m sure you can break something ;)