[libre-riscv-dev] [Bug 279] New: inconsistency in 3.0B spec on definition of "equivalence" operator
bugzilla-daemon at libre-riscv.org
bugzilla-daemon at libre-riscv.org
Sat Apr 4 20:54:12 BST 2020
http://bugs.libre-riscv.org/show_bug.cgi?id=279
Bug ID: 279
Summary: inconsistency in 3.0B spec on definition of
"equivalence" operator
Product: Libre-SOC's first SoC
Version: unspecified
Hardware: PC
OS: Linux
Status: CONFIRMED
Severity: enhancement
Priority: ---
Component: Specification
Assignee: lkcl at lkcl.net
Reporter: lkcl at lkcl.net
CC: libre-riscv-dev at lists.libre-riscv.org
NLnet milestone: ---
Section 1.3.4 p6
Equivalence logical operators ((a===b) = (a XOR ¬b))
Section 2.5.1 p40
The bit in the Condition Register specified by BA+32 is
XORed with the bit in the Condition Register specified
by BB+32, and the complemented result is placed into
the bit in the Condition Register specified by BT+32.
Section 3.3.13 p95
The contents of register RS are XORed with the con-
tents of register RB and the complemented result is
placed into register RA.
these are "technically" equivalent, however the definition is inconsistent
with the wording. to be consistent, Section 1.3.4 should read:
Equivalence logical operators ((a===b) = ¬(a XOR b))
however by an accidental property of XOR, they're the same.
also known as an "XNOR gate", which is *sigh* a better name than "Equivalence"
https://en.wikipedia.org/wiki/XNOR_gate
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev
mailing list