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
vl=0?

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.

http://www.bsc.es/disclaimer