[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 05:16:17 GMT 2020


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

--- Comment #110 from Alexandre Oliva <oliva at gnu.org> ---
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.

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

IOW, the boolean function that tells us whether the next insn starts at the
next half-word, or at the next word, takes current mode, the 6 opcode bits, one
of which overlaps with the N bit, and the M bit, that doesn't.

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?

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.

looking further into minimizing the inputs that the muxer has to take into
account...  what if 16-bit insns had Cmaj.m placed in the remaining primary
opcode bits (i.e., the ones not used for M and N)?  then, the muxer wouldn't
have to look at different bits to tell the length of the present insn

we'd go from a function of (mode, 0..8 (primary opcode and Cmaj.m), M), 11
bits, to (mode, 0..5), 7 bits.

it's not obvious to me that it would actually provide us with any function
minimization opportunities, or just require more hardware buffers for the bits
that would then get more uses.  what does your intuition tells you?

Nicely, changing these would only require mechanical changes to the current
encodings.

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


More information about the libre-soc-bugs mailing list