[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 #66 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #64)
> I quite like the idea for encoding compressed instructions by having their
> address be odd, 

it's novel, i like that.  still need to think it through.  i'd like to see a
table, 4-bytes per row, showing rough examoles of how this would work. 
(expansion to bitlevel can be done after).

my first observation was that, forgetting the actual byte placement, ignoring
the relative positioning/FSM and counting the "effectiveness" (bit usage),
oliva's proposal is effectively:

* move everything along by one byte
  (in any given 16bit contiguous sequence)
* drop the 10bit encoding
  (and then further drop modeswitching)

in other words:

* 3 bits at the end of the EXTNNN Major
  opcode are currently unallocated:
  (can they be used at all?)
* the separation of those 3 bits plus
  the 8 of the alignment nop *used* to
  be the 10-bit encoding opportunity.

with those now split from each other that opportunity is gone.  is it worth the
tradeoff of the LSB being the 16/32 mode identifier? this needs evaluating
carefully.

key questions:

* can the 32 bit v3.0B instructions be
  identified even on 16bit boundaries?
  (4 byte per row tables will help
   illustrate if it is)
* is the loss of 10/11 bits statistically
  worth it? i.e. how many nops are there
  likely to be?

> as long as we retain the ability to be completely
> backward-compatible with Power ISA v3.1 (including their 64-bit
> instructions) in both BE and LE modes.

EXT001 is unfortunately one of the top candidates for use by Compressed
(because it is right next to EXT000 which we need to encode all-zero illegal
encoding, and it saves gates).

however this is not actually a problem because the Compressed and v3.1B
Prefixing are mutually exclusive.  this just leaves ensuring that return to
v3.1 Mode is "clean" (when the OPF EULA is updated to allow anyone to implement
commercial v3.1 ASICs that is)

remember also that the dual half-word reordering is effectively identical to
quad bytelevel reordering.  one is applied to memory prior to decoding, the
other to the 32bit opcode.

essentially there is zero functional difference between them: it's just that
one of them is termed "BE instruction encoding" and has an unfair stigma "BE is
the loser therefore avoid" attached to it.

bottom line: if the 8 bit idea pans out but causes merry hell with the dual
half-word memory reordering, we can always, just as is done with VLE Encoding,
mandate that BE instruction encoding is required [note: *data* BE encoding
*separate* and not included in that].

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