Archimedes updates
Colin Ferris (399) 1798 posts |
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? |
Jon Abbott (1421) 2640 posts |
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. |
David J. Ruck (33) 1586 posts |
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. |
Steve Pampling (1551) 8126 posts |
If Jon is looking to do a collection of fixes and some back ports from current, then maybe 3.141 is a decent tag, |
Graeme (8815) 103 posts |
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. |
Sprow (202) 1150 posts |
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. |
Clive Semmens (2335) 3274 posts |
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…) |
Jan Rinze (235) 368 posts |
Could anyone here enlighten me as to what is ‘Ace’? |
Graeme (8815) 103 posts |
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. |
Colin Ferris (399) 1798 posts |
Try searching https:riscosopen.org ace |
nemo (145) 2496 posts |
Graeme wrote
Cool thing. Sadly e.g. In all other OSes, this code will display “
This is caused by ROOL’s erroneous claim that 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. |
Rick Murray (539) 13751 posts |
To be fair to ROOL, PRM1 on handling errors (p43?) states:
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. |
Graeme (8815) 103 posts |
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. |
Dave Higton (1515) 3479 posts |
It looks to me like a failure of one SWI to conform to the documentation. |
nemo (145) 2496 posts |
Dave foolishly suggested
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. |
Rick Murray (539) 13751 posts |
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… |
nemo (145) 2496 posts |
Graeme clarified
May be corrupted, depending on branch, version and, it appears, whim. |
Rick Murray (539) 13751 posts |
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. |
nemo (145) 2496 posts |
Rick ruminated
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. |
Steve Fryatt (216) 2095 posts |
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. |
nemo (145) 2496 posts |
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.
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.
“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. |
Rick Murray (539) 13751 posts |
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 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.
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. |
Steve Pampling (1551) 8126 posts |
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? |