Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 23 Feb 2003 16:34:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 23 Feb 2003 16:34:44 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:4361 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id convert rfc822-to-8bit; Sun, 23 Feb 2003 16:34:43 -0500 Date: Sun, 23 Feb 2003 13:41:45 -0800 (PST) From: Linus Torvalds To: Xavier Bestel cc: Linux Kernel Mailing List Subject: Re: Minutes from Feb 21 LSE Call In-Reply-To: <1046031687.2140.32.camel@bip.localdomain.fake> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-MIME-Autoconverted: from 8bit to quoted-printable by deepthought.transmeta.com id h1NLiLF04013 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1179 Lines: 28 On 23 Feb 2003, Xavier Bestel wrote: > Le dim 23/02/2003 ? 20:17, Linus Torvalds a ?crit : > > > 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 ? Not gzip, no. It needs to be a random-access compression with reasonably small blocks, not something designed for streaming. Which makes it harder to do right and efficiently. But ARM has Thumb (not the same thing, but same idea), and at least some PPC chips have a page-based compressor - IBM calls it "CodePack" in case you want to google for it. Linus - 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/