qemu-ppc
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]