dave@murphy.UUCP (01/17/87)
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.
(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: dcornutt@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."meissner@dg_rtp.UUCP (01/26/87)
In article <48@houligan.UUCP> dave@murphy.UUCP writes: > 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
wallach@convex.UUCP (01/28/87)
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.