[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] VSX registers definition question
From: |
Jacques Mony |
Subject: |
Re: [Qemu-ppc] VSX registers definition question |
Date: |
Wed, 28 Aug 2013 13:59:35 +0000 |
Hello,
That's my understanding.
However, I am wondering what the best approach is from the following 2 (or any
other?):
- Access GP registers array for lower 64 bits and vsr for higher 64
bits, for the first 32 registers and then use the 32 VR registers for the
second block of VSX registers (It makes sense but adds a layer of logic on all
instructions (slighly less efficient?). But it would limit the impacts on the
rest of the code, which of course is non-negligible.)
- Modify the arrays to have a 64 range of 128 bits registers and modify
all the existing addressing in existing opcodes (Honestly, don't like it)
Jacques
-----Message d'origine-----
De : Alexander Graf [mailto:address@hidden
Envoyé : 28 août 2013 09:39
À : Jacques Mony
Cc : address@hidden
Objet : Re: [Qemu-ppc] VSX registers definition question
On 19.08.2013, at 21:31, Jacques Mony wrote:
> Hello,
>
> In target-ppc/cpu.h, there is the following definition:
>
> /* VSX registers */
> uint64_t vsr[32];
>
> However, according to PowerISA 2.06B, there should be 64 of them, of 128 bits
> size.
>
> Moreover, they should be sharing content with FPR (32 first entries, 64 bits)
> and VSR (32 last entries).
>
> What would be the best way to realign the array and make it map the same
> registers as FPR and VSR ? Would resizing the array break backward
> compatibility of saved VMs?
If I understand the spec correctly, the only thing VSX buys you in terms of
register space are the high 64bits to the FP registers. VRs are already 128
bits. So what this array defines are exactly those 32 fields that sit on top of
the FP registers, no?
Alex