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. 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. 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. |
© 2001-2003 Jean Bellec