Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re:  Re: MicroVAX emulation
Message-ID: <37515@bbn.COM>
Date: 21 Mar 89 15:19:41 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> <12035@haddock.ima.isc.com> <687@scaup.cl.cam.ac.uk>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 24

In various articles various writers write:
>> > 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.
>> Similar things happen with floating point [example about 68000's & 68881's 
>> & Lightspeed C deleted for brevity]
>
>The example is not applicable for 2 reasons.
>
>1)	The "68000 architecture" does not include FP instructions.  The
>	"VAX architecture" DOES include the string instructions.
True statements.  HOWEVER, the MICROvax architecture does NOT include
string instructions, other than MOVC3 (and MOVC5?).  Some DEC-supplied
software includes emulation to ease the transition.  Generating the
in-line emulation using a reduced instruction set is NO PROBLEM, right?
And gets better performance too?  :-)

>> >  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!
1.  The uVAX is NOT said to implement the VAX architecture.
2.  MIPS, AMD, Intel, Motorola, Sun, etc. don't do your work for you either.
    I don't understand why it is OK for the RISC suppliers to supply
    reduced instruction sets, but if DEC does it it's evil.
-Stan