[Libre-soc-isa] [Bug 532] discuss iterative approach for statistical analysis of effectiveness of Compressed PowerISA encoding

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=532

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #10)
> modifying binutils so as to count opcodes that we'd like to compress could
> be done in basically two ways:
> 
> - add to include/opcode/ppc.h:
> #define PPC_OPCODE_COMPRESS 0x800000000000ull
> 
> - in opcodes/ppc-opc.c, mark the opcodes under powerpc_opcodes that are
> candidate for compression with '| PPC_OPCODE_COMPRESS' in FLAGS (the fourth
> column)
> 
> - in opcodes/ppc-dis.c, modify increment_opcode_counter to check for this
> flag, apply any other constraints on the operands, and count the instruction
> as compressed if it fits
> 
> This would require a quick recompilation for every experiment.

and that means if trying to compare those side-by-side it's very challenging. 
whereas a bunch of throwaway 50 line external python scripts is trivial to
rerun and compare.

> I'm not sure the latter effort is worth the additional convenience (if any)
> it would provide.  WDYT?

50 line python scripts reading stdin piped from objdump raw seems a lot easier.

> As for the extra constraints for insns to fit, that's where I haven't quite
> grasped what's proposed yet to be able to generalize the transformations and
> limits from 32-bit to 16- (and/or 10-?) bit opcodes, if there is a general
> rule at all.

OpenPOWER was never designed for dropping 16 bit on top of it.

RISCV RVC was ground-up designed for mixed 16/32.

we need to make some compromises: the 10 bit format makes best use of the
remaining bits whilst transitioning to "full" 16 bit mode.

the absolute simplest general rule is literally that from
https://bugs.libre-soc.org/show_bug.cgi?id=532#c7

at this stage we really do not want to get into the knock-on effects of
register allocation, effect on branches, and so on.  anything which, by the
very *existence* of Compressed, would result in the compiler emitting radically
altered assember, is *not* in scope at this stage: thst is too early.

however i would like to find out:

* word-aligned SP/FP immediates is enough
  (for 32 bit LD/ST)

  this confirms whether shifting the
  immediate by 2 bits is ok

* how many functions have 3, 4, 5 regs as
  parameters

* what sort of range of immediates are
  there on cmpwi and cmpdi

  are they mostly low (small) or are they
  large.  are they mostly against zero

* which CRs are mostly used by branches



>  I'm still trying to get acquainted with the preexisting opcode
> formats of PowerISA (do we have a PDF for 3.1?

ah we are implementing v3.0B.  search "raptorcs wiki v3.0b OpenPOWER spec"
should come up top hit, no JS.


> and I'd rather not) to be better able to make sense of
> https://libre-soc.org/openpower/sv/16_bit_compressed/ (that I see has
> changed since I first went through it; moving target much? :-)

:) i use it to capture ongoing discussions.  if i don't they are lost pretty
much immediately.


to get a rapid overview of OPF v3.0B without needing to go through a 1300 page
PDF try these:

https://libre-soc.org/openpower/isatables/
https://libre-soc.org/openpower/isa/

bear in mind FP is not added yet so not included in those tables.

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