Date:	Thu, 12 Aug 1999 16:02:12 -0300 (ADT)
From:	Peter Cordes <peter AT Cordes DOT Phys DOT Dal DOT Ca>
To:	pgcc AT delorie DOT com
Subject:	Re: bzip2-mmx
In-Reply-To:	<19990808124015.B9659@tardis.ed.ac.uk>
Message-ID:	<Pine.LNX.4.10.9908121555340.1690-100000@Cordes.Phys.Dal.Ca>
MIME-Version:	1.0
Reply-To:	pgcc AT delorie DOT com
X-Mailing-List:	pgcc AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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)

- Raw text -