microVAX emulator bug in 4.3BSD

[Larry Philps]

In article <683 at gvax.cs.cornell.edu>, jqj at gvax.UUCP writes:
> About a month ago a serious bug was reported in the VAX instruction
> emulation code that is distributed as part of 4.3BSD
> (/sys/machine/emulate.s).  To refresh your memory, the following 
> program behaves incorrectly on a microVAX running 4.3 :
> 
>     main()
>     {	float hpos = 0.9;
> 	printf("%.0f\n", hpos);
> 	printf("Correct answer is 1; 4.3BSD on uVAX gives 0\n");
>     }
> 
> Besides verifying that the problem exists only in the 4.3BSD kernel and 
> not on a microVAX running Ultrix 1.2, I have not made any progress in 
> fixing the problem.  Has anyone else?

I posted the original article identifing the problem.  I have found two
solutions to the problem, but neither is suitable for network wide posting,
so I have just kept silent on the issue and hoped someone would find
a better answer.  Anyway, since it appears someone out there is interested
(and everyone should be) here is a short summary of solutions we have.

1)  We have a source license and the code for Ultrix 1.2.  This has
    an "/sys/emul" directory with thousands of lines of assembler designed
    to do everything right instead of just handling the usual cases.  This
    includes getting the contents of EVERY state register right after the
    end of the emulation code.  This is really impressive (and
    non-understandable) assembler coding. A few hours of hacking put it into
    the 4.3 kernel and everything cleared up.  That is the solution we are
    using here.  I KNOW I can't send that code out, but if anyone out there
    also has an Ultrix source lisence, we can help you set up your system
    to include its emulation code.

2)  It turns out that the 4.3+NFS from MT. XINU has different assembler
    code.  The 4.3 I got had version 7.1 of /sys/vax/emulate.s, the XINU
    version was not checked back in so there are no version numbers in it.
    A context diff between version 7.1 and this code did indeed fix the
    problem with printf, but it was a very short diff, and I was sure that
    there were probably other problems.  Since posting that diff would be
    effectively posting the MT. XINU emulate.s, I refrained from doing that
    also.  If enough people ask maybe MT. XINU can be convinced to post the
    diff themselves.

Sorry for this negative response.

-- 
Larry Philps	Engineering Computing Facility	University of Toronto
Usenet:     {linus, ihnp4, allegra, decvax, floyd}!utcsri!utecfb!larry
CSNET:      larry at Toronto
ARPA:       larry%Toronto at CSNet-Relay