Date:	Tue, 23 Mar 1999 12:54:22 -0600
From:	Eric Rudd <rudd AT cyberoptics DOT com>
Subject:	MMX PAND instruction assembled incorrectly by as.exe v2.8.1
To:	djgpp-workers AT delorie DOT com
Message-id:	<36F7E35E.23B4F131@cyberoptics.com>
Organization:	CyberOptics
MIME-version:	1.0
X-Mailer:	Mozilla 4.05 [en] (Win95; U)
Reply-To:	djgpp-workers AT delorie DOT com

The GNU assembler 2.8.1 assembles the MMX instruction PAND with an
opcode of 0x0FDA, rather than 0x0FDB, as specified by Intel.
Unfortunately, I had trouble building the binutils to test the patch I
had (though I was ultimately successful).

The configure.bat file for the binutils has a few problems.  First, one
must run

patch <readme.djg

in order to patch configure.bat itself.  The change

*** configure.bat~       Tue Jul 15 22:55:00 1997
--- configure.bat       Tue Mar 23 09:59:26 1999
***************
*** 2,6 ****
  if exist patch_ok goto patch_done
  echo Applying DJGPP specific patches ...
! patch < diffs.djg
  touch patch_ok
  :patch_done
--- 2,6 ----
  if exist patch_ok goto patch_done
  echo Applying DJGPP specific patches ...
! patch < diffs.djg -p0
  touch patch_ok
  :patch_done

appears to be necessary for the invokation of patch inside configure.bat
to work properly (I was using v2.5).  In addition, I must run configure
with an argument

configure --host=i386-pc-msdosdjgpp

or I get the message that the host is not specified. It seemed to me
that these changes might as well have been rolled into configure.bat

I know that a new version of binutils is in the works, so I don't know
how many of these problems have already been fixed, but one ought to be
able to run configure.bat "out of the box", and do a make.  I would be
interested in testing the 2.9 beta code, if it is available.

I also encountered problems caused by UNIX utilities I hadn't
installed.  This would have been OK if the configuration (or build) had
stopped with the appropriate message, but it just went on -- the error
messages were buried amidst thousands of other lines of output, which
left me scratching my head.

For what it's worth, the bug in the MMX PAND instruction can be fixed by
the following patch

*** gnu/binutl-2.81/include/opcode/i386.h~      Tue Jun 10 16:42:38 1997

--- gnu/binutl-2.81/include/opcode/i386.h    Tue Mar 23 10:23:42 1999
***************
*** 829,833 ****
  {"paddusb",   2, 0x0fdc, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
  {"paddusw",   2, 0x0fdd, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
! {"pand",      2, 0x0fda, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
  {"pandn",     2, 0x0fdf, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
  {"pcmpeqb",   2, 0x0f74, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
--- 829,833 ----
  {"paddusb",   2, 0x0fdc, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
  {"paddusw",   2, 0x0fdd, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
! {"pand",      2, 0x0fdb, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
  {"pandn",     2, 0x0fdf, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },
  {"pcmpeqb",   2, 0x0f74, _, Modrm, { RegMMX|WordMem, RegMMX, 0 } },

Is i386.h DJGPP-specific, or should this bug be reported to GNU?

-Eric Rudd
rudd AT cyberoptics DOT com

- Raw text -