[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 #61 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Luke Kenneth Casson Leighton from comment #54)
> (In reply to Paul Mackerras from comment #26)
> > (In reply to Luke Kenneth Casson Leighton from comment #14)
> 
> > >  https://libre-soc.org/openpower/sv/rfc/ls010/hypothetical_addi/ )
> > 
> > ah, is that where the split fields thing came from...
> 
> yes, from PO1-Prefixing, consider the {24-bit}{32-bit} in the same
> way.  i consider such an approach to be a mistake for SV.
> 
> jacob and i went to a LOT of trouble to ensure that SV is an
> orthogonal consistent RISC paradigm.

That's good, but it's orthogonal to whether the pair of words are considered a
single instruction or a pair of instructions.

I am not saying that you would need to define a split field for each register
operand. There may well be a way to define the register operands precisely
without having to do that. But I definitely consider the SV vectorization word
and the following instruction word (which would be a scalar instruction in the
absence of the preceding word) to be a single instruction.

I understand that you may feel that defining the pair of words as a single
instruction might open the gates to defining very different interpretations of
the second word when vectorized compared to what it would be on its own as a
scalar instruction. The appropriate ways to defend against that are (a) don't
define any such very different interpretation in your proposal, (b) add an
Architecture Note explaining the consequences of defining a very different
interpretation, and (c) stay involved with the ISA TWG and vote against any
future proposal that seeks to add any such very different interpretation.

> therefore just saying RT moves to "a Vector Context" uniformly
> across the *ENTIRE* spec is both possible and reasonable.

It may well be possible to do that, but we would need to see the actual words.

I think that the saturating mode is very much a complicating factor here. If
the effect of vectorization was limited to changing operand sizes and
locations, that would be much easier to fit within the concept of a "vector
context". Maybe you should consider defining saturating arithmetic instructions
as new scalar instructions rather than having a saturating mode as part of
vectorization.

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