30.09.2019. 16.35, "Paul Clarke" <pc@us.ibm.com> је написао/ла:
>
> On 9/28/19 5:17 PM, Aleksandar Markovic wrote:
> > Also, check on the hardware the behavior listed as 'undefined' for
vsl/vsr
> > in the docs - even though it is tehnically irrelevant, I am courious
> > whether the old or the new (or none of them) solution match the
hardware.
>
> There does appear to be some odd behavior when one strays into the
undefined.  For example:
> source vector: 0102030405060708090a0b0c0d0e0f10
> shift  vector: 01020101010101010101010101010101
> after vsl:     020806080a0c0e10121416181a1c1e20
> ...this appears to use the byte-respective shift values
>
> using vsr with that result and the same shift vector:
> after vsr:     0182030405060708090a0b0c0d0e0f10
> I expected to get back a result matching the source vector, but somehow,
an extra bit got set.
>
> It would probably take some more thorough investigation to map out the
undefined behavior, but I doubt there's any value to that.
>

Absolutely agree. I thought if the 'undefined' behavior is something
obviously simple, we could try to match it, assuming also that it remains
constant across all implementations. But, this behaviour is not a simple
one, so, imho, let's leave 'undefined' undefined.

Thanks for a nice experiment!

Aleksandar

> PC