cf to conversation:
http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-February/003861.html

I think I have sub, neg, and carry out working now

(In reply to Michael Nolan from comment #2)
> I think I have sub, neg, and carry out working now

(confirmed here the unit test runs.  a good TODO would be
a formal unit test however we need to do the MoU for that)

niice, it looks like...

+                        bit_set = int(math.log2(lsb))
+                        carry_result |= c << int(bit_set/4)

yeah, then tested that... excccellent, muahahah.

of course (sigh) now eeeverything has to have carry in it, but hey :)

oh wait... do you think you could update the docstring of PartitionedAdder,
make sure i got it right, and/or simply remove the table, replace it with
the link below (or "see wiki page listed at top of page") and edit that instead?

https://libre-riscv.org/3d_gpu/architecture/dynamic_simd/add/

this is kinda important so that people looking at this stuff, from an
educational and review perpsective can go "ok that's actually
understandable".

(In reply to Luke Kenneth Casson Leighton from comment #4)
> oh wait... do you think you could update the docstring of PartitionedAdder,
> make sure i got it right, and/or simply remove the table, replace it with
> the link below (or "see wiki page listed at top of page") and edit that
> instead?

Updated

(In reply to Michael Nolan from comment #5)
> (In reply to Luke Kenneth Casson Leighton from comment #4)
> > oh wait... do you think you could update the docstring of PartitionedAdder,
> > make sure i got it right, and/or simply remove the table, replace it with
> > the link below (or "see wiki page listed at top of page") and edit that
> > instead?
> 
> Updated

star.

ah! spaces, michael! :)  i caught one in an earlier commit as well
(src/ieee754/part_shift_scalar/formal/proof_shift_scalar.py)


+    exp-b    : 0BBBBIBBBBIBBBBIBBBBIBBBBc (32+2 bits plus 4 zeros)
+    exp-o    : o....oN...oN...oN...oN...x (32+4+2 bits - x to be discarded)
     o        :  .... N... N... N... N... (32 bits - x ignored, N is carry-over)
-    carry-out:      o    o    o    o      (4 bits)
+    carry-out: o    o    o    o    o      (5 bits)
vvv SPACE SPACE SPACE SPACE
+    
^^^ SPACE SPACE SPACE SPACE
+    A couple of differences should be noted:

it may sound funny / pedantic however when you are looking at every single
person's diff (like i am) and the spaces show up in red, because if someone
uses a different editor then the whitespace mods end up as well and you
can't tell what's code and what's whitespace in a commit review, that becomes
a major distraction to the reviewer (and other code-readers).

please always always do a "git diff" prior to "git commit", skim-read it
all to the bottom, and you'll see that bash deliberately highlights
extraneous space in red.

i'll update the HDL workflow to match this.

-    carry-in :           c    c    c    c (4 bits)
-    C = c & P:           C    C    C    c (4 bits)
-    I = P=>c :           I    I    I    I (4 bits)
+    carry-in :      c    c    c    c    c (5 bits)
+    C = c & P:      C    C    C    C    c (5 bits)
+    I = P=>c :      I    I    I    I    c (5 bits)


err... oh yes!  of course, well spotted: the example i had done (or
maybe it was jacob), actually it is 5 partitions, but only 4 bits to
subdivide them, and i'd gotten confused when adding the number of
carry-in and carry-out bits.

good catch.

> ah! spaces, michael! :)  i caught one in an earlier commit as well
> (src/ieee754/part_shift_scalar/formal/proof_shift_scalar.py)

ARGH! I added a pre-commit hook that runs flake8 with the trailing whitespace and line width warnings to catch exactly this, but it looks like I don't have it configured quite right (there's a separate warning for the whitespace on a blank line)

(In reply to Michael Nolan from comment #8)
> > ah! spaces, michael! :)  i caught one in an earlier commit as well
> > (src/ieee754/part_shift_scalar/formal/proof_shift_scalar.py)
> 
> ARGH! I added a pre-commit hook that runs flake8 with the trailing
> whitespace and line width warnings to catch exactly this, but it looks like
> I don't have it configured quite right (there's a separate warning for the
> whitespace on a blank line)

:)

it's a useful thing to do to get into the habit of always typing "git diff"
prior to literally every "git commit" even if it's just to skim-read.

with the [justifiably-breakable-] rule being "keep commits reasonable and
small(-ish)" this isn't burdensome at all.

it also means you get to see exactly what you've done, right before you
start typing up the git commit message.