[libre-riscv-dev] partitioned compare and mux

[Luke Kenneth Casson Leighton]

On Fri, Feb 7, 2020 at 10:30 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Feb 7, 2020, 14:23 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > ... damn, you're right.  yes.  we'll need to have the ability to
> > drop-in multiple extra carry bits in at various points.
> >
> > oh wait: i know.  yes, if you look at the way that the partitioning
> > works, extended-A is set up to have the partition points (inverted)
> > inserted in, however B very deliberately has *zeros* inserted in.  if
> > instead the "carry_in" is inserted into those points (the carry_in[0]
> > still has to be added in as a "pre-LSB") then that solves that one.
>
>
> we need to make sure that carry isn't accidentally propagated from the
> previous partition,

yes, this bit is where i get confused: this last bit is the one that
needs to become the carry-out... yes, as well as not accidentally
propagated.

> also, if a particular partition is merged with the
> previous partition, the carry in needs to be masked off to avoid
> accidentally adding a carry when there was none.

ok so one of the conditions would be that the carry_in is only
relevant at the beginning of the partition.  i'm tempted to suggest
that if a carry bit _is_ set in the middle of a partition, it would be
a hardware-fault.

i.e. the numbers attempting to be added had been divided up 8-16-8
(partition = 101) and yet the carry_in was set for a 16-16?  i.e. the
carry was not 0N0N?  that would be bad.

l.