[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1056

--- Comment #8 from paulus at ozlabs.org ---
"Definition of Strict Program Order" section:

This material is a bit hard for the reader to understand when you haven't yet
introduced any details about the iteration of the underlying instruction. I
think this should wait until after you have talked more about how the iteration
occurs.

1st paragraph: you define "Strict Program Order". How does this relate to other
similar concepts defined in the architecture, specifically the sequential
execution model defined in Book I section 2.2, "program order" defined in Book
II section 1.1, and the permitted deviations from the sequential execution
model described in Book III section 1.2.3? Is your term the same as any of
those, or if not, how does it differ? I strongly recommend using the existing
terms if at all possible.

2nd and 3rd paragraphs: the comparison and contrast with other ISAs is not
appropriate or helpful. The architecture needs to stand on its own feet and not
require references to other architectures. Also, the Power ISA usually uses the
term "Current Instruction Address" rather than "Program Counter", so the term
"Sub Program Counter" should be replaced by "Current Iteration Counter" or
similar.

I think what you are trying to say here is that (a) Simple-V defines a specific
order to the iterations it performs, (b) the iterations must appear to the
program to be executed in that order, and (c) the Current Iteration Counter is
exposed in the SVSTATE SPR, allowing interrupts to be taken within the sequence
of iterations. (Point (c) may be Book III material in fact -- what happens if a
program explicitly sets the Current Iteration Counter in SVSTATE to a non-zero
value before executing an SVP64 instruction?)

Saying "Simple-V has been carefully designed" sounds self-congratulatory. I
think you're just saying that all of the state needed to resume a sequence of
iterations after an interruption at any point is available in the SVSTATE SPR.
Is there more to it than that?

4th paragraph: Interrupts are Book III material, strictly speaking. You
probably need to add a subsection somewhere in Book III Chapter 7 talking about
interruption of SVP64 iterations.

You say "and the four REMAP SPRs if in use at the time". How is an interrupt
handler to know whether the REMAP SPRs are in use?

Saying "Whilst this initially sounds unsafe ..." assumes a certain ignorance on
the part of the reader which may not be justified. A Programming Note that says
something along the lines of "Interrupt handlers and function prologs should
generally avoid using SVP64 instructions until after Simple-V architected state
has been saved to memory", with the possible addition of "just as they avoid
using Floating-Point, Vector or VSX instructions until after the associated
state has been saved to memory".

Saying "which is very rare for Vector ISAs" is at risk of becoming dated, and
doesn't help our understanding of Simple-V itself.

5th paragraph: Defer this to the description of Parallel Reduction. It's not an
exception to the general rule, and we don't know what Parallel Reduction is at
this point, so it's confusing.

6th paragraph: Again, this is not an exception to the general rule, and we
don't know how the remapping works at this point, so defer this to the
description of remapping.

7th paragraph: stated more concisely, it seems that what you're saying is that
using CR predication on an instruction that modifies CR gives boundedly
undefined behaviour. Is that correct? If so it needs to be stated (or
re-stated) at the point where CR predication is defined. (You could
alternatively define that as an invalid instruction form (see Book I section
1.8.2), allowing an HEAI to be generated.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.