[Libre-soc-bugs] [Bug 864] implement parallel prefix reduction in simulator

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=864

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #2)
> (In reply to Luke Kenneth Casson Leighton from comment #1)
> > first version including a "yield" version which does not require
> > a move operation.
> > 
> > https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/preduce.py;
> > h=5fb4f26f6d349e5fdf0d15cb50f66a4da6fa40e4;
> > hb=13c4a19e93caf4dc817c508f70f3af42749a7a87
> 
> try testing with a predicate of [0,0,0,0,1,1,1,1], you'll see that element 0
> (the expected output by the compiler) never gets written to,

    vec = [1, 2, 3, 4, 9, 5, 6, 8]
    prd = [0, 0, 0, 0, 1, 1, 1, 1]

    output: [1, 2, 3, 4, 28, 5, 14, 8]

that's expected behaviour.  the first four are masked-out, and
do not get altered. the sum ends up in the first non-masked-out element 
(element 4) 9+5+6+8=28


what *actually* happened was:

round 1:

* 6+8 [14] got stored in element 6
* 9+5 [14] got stored in element 4

round 2:

* 14+14 [28] got stored in element 4

this is "expected behaviour" and i have a suspicion that it does not
require the ORing of the predicate mask.  which would be a huge
advantage because it drastically reduces complexity and reduces state
especially on context-switches.


> hence why moves are necessary.

i've said it about five times now, it is getting very irritating for me
that you are not listening.

moves are NOT happening: please adapt your thinking so that the addition
of moves is entirely and 100% removed from all advocated solutions because
i have made it repeatedly and abundantly clear that moves are NOT going
to be part of the specification.  doing so violates strict RISC principles
and will cause no end of problems.

please help to SOLVE the problem rather than continuing to repeat "moves
are necessary moves are necessary"

they are NOT happening - period.

> also, you can think of reduction as doing operations where the predicates
> are on each element operation's *inputs* rather than its outputs, so,

there's two (for Twin-Predication)

> obviously it needs to do something different when one input is predicated
> off and the other input is still on -- move (or something similar -- e.g.
> integer subtract could be defined to assume predicated off inputs are
> replaced with 0 so a - b with a predicated off would output -b).

unfortunately, changing the inputs to zeros would result in some instructions
(multiply-prefix) outputting zero.

then when considering "ah but you can just make those have a 1 instead"
this massively complicates the decode-and-issue phase, introducing an
inter-dependency between the "Abstracted Schedule" and the "Element Operation"
which violates the strict RISC design principle of SV.

there was something else.  it occurred to me last week.  i can't remember
it, now.  something related to the predicate masks. it was important, and
was a reason why the original algorithm (with modifying predicate masks)
could not be used.

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