On 2020-10-21 6:33 p.m., swallach
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
to the best of my knowledge this never came up as
To clarify, Andrew's reading of the spec has vstart>= vl
behaviour superseding vl=0 implied behaviour.
Thus some vector instructions are executed even when vl=0. vfirst
and vpopc are two of them.
On Fri, 16 Oct 2020
18:14:48 -0700, Andy Glew Si5 <andy.glew@...>
| [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
| Sure. You could
guarantee forward progress, e.g. by allowing no more than 10
successive "first fault" with VL=0, and requiring trap on
| 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
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.