[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 #87 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #86)
> 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.

Do we need to decode 4 64-bit instructions per cycle? can we just have it
decode up to 4 instructions or up to 16 bytes of instructions, which ever is
smaller per cycle?

> 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".

Another way we could structure the decoder is: rather than using a giant
shifter/aligner to compact the decoded instructions into a contiguous list,
instead, we could just have overlapping decoders that start at each 16-bit
offset and we just ignore the decoded instructions for those decoders that
didn't start at the right offset. This totally avoids the need to have the
aligning matrix at the cost of having much wider issue, which might be worth
it.

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