Re: [Qemu-devel] [PATCH 3/3] tcg/arm: improve constant loading

[Peter Maydell]

On 9 January 2011 23:33, andrzej zaborowski <address@hidden> wrote:
> On 9 January 2011 23:40, Aurelien Jarno <address@hidden> wrote:
>> Note that binutils is not able to disassemble such an instruction and
>> outputs in qemu.log something like:
>> | 0x01000008:  e3aa50ff  undefined instruction 0xe3aa50ff
>>
>> However what worries me the most is that the "ARM Architecture Reference
>> Manual ARMv7-A and ARMv7-R edition" defines this opcode with the rn field
>> as "(0)(0)(0)(0)". Looking at what it means:
>>
>> | An instruction is UNPREDICTABLE if:
>> | [...]
>> | * the pseudocode for that encoding does not indicate that a different
>> |   special case applies, and a bit marked (0) or (1) in the encoding
>> | diagram of an instruction is not 0 or 1 respectively.
>>
>> In short is it still going to work on newer CPUs?

It might not work on existing CPUs, never mind newer ones. We
mean it about UNPREDICTABLE :-) Some cores choose to make
patterns which fail these "should be zero/one" checks cause an
UNDEF exception. Some don't.

> I think it *should* work on the new ARM ISAs because of backwards
> compatibility: x works under ARMv4 & ARMv5 and x is not listed under
> the differences between new and old ISA, thus it needs to work under a
> new ISA.

I went back and checked the ARM ARM for ARMv4 (that's ARM
document DUI0100B, dated 1996). It says that for MOV and MVN
bits 19..16 are "SBZ", ie "Should Be Zero", meaning that non-zero
is UNPREDICTABLE. So this isn't a change in behaviour -- the
ISA has always been clear that you should not do it.

[Note for the unwary: UNPREDICTABLE in ARM docs doesn't
mean totally unpredictable -- an implementation isn't allowed to
permit it to be a security hole or to hang the processor, for instance.
But you can't rely on it doing anything useful or consistent.]

-- PMM