Re: Vector Memory Ordering
Allen Baum
If the memory ordering (in this case specifically memory access ordering, I think - correct me if I'm wrong) doesn't affect the final processor state (which would not be the case for a vector reduce that started reduction as the values became available, instead of in some specific order), I don't know that compliance tests can tell the difference. Where this does affect processor state is exception reporting: a golden model which accesses results in one order may not have the same exception state as an implementation that accesses in a different order. Ditto for watchpoints (are they considered architectural?). A possible way to fix this is to have the golden model access in a canonical order, and implementations delay exception reporting until all accesses from logically previous addresses are complete (and any logically previous exception override one that was reported earlier) Debug compliance testing will be verry interesting.... Non-idempotent memory accesses will also affect final state, but I'd argue that is non-ISA and we won't be testing that. Concurrent, overlapping accesses is another pain point.
On Tue, Sep 8, 2020 at 7:21 AM mark <markhimelstein@...> wrote:
|
|