ARM on ARM discussion

What happened to the unreleased StrongARM JIT?
The statement that it runs really fast is nice, is there a place to get this code and test it on other platforms?

What happened to the unreleased StrongARM JIT?

I’ve yet to add the corrections for pipeline changes when storing PC (STM, STR). If that’s not an issue, you can compile ADFFS with self-modifying code support turned off, to turn it into a StrongARM JIT.

What happened to the unreleased StrongARM JIT?

I’ve posted beta ADFFS Modules which include the ARMv4 JIT on the JASPP forum. The majority of code running in ARMv4 mode should be pretty close speed wise to equivalent native code.

Whilst testing officially “StrongARM compatible” games under the ADFFS JIT in ARMv4 mode, it has highlighted a potential problem that’s relevant to this thread.

In the case of ADFFS, memory writes aren’t checked to see if they’re overwriting code; it relies on all code that write to memory issuing OS_SynchroniseCodeAreas so the JIT code cache can be cleaned. That’s fine on paper, however in reality a StrongARM would self-clean it’s cache over time due to its random cache line replacement, so should a section of memory not be synced, it’s likely it wouldn’t be noticeable on a physical processor and the code would run as expected provided enough time had passed. For a caching JIT however it can prove fatal, as the cache may never be cleaned, ending up with the JIT’d code getting out of sync with the original code.

To be clear its bugged code at fault here, but much like Page Zero access bugs, its possibly a widespread issue that’s gone unnoticed. And much like Page Zero access bugs, the preference is to fix the source code and where that’s not possible memory writes need to be checked by the JIT so it can self-clean.

This leads on to another issue: pipeline emulation. For normal code this doesn’t become a factor and can be ignored, but there are protection routines which make use of the pipeline, which would fail if the JIT cleaning doesn’t take it into account.

In short, lots of “StrongARM compatible” software probably isn’t StrongARM compatible.

In short, lots of “StrongARM compatible” software probabably isn’t StrongARM emulation compatible.

There.
Fixed that for you.

If it works as expected on a real StrongARM, it is StrongARM compatible…

In short, lots of “StrongARM compatible” software probabably isn’t StrongARM emulation compatible.

Your probabably right!

Fixed that for you.

If you say so!

If it works as expected on a real StrongARM, it is StrongARM compatible…

Technically what Jon wrote is correct – the problematic software isn’t following the API and has probably been generating small errors that were difficult(almost impossible?) to replicate for the whoe time of existence of StrongARM and similar processors¹.

Jon notes that the emulation of SA pipeline behaviour isn’t complete/perfect but that’s a different issue.

So, as Jon says there are two threads of action required:

1. Fix the pipeline issue in the JIT.
2. Fix the software, where source exists (or patch), and provide a JIT “crutch” in ZeroPain style to deal with the ongoing brokenness of the application software.

¹ Close cousin of Zero page, isn’t it? I wonder how many of those inexplicable SA system errors people experienced arose from this bug that required the exact Feng Shui of cache use and timing to activate?

Fixed that for you.
bq. If it works as expected on a real StrongARM, it is StrongARM compatible…

Much like adding a “compatibility page” with the Page Zero issue, ignorance isn’t going to fix the underlying problem. The fix in emulation is to simply handle self-modifying code, the drawback is the hit to performance.

The software may appear to run correctly on a physical StrongARM, but in reality as the cache uses a random replacement method, there may be occasions where it’s not self-cleaned.

I may just have been unlucky in that out of the three “StrongARM compatible” games I looked at, two had the same issue. Given the amount of Page Zero issues I’ve found and documented, I’m inclined to think it’s possibly a wider hidden issue that’s gone unnoticed.

Fix the pipeline issue in the JIT

Not so easy in a JIT as the code is running native. ADFFS handles it via a hack, that works because game protection doesn’t generally check that previous STM/STR instructions have worked. I’m not sure it would be possible to implement a pipeline correctly in a JIT without a big performance hit.

I may just have been unlucky in that out of the three “StrongARM compatible” games I looked at, two had the same issue. Given the amount of Page Zero issues I’ve found and documented, I’m inclined to think it’s possibly a wider hidden issue that’s gone unnoticed.

Agreed – over the years we’ve found a number of places in the OS sources where OS_SynchroniseCodeAreas wasn’t being called correctly (and only started failing once newer machines came along which had different cache behaviour). So it wouldn’t surprise me if there’s a number of third-party programs which also got it wrong.

ignorance isn’t going to fix the underlying problem.

Oh, don’t get me wrong. I’m not saying the software in question is correct. I’m just raising a flag for you claiming that software that works on a StrongARM is not StrongARM compatible. :-)

On a more serious note, is this problem more specific to the ARM than, say, the x86? Or is it a factor of the x86 expending a billion transistors to maintain 8088 compatibility, whereas ARM is more liable to change how deep magic stuff behaves?

So it wouldn’t surprise me if there’s a number of third-party programs which also got it wrong.

Oh, I can guarantee that some got it wrong. Writing stuff in assembler is hard. There are plenty examples of gonzo code around – remember one of the things that I patched for my Pi2 was loading a register using that register as the base with writeback! What did the author think was going to happen? Or maybe it was just a momentary slip that went unnoticed until the later ARMv7 said hell no and threw an exception.

I’m just raising a flag for you claiming that software that works on a StrongARM is not StrongARM compatible. :-)

“Not published API compatible” suit you as a description?
As Jeffrey pointed out there were instances in the OS where such things happened so the bug happening in third party code is a virtual certainty.
I suppose the most useful situation is a Zeropain style “crutch” that logs and notifies users of the error and some relatively easy method of patching binaries where source isn’t available.

Shame Nemo is off somewhere else¹ because such patches seem to be a thing for him (as well as dinky modules to fix some b***s up in the OS.

Or maybe it was just a momentary slip that went unnoticed until the later ARMv7 said hell no and threw an exception.

That gets my vote.

¹ Can’t say I’m surprised.

Agreed – over the years we’ve found a number of places in the OS sources where OS_SynchroniseCodeAreas wasn’t being called correctly (and only started failing once newer machines came along which had different cache behaviour)

It’s a really hard issue to track down as well, short of an ICE that checks for it, it’s a case of manually checking every STR, STM, OS_File, OS_GBPB etc. or emulation that checks if the instruction in memory matches that in the pipeline.

I’m contemplating adding code to ADFFS when in debug mode, to check every instruction before it executes matches memory. Manually checking game code or watching for misbehaviour is a non-starter as code can fail safe.

I’m contemplating adding code to ADFFS when in debug mode, to check every instruction before it executes matches memory

Sort of related, but we are generally short of debug tools:
I seem to recall that back in the 26 bit days someone wrote a debugging tool that allowed you to single step through programs and displayed the state of flags and content of registeres – damned if I can remember the name, but I think it was among the stuff in the APDL Library (could be wrong there)

back in the 26 bit days someone wrote a debugging tool that allowed you to single step through programs

DDT… and it’s barely been touched since. :-)

Yes, I recall a number of debugging “solutions” but none of them attempted to deal with module code. Even today, if I find something going wrong, it’s a case of spitting characters to DADebug and looking to see how far it got. Kind of how I used to debug on the Beeb!

Sendiri was planning the ultimate debugger (http://sendiri.co.uk/udp.html). I say “was” because I noticed the date… Fourteen years ago already.

but we are generally short of debug tools:

Very much this. Especially remote debug tools that can cater for debugging stuff outside of user mode.
I mean like gdb, not JTAG!

Steve – perhaps you’re thinking of Monitor?
http://www.apdl.org.uk/apdlpd/library/files/b/b208.zip

The description reminds me of Arm_Debug

I mean like gdb, not JTAG!

Wasn’t there some emntion of that(gdb) and a port in the GCCSDK or something?

Steve – perhaps you’re thinking of Monitor? Steve – perhaps you’re thinking of Monitor?

Familiar, but not the one I was thinking of.

The description reminds me of Arm_Debug

This rings a bell – Theo van den Boogaert – the name certainly resonates with something in the back reaches of the skull.

Monitor – 1992 various non-32 elements but amazingly it doen’t fall flat on its face if you try an run it.

ARM_Debug – 2001, latest variant of the module therein is written for RO4 and is non-32.

There was DeskDebug by Niklaus Weiss (sold by Spellings Software), and Vigil by (I think) Alan Wrigley.

we are generally short of debug tools: I seem to recall that back in the 26 bit days someone wrote a debugging tool that allowed you to single step through programs and displayed the state of flags and content of registers

I’ve tried many of the step debuggers and they’re all pretty much useless for debugging all but the most basic code. They certainly don’t work well when there’s IRQ’s and Modules involved, which invariably result in a hard lock.

How the debugger executes the instructions can also be an issue, some copy the instruction, wrap it in pre/post code and then execute it – that inherently changes the behaviour of some instructions.

Debugging tools are also useless when running under a JIT as it can be near impossible to link the code being debugged back to the source instruction. I sort of worked around this issue in ADFFS by creating an instruction trace in a DA, but its use is limited at the rate instructions are being executed. Unless there’s a hard crash or breakpoint, finding the problematic code is usually best done proactively rather than retrospectively.

External hardware debugging is the way to go, I’ve just never figured out how to do it with an ARM processor!

External hardware debugging is the way to go, I’ve just never figured out how to do it with an ARM processor!

Now if there’s anyone not interested in that they really don’t care about any coding on ARM.

They certainly don’t work well when there’s IRQ’s and Modules involved

That’s why my usual method of debugging is to spit bytes to DADebug. Not perfect, but as we all know, debuggers are useless when it comes to module code.

that inherently changes the behaviour of some instructions

Indeed. I’ve had times when adding debug code changed behaviour (was due to shooting over an array and trashing something important, but with the debug code in place the extra stuff gave leeway so that “it worked”).
That said, debugging at processor level is an exercise in wrestling with Schrödinger’s cat. Simply observing what’s going on will change what’s going on.

I’ve just never figured out how to do it with an ARM processor!

I think most processors since the ARMv5(ish) have some sort of Execution Trace Module in hardware, with either JTAG or SWD connections. I don’t know how much flexibility this has (can it do breakpoints? break if register changes?) but I suppose the most useful thing is that if something crashes one can see the registers and a list of “how we got here”.

The cheap and cheerful way is to use a modified version of DADebug to output to serial port (to view on another machine); this may help for application/module development, but it wouldn’t be much use for you Jon as one can’t exactly patch debug code into existing binaries.

Reporter does have a facility to patch an existing code file (eg Utility or Module) to call a debug routine which can list text and any registers of interest. The modification consists of replacing (and relocating) one instruction with a single branch instruction, so there are some limitations on where they can be placed. An example is provided, which was used to add 12 debug statements to SpriteExtend to identify a very long-standing bug. Used with the Log facility, it can record right up to a total machine lockup.

Not the answer to all low-level debugging, but it has helped me in several cases.

lots of “StrongARM compatible” software probably isn’t StrongARM compatible.

I’ve tried most of the officially “SA compatible” games today, to see just how widespread the issue is:

EDIT: Please see the more detailed post on the JASPP forum for details on game compatibility.

Just out of interest, did Acorn ever make a datasheet on how to make things StrongARM compatible?
Just wondering if there was any official guidance that covered the issue.