Opening up EDSAC

EDSAC was the first of the Cambridge University computers, brought up in 1949 and intended for real scientific and mathematical work.

This year, there is considerable revival of interest in EDSAC – as the National Museum of Computing at Bletchley Park – have recreated a faithful reproduction of the original machine.  Also – the Open Source Hardware Users Group (OSHUG) have set up the EDSAC Challenge in September – which is to capture the flavour of EDSAC but using modern, open source FPGA hardware.

Why all this fuss about EDSAC – a 68 year old machine?

EDSAC was the first practical computer designed to do real work. It also exemplifies what a bit of ingenuity can do to an otherwise technically simple machine. It shows what can be done with the simplest of load-store architectures- and also teaches some of the tricks in making a hardware limited cpu do what you need it to do.

The EDSAC instruction set was based on the 5-bit teletype codes read in from a paper tape reader, that were common at that time as they were used for military and civilian communications.

Quite unusually EDSAC was given a multiplier instruction – somewhat simplified because of the serial nature of the memory and the arithmetic. EDSAC was based on the classic Von Neuman “Load-Store” architecture and as numerical precision was considered of high importance it used a 35 bit word length and the accumulator was 71 bits to accommodate the result of a 35×35 bit multiplication.

Instructions were designated capital letters – an early form of mnemonic, which made the program listings easier to read.  This feature is peculiar to EDSAC – and something that must have been lost when computers needed more than 26 instructions.

EDSAC used 18 instructions presumably tailored to the capabilities of the ALU and delay line memory.

What was it like to code on such a machine with such a limited instruction set?  I wanted to know – so I wrote an EDSAC virtual machine that will run on Arduino or MSP430 LaunchPad. From this I can then experiment with the architecture, of EDSAC and other unsophisticated processors.  This leads on nicely to my interest in Minimal Instruction Set Computers (MISC) – which by their nature are simple to model in code and use very little hardware.

So I created a simplified model – in C, which will run on an Arduino or MSP430 Launchpad. For practical coding reasons, 16 instructions will be used, which can be represented with a 4 bit instruction code.

Whilst EDSAC was created to help perform mathematical calculations – about 150 times faster than a 1940’s desktop mechanical calculator and so precision multiplication was deemed to be important,  the aim of the simplified model is to explore the limitations of a reduced instruction set, and especially when you are trying to create a virtual machine and an interactive programming environment with limited instructions.

From an instruction synthesis point of view, we have ADD, AND and SUBTRACT, so NEGATE, NAND, OR, and XOR should all be possible.

There are two jump instructions  Jump if A>=0 and Jump if A<0.  These  should be sufficient to meet most test situations.

A ADD
C COLLATE - AND
E JUMP IF A>=0
F VERIFY
G JUMP if A<0
H LOAD MULTIPLIER REGISTER
I LOAD INPUT CHARACTER
L LEFT SHIFT
N MULTIPLY AND SUBTRACT
O OUTPUT CHARACTER
P LOAD DATA
R RIGHT SHIFT
S SUBTRACT
T TRANSFER AND CLEAR
U TRANSFER NO CLEAR
V MULTIPLY AND ADD
X NO OP
Y ROUND ACCUMULATOR 
Z STOP AND RING BELL

The instruction set was simple and obviously dictated by the serial arithmetic unit. Multiplying iss a fairly straightforward operation with serial data – even on such a limited machine – the ability to multiply and add, or multiply and subtract was given high status.

EDSAC used about 3000 vacuum tubes for it’s logic – and memory consisted of mercury delay lines – where data existed as a series of standing waves that hd to be continuously refreshed.

This poster gives a really good overall view of the EDSAC machine – and has example code for “Initial Orders” which was a very early form of bootloader – in just 31 instructions. These instructions were “dialled” into memory using a system of hardwired uniselectors – as a lot of EDSAC was based on then current (General Post Office GPO) telecommunication hardware.

With the initial orders program running the main program could be loaded into memory from paper tape.

For the over curious – there is an EDSAC simulator here. Coding on such a primitive load-store architecture is certainly not a task for the fainthearted and takes some getting used to.

It’s easy to get hung up on historical details of this machine, so I created a cpu model, that behaves like EDSAC, but not necessarily constrained to the same teletype character codes or other hardware restrictions.

Perhaps it would be easier to impose a Register model on the cpu – so for example the first 16 locations in memory are given R0 to R15 names – that will certainly make it mentally easier to remember where variables have been stored.

On top of this register model – we can then lay out the virtual machine model, with data and return stacks, instruction pointer, top and 2nd, etc.

The code for the MSP430 is here on Github Gist . It consists of a simple instruction decoder and memory model. Instructions may be written in any text editor and then sent to the simulator using a terminal program – such as Teraterm.

 

 

 

//---------------------------------------------------------------------
// EDSAC CPU Model
// --------------------------------------------------------------------
// Instructions between Q and Z are replicated lower in the table
// This allows all instructions to be accessed with a 4 bit opcode
 
 static void execute(int instruction) // This is the EDSAC CPU model
 
 // The Alpha code is held in the top 5 bits of the instruction
 // The bottom 11 bits hold the address
 {
 insn = (instruction & 0xF800)/2048 ;
 _pc = pc + 1;
 
 n = (instruction & 0x7FF); // n is the address field - lower 11 bits
 
 switch (insn) 
 
 
 {
 
 case 0: A += m[n] ; break; // ADD A
 case 1: A -= m[n] ; break; // SUB Subtract
 case 2: A += (m[n] & R) ; break; // COL C
 case 3: m[n] = A ; break; // DEP Deposit D -no clear
 case 4: if(A>=0) {_pc = n; } break; // JGT E
 case 5: break; // VER F
 case 6: if(A<0) {_pc = n; } ; break; // JLT E
 case 7: R += m[n] ; break; // CPY H - Load R register
 case 8: break; // INP I 
 case 9: A = m[n]>>1 ; break; // Right Shift
 case 10: m[n] = A; A=0 ; break; // Transfer and clear
 case 11: A = m[n]<<1 ; break; // LSH L
 case 12: A += (m[n] * R) ; break; // Multiply and ADD
 case 13: A -= m[n] * R ; break; // Multiply and Subtract- N
 case 14: break; // OUT O
 case 15: break; // PUT P
 case 16: break;
 case 17: A = m[n]>>1 ; break; // RHS R
 case 18: A -= m[n] ; break; // SUB S
 case 19: m[n] = A; A=0 ; break; // TRC T 
 case 20: m[n] = A ; break; // UPD U
 case 21: A += (m[n] * R) ; break; // ML+ V
 case 22: break;
 case 23: break; // NOP X
 case 24: break; // RND Y
 case 25: break; // END Z
 case 26: break; 
 case 27: break; 
 case 28: break; 
 case 29: break; 
 case 30: break; 
 case 31: break; 
 
 }


pc = _pc;
 instruction = m[pc];

next_t = _t;

}
 
 
 
 // End of CPU model
 // ------------------------------------------------------------------

 

 

 

Advertisements

About monsonite

mostly human
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s