On Fri, 16 Oct 2020 07:48:00 -0400, "David Horner" <ds2horner@...> 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.
