In quite many instruction descriptions it says:
if d == 15 then UNPREDICTABLE;
What does this mean?
Can the instruction really work in some unexpected way in each such case or what?
I guess if I use a bit-reversing instruction on PC I should expect that the address
the processor jumps is hard to follow, but as such it's not UNPREDICTABLE.
It would be UNPREDICTABLE, however, if the next instruction can be fetched from an address
where the bits are only partially reversed.
I'm wondering, because every second instruction (or maybe more) seems to have that
'warning' in the description.
Hello.
I think it means the implementation dependent.
Basically writing to R15 (or PC) causes the jump.
The internal logics to cause the jump would be limited to the simple ALU such as MOV (including Lord), ADD or SUB.
If nervous or honest designer might implement so that writing to R15 might always caused the jump.
Best regards,
Yasuhiko Koumoto.
ARM has a glossary of terms like that
http://infocenter.arm.com/help/topic/com.arm.doc.aeg0014g/AEG0014G_ARM_corporate_glossary.pdf
Thanks. I didn't know about the glossary. There seemed to be some other terms, that I've been wondering about, explained.
UNPREDICTABLE means truly unpredictable - it can be even implemented as UNDEFINED.
This I had ro read several times:
UNPREDICTABLE behavior must not perform any function that cannot be performed at the current or a lower level of privilege using instructions that are not UNPREDICTABLE
UNPREDICTABLE behavior must not perform any function that cannot be
performed at the current or a lower level of privilege using instructions
that are not UNPREDICTABLE
Does that essentially say, that UNPREDICTABLE behaviour must not violate the privilege restrictions?
Like, an UNPREDICTABLE instruction executed in user mode must not be able to set the machine into
SVC-mode, and such.
It's a bit weird that for even MUL it says:
"if d == 15 || n == 15 || m == 15 then UNPREDICTABLE;"
Hello,
I agree with you.
For the read operand, I desire the PC value should be stable and definite.
Yes that is what it is saying in effect.
Yes. I could understand if the result value is implementation dependent if PC is used for Rn, but that UNPREDICTABLE?
Maybe even implemented as UNDEFINED?
And even if implemented such that it does it in a definite way (say, PC-value is always current instruction address + 4) ,
it must not be documented - it has to remain UNPREDICTABLE not to give users a reason to believe that they can trust on it.
UNPREDICTABLE behavior must not be documented or promoted as having a defined effect.