from Usenet, January 25, 1987

> 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 


---------------------------------------------------------------------------


excerpts from Carl Friend, "Data General NOVA Instruction Set Summary"
to help understand the Nova instruction format

http://users.rcn.com/crfriend/museum/doco/DG/Nova/alc.html

...

The ALC (Arithemtical/Logical Class) in the NOVA is used to perform all
operations requiring the use of arithmetic or logical manipulation of
bit-fields. All instructions in this class involve two accumulators (ACs)
and the Carry bit. Memory is never referenced, save for the instruction
fetch. All the instructions in this class have a common format:

           Destination            Shift             No
  1        Accumulator           Control           Load
/   \       /       \           /       \         /    \
+---+---+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
+---+---+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
    \       /       \           /       \         /    \              /
      Source           Function            Carry             Skip        
    Accumulator                           Control           Control

...

Optionally, it is possible to discard the results of Function. This is
useful if it desirable to merely test the outcome of an operation but
the result need not be saved. This is usually used in conjunction with
the Skip field, discussed next.

...

Finally, a decision may be made to skip the next instruction in the
sequence, or not, based on the result of Function.  ...  The possible
skips are:

   * 000 - Never skip
   * 001 - Always skip
   * 010 - Skip if Carry equals zero
   * 011 - Skip if Carry is non-zero
   * 100 - Skip if the result of Function is zero
   * 101 - Skip if the result of Function is non-zero
   * 110 - Skip if either Carry or result are zero (or both)
   * 111 - Skip if both Carry and result are non-zero

NOTE: In coding for the Nova, it is vitally important that the "No-Load"
and "Never Skip" options are never coded together. This bit configuration
is used by later Novas and the Eclipse line to implement extended
instructions. 


---------------------------------------------------------------------------