[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 #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.