Newsgroups: comp.arch
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: VAX RISC
Message-ID: <1990Nov1.180252.8427@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <10948@pt.cs.cmu.edu>
Date: Thu, 1 Nov 90 18:02:52 GMT

In article <10948@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>Given the tool as a constraint:  what could RAXen look like?  A MIPS
>with stack-based calling convention and non-IEEE floating point??
>Condition codes?  What about the VAX vector unit?  Trap handlers, and
>the stack searches for them? 

The three things you need to fix/break :-) in the MIPS chip if you want
easy mechanical code translation from the VAX would be floating-point
formats, condition codes, and stack-frame layout.  FP formats are pretty
obvious; it is just conceivable that you might be able to get by with
conversion instructions, using IEEE arithmetic for the real work, but
inevitably people would get different answers and start screaming.
Condition-code dependencies are all through VAX code and are subtle,
although in most cases a sophisticated code analyzer could find them
and cope with them if really necessary.  Stack-frame layout is a pain
because it will mean slower function calls, but there are undoubtedly
a billion things that know about it, and things like pointer arithmetic
make it very difficult to fix this mechanically.

>We know the page size... because they probably can't find all of the
>places where VMS assumed it.

VMS would need a lot of fixing no matter what.  The harder part is that
if the VMS system calls make page size visible at all, e.g. as the quantum
of user memory-allocation requests, then user code will depend on it.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry