Messages in this thread | | | Subject | Re: Minutes from Feb 21 LSE Call | From | Kenneth Johansson <> | Date | 24 Feb 2003 02:26:51 +0100 |
| |
On Mon, 2003-02-24 at 00:57, Alan Cox wrote: > On Sun, 2003-02-23 at 20:50, Martin J. Bligh wrote: > > >> And the baroque instruction encoding on the x86 is actually a _good_ > > >> thing: it's a rather dense encoding, which means that you win on icache. > > >> It's a bit hard to decode, but who cares? Existing chips do well at > > >> decoding, and thanks to the icache win they tend to perform better - and > > >> they load faster too (which is important - you can make your CPU have > > >> big caches, but _nothing_ saves you from the cold-cache costs). > > > > > > Next step: hardware gzip ? > > > > They did that already ... IBM were demonstrating such a thing a couple of > > years ago. Don't see it helping with icache though, as it unpacks between > > memory and the processory, IIRC. > > I saw the L2/L3 compressed cache thing, and I thought "doh!", and I watched and > I've not seen it for a long time. What happened to it ? >
http://www-3.ibm.com/chips/techlib/techlib.nsf/products/CodePack
If you are thinking of this it dose look like people was not using it I know I'm not.It reduces memory for instructions but that is all and memory is seems is not a problem at least not for instructions.
It dose not exist in new cpu's from IBM I don't know the official reason for the removal.
If you really do mean compressed cache I don't think anybody has done that for real.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |