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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Nov 21 21:53:17 GMT 2020


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

--- Comment #10 from Alexandre Oliva <oliva at gnu.org> ---
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.

A more dynamic alternative would add a disassembler option or environment
variable or whatever, handled in powerpc_init_dialect, enabling a file name to
be specified that contains opcodes to regard as compressed (subject to the same
constraints)

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

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.  I'm still trying to get acquainted with the preexisting opcode formats
of PowerISA (do we have a PDF for 3.1? the official site insists that I bring
down my Javascript firewalls against web blobs to download it, 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? :-)

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


More information about the Libre-SOC-ISA mailing list