Date: Thu, 12 Aug 1999 16:02:12 -0300 (ADT) From: Peter Cordes To: pgcc AT delorie DOT com Subject: Re: bzip2-mmx In-Reply-To: <19990808124015.B9659@tardis.ed.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: pgcc AT delorie DOT com X-Mailing-List: pgcc AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 8 Aug 1999, Mark Brown wrote: > On Fri, Aug 06, 1999 at 02:46:26AM -0300, Peter Cordes wrote: > > > 2. MMX instructions are executed by the bzip2-mmx binary, even on non-mmx > > machines. (I'm guessing that it is supposed to figure out which you have > > and run the appropriate code, so it is meant to work on non-mmx machines. > > If not, then this is not a bug.) > > It's not supposed to do any detection of the machine. The same thing > will happen with any of the other options which generate instructions > that don't run on all targets (eg, Pentium instructions). > Ok, so why is there a bzip-mmx and a bzip2-mmxonly? I noticed that the bzip2-mmxonly is faster than bzip2-mmx when compressing on a PIII and on a P200 MMX. BTW, like I said, I didn't compile any of these myself, I just downloaded them and tested them, in case that was what somebody was hoping would happen ;) I was expecting the MMX-only version to run only on MMX-capable CPUs, but since there was a different binary called bzip2-mmx, I guessed that bzip2-mmx would pick at runtime what to do. If I guessed wrong, then that's not really a bug. Does anyone know what compile options were used for each of these. There is still the problem about decompressing. #define X(x,y) x##y Peter Cordes ; e-mail: X(peter AT cordes DOT phys. , dal.ca)