ARMalyser source

Is the source for ARMalyser available? It’s a very useful tool, but I’d like to make a few minor modifications to assist me with locating 32bit issues in games, namely:

1. Ignore certain instructions (ADFFS’ JIT entry instruction)
2. Skip certain memory ranges
3. Use the file load address when displaying addressing, instead of an offset of 0

Is the source for ARMalyser available?

I’m not sure how often Dave Ruck reads the stuff here, or c.s.a.* as he seems to have different interests/uses for his time. Try email and csa as well.

A few tweaks to Armalyser would be useful – your 1-3 plus output in a BASIC compatible format.
The latter because it strikes me that a lot of simple 32 bitting work¹ could be done by people who don’t have the DDE, and hence ObjAsm, but obviously do have BASIC.

¹ Sometimes these “not 32bit” items are just a header that’s short of a few entries² or a handful of movs pc,R14 where a mov pc,R14 will do. Page 126 dabhand guide “Archimedes Operating System” module initialisation advises exit with MOV PC,R14 what do you see time after time – MOVS PC,R14. Why?

² Should the documentation mandate ALL entries, even if some are zeros?

Page 126 dabhand guide “Archimedes Operating System” module initialisation advises exit with MOV PC,R14 what do you see time after time – MOVS PC,R14. Why?

Because the book is wrong. The PRM quite clearly states “Must preserve processor mode and interrupt state”. On a 26 bit system, you use MOVS or LDMFD ...^ to restore the processor status.
Pages 1-212 to 1-215 in the PDF version (print numbers, not PDF page numbers).

Should the documentation mandate ALL entries, even if some are zeros?

It would be a good idea, but is it necessary? For modern 32 bit stuff, the 32 bit marker tends to be at the end of the header which implies the rest of the header is present in some form. For older stuff… that horse escaped its stable decades ago.

The PRM quite clearly states “Must preserve processor mode and interrupt state”. On a 26 bit system, you use MOVS or LDMFD …^ to restore the processor status.

Which I’ve tended to interpret as the processor mode and interrupt state on entry will be the same as on the exit. i.e. IF you chuff about with either you will put it back as you found it before exiting.

“Should the documentation mandate ALL entries, even if some are zeros?”
It would be a good idea, but is it necessary? For modern 32 bit stuff, the 32 bit marker tends to be at the end of the header which implies the rest of the header is present in some form.

(Damn, nested quotes?)

As was pointed out by Sprow and, er, you: the flag word can go anywhere, you just point at it but the pointer needs to be in the right place to be recognised and that requires “padding” so to speak and the reason for that “padding” needs to be documented. Basically people need to be told the content is optional rather than the actual field being optional.

For older stuff… that horse escaped its stable decades ago.

The question is should documentation people might read be correct, not whether it’s been a bit loose for years.