Norcroft generating LDMDB that takes undefined instruction on ARMX6
Stuart Swales (8827) 1323 posts |
A surprise this morning was an undefined instruction exception in a test program, on the instruction
This disassembles without warning in DecAOF, but This was generated by Norcroft v5.86 when loading a series of uint64_t’s onto the stack as args for a printf(). The ARMv7-A/R ARM C.d states “Instructions with the base register in the list and ! specified are only available in the ARM instruction set before ARMv7, and ARM deprecates the use of such instructions. The value of the base register after such an instruction is UNKNOWN.” I guess the compiler should avoid generating these when moving 64-bit quantities around! Is it just me, or does the Norcroft compiler of the last decade or two seem to add in spurious unnecessary writebacks for load/store single/multiple? It’s certainly the case with this example.
|
Clive Semmens (2335) 3274 posts |
I never wrote that! It’s in an edition later than my retirement. I don’t know who wrote it, or why. It’s such an imbecilic thing to try to do that it never occurred to me (or to any of the engineers involved) that it was necessary to mention it, and that any witless programmer who tries to do it deserves the obvious unpredictability that results. Unless the standard phraseology of the ARM ARM has changed, UNKNOWN is an error, too – the standard phraseology would have been UNPREDICTABLE in my day. |
Stuart Swales (8827) 1323 posts |
ARMv8 ARM seems to have gone back to UNPREDICTABLE for behaviour (with qualifiers): CONSTRAINED UNPREDICTABLE behavior If wback && registers<n> == '1', then one of the following behaviors must occur: • The instruction is UNDEFINED. • The instruction executes as NOP. • The instruction performs all of the loads using the specified addressing mode and the content of the register that is written back is UNKNOWN. In addition, if an exception occurs during such an instruction, the base address might be corrupted so that the instruction cannot be repeated.
Many compilers can be described as ‘witless programmers’. Sometimes I am delighted to see what they produce, but most of the time am dismayed. |
Rick Murray (539) 13747 posts |
What are they smoking? These instructions were never available, they just weren’t shot dead on sight. I mean, think about it. You’re loading Rn from an address pointed to by Rn, with the new address to be written back to Rn. |
David J. Ruck (33) 1585 posts |
Yes, I removed quite a few of these when porting things to 32 bit, as ARMalyser warns about them. |
Stuart Swales (8827) 1323 posts |
Indeed it is crazy, but for a time ARM got round to defining it to work in what would probably be the safer of the two options where execution completes: ARM7 has “When writeback is specified the base written back at the end of the second cycle … A LDM will always overwrite the updated base if the base is in the list”. ARM2 documentation was, of course, silent on the matter, as we weren’t all idiots. [Edit: ARM2 appears to be documented in the Data Abort section as behaving as defined by ARM7.] Hey, perhaps PatchSWP needs to be PatchCrazyShite? [Edit: Thought it best to report this issue over here as more people are likely to look at this, and maybe have used int64_t and friends and might need to give their code the once-over (ARMalyser is your friend), than the obscure stuff I’ve been reporting recently over in the actual Bugs reporting section.] |
Stuart Swales (8827) 1323 posts |
Thought that it might be particular to marshalling args for variadic functions, but can demonstate that it’s not. Someone will no doubt be along shortly to inform us of the error of our ways in using 64-bit values… ;-) |
Clive Semmens (2335) 3274 posts |
Surely any compiler that can be described as a witless programmer must have been written by a witless programmer? Assuming the “witless” means “stupid” of course, rather than literally “without a brain.” That compilers might faithfully follow the witless creations of witless programmers is understandable, but generating their own stupidities is unforgiveable. I had friends at ARM who wrote compilers; they were certainly very clever people, understood the instruction set(s) very well, and knew a lot about optimization. But they were – like the rest of us – always under the pressure of tight deadlines. Which might be a possible reason for apparent witlessnesses. |
Rick Murray (539) 13747 posts |
It’s always depressing how marketing promises the earth without consulting anybody else (especially those who must deliver on the promises), and the beancounters only look at short term gains so seem institutionally incapable of understanding that a poor product now is not as good as a better product later (assuming a reasonable definition of later). |
Stuart Swales (8827) 1323 posts |
“We’ve already shipped it” |
Paolo Fabio Zaino (28) 1821 posts |
Don’t forget the POs that at every decision like “ok you can either have (a) or (b)”, they systematically say “both” or the even more annoying “yes”, and then they come back with “but why do we have this problem?” and you have to tell them it’s because of the (ab) option that wasn’t in the list of feasible ones. Oh and the “website” of the competitor X that states they can do “A,B,C and D”, and so that’s good enough to say “if they did it we have to do it too”! The problem is that the competitor “forgot” to mention that they can only do “(A OR B OR C) AND D” not all of them at the same time… |