[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Nov 30 09:18:16 GMT 2020


--- Comment #117 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Alexandre Oliva from comment #116)
> great question.  I've heard about them, but I don't know where they fit in. 
> I thought they would fit in yet another execution mode, so I was not
> concerned about them.
> some possibilities:
> - 1 bit per insn, telling the encoding mode, not necessarily the length. 
> not quite as useful for the monster muxer, but enough to enable the compact
> mode-switching possibilities

This is the approach I'd take, since the primary opcode already is used in
PowerISA v3.1 to determine if an instruction is 32/64-bit. Add 48-bit to that,
supporting 32/48/64-bit instructions in the PowerISA v3.1 compatible encoding
(I named it Standard Mode), we only need the alternate encoding (I named it
Compressed Mode) for 16-bit instructions.

> - 2 bits of pre-length encoding for each insn, so the 4 (known to me?)
> lengths can be represented

4 different lengths is correct afaik: 16/32/48/64-bits
> - use enough bits to cover equivalent lengths, even if not all bits cover
> insns.  for 48-bit, we'd need 1 bit for 16-bit and one for 32-bit.  which
> one comes first depends on the mode in which the 48-bit insn is encoded, but
> 48-bit insns would consume two bits from the queue.  ditto for 64-bit insns,
> that would encode 2 bits for 32-bit insns.  the muxer would have to peek at
> insns, but maybe not quite as much as it would have to without the helper
> bits.

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

More information about the libre-soc-bugs mailing list