[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Nov 30 12:50:45 GMT 2020
--- 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
|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".
therefore the positioning of the bits - 5, 8, 3, 23, 16 - is completely
bit M does not need to move position just for the convenience of software
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
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.
More information about the libre-soc-bugs