Archimedes updates

Not really for this forum – but are there any interesting updates to old Arc’s RO 3.10?

Could MSR / MRS be added to Ace?

Probably a question for StarDot.

What sort of “interesting updates” are you after? I’ve got a slow-burn project to create a RISC OS 3.20 ROM if it’s that sort of update you mean.

I pretty sure I was running RISC OS 3.22 on my A5000, which contained a lot of prototype modules that would go into RISC OS 3.5 on the Risc PC.

If Jon is looking to do a collection of fixes and some back ports from current, then maybe 3.141 is a decent tag,
Not as high as 3.2x but higher than 3.10.

Could MSR / MRS be added to Ace?

ACE uses MSR/MRS instructions and expects them to be performed by the CPU. If the CPU does not have MSR/MRS then ACE will fail to work correctly. I am not sure if these instructions even could be emulated on the older machines due to the difference in architecture. If someone did, what would be emulated would be very limited.

Could MSR / MRS be added to Ace?

I don’t think that could work if ACE is catching undefined instructions and emulating them. The MSR/MRS family were carefully (I believe) chosen to sit in a part of the instruction space that previously did nothing. So if an ARM2 encounters either it just silently passes over it.

Many macros in the RISC OS sources rely on this to achieve 26/32 bit neutral operation.

The MSR/MRS family were carefully (I believe) chosen to sit in a part of the instruction space that previously did nothing.

You are correct. Same goes for all new instructions, as distinct from old instructions with somewhat altered behaviour. That was true up to 2007, at least – but I retired in 2007, so I can’t speak for anything later. (ARMv8 of course is stoatally different…)

Could anyone here enlighten me as to what is ‘Ace’?
Googling wasn’t very helpful.

I wrote ACE. It reduces the chance of getting an ‘Undefined instruction’ error by emulating instructions which are missing from some CPUs. You can download it from http://www.nationwidesucks.co.uk

You will find it does not work on some older machines. It should work on Risc PC and later. It is has not tested on anything earlier.

Try searching

https:riscosopen.org ace

Graeme wrote

ACE

Cool thing.

Sadly ACE_VforMSR is yet another demonstration of RO5’s broken SWI mechanism – despite your intentions, R0 will be corrupted on exit because of ROOL’s misunderstanding about how SWIs work in RISC OS.

e.g. In all other OSes, this code will display “3 in, 3 out”. But since 5.24 R0 will be corrupted on exit (with ACE running).

REM Yet another demonstration of RO5’s broken SWI mechanism.
REM Tired of pointing this out.

DIMP%63:[OPT2:.see
MOV R0,#3
SWI &E0082
SUB R1,R8,#&400
MOV R2,#11
SWI “XOS_WriteS”:="3 in, ":=0:ALIGN
SWI “XOS_ConvertCardinal4”
SWI “XOS_Write0”
SWI “XOS_WriteS”:=" out" :=13:=10:=0:ALIGN
MOV PC,R14
]
CALL see

This is caused by ROOL’s erroneous claim that R0 must point to an error block on exit from a SWI if V is set. This is wrong, and has always been wrong.

It is not true of a couple of Kernel SWIs, never mind the eight million other SWIs that may exist.

This is not your fault Graeme.

I look forward to playing with ACE, it’s something I’ve been meaning to write myself.

To be fair to ROOL, PRM1 on handling errors (p43?) states:

If an error did occur, the SWI routine will set V on exit. Furthermore, R0 will contain a pointer to an error block, which is described below.

It says similar earlier (p23?) when describing SWIs.

Now, to be fair to you, Acorn rarely followed their own advice, and some thirty years later isn’t really the time to start baking in enhanced checking. Indeed, I’d question whether or not it’s the kennels job to be vetting SWI exits. If the V flag is set and R0 isn’t an “approved error number” then, sure, it’s probably wrong…but given the number of things the kernel could do but doesn’t (such as faking SWP on machines without), it’s a bizarre choice.

That is a good point. The reason I chose the V flag to be set is so code can use the X numerical form of the SWI and if my module is not present, the V flag will be set by the OS. Of course, if my module is not present R0 will be a pointer to an error block by the OS and therefore corrupted anyway!

I’ll have to update the documentation to state R0 is corrupted and use a different register in the example. The help file is terrible and was written a handful of minutes so that deserves a better rewrite anyway.

yet another demonstration of RO5’s broken SWI mechanism – despite your intentions, R0 will be corrupted on exit because of ROOL’s misunderstanding about how SWIs work in RISC OS.

It looks to me like a failure of one SWI to conform to the documentation.

Dave foolishly suggested

looks to me like a failure of one SWI to conform to the documentation

OS_GenerateError.

To be more specific, where in your documentation does it say that all authors of modules are prohibited from writing a SWI that behaves similarly to OS_GenerateError.

Because the only reason that OS_GenerateError still works is that it is special-cased in the code.

If one of my engineers special-cased the exhibit that demonstrated their code was wrong they’d be looking for a new job just as soon as they’d removed my boot from their fundamental unsuitability for the role.

If I remember correctly, there’s logic in the “is this a valid error block” guff to handle various special cases (FileCore?).

Really, the document says R0 if V set is a pointer to an error block. Validating that there is a valid error number is…

Graeme clarified

I’ll have to update the documentation to state R0 is corrupted

May be corrupted, depending on branch, version and, it appears, whim.

May be corrupted

Well, to be honest, what the OS does if your module isn’t loaded really isn’t your problem.

That being said, it sets the V flag for a reason. That should be checked before assuming anything about what may or may not be in any of the registers.

Rick ruminated

the document says R0 if V set is a pointer to an error block

Any documentation that says that is wrong.

OS_GenerateError says that is wrong.

OS_CallAVector says that is wrong.

PSR_SetV, if there were such a thing, says that is wrong.

Every debugging SWI in my WriteReg module says that is wrong (as it preserves all flags, obviously).

Graeme’s ACE_VforMSR says that is wrong.

It’s a staggering work of arrogance to introduce a corruption where previously there was none, based on a theory that is not only demonstrably incorrect, it was known to be demonstrably incorrect which is why OS_GenerateError is special-cased.

Shameful.

Now, to be fair to you, Acorn rarely followed their own advice, and some thirty years later isn’t really the time to start baking in enhanced checking … it’s a bizarre choice

I’m fairly sure that there was a request for comments at the time when the changes were being proposed, to which I’m sure that you and nemo would have been very welcome to have contributed… although I can’t see your names in that thread, so I assume that neither of you had any concerns about the idea back then. Ad hominem attacks nearly ten years later against those who – unlike yourselves – did make practical contributions to moving the OS forward isn’t really helpful behaviour, either.

ad hominem

Which hominem? I’ve no idea who messed this up. I referred to “ROOL”, which is the whole enterprise, not one person.

And “You didn’t stop me” is no excuse. Even when I have noticed things getting broken at the time I’m ignored – e.g. MOSVars, Wimp_GetCaretPosition, SetCaretPosition etc.

neither of you had any concerns about the idea back then

So it’s too late now to fix it, but it wasn’t “too late then” for the breakage to be introduced? Unconvinced by that reasoning.

against those who – unlike yourselves – did make practical contributions to moving the OS forward

“Please don’t complain about potholes in the road unless you built the road.”

I don’t drive on this road mate, but I will continue to point at the holes.

so I assume that neither of you had any concerns about the idea back then

Given how long ago it was, I would imagine “the OS should not be trying to deal with stuff erroneously setting V on exit” would not have been a popular opinion.

After all, remember I was quite vocal against making page zero “nothing” due to the amount of stuff it would break (Word of God at the time was “if it crashes it’s broken and needs to be fixed”), and
I even made a hacked version of ZeroPain that didn’t expire (because reality at the time was that not everything is going to be fixed and it’s not the OS’ job to introduce breakages, no matter how well intentioned).
A little later, a “compatibility page” was introduced, no doubt because of the amount of stuff it actually broke.

I also recall numerous other discussions regarding sudden new “SWI &xxx returned a bad error pointer” messages appearing where they didn’t previously (and, of course, the OS electing to replace whatever might have been in R0 with its own message).

We’ve also had discussions about how a failing module will crash an application because of the way the RISC OS error handling percolates up until something is able to throw toys out of the pram; which is usually the foreground application that might be completely unrelated to whatever actually died.

So pointing to one topic that I might even have missed, doesn’t really say anything much. Talking about things doesn’t show effects. Shaking the tree does.

As it happens, all these years later it doesn’t really bother me. But it still seems odd to build in sanitisation for somebody else’s broken code, when error handling in general is a bit of a mess.

those who – unlike yourselves – did make practical contributions

So neither of us have made any contributions to the OS, huh? I’ve found and fixed a few bugs, pointed out others that Jeffrey rummaged around and fixed, and nemo… well… I think you owe him, at least, an apology.

Word of God at the time was “if it crashes it’s broken and needs to be fixed”

Coo, I’ve been promoted – how long ago, and what’s the back pay?

Seriously though, is this a case of one small bit of frequently called code which could be changed?