---+ Expanded
From vector meeting last Friday: trimming, fault-on-first.
I realized that it is similar to the forms of SW visible non-faulting speculative loads some machines, especially VLIWs, have. However, instead of delivering a NaN or NaT, it is non-faulting except for vector element 0, where it faults. The NaT-ness
is implied by trimmed vector length. It could be implied by a mask showing which vector operations had completed.
All such SW non-faulting loads need a "was this correct" operation, which might just be a faulting load and a comparison.
Software control flow must fall through such a check operation,
and through a redo of the faulting load if necessary. In scalar, non-faulting and faulting loads are different instructions, so there must be a branch.
The RISC-V Fault-on-first approach
has the correctness check for non-faulting implied by redoing the instruction.
i.e. it is its own non-faulting check. it gets away with this because the trend vector length indicates which parts were valid and not. forward progress is guaranteed by trapping on vector element zero, i.e. never allowing a trim to zero
length. if a non-faulting vector approach was used instead of fault-on-first, it could return a vector complete mask, but to make forward progress it would have to guarantee that at least one vector element had completed.
David Horner's desire for fault-on-first that may have performed no operations at all is (1)
reasonable IMHO (I think I managed to explain that the Krste), but (2) Would require some other mechanism for forward progress. E.g. instead of trapping on element zero, the bitmask that I described above. Which is almost certainly a bigger architectural
change than RISC-V should make it this time.
Although more and more I am happier that I included such a completion bitmask in newly every vector instruction set that I've ever done. Particularly those vector instruction sets that were supposed to
implement SIMT efficiently. (I think of SIMT as a programming model that is implemented on top of what amounts to a vector instruction set and microarchitecture. https://pharr.org/matt/papers/ispc_inpar_2012.pdf ).
It would be unfortunate for such an SIMT program to lose work completed after the first fault.
MORAL: fault-on-first may be suitable for vector load that might speculate past the end of the vector -
where the length is not known or inconvenient when the vector load instruction is started. Fault-on-first is
suboptimal for running SIMT on top of vectors. i.e. fault-on-first
is the equivalent of precise exceptions for in order execution,
and for a single thread executing vector instructions, whereas completion mask
allows out of order within a vector and/or vector length threading.
IMHO an important realization I made in that meeting is that fault-on-first does not need to be just about faulting. It is totally fine to have the fault-on-first stuff return up to the
first really long latency cost miss, as long as it always guarantees that at least vector element zero was complete. Because vector element zero complete is what guarantees forward progress.
Furthermore, it is not even required that fault-on-first stop at the first page-fault. An implementation could actually choose to actually implement a page-fault that did copy-on-write or swapped in
from disk. but that would be visible to the operating system, not the user program. However, such an OS implementation would have to guarantee that it would not kill a process as a result of a true permissions error page-fault. Or, if the virtual memory
architecture made the distinction between permissions faults and the sorts of page-fault that is for disk swapping or copy-on-write or copy on read, the OS does not need to be involved.
EVERYTHING about fault-on-first is a microarchitecture security/information leak channel and/or a virtualization hole. (Unless you only trim only on true faults and not COW or COR or disk swappage-faults).
However, fault-on-first on any page-fault is a much lower bandwidth information leak channel than is fault-on-first on long latency cache misses. so a general purpose system might choose to implement fault-on-first on any page-fault, but might not want
to implement fault-on-first on any cache miss. However, there are some systems for which that sort of security issue is not a concern. E.g. a data center or embedded system where all of the CPUs are dedicated to a single problem. In which case, if they can
gain performance by doing fault-on-first on particular long latency cache misses, power to them!
Interestingly, although fault-on-first on long latency cache misses is a high-bandwidth information leak, it is actually much less of a virtualization hole than fault-on-first for page-faults. The
operating system or hypervisor has very little control over cache misses. the OS and hypervisor have almost full control over page-faults. The usual rule in security and virtualization is that an application should not be able to detect that it has had an
"innocent" page-fault, such as COW or COR or disk swapping.
--
--- Sorry: Typos (Speech-Os?) Writing Errors <= Speech Recognition <= Computeritis
