[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 #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to cand from comment #5)
> Why have a "stay 16-bit" bit, instead of one instruction for "exit 16-bit
> mode"?

because doing so punishes (penalises) very short sequences where
16-bit ops are regularly interleaved with 32-bit ones.

> Having 11 vs 10 bits available. Then the overhead of using 16-bit
> mode is enter + exit instruction, the compiler can calculate if there are at
> least two 16-bit instructions and so it's worth it.

one of those will be the "exit 16-bit mode" instruction.  it would need to
be at least 3 16-bit instructions to be worth it.

add r1, r1, r2
mulli r1, r2, 5
or r2, r2, r3
sub. r5, r5, r2
bcctr cr0

as 32-bit instructions these come out to 10 hwords.

with 1 bit saying "enter/exit":

* add -> 16bit (10bit mode with exit bit)
* mulli -> 32bit
* or -> 16bit (10bit mode)
* sub -> 16bit (16bit mode with exit bit)
* bcctr -> 32bit

total hwords: 7 - a 30% saving

with 1 *instruction* saying enter/exit:

* add -> 32bit (can't get out of 16-bit mode so no point going in)
* mulli -> 32bit
* or -> 16bit (11bit mode)
* sub -> 16bit (16bit mode)
         plus another 16bit "exit 16 bit" instruction
* bcctr -> 32bit

total hwords: 9 - only a 10% saving


so the overhead is: 1/16 bits encoding bonus in exchange for a 1-instruction
penalty, my feeling is that it's not a worthwhile price.

however!

what if we had alternative 16-bit encoding "paging" modes?  where some
(potentially entirely new) encodings were swapped in/out?

if those pages could be specified even at the 10-bit level that's where
an overhead of the use of 16 bits becomes worth it, because the chances
of needing context-relevant opcodes (heavy FP computation, or heavy
Video computation) become much higher.

what do you think?

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