From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: openpower-hdl-cores@mailinglist.openpowerfoundation.org
Cc: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: [libre-riscv-dev] discrepancy in v3.0B spec immediate shift operations regarding sh field, XS-form
Date: Mon, 13 Jul 2020 14:08:45 +0100
Message-ID: <CAPweEDzPcjfZzDk2s=EjzQFLP9i9zarggCi6XWZ7r6yMGZFxnw@mail.gmail.com> (raw)
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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
reply index
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPweEDzPcjfZzDk2s=EjzQFLP9i9zarggCi6XWZ7r6yMGZFxnw@mail.gmail.com' \
--to=lkcl@lkcl.net \
--cc=libre-riscv-dev@lists.libre-riscv.org \
--cc=openpower-hdl-cores@mailinglist.openpowerfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Libre RISC-V Mailing list Archives (accessible via public-inbox)
Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev
Example config snippet for mirrors
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git