[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

[bugzilla-daemon at libre-soc.org]

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

--- Comment #99 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #97)
> > what you propose sounds perfectly reasonable for single-issue designs of
> 10-20 years ago.
> 
> Err, what you appear to be objecting now is to the 16-bit N=M=1 encoding for
> a 16-bit immediate, which is not something I propose.

ah then that is a misunderstanding.  what i understood you to have said is, at
the length-mode decode phase, embedded somewhere in the FSM:

   if N=M=1 # 16bit.imm mode
       # but wait... there is more
       # complexity
       if bits[A:B] == pattern1  or
            pattern2, 3, 4, 5 or 10
          # arbitrary suite of encodings
          # changes length and mode
          length = 32
          mode = compressed.something
       elif
       elif
       else
          length = 16
          mode = 16.imm

this level of complexity is just not going to fly.

however the N=M=1 mode (without additiobal complexity which is deginitely not
acceptable) because it is just 2 bits is on the borderline of acceptable.



> Considering that the monster alignment muxer has to deal with it (if we
> adopt that sort of encoding), but it's not responsible for the translation
> from 16-bit to 32-bit instructions, I don't see that the alignment muxer
> would care at all about what's in the 16-bit extension.  

if as above pseudocode there exists a fourth level of decoding affecting the
determination of length and mode that changes the FSM entirely to one where a
simple hierarchy is no longer possible, merging the two phases (see below) this
is unacceptable.


> Therefore, the
> remapper could very well use those bits for purposes other than just an
> extension of the varying-width immediates already present in several of the
> immediate opcodes.

.... "varying width immediates"... ah i think i know what you are referring to.
 you are referring to the fact that some subencodings of MN=1 use different
length portions of the 16 bits to specify an immediate?

i thought that you had said, "some subencodings would affect the FSM of the
INSTRUCTION length, back 2 stages ago in the pipelined instruction decoder".

right.

mentally you need to separate out the two following distinct phases:

    phase 1: raw instruction length/mode detection

    phase 2: operand, register and imm decoding.
             (these are different per
              length per mode obviously
              and also have further
              subdecoding)

phase 1 because it is the raw data stream has to be as drastically simple as
possible, especially and particularly because of a multi issue decode context.

once that barrier is passed, and multiple INDEPENDENT instructions are passed
to parallel processing units, given that those are independent and have local
access to all state they need, there is far less pressure.

if it takes 4,000 gates to decode a given instruction (because yes, OpenPOWER
really is that complex, that *is* how many gates it takes) then so be it but
bear in mind this is **AFTER** length/mode has been identified.

so.

back at the 16.imm (MN=1), having different subencodings select different bits
to fill out an immediate? this is pretty normal for OpenPOWER.  have a look for
example at the shift instructions section, in v3.0B PDF.  compare it to addi
and you see the fields (immediates) are not only completely different lengths,
they're in completely different bit allocations.

this is *normal*.

however - and i stress once again - this is AFTER the length/mode has been
determined to be 16bit.imm

to have some of the MN=1 unused sub encodings go backwards in time and set a
32bit instruction length or 48 bit or N bit: this we are *not* doing.


> So, are you saying we can't afford to have the 16+16-bit immediate encodings
> with N=M=1, 

incorrect.

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