On 17 May 2018 at 17:51, Richard Henderson <richard.hender...@linaro.org> wrote: > On 05/17/2018 08:57 AM, Peter Maydell wrote: >> 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 ? > > You're right that it's not a proper int128 for host arithmetic. Fortunately, > the only operation we have on 128-bit values, at present, is move. > > How better might you word the commit message?
You could add in the comment in the function something like: "For 32 byte elements, we return an offset of zero. The two halves will not form a host int128 if the host is bigendian, since they're in the wrong order. However the only 32 byte operation we have is a move, so we can ignore this for the moment. More complicated 32 byte operations would have to special case loading and storing from the zregs array." thanks -- PMM
