* TODO: update wiki to describe always writing
* TODO: partially undo:
* TODO: look for other wiki changes that need to be made.
* WIP?: change openpower-isa.git to account for failing element writing.
* TODO: add unit tests for RC=1 writing failing subvector with subvl>1
programmerjake (talking about using fail-first for pcdec.):
> uuh, RC1=1 can't be used, since the spec says the results are never stored,
> only the CR outputs...the whole point of pcdec. is the RT output, without
> it it's mostly useless
> either that or the spec is unclear
> > Note that when RC1=1 the result elements are never stored, only the CR Fields.
> imho the spec should be changed to always write outputs for each element up
> to and including the first one that fails the data-dependent fail-first
> test, only elements after that one are not executed. VL being set to exclude
> the failing element should happen after.
> that way, an element is always fully-executed or not executed. not
> all outputs, RT, CR, OV, etc.
well, the purpose of VLi mode is simply to save an annoying
"VL += 1" in hot-loops, on detection of truncation. if that
can at least be detected then it's fine, no need to modify
my feeling is that it *may* be worthwhile thinking of a new
RM Mode for this type of instruction, one which uses CR.lt
and CR.gt as indicators whether to increase srcstep and
yep agreed, RC=1 should write its results for DD FF mode.
btw if something more complex is needed (FFirst inv/crbit with
VLi i.e. not just eq/ne) then crand, cror can be used, even if
the cror is an apparent nop (sv.cror *0,*0,*0) it gives the chance
to walk (and test) the CRfield bits.
still have to properly code up crops, that they work at all in
sv/trans/svp64.py is a total coincidence of the similarity between
crops and normal mode.
added todo list in top comment
(In reply to Jacob Lifshay from comment #0)
> * TODO: add unit tests for RC=1 writing failing subvector with subvl>1
it's not that simple.
the "stop" point will be not only in the middle of an outer
loop, but in the middle of an *inner* loop as well.
do you carry on to the end of the inner loop, long past the initial fail?
where is the state information "fail after the end of something that
happened up to 3 instructions ago?"
what if there is an interrupt in the middle?
how do you know which subvector element was the one that failed,
when all the SVSTATE src/dst steps including substeps have been
reset to zero?
DDFF subvectors are basically not practical.
(In reply to Luke Kenneth Casson Leighton from comment #4)
> DDFF subvectors are basically not practical.
the reason is that if you truncate SUBVL it is meaningless.
and also SUBVL is specified in the instruction, not in SVSTATE.