By Luigi Logrippo
January 2007 –
last updated July 2011
The Olivetti Elea 9003 was the first industrial
electronic computer made in Italy. The first 9003 was completed in 1958 and its
commercial announcement was made in 1959. The first operational specimens were
installed in 1960, and the last in 1964. About 40 were produced. Its
predecessors, the Elea 9001 and 9002, were only prototypes and the first one
(of 1957) used vacuum tubes.
The
It has been claimed that this was the first fully
transistorized commercially distributed computer in the world. This claim is
difficult to substantiate for a time when all computers still contained some
vacuum tubes (I believe that the 9003 had some in the power system). IBM had
announced a fully transistorized system
Just as other computers of the time, this one was a…
dinosaur. It occupied large, air-conditioned rooms. It consisted of a series
cabinets interconnected by overhead wiring, each about 1.5 meters high. A
cabinet included main memory and CPU (additional cabinets were required for
memory extensions). Another cabinet was the control unit for the tape units. A
third cabinet would contain the control unit for other peripherals such as the
printer. The tape units and the peripherals themselves were quite bulky.
Happily, the machine looked good because it was designed by a famous architect,
Ettore Sottsass. Several
pictures are available on the Web.
A variant of Binary-Coded Decimal (BCD) representation
was used for addresses and data. The basic storage unit was the ‘character’.
With six bits per character, there were sixty-four possible characters. However
the binary encoding of numeric characters was not the usual one: e.g. 2 was
000011, 3 was 000111 (see programmer’s
reference card).
Of course there was no dynamic memory allocation so
each program would be loaded contiguously always at the same memory location,
and would be the only program in memory during its execution. All memory was
usable by the programmer, although it became usual to leave the first 3,000
characters available for testing programs.
There were no floating point
representation nor floating point instructions, this computer being
designed for commercial applications.
Memory size could go from 20K (two memory modules) to
160K characters, with typical sizes around 40K. The
CPU had an accumulator register of the capacity of 100 characters, which was
the main operating register of the programming logic, as well as 40 additional
registers, called T registers, each of the capacity of 5 characters. These were
mostly used as base or index registers, see below, although they could be used
to store and operate on any small values.
All the instructions were of eight characters. Many
instructions were of the form:
LL IIII T O
Where: LL was the length, the number of memory
characters affected by the instruction, IIII were four characters of address in
memory (I stands for Indirizzo in Italian), T was the
address of a T register whose contents was to be added to the address IIII, O
was the op code.
For example, the instruction:
12 3456
would take 12
characters starting from the address (3456 + contents of register 7) and move
(copy) them to the accumulator register. So if the current content of the
register 7 was 50, the characters in the memory positions 3506, 3505… to 3495
would be moved.
The 1960s were a decade of great inventiveness in
terms of proposing rich instruction sets, intended to help programming common
tasks. This phase in computer history came to an end with the introduction of the
IBM360, which avoided complicated instructions. The Elea 9003 instruction set
was fairly rich (99 instructions), and many instructions were designed to be
used in ingenuous ways, which was not necessarily conducive to clear
programming style. There were instructions to add, subtract, compare
the content of the accumulator register to the content of memory positions.
There were similar instructions for the T registers. The start positions of the
accumulator and the registers could be changed. There were many jump
instructions (unconditional as well as depending on several types of
conditions) and some instructions that operated directly between memory
locations. The list of all instructions is given in the programmer’s reference card. Some
complicated I/O instructions are mentioned below.
Although addresses were only four characters, letters
were also used, allowing to address the maximum 160K.
From the
programmer’s reference card it is possible to calculate the instruction
execution times. As mentioned, a memory cycle in this computer was 10
microseconds. Let us consider for example a very common instruction, the MA (to
transfer data from Memory to the Accumulator). The execution time for this
instruction is listed as 10+L memory cycles(‘tempo in periodi di cifra’).
This means, 10 cycles=100 microseconds to prepare the instruction (read it into
the CPU and prepare it for execution), plus as many memory cycles as there are
characters to be transferred. Hence, 150 microseconds would be needed in total
to execute an MA to transfer 5 characters from memory to accumulator, 200 to
transfer 10 characters, etc.
Ampex tapes were
used. All files were kept on tape. In
fact, one way of thinking of the 9003 is that it was essentially a machine to
process tape files: sorting, merging, updating, preparing and printing reports.
Typically, there would be from four to ten, up to twenty tape units. Many tape
units were useful to reduce tape sorting time, allowing dividing the sequence
to be sorted into a number of subsequences determined by the number of tape
units available. Sorting a tape file was viewed as a major job that could take
several hours. Interestingly, Von Neumann’s “merge-sort” algorithm, invented in
1945, was in common use, in variations such as polyphase
merge sort. Of many inventions of Von Neumann, this one is perhaps one of the
least mentioned; it may be one of the most commonly used, still today (if we
include algorithms that were derived from that one).
In the first years, the program and data would be read
initially from punched tape, later Bull card readers
became standard. The console had a typewriter, an Olivetti telex machine. The
console also had a keyboard from which instructions could be entered for direct
execution, one at a time.
There was a line printer, made by Sheppard. It was an
impact drum printer, which activated tiny hammers as they passed over
characters on a cylinder. It was capable of printing 300 lines a minute. It
could be programmed by means of a patchboard. For
example, by appropriate connections on the patchboard,
it was possible to program the printer to skip a line before printing a line
with a ‘+’ at the beginning, or to start a line on column 10 when encountering
the ‘%’ sign in the same position.
There was the possibility of attaching up to three
magnetic drums, meant to store the most frequently used files, or as swapping
devices.
One day we were shown a disk unit, a glass cabinet
containing a pile of large metal disks. I believe it could contain about
300,000 characters. This was produced outside of Olivetti.
At Olivetti, a mass storage unit was later developed
consisting of large floppy disks disposed in a toroid
shape around a reading mechanism, a sort of old-fashioned jukebox for those who
have seen such things. When a read instruction was executed, an arm would
quickly grab the appropriate disk and place it on the reading mechanism. The
disks could be manually inserted and removed. The name was Miac,
Memoria Intercambiabile ad Accesso Casuale.
My information is that none of these devices (drums,
disks, Miac) were ever installed at customer sites
for the
Computing centers that had many cards also used
specialized machines to convert card files to tapes.
There were sophisticated I/O instructions, as in other
mainframe computers of the time. For example, there was a tape search
instruction that could find on a tape file a block containing a given character
sequence (instruction PRN – Prepara Ricerca Nastro). Another
instruction could read a tape block, scatter its records in main memory
according to an address vector provided, and simultaneously compose (gathered)
another block for writing, according to the same address vector (instruction
NDN – Da Nastro seguendo una Direttrice
a Nastro). This facilitated tape sorting: a block
was read in, the program compared the sort keys and set the address vector, and
the records were written in sorted order on the output block. Simultaneously,
another block was read in the memory areas freed by the outgoing records, and so
on.
The computer had a primitive interruption mechanism
for I\O, as well as the concept of second and third program: up to 3 programs
could run at one time. This was made possible by the existence of two Transfer
Channels, the Internal (connecting memory, CPU, etc,) and External (connecting
slower peripherals). . The programmer had to determine which were
the first, second and third program, and had to explicitly program jump
instructions between programs (S2P, S3P: salta al secondo, terzo programma). Normally, the
first program would be dedicated to processing data in memory,
the second program would be dedicated to fast peripherals such as tape and
drums, and the third program to slower peripherals such as card readers and
printers. Priority was automatically given to the third, then second, then
first program. When a program became blocked for an I\O operation, a hardware
mechanism assigned the CPU to another program. A program could regain the CPU
after the operation it was waiting for completed. So multiprogramming, with
superposition of I/O times of different devices and CPU times was possible. The
scheduling of the programs was done by hardware,
however the three programs had to be explicitly programmed as parts of a single
program structure. Setting up the program in such a way as to optimize overall
execution time was far from trivial. These possibilities were complicated to
use and not well documented and thus were seldom used. It was later understood
that the management of multiprogramming cannot be left to the programmer, it
must be done by layers of software known nowadays as the operating system (of
course there was neither OS nor any BIOS whatsoever on this machine, the
concepts had not been invented yet).
From the programmer’s point of view, the organization
in characters was a considerable advantage with respect to the more usual
organization in binary words of other contemporary computers. A character on
the coding sheet became a character to punch on tape or card, and in turn that
became a character in the computer memory. No need to deal with octals or hexadecimals, as with many computers of the
time.
The fixed length of instructions was also an asset,
because it made it easy to determine the address in memory of each instruction.
The base registers enabled relative programming: for
example, in a loop to fill a block of records to be written on tape, the
instructions in the loop would all point to the first record, while on each
execution of the loop the contents of the registers would be updated to
successively point to the second, third, … record. This of course has always
been a standard programming technique, but not all computers of the time had
enough hardware registers to facilitate it.
As mentioned, there were also rather complex features,
but they could be avoided and indeed wise programmers avoided them …
When it comes to software, a painfully familiar
picture appears. ‘Basic software’ R&D started at Olivetti only around 1959,
as the
So, asks Pinocchio, pray tell, who will develop
input-output macros, mathematical macros, an assembler, a sort and merge
program generator, a linker and a loader, testing tools, FORTRAN and COBOL?
Very simple, answered the Blue Fairy, the machine is so pleasant to program
that programmers won’t mind developing all the necessary programs by
themselves, in machine code, over and over again for every application. Today
this is called ‘programming on the bare metal’, and starting from scratch every
time.
Still, some basic software was developed slowly,
mostly by a handful of people in the marketing division, independent of the
R&D division. By the time the
Initially, the main method of debugging was step-by
step execution controlled from the console, looking at the contents of the CPU
registers that were shown in binary on arrays of lights. One would also use
small memory dumps on the console typewriter, and larger ones on the line
printer. Some time later, the most commonly used debugging
program became the ‘Monitor’ which could be used to print the execution of a
program instruction by instruction, showing the instruction itself and the data
modified by the instruction, before and after. Obviously, it used a lot of
paper… Still, it may sound like a miracle today that this program only occupied
3K of memory; it was in fact the result of machine programming virtuosity.
(Incidentally, this is the reason why
At that time it was not commonly understood that in
order to justify the cost of software production, companies had to develop
long-lasting and wide-ranging lines of compatible computers. The IBM 360
(introduced in 1964) was the first family of computers that was based on this
idea. At the Olivetti R&D labs the same problem was addressed with research
on high-level languages that would eventually became common to all the
computers of the company, an idea that became practical several years later
with the language C.
Not much was known about programming at that time.
Some programming manuals in English existed, but they were not known at
Olivetti, and it is very possible that they were very machine-oriented, since
high level languages were just being invented. Programmers were mostly
graduates from technical schools who were given a five to ten week course on
machine language and flowcharting (see
flowchart template). Their first chance to work with a computer and run
programs would come after the course.
Programming style was most primitive. ‘Jump’ (or ‘go
to’) instructions were used wholesale and went in all directions. When a
program had to be modified, programmers did not dare to touch the code that had
already started to work, they would rather make a ‘patch’ in the form of a
‘jump’ instruction that would go to the end of the program to the new code, and
then jump back in. Later availability of an assembler (called Psico) did not change the picture much, because the
assembler was slow (the source program was stored on tape and each compilation
would take several tape passes) and so programmers did not want to reassemble a
program every time a correction was needed.
Some people today might wonder how anything useful
could be done with computers having such small memories. Well, some time ago I saw
(Comm. ACM 48 (2), 99-101) a ‘Hello World’ program, written, according to the
author, in ‘proper’ object-oriented style.
It had over 20 lines of Java-like code.
Its execution (let alone compilation) would involve the execution of
untold numbers of machine instructions, including Operating System code.
Granted, the same work could be done by a much shorter program however
apparently it would not be proper OO style.
On the
11 0017 # ø Prints the memory contents from address
17 for length 11
0X XXXX # 0 Stops the program
HELLO WORLD The constant at
address 17
And how to execute this program? Since it is short, we’ll type it directly in memory at address 1, so we
enter from the console keyboard:
27 0001 # %
Then we type the 27 characters on the console typewriter. Finally we branch to
position 8, the address of the rightmost character of the first instruction, entering
the following instruction from the console:
)# 0008 # O
Which causes the program to be executed. In modern terminology, this was our way to bootstrap on the bare metal.
Simpler times…
Well, and then we could talk a lot about the tricks so
common among machine language programmers of the time. Here is a particularly
daring one: since instructions were of length 8, if a program was loaded at
address 1, then legal branching addresses were: 8, 16, 24, 32… BUT perhaps a
program could be organized in such a way that an executable sequence could be
encountered by jumping at an intermediate address, such as 27. In such a way
one could have two partially overlapping programs. This trick was used in the
program Monitor, mentioned above. It was later understood that program
optimization can be much better achieved by using a transparent programming
style.
As example of short mathematical program, I offer the
attached long division subroutine
(with thanks to Prof. Stefano del Furia).
In the absence of loaders and linkers, this subroutine had to be copied in all
programs that needed it. The addresses of the subroutine had to be manually
written in at the time the program was written.
Address X was the address of physical memory where the subroutine
started in the program that used it. Note that the subroutine is in the first
column, the one titled ‘Istruzione’. The rest are
comments.
What application types did we work on? Payrolls,
inventory control, client inventories, bank and insurance accounting were the
bread-and-butter. Information retrieval for industrial libraries was one of my
specialties. Other groups worked on Operations Research and engineering
computations. And, thinking back, it is amazing how many possibilities were
being explored, which are still considered research topics now.
In the first years, the Olivetti Elea 9003 was plagued
by maintenance problems. Computers were maintained every morning by a team of
technicians. However by early afternoon things started to fall apart,
especially in the peripherals. Was there a non-recoverable read error in a
tape? Here is the fix. Perhaps the operator could still manually read in memory
the block, find the affected characters and replace them with a ‘reasonable’
interpretation of what should have been there. The whole tape could then be
reconstructed with the new block in place.
A programmer of those times recollected that a janitor
thought she had an identical sister, one going home at dawn and the other
arriving to work at
Because of the absence of debugging systems, program
debugging could be done only by programmers themselves when the machine was
available, usually in chunks of a few hours. This was usually at night, because
in the daytime computers were used for production purposes, to execute working
programs. The problems just mentioned, unavailability of software and
maintenance issues, caused many frustrations.
For example, here is how programs were initially
loaded for the first many months. They would be punched on paper tape, and then
read by the paper tape reader. Unfortunately, this one would usually tear the
tape, over and over. However before the tape was broken, a portion of the
program had been read in memory… so programmers read the paper tape in memory a
bit at the time, by repeatedly patching it, and then assembled the program in
memory by operations entered from the console. The assembled program would then
be copied to magnetic tape (itself fraught with errors). When card input became
available, the Bull card readers were also slow and unreliable.
Engineers usually take existing systems as models for
the new products they design. They usually want to improve on something that
already exists. So the question comes up, what were the predecessors of the
Elea 9003? I have not been able to find a clear answer to this question.
Giorgio Sacerdoti, the main designer of the computer,
did not leave any writings. Previously to his work at Olivetti, he had worked
with the Ferranti Mark 1, and one can recognize some of the characteristics of
this machine in his design: single address, fixed length instructions,
accumulator, index registers. However the Mark 1 was word-based rather than
character-based.
I hope that some of my readers will be able to help. It
may be possible to find similarities with other computers existing in 1957, the
date of the Elea 9001.
My account of the 6001 will be shorter, because I used
it much less. Also several of the observations already made for the 9003 hold
for the 6001.
The Elea 6001 was designed as a smaller brother of the
9003, and as a scientific computer (it would have been very nice if it had been
just a scaled down 9003… ).
Production started in 1961. About 170 were sold.
The Elea 6001 was also fully transistorized, with
ferrite core memory. Memory sizes were from 10,000 to 100,000 4-bit characters,
small sizes being the most common. It had a floating point representation for reals. It had a microprogramming memory (called matrice di sequenza logica, or logic
sequencing matrix), which was used to microprogram
mathematical functions such as multiplication, division and square root.
The Elea 6001 memory was organized in characters of 4
bits. As for the 9003, the binary coding
of the numerals was peculiar (see programmer’s
reference card). Of course, only sixteen characters could be represented in
4 bits, which means that numerical digits were represented by one character, while
letters had to be represented as combinations of two characters. This may be
acceptable for scientific applications, where numeric and alphabetic fields are
usually separated, however alphanumeric fields, containing variable numbers of
alphabetic and numeric characters, were of unknown length between a minimum and
a maximum (more on this below).
Each character had an extra bit, the ‘wordmark bit’ that delimited the length of the variables in
memory (more on this below). The bit was ON if the character was the most
significant character of a quantity, OFF otherwise.
There was, of course, floating point logic.
Instructions were of varying (and variable) lengths. A
typical instruction could be as follows:
OO T IIIII
Where OO was the op code, T was the name of a register
(registers were used in the same way as for the 9003), and IIIII were five
characters of address. The full list of instructions is given in the programmer’s reference card. A
typical instruction would operate from the address IIIII + T for decreasing
addresses until it encountered a character with the wordmark
bit ON.
Several of the characteristics of the 6001 were
difficult to manage for the machine code programmer, although they could have
been used to advantage by optimizing compilers:
In addition, variable-length instructions made it
difficult to calculate addresses in the program, another problem for the
machine-language programmer.
It should be noted that such memory-saving tricks were
not unusual in the small computers of the time (among others, they were present
in some IBM computers).
As in the case of the
At some point the decision was taken in Olivetti that
the Elea 6001 would be marketed for business applications, and a number of them
were sold for this purpose. Given the memory structure used by the computer, I
can only feel sympathy for the programmers that had to program these
applications. Consider that in business applications fields are often
alphanumeric, e.g. an address field punched in a card typically contains
variable numbers of numeric and alphabetic characters. So a card consisting of
80 alphanumeric characters could take anywhere between 80 and 160 characters in
memory (the extremes being the cases where it contained only numbers or only
letters). This quantity was not known until after completion of the read
instruction. Now, how to find the
different fields in the card? Field lengths and memory addresses had to be
determined in some way for each card read, at execution time (looking for
spaces, looking for certain characters?). Similar problems had to be solved for
lines to be printed: some fields were of varying length in memory but of fixed
length on paper. Things that are straightforward in most computers were
headaches in this one.
Surely these problems could have been helped by a
high-level business-oriented language, however I doubt
that one was ever made available. Would you like to write a COBOL compiler for
this computer?
It seems to be fairly obvious that the 6001 was
Olivetti’s answer to the IBM 1620, a transistorized scientific computer
announced in October 1959. It did share some of the characteristics of the
1620.
The
These are recollections from my working experience at
Olivetti, Computer Marketing division, from 1961 to 1964. They are written mostly from memory, with the
help of various sources. Corrections are welcome. Interventions could be
included in the form of signed addenda after my text.
Much additional information can be found on the Web.
De Marco, G.; Mainetto, G.; Pisani, S.; Savino, P: The early computers of
Volume 21, Issue 4, Oct-Dec 1999 28 – 36
Parolini, G.: Olivetti Elea 9003: Between Scientific Research and Computer
Business. IFIP, History of Computing and Education 3, 2008, 37-53.
Answer to quiz above: According to Wikipedia and other
Web sources, the word software first
appeared in print in a paper by statistician John W. Tukey
in 1958 in the American Mathematical Monthly. Tukey
is also credited with the invention of the word bit. However of course there are also differing stories on the web…
