Hi,

the following minimal test program crashes with an "Illegal
Instruction" signal when run on a P-II/400MHz system running
NetBSD-current of 5 Jan 1999:

--- snip ---
#include <stdio.h>

int
main(argc, argv)
	int argc;
	char **argv;
{
	int a = 5, b = 6, c;

	__asm("
		movq %%mm6, %1
		movq %%mm7, %2
		pand %%mm6, %%mm7
		movq %0, %%mm6
		" : "=m" (c) : "m" (a), "m" (b));

	printf("%d\n", c);

	return 0;
}
--- snip ---

It bombs out at the 'pand' instruction, at least that's what gdb
is telling me:

vader% gdb t
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386--netbsd), Copyright 1996 Free Software Foundation, Inc...
(no debugging symbols found)...
(gdb) run
Starting program: /tmp/t 
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGILL, Illegal instruction.
0x1805 in main ()
(gdb) x/i 0x1805
0x1805 <main+33>:	pand   %mm6,%mm7
(gdb) x/i main
0x17e4 <main>:	pushl  %ebp
(gdb) 
0x17e5 <main+1>:	movl   %esp,%ebp
(gdb) 
0x17e7 <main+3>:	subl   $0xc,%esp
(gdb) 
0x17ea <main+6>:	call   0x189c <__main>
(gdb) 
0x17ef <main+11>:	movl   $0x5,0xfffffffc(%ebp)
(gdb) 
0x17f6 <main+18>:	movl   $0x6,0xfffffff8(%ebp)
(gdb) 
0x17fd <main+25>:	movq   %mm6,0xfffffffc(%ebp)
(gdb) 
0x1801 <main+29>:	movq   %mm7,0xfffffff8(%ebp)
(gdb) 
0x1805 <main+33>:	pand   %mm6,%mm7
(gdb) 
0x1808 <main+36>:	movq   0xfffffff4(%ebp),%mm6
(gdb) 
0x180c <main+40>:	movl   0xfffffff4(%ebp),%eax
(gdb) 
0x180f <main+43>:	pushl  %eax
(gdb) 

Is this as it should be?  The 'pand' is (AFAIK) an MMX
instruction.

In case anyone's wondering, I'm trying to compile a new rc5des
client for NetBSD/i386 -- I have the 486/386 version working
fine, but the DES engine auto-detects MMX hardware and uses a
"core" written using MMX instructions, and that is failing badly
due to this problem.

As near as I can tell, other MMX instructions do not cause this
problem -- instructions such as 'pxor' and 'por' are executed
prior to the 'pand' in the rc5des code and they do not trigger
this problem.  For some strange reason 'pand' bombs out as shown
above.

Do I stand any chance of getting this to work at all on
NetBSD/i386, or is this a can of worms not worth contemplating
opening, related to whether floating point context needs to be
saved on context switches and other related goo?


Regards,

- Havard