Remember Aasm

Cementing my cutting-edge credentials, I have to admit that I use Aasm for 99% of my machine code development on RISC OS. I always have and… well, that’s the only reason really.

I patched the “LDR Rn,[Rn] → LDR Rn,[Rn],#0” problem a very long time ago, so this ancient build carried on working fine. It’s 2.01 actually.

It has one big annoyance though – filetypes: It only knows about two, Absolute and Module. And regardless of what the source does, it’s a command-line option that causes the filetype to be applied. -stamp and/or -module trigger the filetyping. The FrontEnd offers Module as an option, but -stamp is hard-wired.

Aasm has a directive called LEADR <addr> which specifies the load and execution addresses (weirdly there’s no way of specifying two different ones). So is it possible to fake a ‘Utility’ filetype (for example) via LEADR &FFFFFC00? Well sort of. Only if the FrontEnd hasn’t supplied either of -stamp or -module because they override it (and the -stamp has to be manually removed from the command line).

That’s enough to fool the FrontEnd – it shows a nice Utility icon in its save box. Unfortunately it doesn’t fool the Filer or FileSwitch, because as any fule kno, if the load and exec addresses are identical then it is not a stamped file. So that doesn’t work. Drat.

Aasm also has an ORG <addr> directive that sets the start address. Using that stops -stamp and -module from interfering, but although it sets the load and execution addresses (hurrah!) it also makes absolute addresses rather silly (boo!) and doesn’t fool the Filer anyway as we know. Also, it absolutely has to be used before you do anything else at all. You can’t even define a macro. Which means it can’t be hidden in a handy macro, unlike LEADR. Double drat.

I decided to fix it. Nobody needs files with load and execution addresses any more, but even if they did, you couldn’t have an execution address <&4000 even on old OSes (you could arguably use the “OS scratch area” &4000-&7FFF I suppose, but zero page is ridiculous). And on RO5 anything below &8000 is probably not going to work. So LEADR could take a filetype without ambiguity.

So I’ve spent some joyful hours spelunking through a very ancient 26bit compiled-C assembler that only I use, so I could extend the syntax of one of its directives. Which means that when I assemble some code that uses my UTILITY macro, the resulting output is filetyped correctly, automatically.

Which is how it should have worked 30 years ago.

This makes me inordinately pleased. Don’t ask me for a 32bit version of Aasm though.

Don’t ask me for a 32bit version of Aasm though.

Don’t need one. Run ObjAsm with the -ABSolute command line option, it switches to Aasm mode. ;-)

And what filetype does it produce?