[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 #26 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Luke Kenneth Casson Leighton from comment #14)
> (In reply to Paul Mackerras from comment #4)
> 
> > In this and subsequent paragraphs, you keep hammering on the idea that the
> > underlying scalar instruction is (a) a word instruction 
> 
> this is mandatory and inviolate, yes.
> 
> > and (b) completely unchanged in its behaviour.
> 
> except for elwidth-overrides, yes.
> 
> it goes like this:
> 
>   for i in range(VL):
>       {DO_SCALAR_DEFINED_WORD_INSTRUCTION}
> 
> where predication would be:
> 
>   for i in range(VL):
>       if predicate_mask[i]:
>           {DO_SCALAR_DEFINED_WORD_INSTRUCTION}
> 
> the instruction *hasn't* changed - not in the slightest bit - just because it
> is predicated.
> 
> > Neither is in fact true. As to the unchanged
> > behaviour, it is not clear why that would be so crucially important even if
> > it were true.
> 
> dramatic simplification of Decode Phase.

At this point what we need explained is *what it is*. Things such as why it is
good for it to be the way it is, or what other possible things you could think
of that would be much much worse, are secondary considerations here. Once we
understand what it is, then we might be able to understand those other things
(or we might not care, if we are just trying to program the thing and don't
know or care what a decode phase is, and still less have any ambition to extend
the ISA in any direction).

> > Instead it would be far more helpful to put a complete list of the ways that
> > the behaviour of the underlying instruction is (or can be) changed.
> 
> strictly-speaking: element-width overrides, and that's it.
> that's the *only* change, and that's covered by ls005.xlen.
> 
>   for i in range(SVSTATE.VL):
>       if PREFIX.elwidth == 8:
>           {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=8-bit}
>       else if PREFIX.elwidth == 16:
>           {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=16-bit}
>       else if PREFIX.elwidth == 32:
>           {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=32-bit}
>       else if PREFIX.elwidth == 64:
>           {DO_SCALAR_DEFINED_WORD_INSTRUCTION... BUT @ XLEN=64-bit}
> 
> that *still* does not imply that the actual Defined Word Instruction
> itself "changed" [became a multiply instead of an add, had access
> to other operands, etc.]

Irrespective of what you would consider a "change" to the instruction, the
reader does need to know at this point what could be different in the execution
of the instruction compared to the plain instruction, and since this a
reference work, it needs to be a complete and accurate list.

The list would include the registers accessed, the element size, which bits of
the destination are updated, the nature of the arithmetic operation (if
saturating arithmetic can be specified), and whatever else could be different
from the plain instruction.

And since this is a reference work and you gave a complete and accurate list,
any other changes to execution are implicitly forbidden.

> the looping *REALLY IS* a completely separate concept from the
> {execution-of-the-Defined-Word-Instruction} - it *REALLY IS*
> a Sub-Current-Execution-Counter (CIA.SVSTATE)
> 
> 
> (strictly-speaking not so for Register numbers, which techincally
>  become "split fields" - but i demonstrate here why attempting to
>  put those into the actual RTL - of every single damn instruction -
>  would be absolute hell
>  https://libre-soc.org/openpower/sv/ls010/hypothetical_addi/ )

ah, is that where the split fields thing came from...

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