[libre-riscv-dev] partitioned compare and mux
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Feb 7 23:07:54 GMT 2020
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>
> > ... 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
> > 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
> 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
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.
More information about the libre-riscv-dev