[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 #124 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #113)
> actually, this thinking further of the detection of 10-bit insns,
> mode-switching or not, led me to an interesting realization
> 
> our reasoning seems to be significantly affected from a perception
> distortion out of the notion that one mode has 32-bit insns, while the other
> has 16-bit insns

not a distortion: a strict decision based on the amount of gates it takes.

> well, that's not true.  an instruction appearing while in uncompressed mode
> requires us to look at 6 of its bits to tell whether the next instruction is
> at the next half-word, or at the next word,

this is incorrect.  the FSM is pretty clear.  the transition *in* to the
16-bit length/mode part of the FSM uses those 6 bits.

this is the **ONLY** time when the 6 bits are read.

if you look again closely at the FSM you will find that **AT NO TIME**,
when the FSM has detected "length==16" for the current instruction, does
the examination of bits beyond those 16 occur.

this is EXACTLY AND PRECISELY why the FSM was designed the way it is designed,
so that once the length/mode is known, the length/mode is KNOWN.

is there anywhere in the FSM (comment #108) that says:

   if the mode is 16 bit, actually go look at the future bits 17 thru 31
   and check to completely change the length and meaning to 32, 48 or 64 bit?

is there anywhere in the FSM that says:

   if the mode is 16 bit, actually go read bits 17 thru 31 to see if there's
   another EXTNNN?

no, they do not, do they?


> and at another bit on top of
> them (unless we move M as I suggested) 

which is based, as best i can tell, on a false misapprehension of the
difference between hardware and software.


> now let's change the perspective a bit.  instead of starting from the
> premise that uncompressed insns are 32-bit and compressed ones are 16-bit,
> let's start from a premise that is just as invalid, namely, that insns in
> either mode take 16-bits

no.  please can we not do that whilst we are in the middle of trying to make
sure that you fully understand the current (v1) encoding scheme?


> in uncompressed mode, we look at the primary opcode to tell whether it
> really is a 16-bit (or 10-bit, as we call them) instruction, or whether it
> extends over 32, or even 64 bits!

no, please.  please do not discuss variable-length encodings in the Compressed
(16-bit) bugreport.

i don't *mind* discussion and speculation on alternative variable-length
encodings... just not under this bugreport which for some reason has become far
more complex than it actually is.


> but in compressed mode, we can't have even one bit or opcode to extend to
> tell the insn isn't just 16-bits long, but rather 32, because...  somehow
> the reasons that make it acceptable in one mode don't apply to the other,
> even if we had to look at the very same 6 bits plus mode?!?

this tells me that it still has not yet sunk in that the two phases (1:
length/mode detection and 2: instruction decoding) are still not yet completely
separated in your mind.

i keep emphasising how critically important it is that you separate those two
phases.

once you have done so, and accepted it, things will become clearer for you.


> conversely, if looking at all those bits is so bad that it's unacceptable in
> compressed mode, maybe it's just as bad in uncompressed mode and we should
> find another way to go about it, one that doesn't take up two of the few
> major opcodes.

i've already identified 16 major opcodes for re-use.  there are not "few", at
all.

however, again: this is not for discussion under the Compressed encoding
bugreport.


below is an alternative Compressed encoding so is relevant for this bugreport,
i'm happy to go through it (as best i can)

> consider, for inspiration, something that won't quite work because of the
> 64-bit instructions:
> 
> - 32-bit words may contain either a single 32-bit insn, or a pair of 16-bit
> insns
> 
> - there's one 32-bit opcode, primary or extended, that encompasses:
> 
> -- 6+ bits to make it recognizable
> 
> -- 16-bits for a 16-bit insn
> 
> -- up to 10 bits that guide the decoding of *statically* subsequent insns

right.  this was - i believe - one of the very early ideas (18 months ago) that
was discarded.

the reason is because the fixed overhead of using the 10 bits to "enter" 16-bit
mode turns out to be very large when you have a huge quantity of switching
(mixed standard v3.0B and Compressed instructions).

consider how and whether the 10 bits could be used to efficiently encode this
scenario:

    Compressed v3.0B Compressed v3.0B Compressed v3.0B Compressed

you'll almost certainly find that the space required to do so is *GREATER* than
that of just leaving them as v3.0B 32-bit instructions.


> - there's also one 16-bit opcode that encodes:
> 
> -- 4+ bits to make it recognizable
> 
> -- up to 12 bits to guide the decoding of statically subsequent insns

these types of encodings were investigated (2 years ago) for something called
"VBLOCK".  they're... extremely complex and took about 8 months to design.

i would greatly prefer that we tackle the simpler encodings first.


> these bits are similar in purpose to our current M and N, but they're packed
> into an insn like the above, so that the decoder can readily tell, even
> ahead of time, where insns are, and how to decode them

it's basically a form of hardware compression, and the fixed overhead not only
penalises short instruction runs, it also produces a stunningly-complex FSM
that requires a huge amount of thought and planning.

unfortunately we don't have time for that.  we did, 18+ months ago: we do not,
now.

so unfortunately, such encoding schemes need to be eliminated from discussion
right now and re-visited in 12-18 months time, once we have 100% completed
NLnet Projects and can apply for additional funding.

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