[Libre-soc-dev] svp64 questions: variable parallelism vs predictability

[Alexandre Oliva]

On Dec 26, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> the requirement is to provide the expected behaviour as if those
> instructions had been issued literally in the instruction stream.

literally and sequentally.  that was what I wasn't sure about.

> instructions issued by the Program Counter have strict ordering
> guarantees: why would the Sub-Program-Counter (0..VL-1) be treated any
> differently?

While some languages specify a strict ordering for array assignments,
requiring the infrastructure to satisfy certain guarantees, other leave
it unspecified, reducing the complexity for the implementation or giving
it more flexibility and room for optimizations, while shifting
trouble-avoidance onto another layer.

These are all valid design decisions, they just need to be documented.
E.g., the fact that the loop over the vector was intended to be taken as
sequential, rather than parallel, was not obvious to me, especially
given that AFAICT there isn't an option to count downwards rather than
upwards, as an implied ordering would suggest.


Now, detecting overlaps and enforcing serialization is something that
requires additional gates, and it's a job that a compiler could do
without much effort, so we could relieve the hardware and rely on
compilers to do this job.  E.g., overlaps could be ruled out entirely
(whether or not traps are mandated), or even specified and documented as
means to detect the amount of parallelism that a certain hardware
implementation offers, to then select ifuncs that best exploit the
available amount of parallelism.

OTOH, multi-issue already requires detection of dependencies across
insns, so it's not obvious that attempting to relieve the hardware from
this complexity in the vector case would accomplish much.


Anyway, it looks like a decision has already been made.  I'm a little
surprised that it enforces the strictest possible ordering, rather than
enabling flexibility to improve parallelism, but I'll just hope these
possibilities have been considered when the time was right to make these
decisions, and that the right decisions were made back then ;-)


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar