Re: [Qemu-devel] [PATCH 11/21] target-arm: Update generic cpreg code for AArch64

[Peter Crosthwaite]

On Thu, Dec 19, 2013 at 7:11 PM, Peter Maydell <address@hidden> wrote:
> On 19 December 2013 06:01, Peter Crosthwaite
> <address@hidden> wrote:
>> On Wed, Dec 18, 2013 at 1:12 AM, Peter Maydell <address@hidden> wrote:
>>> +                    *key = ENCODE_AA64_CP_REG(r2->cp, r->crn, crm,
>>> +                                              r->opc0, opc1, opc2);
>>
>> You have mixed terminology here with "opc" and "op". Should they be
>> unionised in ARMCPRegInfo?
>>
>> union {
>>     uint8_t op1;
>>     uint8_t opc1;
>> };
>
> That seems pretty ugly to me. The terminology mixing is kind of
> inevitable since AArch32 uses opc and AArch64 uses op.
>

The union does self-document that fact however.

>>> +                } else {
>>> +                    *key = ENCODE_CP_REG(r->cp, is64, r->crn, crm, opc1, 
>>> opc2);
>>> +                }
>>
>> Why the mutual exclusivity between 32 and 64 bit defs? Shouldn't it be
>> possible to define with one ARMCPRegInfo a register that exists in
>> both 32 and 64 and this code can just double add it to the hash table?
>> May need two flags to describe existence in either or both schemes
>> accordingly.
>
> Almost all the shared registers appear as 32 bit on the AArch32
> side and 64 bits on the AArch64 side.

Really? Reading v8, there are many 32 bit regs with these op0 AArch64
encodings, for example the documentation of MIDR_EL1:

Configurations
MIDR_EL1 is architecturally mapped to AArch32 register MIDR.
MIDR_EL1 is architecturally mapped to external register MIDR_EL1.
Attributes
MIDR_EL1 is a 32-bit register

CTR, REVIDR, ID_PFRx, CSSELR, CLIDR, DACR32 to name a few more that
are similarly documented and by no means an exhaustive list (I just
randomly picked those from the list).

Regards,
Peter


> This means the required
> fieldoffset value is different [or potentially so for bigendian hosts].
> So you'd only be able to share registers which were genuinely
> 64 bit on both sides, which are very rare. So it didn't seem worth
> trying to accommodate it.
>

The support 32 vs 64 encoding scheme seems quite othogonal to the
backing sotre bit width.

> -- PMM
>