PDP-11 compatibility mode in Vaxen
da...@murphy.uucp
the Eclipse/MV machines came out, they had the ability to execute the
instructions of the older 16-bit Eclipse machines *without going into a
compability mode*! (I think they did this be designing the MV instruction
set around the older set, so that all of the older set's opcodes remained
the same. Probably made the instruction set a bit messy... oh, well...)
Since they already had AOS running on some of the older machines,
porting their applications to the MV's consisted solely of copying the
binaries. I don't know how well this worked, either technically or as
a marketing point.
(Disclaimer: I do not and have not ever worked for DG.)
---
"I used to be able to sing the blues, but now I have too much money."
-- Bruce Dickinson
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP: ...!{sun,pur-ee,brl-bmd,bcopen}!gould!dcornutt
or ...!{ucf-cs,allegra,codas}!novavax!houligan!dcornutt
ARPA: dcor...@gswd-vms.arpa (I'm not sure how well this works)
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."
meis...@dg_rtp.uucp
> Actually, I believe Data General went them one better. When the first of
> the Eclipse/MV machines came out, they had the ability to execute the
> instructions of the older 16-bit Eclipse machines *without going into a
> compability mode*! (I think they did this be designing the MV instruction
> set around the older set, so that all of the older set's opcodes remained
> the same. Probably made the instruction set a bit messy... oh, well...)
> Since they already had AOS running on some of the older machines,
> porting their applications to the MV's consisted solely of copying the
> binaries. I don't know how well this worked, either technically or as
> a marketing point.
Let me follow up on that. As a disclaimer, I do work for Data General.
DG has had 3 families of computer: 1) Nova (16-bit machine ~16 instructions);
2) Eclipse (16-bit, ~150 instructions); and 3) MV/Eclipse (32-bit machine,
~350 instructions). The basic Nova instruction set has a series of modifiers
to the register-register instructions, such that the next 16-bit word (ie,
one instruction) would be skipped depending on some condition (such as a
register being 0 or non-zero). There were 3 bits for this skip condition,
including never skip and always skip. There is another 1-bit modifier that
says whether the result is to be stored back into the destination register
(test instructions were made by setting the NO-LOAD bit).
When it came time to design the Eclipse, the engineers were probably
told to make it compatible (before my time...), so they realized the
NO-LOAD and NO-SKIP combination was useless, and created the Eclipse
instructions from those bit patterns. However the Nova didn't just
die at that point, and later Nova's had instructions similar to, but
not quite the same as the Eclipse instructions.
Years later, the MV was designed to be upwardly compatible with the Eclipse.
It was realized that NO-LOAD and ALWAYS-SKIP were also useless, so most of
the MV instructions came from that pattern. One Eclipse instruction (XOP)
was also sacrificed to make up some other instructions.
The first MV (the MV/8000) kept the Eclipse memory management instructions
in addition to the MV instructions. This was dropped from later generation
MV's, and even from the MV/8000 (in case users were still using 16-bit AOS
on a MV/8000, two versions of microcode are shipped for the MV/8000, one
that has Eclipse memory management, but not 32-bit COBOL instruction
enhancements, and the other for 32-bit AOS/VS).
The method of getting into the operating system changed from Eclipse to
the MV (in the Eclipse, you execute a change context to OS type of
instruction, in the MV the OS is in an inner ring, but shares the address
space, and users call into the inner ring). Also, while the system calls
between AOS and AOS/VS are compatible, but unfortuneately, the system call
numbers are different. The upshot of this is that most users have to
relink their programs (and if they use direct system calls, recompile)
to move them from AOS to AOS/VS. Many programs (including the command
line interpreter) that run on AOS/VS are still 16-bit, though the percentage
is dropping.
Did this compatibility help DG (and hopefully it's customers)? Yes I think
it did.
--
Michael Meissner, Data General
...mcnc!rti-sel!dg_rtp!meissner
wal...@convex.uucp
the 32-bit superset of the 16-bit instruction set worked very
well. it turns out that to run under the 32-bit os (aos/vs), one had
to relink the 16-bit binaries. otherwsie, if the 16-bit os was
running no relinking was necessary.
g...@hoptoad.uucp
In article <900@dg_rtp.UUCP>, meissner@dg_rtp.UUCP (Michael Meissner) writes:
> ...while the system calls
> between AOS and AOS/VS are compatible, but unfortuneately, the system call
> numbers are different. The upshot of this is that most users have to
> relink their programs (and if they use direct system calls, recompile)
> to move them from AOS to AOS/VS. Many programs (including the command
> line interpreter) that run on AOS/VS are still 16-bit, though the percentage
> is dropping.
I worked for DG while they were designing and bringing up the 32-bit machine.
(By the way, Steve Wallach, convex!wallach, designed the machine architecture.)
I ran across my first production MV/8000 at Berkeley some time after I left DG.
I loaded in my old 16-bit programs and tried to run them under the 32-bit OS.
They failed miserably.
Now Edson DeCastro, the president and founder of DG, had *INSISTED*
that the 32-bit machine run old binaries without a mode bit. He had
canceled the two previous 32-bit-machine projects because they did not
do it this way. As told in "The Soul of a New Machine", Steve went to
him and said "what do we have to do so you won't cancel this one" and
he said "no mode bit". So they wedged the instruction set into the
holes in the old one, modulo some fiddling in the interrupt handlers --
the microcode actually fetched the first instruction of the interrupt
routine to see whether to handle the interrupt the "old" way or the
"new" way, depending whether it was an "old" or "new" instruction!
Steve got the hardware compatability right, but the software screwed it up.
What blew up my 16-bit programs was that the OS group had renumbered
the system calls. I called back to Westboro and talked to Claude Finn,
who managed the OS group. He said, "Yeah, I renumbered them, it made
the tables smaller."
* I * D * I * O * T * ! * ! * ! *
Now, I like Claude but he sure blew binary compatability for an utterly
trivial reason. He probably saved about 10 or 20 bytes! Half the
system calls in the 16-bit machine had the high-order bit on, because
they were handled by a "ghost" process due to 64K address space
limits. The other half were handled directly by the kernel. So there
were two tables and the code looked at the high order bit to figure
which one to use. Claude renumbered all the ghost calls to be sequential
with the kernel calls, so he wouldn't have to test the high bit and use
two tables any more.
What blew me away was that, as a good programmer and as the manager
of an operating system group, he didn't see that he had done any harm.
Of course, DG has never fixed this mistake, either, though Claude has
moved on. (They could add back the second table and support the old
ghost call numbers with the same trivial effort it took to remove
them.) By now nobody expects them to -- except me. But I'm not a DG
customer. I wonder how many customer-years of time were burned to save
those 20 bytes, and how many of them knew why?
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu g...@ingres.berkeley.edu
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvania
wal...@convex.uucp
claude always wanted a memorial named after him.