[libre-riscv-dev] discrepancy in v3.0B spec immediate shift operations regarding sh field, XS-form

[Luke Kenneth Casson Leighton]

apologies again, keenly aware that the team is extremely busy with POWER10.

another discrepancy has been detected in the V3.0B specification
regarding all XS (and MD) Form fields for "sh".  V3.0B p20 Book I
Section 1.7, sh is defined - *defined* - as:

sh (30,16:20)
    Fields that are concatenated to specify a shift
    amount.
    Formats: MD, XS

this as best i can tell places the bits of sh into the correct order -
*as defined by this section*.

now let us move to a definition of an XS-Form instruction, for example
extswsli.   the bits are identified as:

31   RS    RA    sh    445 sh Rc
0    6    11    16    21     30 31

*however* - and here is where the discrepancy exists - the pseudo-code
then goes on to place sh[5] into a *different* position:

   n <- sh[5] || sh[0:4]

this as best i can tell does effectively exactly the same
bit-reordering as the definition covered in Section 1.7 and
consequently *does it twice*.

it could be argued that the pseudo-code is "clear" because it is
taking the bits from the instruction field and "re-ordering" them,
however remember that *by definition* in Section 1.7 *those bits have
already been re-ordered*.  bit 30 is, by definition in Section 1.7,
*already* sh[5].

consequently we logically conclude that the pseudo-code is incorrect,
in all cases (sradi, extswsli, rldimi, rldic, rldicl, rldicr) and
should simply be:

    n <- sh

this change has been tested and found to be correct.

unfortunately, again, i must apologise: as we are critically dependent
on the actual pseudo-code for correct functionality of the
python-based cycle-accurate simulator, we have to commit these changes
to the published pseudo-code on the libre-soc.org website, without
delay, as part of the funding remit from NLNet, under the PET
Programme.

l.

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68