PowerTec !Speed

Does anyone have a version of PowerTec’s !Speed utility that works on a Pi 4B with RO 5.28? I have 1.37 (27-Jan-2004) which works on the Mini.M, but crashes with a type 3 on the Pi after its done all of its measurements but before updating the window.

Can’t help with a later version but do note that Gary partis is still showing PowerIDE on his website and that that includes !Speed. Maybe worth contacting.

Thanks, I’ve sent him an email.

While I’m waiting for a reply, I ran it through ARMalyser and found the supposed 32 bit executable, isn’t by a long way. It looks like it has been compiled against the 32 bit stubs, but the code generation is still 26 bit. So I’ve manually fixed it up, and now completes without crashing on the Pi 4B.

While I’m waiting for a reply, I ran it through ARMalyser and found the supposed 32 bit executable, isn’t by a long way. It looks like it has been compiled against the 32 bit stubs, but the code generation is still 26 bit.

I’ve seen a reasonable number of items like that – mostly stuff that Dave Holden had, whether of his own making or someone else. Various 26 bit modules with a 32 bit header being a regular.

The ARMv8 capable processors are a lot less tolerant of 26 bit code being used in user mode and will crash. Where as ARM v5,v6 and v7 would usually just not preserve/alter the flags, which in many cases did not cause significant issues. 26 bit mode privileged code on any 32 bit processor is always going to fail. So bodges such as just sticking a 32 bit header on things is not an option.

So bodges such as just sticking a 32 bit header on things is not an option.

Even I know that. Some people were resolutely 26bit and 32bit was “a passing fad”

!Speed will run on a Pi4 under AemulorA72.

Running something which tries to measure performance under something which sacrifices performance for compatibility, probably isn’t a great idea!

While I’m waiting for a reply, I ran it through ARMalyser and found the supposed 32 bit executable,

You might want to edit that link to be “free” rather than “fee” – unless you’re going to start charging :)

something which sacrifices performance for compatibility

Fair point, but the result agrees pretty well with ROmark (first set of figs below):
Read 8MB=32125
Write 8MB=30062

!Speed:
Read 512KB=30719
Write 512KB=28205

Bearing in mind the bigger block should be more efficient, the Aemulor overhead, if any, appears to be modest.

So bodges such as just sticking a 32 bit header on things is not an option.

Whoever thought that was actually going to work? We ought to name’n’shame such cluelessness.

I don’t think I’ve come across such Eldritch Abominations. At least the code that my ARMv7 chokes on is good old fashioned gibberish likely the result of a typo or programmer caffeine insufficiency.

But sticking a 32 bit header on 26 bit code? WTF? And, pray tell, what exactly is supposed to happen the moment one starts fiddling with PC to handle flags? Because, uh, that’s an address, not a flag bit!

[I would drop in a few facepalm emoji, but I’m currently using NetSurf on RISC OS…]

Some people were resolutely 26bit and 32bit was “a passing fad”

Well, that appears to have been the case. 32 bit is a fad that came, lurked for a mere two decades, and is now on the way out, to be replaced by 64 bit.
26 bit, on the other hand, was dropped more or less the moment Acorn was no longer. So the writing on the wall (in neon magenta glow-in-the-dark spray paint) really ought to have been obvious.

But sticking a 32 bit header on 26 bit code? WTF? And, pray tell, what exactly is supposed to happen the moment one starts fiddling with PC to handle flags? Because, uh, that’s an address, not a flag bit!

In handwritten assembler you tend to be actively manipulating the flags in functions to return information to the caller, and as you say, as soon as you touch bits 24 to 31 of R14, you are going to break the return address, and crash.

However, C doesn’t use the flags for returning state, it just tends to check the result of the V flag coming back from SWIs and sets a1 accordingly. 26 bit compilers create flag preserving functions by default, even though most functions don’t need to be, and the MOVS pc,lr in user mode is ignored prior to ARMv8. There are a small number of functions which need to be flag preserving as they are conditionally called, and the following instruction is also conditional and assumes the flags have not changed.

The fix is to change MOVS pc,lr to MOV pc,lr and fix up calling sequences which assume flag preservation.
e.g.

CMP something
BLEQ subroutine
MOVEQ reg,value
...

CMP something
BNE skip
BL subroutine
MOV reg,value
.skip
...

This is one instruction longer, which means ARMalyser needs to have identified all offsets and addresses in the code and adjust them accordingly.