SECTION IV
Modes and Emulators
A specific
feature of GCOS was its capability to operate in foreign modes by providing to the user an
environment identical to that he enjoyed (?) in his previous machine. Those modes run
simultaneously with GCOS native applications. While such simulators are now available for
free as simulators for 8-bits microcomputers in our PCs, the performances ratio between a
to-day 32-bits processor and the emulated machine is more than 10 to one. In the case of
GCOS emulators, the margin was significantly lower and the realization of emulators needed
more features and more talents. The marketing objective was to emulate with a positive
margin systems that had a row computing power not inferior to 1/3 of the raw power of the
GCOS hardware.
That hardware was based upon a 32-bits architecture, and used a bank of registers. The
strategy adopted for GCOS emulators was to use that hardware in conjunction with a
dedicated firmware to interpret the sequence of instructions of the emulated machine. No
particular effort was made to reuse the native firmware. This architecture is similar to
that used by the lower models of the IBM S/360 as opposed to the strategy used on the
emulators of S/360-65 where native instructions were monitoring each emulated
instruction.
However some emulated machines had features that cannot well emulated by the native
hardware. In such case, an additional feature was added to the hardware either as standard
(like op-code decoding in the P7G system, or as an option (like flags processing in the P7
system). Those features were ignored in native mode.
The emulator firmware processed all instructions with some exceptions. The exceptions
concerned features due to be shared by the native programs due to operate simultaneously
with the emulators (timers, I/O ...).
The general architecture of the emulator was to encapsulate the emulated program into a
native mode program that monitored the emulator launching and processed the functions not
executed by the emulated firmware. The emulated memory was included as a native segment in
the "emulator" process group. That "emulator" was in general
multi-threaded, allowing a processing of I/O more effective than the emulated machine (for
instance by increasing the buffer capacity, or in relinquishing control to the emulated
program without waiting for I/O completion). Mapping the I/O devices of the emulated
machine or faster native devices was also a way to achieve better overall performances.
GE-100 Emulator
The GE-100 system
emulated on Level-64 was a batch second-generation system with card input, printer output
and files located on tapes or discs. Sequential processing was the rule, but optional
discs were often used in "direct access", by their physical addresses.
The system used
byte addressing, as was Level-64, so there was no need for special hardware for the
emulation. GE-100 instructions sequences were interpreted by the emulator micro-programs
at the exception of a few instructions noticeably I/O that were trapped to the emulator
support software.
The emulator
software was a native GCOS process group including several threads dealing with I/O and
exceptions and addressing a data segment image of GE-100 main memory.
I/Os were buffered inside the emulator process group, allowing the operation to define
larger data blocks on the native devices than the usual 80 characters of the emulated
machine.
GE-100 discs were
reconnected to the Level-64, but the emulator software offered also the access of the
GE-100 disc image on native discs (GE-100 images being considered as native files on the
direct access method).
H-200 Emulator
Honeywell
H-200/2000 had an architecture quite different from Level 64. H-200 was derived from the
IBM 1401 architecture. It handled data as 7-bits bytes using a flag (an additional bit in
the last byte) to delineate character strings; when the native machine was processing
8-bits bytes defined by length in the instruction. A hardware feature to detect the flag
by hardware instead to checking it by firmware for each data byte. The emulator was so
able to benefit from the 4-byte word mover capability offered by the native hardware,
instead of performing moves one byte at a time. That flag detection was the main feature
of the special hardware card cage required by the emulator.
The software side
of the emulator had a similar architecture to the GE-100, while designed in Billerica and
initially delivered under the 4A Back-up environment (a back-up operating system designed
in Boston) instead of GCOS-64. In 1975, it was integrated within GCOS 64.
H-200 discs were
also supported for conversion purpose by the GCOS operating system through the HFAS access
method. Few programs apart a conversion utility did use that native method. H-200 differed
from other file organization in allowing a hardware search on the data field of a record.
HFAS was also available on native discs allowing the emulator to tale advantage of higher
capacity and performance.
The Honeywell
policy evolved during the 1970s attempting to move H-2000 customers to DPS-8 by attaching
a co-processor to the DPS-8. So, H-200 emulation was abandoned at the end of the 1970s on
the different versions of DPS-7
S/360 Emulator
Honeywell placed
hopes in a S/360 emulator and a running system was designed by Billerica's engineering.
As Level 64 basic
instructions and registers had been limited from S/360 and as the I/O formats were a
superset of IBM offering, the emulation of that machine was relatively easy. S/360
emulator was a specific piece of firmware reusing native firmware primitives. CSV
statements were translated by software into native calls.
The delivery of
S/370 and the ambiguous position of IBM on 360/20 put the technically successful program
in marketing jeopardy. Paging would require the implementation of that feature on Level-64
to maintain efficiency of programs and IBM unbundling policy seemed to forbid a customer
to use a DOS/VS license on a stranger system.
Siris 3 Emulator
Siris 3 emulation
was developed to maintain the CII-HB commitment to Iris-5x/6x customers. As it was the
case with GE-100 and S/360, no special hardware was required. Some features of Iris-65
like topographic memory were not software supported or could be supported through the
paging hardware of DPS-7/8x.
A special
firmware was developed for the P7G processor and was supported by a native software
process group performing I/O and sharing resources with GCOS software. A few changes were
made in Siris 3 software to minimize the interpretation work, especially for supporting
the DSA front-end processor. Support of CII specific data communications protocols (TMM-VU
and other) was also added to the FEP and handled via FNPS by the Siris 3 emulator
software.
Siris 8 Emulator
CII Iris 80
architecture was an extension of the SDS Sigma 7 32-bits architecture. It added
essentially a MP capability to the Sigma 7. The main difference from the native mode was
the position of the op-code that was inverted inside the word. As op-code detection was
the first thing interpreted by the emulator (as a branch vector) it required that the
instruction decoding part of the P7G be able to reference the last part of the word
instead of the first. The cost of that modification was low and the feature stayed unused
in the majority of systems.
The emulator
software interpreted CSV (call supervisor) instructions, bypassing the inner layers of
Siris 8 for efficient data management. It was the first program to take benefit of the SMP
operation of DPS-7.