[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 #137 from Alexandre Oliva <oliva at gnu.org> ---
luke, please get back to it when you're rested, so that *you* understand

I had not read jakob's 3-phase decoding plan when I wrote today's working out
of the actual bit dependencies of len and mode computation for up to 4 insns,
but none of that changes the fact that the next-insn-mode computation needs to
take almost twice as many bits into account with the current encoding, vs the
encoding change I proposed, or even that the current-insn-len computation needs
to take 5 out of the 6 primary opcode bits into account

what that arrangement does is to avoid having to work out the dependencies in
full, and avoid cascading dependencies.  it trades working out and optimizing
the actual dependencies, possibly simplified by O(n) cascading, for O(2^n)
parallel-precomputing gates, followed by O(log n) selection and aggregation.

given the exponential growth of the precomputation, worrying about its
complexity makes even more sense than in a linear-growth case.  OTOH, the
separate selection and aggregation removes a lot of the supposed complexity of
handling different-sized insn formats in compressed mode.

so the question becomes, is there a way to enable extended formats in
compressed mode, that would make it a lot more useful, without increasing the
complexity of the exponential-growth parallel throw-away computation?

it turns out that there is.  one of the outputs of phase 1, for each half word,
is a but computed from 5 out of 6 of the opcode bits.  it's used to recognize
10-bit insns.

what if the same bits expressed, in compressed insns, an extended insn?  for
phase 1, this is the same computation; for phase 2, it will just change one
gate that combines mode and opcode from say and to xor.

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