[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 #86 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #78)
> 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

yep i like this one.

> 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)

with jacob kindly going through the analysis of a multi-issue length/mode
identifier, i realised just now that the proposed 8-bit alignment concept
has a fundamental flaw: extracting the identified instructions out of the
shift register which contains the raw instruction stream will require *8-bit*
indexing.

for a 4-way multi-issue, which will have up to 4x8=32 bytes of data in
the "raw" shift register, that would imply an absolutely insane 8x32-way 
8-bit parallel multiplexer to get any one of the 32 bytes into their respective
targetted 4x 64-bit parallel 2nd-stage decoder buffers.

that's 8192 MUXes which are.. what... 5 gates each?  that's a whopping 40,000
gates which, to give you some idea of scale, alexander, is 3x times larger than
a 64-bit multiplier.

even a 16-bit encoding (aligned at 16 bits) is going to be 4x16-way 16-bit
parallel multiplexing however with the reduction in both dimensions that's an
O(N^2) drop (down to "only" 10k gates) which is "just about borderline
acceptable".

bottom line i think we eliminate the 8-bit-aligned concept on the basis that
it's simply far too costly, much as i liked the idea of using the LSB of the PC
as an encoding-identifier.

that leaves just simply aligning to 2-byte (hword) boundaries... which of
course leaves no space for a marker unless it's a 16-bit encoding... and after
a few more rounds of logical deductive reasoning we're back at the 10/16-bit
encoding scheme.

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