Related articles |
---|
Facts about the Java class file format pilz@ifi.unizh.ch (Markus Pilz) (1998-10-17) |
Re: Facts about the Java class file format pilz@ifi.unizh.ch (1998-10-30) |
Re: Facts about the Java class file format albaugh@agames.com (1998-11-01) |
Re: PowerPC CodePack (Was: Facts about the Java class file format) zalman@netcom.com (1998-11-06) |
Re: PowerPC CodePack (Was: Facts about the Java class file format) peter@baileynm.com (1998-11-08) |
Re: PowerPC CodePack (Was: Facts about the Java class file format) jean-francois.brouillet@virgin.net (Jean-Francois Brouillet) (1998-11-08) |
Re: PowerPC CodePack (Was: Facts about the Java class file format) zalman@netcom.com (1998-11-12) |
From: | zalman@netcom.com (Zalman Stern) |
Newsgroups: | comp.compilers,comp.arch,comp.sys.powerpc.tech |
Date: | 12 Nov 1998 01:32:00 -0500 |
Organization: | ICGNetcom |
References: | 98-10-108 98-10-171 98-11-018 98-11-042 98-11-061 |
Keywords: | architecture, performance |
Peter da Silva (peter@baileynm.com) wrote:
: Seems to me, it'd cut down the cost of I-cache misses.
CodePack (the IBM technology we are discussing) does not do this all
the time as there is cost associated with the decompression and it
hits every taken branch (that wasn't the same as the last taken
branch). Seems like more of a break even kind of thing than a speed
win.
: Remember, ROMs are SLOW.
According to Microprocessor Report, the only place where CodePAck wins
significantly in speed is for running out of a slow byte wide ROM
interface.
I expect the real issues for code size are fitting something onto an
ASIC with a PowerPC core (where ROM space may be quite tight) and
competing against ARM's Thumb or MIPSsub16. Adding another chip or
going to a higher capacity ROM will have an incremental cost and if a
competitor doesn't incur that cost, its an advantage. I expect its a
pretty big one in most high volume markets.
-Z-
Return to the
comp.compilers page.
Search the
comp.compilers archives again.