Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)
i have not totally been following this discussion. but at convex we handled this very simply
if Vl = 0, no vector operation was executed, and the vector instruction was executed and sequential operation proceeded.
to the best of my knowledge this never came up as an issue
On Fri, 16 Oct 2020 18:14:48 -0700, Andy Glew Si5 <andy.glew@...> said:
| [DH]: I see this openness/lack of arbitrary constraint as precisely the strength of RISCV.
| Limiting vector operations due to current constraints in software (Linuz does it this way, compilers cannot optimize that formulation[yet])
| or hardware (reminiscent of delayed branch because prediction was too expensive) is short sighted.
| A check for vl=0 on platforms that allow it is eminently doable, low overhead for many use cases AND guarantees forward progress under
| SOFTWARE control.
| Sure. You could guarantee forward progress, e.g. by allowing no more than 10 successive "first fault" with VL=0, and requiring trap on element zero
| on the 11th. That check could be in hardware, or it could be in
| the software that's calling the FF instruction.
I don't want us to rathole on how to guarantee forward progress for
vl=0 case, but do want to note that this kind of forward progress is
nasty to guarantee, implying there's long-lasting microarch state to
keep around - what if you're context swapped out before you get to the
11th? Do you have to force the first one after a context swap to not
trim? What if there's a sequence of ff's and second one goes back to
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.