FPEmulator on Raspberry Pi 3

A crash when using PipeDream on a Raspberry Pi Mk3 was reported on the PipeDream mailing list. I was able to replicate something here.

After a lot of RPi3 crashes, and it really does crash, the RPi3 has to be restarted, the cause of the problem, as seen here, is very simple. Open a new sheet on either PipeDream 4.54 or Fireworkz 2.00.02 and enter the number 1.01.

13 Apr 08:13:01 000 00800E07: Error from (unknown): Internal error, no stack
for trap handler: Internal error: abort on data transfer at &FC21600C, pc =
FC176D90: registers at 000C38D4
13 Apr 08:13:32 000 80000002: Error from (unknown): Internal error: abort on
data transfer at &FC210418

*fx0
RISC OS 5.23 (10 Apr 2016)
*where FC21600C
Address &FC21600C is at offset &000060B0 in module 'FPEmulator'
*where FC210418
Address &FC210418 is at offset &000004BC in module 'FPEmulator'
*

*Help FPEmulator
==> Help on keyword FPEmulator
Module is: FPEmulator      4.34 (29 Feb 2016) (1.13CELM)
*

It is RPI3 specific.

ZeroPain 0.06 is on the case, there is nothing logged.

I spotted something similar on Monday, while working on some code of my own. Looked like it was getting the wrong workspace pointer somehow. I guess I’ll be looking into this tonight, then!

Should be fixed with FPEmulator 4.35. Looks like the problem was a false assumption about what type of workspace pointer a particular routine needed – if you had two FP instructions next to each other, and the first one fails the condition code check but the second one passes, then when the second instruction is emulated it would treat the module workspace as if it were a FP context. In my case this was causing the context pointer (held in the module workspace) to be overwritten by a floating-point value, causing all future FP instructions to crash.

On other machines this wouldn’t have been an issue because the CPU wouldn’t have taken the undefined instruction vector for the first instruction of the pair (FPEmulator has an optimisation where it scans ahead to look and see if the next instruction to be executed is an FP instruction – if it is, it stays in its handler rather than returning straight away after the first instruction has been dealt with. Without that optimisation, things probably would have been fine as well)

Although this was a bit of a pain to track down, the upside is that I do now have some sample code for configuring the hardware watchpoints (data breakpoints) on the Pi 3 (and potentially other devices), so I may be tempted to add support for that to the debugger module at some point…

Should be fixed with FPEmulator 4.35.

It is. Many thanks.