[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH v3-a 26/27] target/arm: Extend vec_reg_offset to l
From: |
Peter Maydell |
Subject: |
Re: [Qemu-arm] [PATCH v3-a 26/27] target/arm: Extend vec_reg_offset to larger sizes |
Date: |
Thu, 17 May 2018 16:57:45 +0100 |
On 16 May 2018 at 23:30, Richard Henderson <address@hidden> wrote:
> Rearrange the arithmetic so that we are agnostic about the total size
> of the vector and the size of the element. This will allow us to index
> up to the 32nd byte and with 16-byte elements.
>
> Signed-off-by: Richard Henderson <address@hidden>
> ---
> target/arm/translate-a64.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/target/arm/translate-a64.h b/target/arm/translate-a64.h
> index dd9c09f89b..5a97ae2b59 100644
> --- a/target/arm/translate-a64.h
> +++ b/target/arm/translate-a64.h
> @@ -67,18 +67,18 @@ static inline void assert_fp_access_checked(DisasContext
> *s)
> static inline int vec_reg_offset(DisasContext *s, int regno,
> int element, TCGMemOp size)
> {
> - int offs = 0;
> + int element_size = 1 << size;
> + int offs = element * element_size;
> #ifdef HOST_WORDS_BIGENDIAN
> /* This is complicated slightly because vfp.zregs[n].d[0] is
> * still the low half and vfp.zregs[n].d[1] the high half
> * of the 128 bit vector, even on big endian systems.
> - * Calculate the offset assuming a fully bigendian 128 bits,
> - * then XOR to account for the order of the two 64 bit halves.
> + * Calculate the offset assuming a fully little-endian 128 bits,
> + * then XOR to account for the order of the 64 bit units.
> */
> - offs += (16 - ((element + 1) * (1 << size)));
> - offs ^= 8;
> -#else
> - offs += element * (1 << size);
> + if (element_size < 8) {
> + offs ^= 8 - element_size;
> + }
> #endif
> offs += offsetof(CPUARMState, vfp.zregs[regno]);
> assert_fp_access_checked(s);
This looks right for element sizes up to 8, but I don't understand
how it handles 16 byte elements as the commit message says -- the
d[0] and d[1] are the wrong way round and don't form a single
16-byte big-endian value, so they must need special casing somewhere
else ?
thanks
-- PMM
- [Qemu-arm] [PATCH v3-a 17/27] target/arm: Implement SVE Stack Allocation Group, (continued)
- [Qemu-arm] [PATCH v3-a 17/27] target/arm: Implement SVE Stack Allocation Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 19/27] target/arm: Implement SVE Compute Vector Address Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 18/27] target/arm: Implement SVE Bitwise Shift - Unpredicated Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 21/27] target/arm: Implement SVE floating-point trig select coefficient, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 20/27] target/arm: Implement SVE floating-point exponential accelerator, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 23/27] target/arm: Implement SVE Bitwise Immediate Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 22/27] target/arm: Implement SVE Element Count Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 25/27] target/arm: Implement SVE Permute - Extract Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 24/27] target/arm: Implement SVE Integer Wide Immediate - Predicated Group, Richard Henderson, 2018/05/16
- [Qemu-arm] [PATCH v3-a 26/27] target/arm: Extend vec_reg_offset to larger sizes, Richard Henderson, 2018/05/16
- Re: [Qemu-arm] [PATCH v3-a 26/27] target/arm: Extend vec_reg_offset to larger sizes,
Peter Maydell <=
- [Qemu-arm] [PATCH v3-a 27/27] target/arm: Implement SVE Permute - Unpredicated Group, Richard Henderson, 2018/05/16
- Re: [Qemu-arm] [Qemu-devel] [PATCH v3-a 00/27] target/arm: Scalable Vector Extension, no-reply, 2018/05/17
- Re: [Qemu-arm] [PATCH v3-a 00/27] target/arm: Scalable Vector Extension, Peter Maydell, 2018/05/18