[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 #120 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #109)
> /me blinks, blinded by the light that just hit him
> 
> yeah, now it all makes sense.  I found it so hard to believe that the 16-bit
> immediate insns were limited to such narrow immediate fields that I managed
> to twist 16bit/imm into 16+16.  I wanted it so bad that I made it so. 
> *blush*  wow, what a mess I have made!  apologies for being so dense, and
> for the noise.

no problem.

the important thing here is to appreciate that we have to do a 2-phase
analysis (1: length/mode, 2: full-decode), and that, because it is hardware,
the 2nd phase absolutely cannot go backwards in time and interfere with the
1st.

the 1st phase *has* to determine length/mode in the absolute most simplest,
most basic, most gate-minimalist fashion possible.

the 2nd phase is where the length/mode must be considered, categorically, to be
"fixed", and because it is fixed, you can now take longer (and use more gates),
have much more complex decoding to get at fields, immediates, register numbers,
sub-encodings etc. etc. etc. etc.... but all at a **FIXED** instruction width.


> I (think I) get it now.  compressed mode is 16-bit to enter (called 10-bit,
> because 6 bits are used by the opcode that tells us it's a 16-bit insn we're
> lookng at, rather than the usual 32-bit),

correct.  this is the entry-point to the FSM.

> and 16-bit only while in compressed mode. 

correct.

> now, some of the 16-bit insns may only switch back to
> 32-bit mode permanently, while others can also switch for one insn

correct.  otherwise, think about it: how could you get back to Compressed
mode? the only other way would be via the 10-bit encoding, which is of
course wasteful.

> (N is not repurposed), and some can't switch out at all (M is repurposed)

this is confusing me, i can't understand what you mean from the use of the word
"repurposed".  the two bits N and M are relevant to the 16-bit FSM.  they're
listed in "Opcodes exploration (attempt 1)" section.


> this means the logic in the compression estimator I wrote on Saturday is all
> wrong.  dang!

:)

> 
> ok, I went through it all again, under this new understanding, and though
> it's almost as if I was looking at a fully rewritten document, it all makes
> a new sense to me ;-)

:)

> new questions pop up:
> 
> - what's the use of N, when M is not there, as in the "16-bit mode only"
> blocks of encodings under 2.1.7 Logical and 2.1.8 Floating Point insns?

i didn't want to have to duplicate the contents of the 10-bit encodings in a
completely separate table, because (a) it's a lot more work and (b) the 16-bit
is an extension of 10-bit anyway.

so remember: there are 4 possibilities for N and M:

* N=0, M=0
* N=1, M=0
* N=0, M=1
* N=1, M=1

however there is also 10-bit mode and 16-bit mode, so it is actually:

             | bit 0 | bits 1-4 | bits 6-14       bit 15 | 
* 10-bit mode (EXTNNN=Compressed)  10-bit-encoding   M=0
* 10-bit mode (EXTNNN=Compressed)  10-bit-encoding   M=1
* 16-bit mode N=0 ...... ..... ...... .... .....  .. M=0
* 16-bit mode N=1 ...... ..... ...... .... .....  .. M=0
* 16-bit mode N=0 ...... ..... ...... .... .....  .. M=1
* 16-bit mode N=1 ...... ..... ...... .... .....  .. M=1

and the whole reason why the 10-bit Compressed exists is because: N (bit 0)
is *not accessible* when it's *also* used as part of the EXTNNN v3.0B Major
Opcode.


now, having explained all that: what you've missed is: take a look at
bit **ONE** in the 2 sections you refer to.

you see how insn[1] is zero in the first table, and one in the second?
this is therefore a sub-sub-encoding:

Cmaj.minor.sub

* Cmaj: bits 5-7
* minor: bit 8
* sub-sub-encoding: bit 1

but... look again at 10-bit mode.

             | bit 0 | bits 1-4 | bits 6-14       bit 15 | 
* 10-bit mode (EXTNNN=Compressed)  10-bit-encoding   M=0
* 10-bit mode (EXTNNN=Compressed)  10-bit-encoding   M=1

how can we use bit 1 to mean anything when entering the Compressed FSM?

we can't, can we?

therefore, bit 1 is ***ONLY*** relevant (useable) when we are **ALREADY** in
the Compressed (16-bit) FSM Mode.

yes?

in other words, you **CANNOT** get access to fdiv, fabs, fmr. or xor, extsb
etc. *UNTIL* you are in the 16-bit FSM, aka "16-bit mode".

and you get access to those instructions - only in 16-bit mode - by checking
bit 1.  which you CANNOT use on entering the FSM (10-bit mode) because bit 1 is
part of the EXTNNN identifier.


> - "SV Prefix over-rides help provide alternative bitwidths for LD/ST" -> I
> had previously assumed this was an instruction prefix,

it is - and it's a 1st-phase (length/mode) decoder.

> a little bit like the
> extend-next-insn opcode I'd suggested before.

it is... but it's at the 1st level (1st phase decode).  what you proposed was
to massively complexify and intertwine 1st and 2nd phase decoding (intertwine
length/mode decoding with actual instruction decoding) which would have
required going back in time to achieve efficiently.

>  Now, I assume it's not.  

this would be an incorrect assumption.  it's called "SV Prefix" because it's a
prefix.


> how does that work, then? 

i strongly recommend leaving that question for now and/or asking under the
SVPrefix bugreport.  this bugreport is for Compressed, not
SV-Prefix-Compressed.


> I suppose I may have to know it, to estimate
> correctly the compression of these instructions.

no.  the current context is: Compressed without SVPrefix.  Scalar
(non-vectorised) Compressed.

SVPrefix is completely out of scope for the purposes of the current discussion
(other than as an incidental / ancillary / future work).

let's get through Compressed first.  please completely disregard SVPrefix
(Vectorisation) for now.

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