[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 #78 from Alexandre Oliva <oliva at gnu.org> ---
re: comment 76

let me straighten out and separate some ideas so that they're not conflated:

1. use 2-operand encoding in compressed mode, and modify the compiler to give
preference to such insns

2. simplify the mapping by using the same 6-bit opcode encoding that
uncompressed mode uses (even if we don't map every opcode; just make those that
we do the same)

3. use 1-byte mode-switching instructions

3 implies we'd have to look at all opcode bits to tell how to interpret the
next byte in the stream, i.e., whether it's the second half of a 16-bit insn,
or the opcode byte of a 32-bit insn (which might be a switch-back, but I
disgress)

I don't see how that's worse than having an opcode that sets one bit for the
operand mapper of the next insn, and saves some 8, 9 or 10 bits for the
decoder/mapper to use, presumably as operands, when decoding the next insn.

if you think of this pair as a single insn you'd like to process in a single
cycle, yeah, I can see how that would put pressure in the decoder and in the
pipeline, and make it very CISCish

but if you conceive of it as a mostly-separate instruction, then it's not that
bad.  taking an extra cycle to process the pair is not so bad compared with the
alternatives:

- issue an extra move before (par)

- switch to 32-bit mode, perform the operation, switch back (lose)

that said, looking at the insns available through primary opcode encoding, and
how many resort to extended encoding, I come out leaning towards agreeing that
using that direct mapping only might give us too little, and that we might have
to switch back to uncompressed mode far more often than I was hoping for

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