Help us defend against VMS!

[Rahul Dhesi]

In article <3201 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>	If I understand Henry correctly, he's saying that you can't port
>VMS to a RISC machine.  Why not?  Other than it's proprietary nature, what
>is there to prevent a VMS port hardware other than a vax?

The VAX/VMS kernel seems to be written in some combination of assembly
language and the high-level language BLISS.  But BLISS is a machine-
dependent language.

The basic design of VMS is heavily dependent on the VAX architecture.
The four VAX CPU modes (kernel, executive, supervisor, user) are
everywhere assumed to exist and the security of the system relies on
having these modes available.  System calls assume the existence of a
VAX-specific trap mechanism.  Even specific address bits are assumed (I
believe the high bit in the address distinguishes between user address
space and system address space).

Take a look at the VAX/VMS Internals handbook, and compare it with the
UNIX design book by Bach.  The VMS book is chock-full of information
about how specific VAX registers are used and how things are pushed and
popped on the stack by instructions to change mode to kernel etc., how
address bits are used, how hardware-dependent tricks are used to
achieve this or that.  The UNIX book, on the other hand, says nothing
about the hardware.  The difference in philosophy is clear.

The concept of separating a small machine-dependent part and a large
machine-dependent part and rewriting only the small machine-dependent
is foreign to VAX/VMS.

Making VMS work on a non-VAX architecture would not be a port. It would
be a rewrite from the ground up.  VMS is an efficient, specialized
dinosaur that will become extinct when the climate changes, and the
climate is changing.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi