Re: PowerPC CodePack (Was: Facts about the Java class file format)

Mike Albaugh (albaugh@agames.com) wrote:
: There is a fascinating article in the latest Microprocessor
: Report about an IBM POWER (or possibly PowerPC) implementation that
: _executes_ compressed binaries, de-compressing as it loads them into
: the moral equivalent of I-cache lines. I have passed on my copy by
: now, but IIRC, they alleged something like 40% compression.


This is IBM's CodePack technology which will be in the new PowerPC 405
microcontroller. From the Microprocessor Report article:


Code is compressed in 64-byte blocks using a Huffman encoding type
scheme. There are two 2Kbyte tables for holding the token
expansions. One table is used for the high 16-bits of each instruction
and the other table is used for the low 16-bits of each
instruction. The high 16-bits can be compressed to anywhere between 5
and 19 bits. The low part can be between 2 and 19 bits. (Due to fairly
regular encoding in the PowerPC ISA, high parts are opcodes plus
register specifiers, while low parts tend to be literals. The two bit
literal compression is hardwired to expand to 16 zero bits.)


The CPU core and the I-cache are very similar to a design without
compression. Compressed blocks are expanded when a 64-byte cache line
is loaded. (By hardware on the memory side of the cache.) Of course if
the compression would make the code larger, the block is stored
uncompressed. (There is a bit controlling this in the MMU's page table
entry. I infer from this that all blocks in a page must be compressed
or uncompressed but perhaps I misunderstood how it works.)


There are another set of tables to implement a mapping table for
resolving branch addresses. Each time a branch is taken, a hash table
is searched to find the real address to use. (The description in the
article is not very detailed and I didn't quite get it. It does
implement a single entry cache for the branch address lookup, which
seems very small. Future designs will likely have a larger branch
target cache there.)


The tool chain is just like for other PowerPC processors but there is
a post-processor that compresses a ROM (or RAM I suppose) image and
builds the necessary tables. Claim is the compression reduces code
size by 40% on average. Which is comparable to the 16-bit subset ISAs
from ARM (Thumb) and MIPS (MIPSsub16). uProc Report proposes a new
compiler benchmark for CodePack: how small a compiler's compressed
output is.


-Z-
[Are ROMs still expensive enough that this kind of hackery is worth it?
I suppose so if you're building a million chips to put into consumer
appliances or cars. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.