🚀 go-pugleaf

I've noticed a strange connection which perhaps someone could set me
straight on.  On a Sun 3 (SunOS 3.5) with a 68881, you can use gcc or cc
-f68881 to get access to the 68881 chip.  However, the Mcrt1.o library,
which checks for and initializes the chip, seems to screw up the interval
timer mechanism (!).

Looking into the libc code (for minitfp) I find that commenting out the
sigvec() call for the EMT trap during the chip initialization makes the
program work fine on our Sun 3's.  (Since there is no trap in that
environment, it's safe.)  But it's not just the sigvec call that causes
the problem, since inserting it in the body of the test code doesn't cause
any problems.

Here's a 15-line code fragment to compile to see what I mean.  Compiling
it cc -fsoft works but doesn't use the chip; -f68881 uses the 68881 but
the setitimer() returns EINVAL and the for-loop never exits; and -fswitch
works and uses the 68881 but brings in lots of unnecessary code.

	#include <sys/time.h>
	#include <signal.h>

	main()
	{
		struct itimerval itv;
		extern exit();

		itv.it_value.tv_sec = 2;
		itv.it_value.tv_usec = 0;
		(void) signal(SIGALRM, exit);
		if (setitimer(ITIMER_REAL, &itv, (struct itimerval *)0))
			perror("setitimer");
		for (;;);	/* expect an interupt after two seconds */
	}

Please mail any fixes or workarounds to me, as well as cc'ing to SunSpots
if it seems of sufficient interest.

Thanks in advance,

Chris Metcalf -- l'Institut de Recherche et de Coordination Acoustique-Musique
metcalf%ircam@uunet.uu.net / ...!inria!ircam!metcalf / metcalf@ucbingre.bitnet