[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 #121 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #110)
> some more thinking about the massive alignment muxer, and opcode formats
> 
> we use 6 bits, the primary opcode, to tell whether we're looking at a
> regular 32-bit insn, or a 10-bit insn.

actually, it's 6 bits to indicate a regular 32-bit instruction
however for entering 16-bit mode (which includes the 10bit variant)
it requires *two* Major Opcodes.  examples:

EXT000 (6 bits)
EXT001 (another 6 bits)

(please don't comment on how those are already used by v3.0B: they're given for
illustrative purposes only)

the MSBs of those 2 encodings are the same (0b00000).  the LSB is different.
therefore, EXT000 selects **ONE HALF** of the 10bit encoding space, whilst
EXT001 selects the **SECOND** half.

this is explained at the beginning, in the introduction.  search
for this text:

    The reason for picking 2 contiguous Major v3.0B opcodes is illustrated
below:

|0 1 2 3 4 5 6 7 8 9 a b c d e f|
|major op..0| LO Half C space   |
|major op..1| HI Half C space   |
|N N N N N|<--11 bits C space-->|



> since any presumed 32-bit insn may turn out to be one of these 10-bit insns,
> we have to be prepared to have another 32-bit (or 10-bit) insn at the next
> half-word, or a 16-bit insn, depending on yet another bit

errr.... no.  emphatically no.

the FSM is very simple, and very clear.  i outlined it in comment #108 and
it most definitely and categorically does not need "yet another bit".

* 32 bit mode instructions may ONLY be followed by 10-bit ones
* 10-bit ones may be followed ONLY by either:
  - 16-bit ones (M=1)
  - 32-bit ones (M=0)
* 16-bit ones may be followed ONLY by:
  - 16-bit ones
  - 32-bit ones

there is no need for "more bits".


> wouldn't it make sense to move the M bit so that it overlaps with the
> primary opcode, so as to (potentially?) simplify the muxer's alignment
> decision, by reducing the number of bits it has to look at?

this is a common mistake made by software engineers, who think in terms of
instructions that cannot perform arbitrary bit-level manipulation.

hardware is dead simple: you just route the wire to put it into the "thing".

done.

therefore the positioning of the bits - 5, 8, 3, 23, 16 - is completely
irrelevant.

bit M does not need to move position just for the convenience of software
engineers.

in hardware, whether bit M is at position 5 or position 15 is utterly
irrelevant: in both cases it's just "a wire".


> indeed, this would enable us to drop entirely the requirement for a pair of
> opcodes that differ only in the least-significant bit of the primary opcode.
> we could take any pair of primary opcodes that differed by a single bit, and
> use that single bit as the M bit.

i deleted the rest and am ignoring this paragraph for now until you've
understood the difference between software engineering and hardware
engineering.  bit-positions in hardware are simply "conventions" and the
routing is done by wires.

bit-positions in *software* are relevant because 100% of practical real-world
general-purposes processors are capable of efficient arbitrary bit-level
manipulation.

if after that misunderstanding is cleared up there is something that is
relevant please do ask.

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