[libre-riscv-dev] [Bug 132] SIMD-like nmigen signal for partitioning

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #30 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #29)
> I managed to rework the multiplier code, will write a test tomorrow.
> 
> Whilst the ALU parts of this experiment are easy enough, control and
> decision making is not. Mux can be made a class member of the partitioned
> signal, however m.If and m.Case cannot.
> 
> Fortunately i think Case is never used except in things like global
> operands, however m.If and Else are used all over the place.
> 
> I haven't yet fully thought through how m.If when made partitionable would
> even work.
> 
> It would need to hide a set of *adaptive* boolean tests, where the objects
> within the context would also need the same partitioning.
> 
> It is actually quite fascinating.

I actually think it may be better to refactor the code to use Mux instead of
m.If and m.Else:

1. we won't have to modify nmigen's Module

2. it appears as though we have been subconsciously thinking that m.If somehow
makes the logic inside the m.If less expensive when the condition is
dynamically disabled. Having an explicit Mux may fix that.

3. we will need to review and, if needed, rewrite code anyway when converting
to partitioned form. rewriting to Mux may help us avoid missing any code.

for part 3, we will need PartitionedValue to not be derived from nmigen's Value
to allow nmigen to catch mixups.

It may also be a good idea to use a slightly different name for Mux since they
are different operations, how about MuxP for Mux-partitioned? that would allow
using a free function/class instead of a member.

-- 
You are receiving this mail because:
You are on the CC list for the bug.