software compatibility list
GavinWraith (26) 1532 posts |
I note that on the ROOL homepage the link labelled Software compatibility leads to a page called ARMv6/v7 software compatibility list that mentions ARMv6/v7 but not ARMv8. There is a link from it to a page called ARMv7 compatibility primer which mentions ARMv6, ARMv7 and ARMv8. This is a bit confusing. May I suggest that ARMv7 and ARMv6/v7_ be replaced in these titles by ARMv6/v7/v8 ? There will be links on other pages (e.g. Introduction to RISC OS ) that will need emending accordingly. Also may I suggest that the png file armv7ok.png acquire cousins armv6ok.png and armv8ok.png ? |
Rick Murray (539) 13406 posts |
But would such a thing be reliable? Zap (and other stuff) worked fine on the ARMv7 Beagle. It all failed on the ARMv7 Pi2… There’s more to it than just processor family. |
GavinWraith (26) 1532 posts |
I agree. But it would give slightly more information. The problem may cure itself statistically, because I expect the Rpi3 to outsell the Rpi1/2 in future, even for those who intend to use RISC OS on it. |
Jon Abbott (1421) 2601 posts |
I believe it’s AArch32 compatibility not ARMv8, as its specifically around the instruction set. Reiterating the point Rick has made, something may appear to be ARMv7 compatible because it runs on system X, but will fail on system Y because there’s a lot of implementation defined and deprecated instructions that aren’t implemented in the same way across ARMv7 cores. There’s also the elephant in the room. On paper use of R13/R14/PC are deprecated in ARMv7 in various forms and at some point there may be an ARMv7 core that enforces that, making RISCOS non-ARMv7 compatible – just to add to the confusion. We’re almost at the point where compatibility is machine specific. |
GavinWraith (26) 1532 posts |
That is going to make it hard for software providers to test their offerings. |
Rick Murray (539) 13406 posts |
Given ARMs target market is embedded devices usually running custom baked in firmware (often based around Linux or Android with binary blob drivers), there hasn’t ever really been much incentive to consider any sort of cross compatibility. Sure, ARMv7 and ARMv8 (etc) are fairly standardised, but the degree of leeway for deprecated things varies greatly. This is a non-issue in a context where the firmware will be built for the device. It affects us because we try to have an executable capable of running on both the Titanium and an A310; and we have a number of legacy applications that may do weird things by accident. Consider also that device booting is frequently completely different (the BCM family and the OMAP family behave very differently), the graphics hardware and GPU is quite different, and even the support for VFP/Neon varies. Plus ARM doesn’t seem to consider backwards compatibility to be an issue worth worrying about. Linux builds many things from source, Android builds from pseudo-code, so it’s a non issue there. For us, what ran on last year’s machine may fail horribly on this year’s hardware. We are very very far from the stage of having an ARM device booting itself up from a generic CD image like you can with any old PC. Something Linus has been somewhat shouty about. He has a point, but while ARM is weak in the desktop sector (few people actually change the OS on their tablet or phone, other than OTA updates) this won’t change. The OS can gloss over many such issues, and it can even fix some of them (such as having the unknown instruction handler recognise certain things (like SWP) and fake the expected behaviour, but ultimately if you use older compilers or have a mental hiccup while coding, later machines are less forgiving of weird code, such as the So: lack of standardisation 40%, bogus code 60%… More or less… |
Jon Abbott (1421) 2601 posts |
I believe this syntax was used in (legacy?) C code function headers which stacked the entry value of R13. |
Clive Semmens (2335) 3130 posts |
When did that get deprecated? Even the LDM version wasn’t deprecated in v7 when I was at ARM – it was UNPREDICTABLE and foolish to use, but not deprecated (nobody expected any implementation ever to test for it, nor did anyone expect to re-use that tangled smidgeon of instruction set space). The STM version isn’t even unpredictable, and can be perfectly useful. |
Rick Murray (539) 13406 posts |
Hasn’t it been for a while? Generally it would “do the expected thing” if the base was the first register stored, but if not (STMFD R12!, {Rx-Ry,R12} for example), the actual value stored would be unpredictable.
I think later versions of ARMv7 and all of ARMv8 have taken the opinion that foolish means throw an exception. An example being something I had to modify when I got my Pi2 because it did an LDR of a register to itself with writeback which is dumb and unpredictable. And on the Pi2 caused an exception. |
Clive Semmens (2335) 3130 posts |
Oh, I didn’t doubt that. After all, the last ARM ARM I worked on was in 2007. I just wondered when.
I presume that means for this case in particular, not for the general case – that would involve a LOT of logic, consuming both chip real estate and energy. Foolish ought to be dealt with by compilers, assemblers etc., not hardware! |
Clive Semmens (2335) 3130 posts |
Indeed. That it didn’t work for later registers was always an oddity, simply a result of the way early implementations worked. It would have been perfectly straightforward (and useful) to ensure that it worked whichever register was the base, but at that time that little extra bit of chip real estate (one 32-bit latch) mattered. |
Rick Murray (539) 13406 posts |
Indeed. I guess if you give a processor a gibberish instruction, you should expect a gibberish reply. That said – I wonder if this is all gearing towards priority for 64 bit with the 32 bit versions being less important.
It reminds me of the 6502. The original NMOS version had the undefined instructions doing all sorts of weird and wonderful things, while the CMOS version treated all of the undefined instructions as a NOP with varying length – I wonder how much logic it took to make all of those be NOPs? |
Jeffrey Lee (213) 6046 posts |
STMFD R0!, {R0-R1} is not an ambiguous instruction, just one that’s been deprecated I think the deprecation appeared in some version of the ARMv7 ARM. This is what the rev C ARMv7 ARM says: ARM deprecates the use of (STM) instructions with the base register in the list and ! specified. If the base register is not the lowest-numbered register in the list, such an instruction stores an UNKNOWN value for the base register. The reason for the deprecation is probably a mix of (a) avoiding some awkward edge cases for the silicon to deal with, and (b) an effort to eliminate (or at least trap) all cases of unpredictable behaviour in order to improve security. |
Clive Semmens (2335) 3130 posts |
So it appeared either in Rev B or Rev C – I don’t have Rev B. I wrote that part of Rev A 8~) and it certainly didn’t appear there! I suspect you’re right about dealing with unpredictable behaviour for security reasons. |