[Prev][Next][Index]
[Fwd: Code Compression]
- From: "Alvin R. Lebeck" <alvy@cs.duke.edu>
- Newsgroups: duke.cs.os-research
- Subject: [Fwd: Code Compression]
- Date: Wed, 21 Oct 1998 09:57:22 -0400
- Organization: Duke University Department of Computer Science
- Sender: alvy@cs.duke.edu
- Xref: news.duke.edu duke.cs.os-research:225
This is a multi-part message in MIME format.
--------------5E0549D4296079804DDE06FC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
-----------------------------------------------------------------------
Alvin R. Lebeck Office D304 LSRC
Assistant Professor Phone (919) 660-6551
Dept. of Computer Science FAX (919) 660-6519
Box 90129 e-mail: alvy@cs.duke.edu
Duke University http://www.cs.duke.edu/~alvy
Durham, NC 27708-0129
-----------------------------------------------------------------------
--------------5E0549D4296079804DDE06FC
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from jarlsberg.cs.wisc.edu (jarlsberg.cs.wisc.edu [128.105.76.17])
by duke.cs.duke.edu (8.8.5/8.8.5) with ESMTP id PAA03752
for <alvy@cs.duke.edu>; Mon, 19 Oct 1998 15:04:03 -0400 (EDT)
Received: from jeeves.cs.wisc.edu (jeeves.cs.wisc.edu [128.105.37.11])
by jarlsberg.cs.wisc.edu (8.8.6/8.8.6) with ESMTP id OAA22068;
Mon, 19 Oct 1998 14:04:02 -0500 (CDT)
Received: from localhost (daemon@localhost)
by jeeves.cs.wisc.edu (8.8.6/8.8.6) with SMTP id NAA29008;
Mon, 19 Oct 1998 13:59:18 -0500 (CDT)
Received: by jeeves.cs.wisc.edu (bulk_mailer v1.8); Mon, 19 Oct 1998 13:58:51 -0500
Received: (from majordom@localhost)
by jeeves.cs.wisc.edu (8.8.6/8.8.6) id NAA28974
for architecture-outgoing; Mon, 19 Oct 1998 13:58:51 -0500 (CDT)
Received: from cs.wisc.edu (cs.wisc.edu [128.105.2.6])
by jeeves.cs.wisc.edu (8.8.6/8.8.6) with ESMTP id NAA28970
for <architecture@jeeves.cs.wisc.edu>; Mon, 19 Oct 1998 13:58:49 -0500 (CDT)
Received: from cs.wisc.edu (helga.cs.wisc.edu [128.105.66.48])
by cs.wisc.edu (8.8.6/8.8.6) with ESMTP id NAA27079
for <architecture@cs.wisc.edu>; Mon, 19 Oct 1998 13:58:48 -0500 (CDT)
Message-ID: <362B8BBB.31C335BC@cs.wisc.edu>
Date: Mon, 19 Oct 1998 13:58:04 -0500
From: Andy Glew <glew@cs.wisc.edu>
Organization: U Wisc CS (& Intel)
X-Mailer: Mozilla 4.5b2 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: architecture@cs.wisc.edu
Subject: Code Compression
Content-Transfer-Encoding: 7bit
Sender: owner-architecture@cs.wisc.edu
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
Just in case any of you felt that I was crazy espousing compression
in the memory hierarchy, IBM is doing it, albeit for code only.
Compression for data is the obvious next step. I can show you how.
*** IBM Introduces Code Compression for PowerPC
At last week's Embedded Processor Forum, IBM's chief architect for embedded
PowerPC,
Tom Sartorius, revealed that IBM has developed a code-compression system
for
embedded PowerPC chips that can shrink code size by as much as 40%. The
code-
compression system, called CodePack, is ready now. The first chip to use it
should
appear on the market in 2Q99.
IBM's CodePack is fundamentally different from ARM's Thumb or MIPS' MIPS-16
code-
compression techniques. Rather than supplement the PowerPC instruction set
with a
second, 16-bit format, CodePack actually compresses object code, like
running PKZip
on a finished program. IBM claims a better overall compression ratio than
its
competitors, and CodePack can be applied to any PowerPC program or PowerPC
chip,
past, present, or future. It also does not interfere with software tools
such as
assemblers, compilers, or linkers.
CodePack uses an adaptive compression algorithm to squeeze the most out of
each
program. After the compressed object code is stored in memory, special
CodePack
hardware on the microprocessor decompresses the code in real time as it is
fetched
from memory but before it is executed. Although there is a slight
performance
penalty for this decompression, the extra latency is felt only during
instruction-
cache misses. Overall, CodePack is an interesting and unique approach to an
old
problem of minimizing the memory usage of high-performance embedded RISC
processors.
--------------5E0549D4296079804DDE06FC--