[libre-riscv-dev] [Bug 279] New: inconsistency in 3.0B spec on definition of "equivalence" operator

[libre-riscv-dev] [Bug 279] New: inconsistency in 3.0B spec on definition of "equivalence" operator

[bugzilla-daemon]

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@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@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.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 279] inconsistency in 3.0B spec on definition of "equivalence" operator

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=279

Jacob Lifshay <programmerjake@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake@gmail.com

--- Comment #1 from Jacob Lifshay <programmerjake@gmail.com> ---
In my opinion, both == and XNOR (as well as != and XOR) can be used to denote
the same operation, but with two different ways of thinking about it:

1. XNOR/XOR used when flipping bits, (carry-less) adding, LFSRs, etc.
2. ==/!= used when checking for same/different values.

So pick which one you use based on how you are thinking about it, perhaps with
a note about being the same as the other operator when relevant.

Jacob

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 279] inconsistency in 3.0B spec on definition of "equivalence" operator

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=279

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #1)
> In my opinion, both == and XNOR (as well as != and XOR) can be used to
> denote the same operation, but with two different ways of thinking about it:
> 
> 1. XNOR/XOR used when flipping bits, (carry-less) adding, LFSRs, etc.
> 2. ==/!= used when checking for same/different values.

yes, interestingly, Anton, in Microwatt, splits up add/sub into its
sub-components:

* add 0, 1, carry
* actual add
* invert / don't bit-invert result (1s complement)

therefore, bit-inversion of the result could, hypothetically, be done
here as well.

i "solved" this one temporarily by removing the XNOR operator and
replacing it with invert (a XOR b)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev