Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!haddock!suitti
From: suitti@haddock.ima.isc.com (Stephen Uitti)
Newsgroups: comp.arch
Subject: Re: MicroVAX emulation
Message-ID: <12035@haddock.ima.isc.com>
Date: 13 Mar 89 19:48:10 GMT
References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com> <1133@auspex.UUCP> <12000@haddock.ima.isc.com> <1368@husc6.harvard.edu> <679@scaup.cl.cam.ac.uk>
Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti)
Organization: Interactive Systems, Boston
Lines: 53

In article <679@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
>In article <12000@haddock.ima.isc.com> Stephen Uitti writes:
>>uVAX IIs implement all sorts of VAX instructions that just aren't in the
>>hardware.  Both VMS & flavors of UNIX do this (sometimes even correctly) ...
>>Almost no one uses these instructions, so who cares?
>
>We do!.  The MIT CLU compiler generates LOCC, CMPC and MATCHC instructions 
>for various operations on the (builtin) string type. 
>
>OK ... so you take a performance hit on an Ultrix uVAX II.  Fine you say.
	Wait a minute.  I never said that taking a performance hit
	would be OK.  It was more like, "If an instruction is never
	used anyway...".

	Similar things happen with floating point.  For example,
	current compilers for the Mac (Lightspeed C) support
	68881 code generation.  Of course, a Mac Plus doesn't
	have one of these.  Code produced with the option will
	either work fast or not at all.  One could have a VAX
	compiler option to generate wierd instructions or not.
	The code with the wierd instructions would run faster
	(one hopes) on, say, an 8600, but wouldn't run at all
	when brought to a uVAX II.  I prefer the way Turbo C
	handles 8087 (floating) support on PC:  look to see if it
	is there - if so, use it, if not, emulate it in software.
	That way it at least always runs.

>But on a UVaxII running the Amoeba OS, your program keels over!!  Why?
>Well ... the Amoeba kernel does not include the code for emulating the
>instructions!  And why is that?  Because the emulation code in Ultrix
>and VMS is all copyrighted by DEC

	4.3 BSD (Mt Xinu?) implemented their code from the
	architecture manuals.  The code differed from the Ultrix
	code, in that it didn't work.  Something about using the
	wrong manuals.  I assumed that since the OS seemed to
	work that these instructions were not used.  Silly me.
	Amoeba doesn't "really support" the uVAX II.  Maybe the
	Amoeba people can get support code from Mt Xinu.  [For
	a small fee, I'd do write it. :-]

>Contentious statement:
>  Until DEC is prepared to supply free and unencumbered source code
>  for the instruction emulation routines, the uVAX II cannot be said
>  to implement the VAX architecture!

	Pretty soon we'll all be working for the Free Software Foundation.

>-- Steve
	Stephen.
>
>#include "disclaimer.equ"
	yeah, sure.