Path: utzoo!attcan!uunet!fernwood!apple!usc!cs.utexas.edu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.YorkU.CA (David Collier-Brown)
Newsgroups: comp.arch
Subject: Re: DEC RISC Architecture?
Message-ID: <16034@yunexus.YorkU.CA>
Date: 11 Oct 90 11:55:37 GMT
References: <4462@trantor.harris-atd.com> <107038@convex.convex.com>
Organization: York U. Computing Services
Lines: 29

pelakh@mozart.convex.com (Boris Pelakh) writes:
| I don't know much about this new processor, but option 3 - porting VMS to
| RISC seems to be highly unlikely, considering the fact that VMS heavily
| relies on the original VAX architecture with it's ultra-CISC style
| instruction set.

  Er, I wouldn't describe the VAX as ultra-CISC.  The existing vCISC
architectures implement whole higher-level-language constructs as
single instructions... one of the better examples is the old Honeywell
EISbox, which did the basic constructs of COBOL and PL/1 in ``hardware''.
  That is not to comment on the research architectures, like the SWORD
machine or the BBN C-machine.

  As to running VMS on a RISCy chip, it depends on the expansion factor when
one maps (translates) VAX instructions into sequences of RISC instructions.
It is simple to go the other way: Mips did so to simulate their earlier
machines on a VAX. Going to a simpler architecture is a straightforward but
**labourious** problem in optimal instruction-sequence selection, eactly
what one slaves over to get a compiler to generate good code...

  The question reduces to ``do you expect to get good enough
price-performance out of the result to justify the effort?''.

--dave
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave or just
Willowdale, Ontario,  | postmaster@{nexus.}yorku.ca
CANADA. 416-223-8968  | work phone (416) 736-5257 x 22075