[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 #58 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Luke Kenneth Casson Leighton from comment #51)
> (In reply to Paul Mackerras from comment #41)
> 
> > So every instruction whose behaviour is modified by vectorization has a
> > SVP64 prefix? 
> 
> has to, yes.  HOWEVER... and this is waaay into the future: due to
> the startling sililarity to ZOLC i have long-term plans to *SEPARATE*
> the 24-bits into a SEPARATE (3rd) L1 Cache.
> 
>    
> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.301.
> 4646&rep=rep1&type=pdf
> 
> that will be a huge research project on its own.

Let's get through the current proposal before we start worrying about future
research. :)

> > I haven't seen a clear and unambiguous answer as to whether
> > that is true or not. (You do seem to say it is true below, except that each
> > such statement seems to have some sort of caveat on it.)
> 
> it is.  an Embedded Finite State Machine (and Libre-SOC's TestIssuer
> does this) would:
> 
> * read the PO9-word
> * cache the 24-bit RM area and prohibit interrupts
> * read the next 32-bit word
> * throw {24}{32} at decode+issue+execute and re-enable interrupts
> 
> and that is an important Micro-Architecture to have (minimum resources).
> 
> i considered at some point having an actual SPR to store the state in
> between the two (the PO9-word and Defined-word-instruction) but i feel
> it is a tiny bit overkill.

Having an actual SPR would be a bad idea in my opinion because it would destroy
the property of being able to tell what registers are read and written just
from the instruction word(s). I realize that SV already lacks that property for
any vectorized instruction, but making that intermediate state explicit, and
settable by other means (e.g. mtspr) would destroy that property for any
instruction with register operands (i.e. almost all of them).

More generally, I think there is an important point here about how Simple-V is
understood and explained, which I hope I can get you to reconsider. You (Luke)
seem adamant that a vectorized instruction is not to be thought of as a
prefixed instruction, whereas it seems to me that explaining it as a prefixed
instruction has a lot of advantages and is the natural way to think about it.

The reasons for thinking of the instruction word containing the vectorization
parameters as a prefix, and the following instruction word as a suffix, are:

* The meaning and interpretation of the first word depend on the second. So the
first word is not an independent instruction in its own right. If the first
word were an instruction in its own right then you would be able to tell me
exactly what it does without reference to any following instruction.

* The meaning and interpretation of the second word do in fact get changed by
the first word. The first word can change which registers are accessed, which
parts of the registers, and other aspects such as what type of addition is
performed (saturating vs. two's-complement).

* You can't allow any interrupt, not even machine check or system reset,
between the execution of the first word and the execution of the second. In
other words you can't really let the first word "instruction" complete until
the second word has done its work.

* If you started to execute the function identified by the two words together
and then wanted to take an interrupt before you were finished, you would need
to set SRR0 to point to the first word, not the second. But if you think of the
two words as two separate instructions, you would naturally set SRR0 to point
to the second word, which would be wrong.

* If the two words are really two separate instructions, then you don't really
have any grounds for prohibiting certain instructions as the second word.

All of that says to me that the pair of words looks like a prefixed instruction
and acts like a prefixed instruction. So why not just call it one?

> attitudes on that vary, certainly the use of the same technique in
> RISC-V does not make people happy (the 18-bit in one instruction being
> concatenated with a 12-or-so bit immediate in the following instruction)
> 
> 
> 
> > It did seem like a "bare" addi (without SVP64 prefix) in a vertical-first
> > loop might be subject to register index modification, 
> 
> no absolutely not.  ok, i considered it, it is called "register tagging"
> which historically has been left by the wayside but is making a
> comeback in "Vector Streaming" in ARM SVE, Eth-Zurich Snitch, and
> the European Processor Initiative.
> 
> the problem with tagging is that it becomes part of the Architectural
> State (an SPR or in this case *group* of SPRs), which massively
> complexifies simulators debuggers etc.
> but also context-switch becomes absolute hell.

Right.

Thinking about this in a way that requires some kind of state to be set by the
execution of the first word really does seem to me to add complexity and not
aid comprehension. Any kind of hidden state tends to create difficulties (I
think the only hidden state we have in the ISA at the moment is the
reservation), and if you expose that state then you make it possible to be set
by other means, which opens another whole can of worms.

[snip]

> > I was concerned with the case where there is no SVP64 prefix before an
> > instruction. In that case, is it correct to say that it is guaranteed to
> > behave exactly in all respects as specified in the current architecture,
> > regardless of any values in SVSTATE or any other SPR?
> 
> aabsolutely correct. can you imagine the freaking-out that would occur?
> i can :)

I was starting to do that freaking out, so yes.

> (and save/restore context-switch would become a nightmare, you'd have
> no idea if you could safely use even one GPR!)

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