Re: [RISC-V] [tech-cmo] Fault-on-first should be allowed to return randomly on non-faults (also, running SIMT code on vector ISA)


David Horner
 

On 2020-10-16 10:30 a.m., krste@berkeley.edu wrote:

On Fri, 16 Oct 2020 07:48:00 -0400, "David Horner" <ds2horner@gmail.com> said:
| First I am very happy that "arbitrary decisions by the
| micro-architecture" allow reduction of vl to any [non-zero] value.

| Even if such appear "random".
[...]
| 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.

If we allowed implementation to return vl=0, how does software
guarantee forward progress?
The forward progress is to advance to another task.

In the case of machine mode it can potentially "resolve" the cause of the vl=0 return and re-execute the loop (without the overhead of the trap).



| I see it as no different [in fundamental principle] than other cases
| such as RVI integer divide by zero behaviour that does not trap but can
| beĀ  readily checked for.
| Also RVI integer overflow that if you want to check for it is at most a
| few instructions including the branch.

I don't see how these examples relate to returning vl=0 on some
microarchitectural event. The examples here have results that depend
only on architectural values, so can be deterministically handled.
The similarity is the avoidance of trap handling, when it is sufficient to check instead register state.

vl=0 is more related to load-reserved/store-conditional failure, where
we need to add implementation constraints to guarantee forward
progress.
Ok. I can see providing guidance as to when vl=0 is allowed, but not to exclude it outright.


Krste

Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.