[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 #133 from Alexandre Oliva <oliva at gnu.org> ---
> the 1st phase *has* to determine length/mode in the absolute most simplest, most basic, most gate-minimalist fashion possible.

I get it.  That's what I was trying to improve on.  But, not knowing I have
hardware-design training, someone jumped to the conclusion that it was for
software rather than hardware engineering concerns.

> remember always to separate that out in your head from phase two which
is where you further analyse major[.minor][.sub] fields to work out which
operation is which.

you and I wish it was so, but with the current design, it's far from it.

not when you think of a single insn, but when you think of the multi-issue
muxer, that's quite dramatic, and that's what my observations and suggestions
from last night had to do with.

consider, setting aside any 64-bit insns from 3.1, that, to decide the length
of the current insn, we have to take into account the current mode (let's call
it mode0), and 5 out of the 6 opcode bits (to decide whether it's 10- or
32-bit, in case mode0 is uncompressed) from the half-word at the insn address,
say addr

now, to decide the mode of the next insn, say mode1, you have to look at all of
these, plus M in case it's a 10-bit insn, and also a
switch-back-to-compressed-after bit (*) carried over from insn -1, say SBTCA0
for after 0; whereas when mode0 is compressed, you have to look at M and N, and
Cmaj.m to tell whether they have their usual meaning, which adds another 5 bits
to the inputs to this decision (not 6 because N overlaps with the major opcode)

my proposal of moving M and Cmaj.m in the compressed encoding enables this
decision by the muxer to be made with only 7 wires flowing in, rather than 12. 
now, my hardware design training may be rusty and dated, and I may even use
wrong terms because I'm translating from my native language, in which I was
trained, but I'm pretty sure it still holds that fewer and shorter wires
usually save in power consumption and routing complexity, even if the gates
remain exactly the same

(*) I haven't seen anything to enable the inspection or preservation of this
bit across an interrupt; if the interrupt triggers right after a compressed
insn that has NM = 0b10, it is to return to an uncompressed mode insn, but then
switch back to compressed mode for the next one.  that has to be represented
somewhere that is architecturally visible, saved across context switches, and
in signal stack frames.  just like the pre-length queue I proposed last night,
which hit me just as I rested my head on the pillow.  lucky for me I don't have
to sort that one out any more ;-)

now, to decide the length of insn 1, len1, you need mode1, and 5 bits selected
from addr+2 or addr+4, depending on len0.

to feed the decision of mode2, the selection of bits from addr+2 or addr+4 has
to extend over an additional 5 bits, as shown for mode1 above.  here, my
proposed shift of 16-bit insns saves nearly half of the selectors

len2, similarly, takes mode2 into account, plus 5 opcode bits selected from the
half-word selected from among addr+4, addr+6, and addr+8, depending on len0 and
len1

finally, the decision of mode3 takes the same 5 bits selected above, plus
another 5 bits from the same half-word, unless my proposed rearrangement is
taken to reduce the number of selected bits

is the intent clear now?  isn't this hardware engineering reasoning sensible
and sound?

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