By Luigi Logrippo
January 2007 –
last updated March 2013
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 Elea 9003 CPU was entirely transistorized, but not
integrated. In fact, there were approximately 300,000 components in a typical
system, between transistors and diodes. In the RAM module, each bit was stored
in a ferrite ring (a core). The
diameter of each core was approximately mm. 1 and each core was crossed by 4
copper wires. A character consisted of six bits with an additional parity bit
and a ‘wordmark’ bit (the latter two not visible from
program), so a module of 10,000 characters of memory required 80,000 cores –and
each was threaded manually, I was told!
The size of such a module, with the addressing circuitry, was of
approximately cm. 50x45x20. The ‘periodo di cifra’=memory cycle (access to one character for reading or
writing) was 10 microseconds, thus the machine’s speed was 100KHz.
This was fairly standard technology around 1960, in fact initially somewhat
ahead of other competing systems.
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.
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 608 in mid-1955,
however this one should be put in the category of punched-card equipment: it
was programmed from a patch-board and it was extremely limited in terms of main
memory and number of program steps. The Metropolitan-Vickers MV950 of 1956 has
been cited as the first transistorized computer to become commercially
available. Siemens had announced a fully transistorized System 2002 some months
before the 9003. IBM transistorized mainframes followed months later. In
fairness, it must be said that these were shipped with a good set of software
tools from the start, which was not the case for the Elea. However
surely the Elea 9003 was among the very first in the world in this category.
And Olivetti management showed a lot of vision and courage to bet on transistor
technology at a time when leading computer manufacturers were still selling
vacuum tube technology.
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).
The decision of using decimal, rather than binary,
representation of numeric quantities and addresses was friendly to programmers
but created some problems. For one, numeric quantities required more bits than
necessary for binary representations, since numeric characters had two bits (of
six) that were always 0. This is normal in today’s large memories but had
consequences in the memory sizes of the times. In addition, if the addresses
could only be numeric, the maximum memory size would have been 9999. In order
to allow addressing the second memory bank the address after 9999 was ø000,
and after ø999
we had A000. Somehow, address 40,000 was 0ø00, no need to get into further details … Since the T registers
were used for addresses, the arithmetic on the T registers had to give valid
addresses and thus was different from the arithmetic for the accumulator. The
complexity of the arithmetic unit was considerable for the time.
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 7 F
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.
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 Elea 9003. The only mass storage units were the tapes.
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 Elea 9003 started to be marketed, and with a very small staff. At peak
some years later, this staff reached a level of about 35 people for both Elea
9003 and 6001: compare this with IBM, for which there is a contemporary picture
showing 25 people in the FORTRAN team only. Furthermore, the main mandate of
this small group was innovation, to develop concepts in programming languages
and compilers. There was no integrated planning between this group and the
marketing group, a structural fault that had serious consequences.
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 Elea 9003 went out of production, this
software was limited to: the assembler Psico, some
testing software, and some tape merging and sorting utilities.
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 Elea 9003 programs usually
are written to be loaded at memory address 3000). Some time
later a more sophisticated testing program became available, where one could
specify parameters to focus on certain sequences of instructions.
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 Elea 9003, we would program this in 27
characters; the rest of the memory would be empty.
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 8:30. A manager asked for explanations when she discovered
that ‘the machine’ had been shut off between 00:00 and 8:00 a nice Christmas
day.
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 Elea 9003, software was late
arriving. The software R&D division produced a compiler for Palgo, a dialect of Algol.
However the scientific programming world at that time (and for a long time
thereafter) was dominated by FORTRAN. So a compiler for FORTRAN had to be
produced quickly by the marketing division, a fact that caused embarrassing
rifts in the company. It is interesting to note that the R&D division was
historically correct, since many modern programming languages have been
influenced by Algol through Pascal, Ada, C, and Java, while
FORTRAN has remained almost without descendants.
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 Elea 4001 was a 7-bit computer, on which the
Olivetti engineering team worked around 1963. I gather from the information I
have found that it was not marketed and evolved towards an 8-bit computer
called Elea 4-115. In 1964 Olivetti sold its computer division to General
Electric and this machine was adopted by GE, becoming the GE-115. It was also
sold by Bull under the name Gamma 115. This one was a successful computer:
apparently about 5,000 were sold worldwide.
I have had no experience with these machines, but I have the 4001’s programmer’s reference card,
which I am making available in case it interests someone.
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 Italy. Annals of the
History of Computing, IEEE
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…
