Tuesday, December 08, 2015

Learning from the Past

Learning from the Past

We can learn a lot from looking back at computer systems of the past - that were by their very nature much simpler than those we use today, constrained by memory and the cost of the hardware they were implemented in.  The early computing pioneers had to find practical ways to program and run their machines using very basic technology.

It's now almost 50 years since EDSAC was designed then constructed at Cambridge University.  It was a serial arithmetic processor - as this consumed vastly less hardware than a parallel machine. Whilst it was really quite a simple, resource limited machine - it was capable of serious mathematical calculation  - assisted by the collective genius of the Cambridge maths department.

EDSAC had some interesting features that are worth noting, as they are still very valid to this day.

The first was the limited instruction set or "Order Codes" - which had to be input into the machine memory from a 5-bit paper tape. This was standard telegraphic practice at the time, and by way of a couple of shift characters, was able to input capital letters, numerals and some punctuation symbols. With this limited character set of around 60 symbols - the whole instruction set was coded - and this naturally made it a minimal instruction set machine.

The capital alphabetical characters were used by way of instruction mnemonics - mainly because they were easy to read and remember.

The second notable feature was that despite the limited instruction set, there were specific codes for paper tape input (I)  and teleprinter output (O).  These operations were central to the whole functioning of the machine, and were given their own high prominence instructions.

The boot up sequence of EDSAC was referred to as "Initial Orders".  This was effectively a hard coded bootloader routine that allowed paper tape to be read direct into the main memory.  It was hardwired using uniselectors - that were a common electromechanical data-selector (mux - demux) used in telephone exchanges.

EDSAC had limited memory - which consisted of 32 mercury delay line "tanks"  which could store initially 256  36 bit words. This was later extended to 1024 words.

Instructions were executed at a rate of approximately 600 per second.

Details of the instruction set, are given in this poster 

EDSAC is currently being recreated from original drawings, photographs and contemporary notebooks at the National Museum of Computing in Bletchley Park.

Applying it Today

The value of studying a simple machine like EDSAC is that it illustrates how the core of the machine, the instruction decoder, the arithmetic unit and the memory work together to make a functioning computer.   These techniques may be applied to the design of any simple processor - translated into whatever hardware is available - today FPGA is the most likely choice - allowing a small fast and agile machine.

It is clear that the machine language for EDSAC was compact, memorable, human readable  and with a little practice could be written down on paper,  and the various jumps worked out manually.  The first programs would have to be done this way  - because there was no other solution. Assemblers and Compilers were still a long way off.
Notable from this design was the minimum instruction set and the use of alphabetical character as mnemonics.  The 5 bit character was decoded directly into the instruction field.  After the instruction came the 10 bit memory address on which the instruction operated.  It appeared that literals were not coded in the instruction - however - some constants like 2 and 10 were placed in low address memory locations.
A machine like EDSAC could be readily ported to a FPGA, with the core of the cpu described in about 100 lines of Verilog.  This was the approach taken by James Bowman with his J1 Forth cpu - a simple machine, implemented in a small FPGA and intended for high speed operation.  Many of the features of the EDSAC are apparent if you look closely at the J1 design - although fundamentally one is a load-store architecture and the other a stack architecture.

FPGAs logic cells have block RAM resources, that are arranged in 9 bit arrays - the extra bit being available for parity or other purposes.  This means that 18, 36, 72  bit structures are all possible in the high speed block ram.

Even in a small FPGA there are sufficient logic blocks to implement multiple processor cores, linked by shared dual port RAM. Two or four EDSAC cores could fit into a Spartan 6 LX9. These small cores are designed for efficient execution of code, within a small address range - so suited for small applications.

The Fabric of Computing

This week Jean Claude Wippler has been running a week long series of posts discussing what he has termed The Fabric of Computing.  TFoC.

In his posts he starts by saying that whatever happened to the golden days of interactive computing where great things were achieved on processors that were very much resource limited when compared to these we use today.

He looked at how 40 years ago, some very creative programming led to the creation of some clever applications such as Tiny Basic - which at a pinch, could be coded into about 2500 bytes of memory. This was a complete workable programming language, line editor and interpreter - shoehorned into the smallest of memory maps.

Jean Claude then compared this with an application that many of us are familiar with  - the Arduino IDE. This now has a disk image of some 370Mbytes - just so that we can program an ever increasing range of microcontrollers in C++. He concluded that there has to be a better way - and I tend to agree with him.

I too am a fan of minimal computing, and I have even ventured into the design of an interpreted language that can run on virtually microcontroller - and offer a range of commands, aimed specifically at exercising the hardware.

LED flashing, audio tones, PWM, ADC reading, digital input and output form just a few of the commands available directly to the User via a serial terminal. Loops, integer arithmetic, conditional branches millisecond and microsecond delays and easily extendable from the keyboard terminal are key features of this minimal user interface.

The language directly interprets the serial characters input from the terminal (or a file) and executes a series of subroutines. 

The characters are chosen for ease of memorability - not unlike the "Order Codes" that were used in the 1949 EDSAC instruction set  - see poster. 

The "language" was inspired by Ward Cunningham's Txtzyme Interpreter - which I have built upon and greatly enhanced to include integer maths, defining new words, compilation, and a host of other features. 

The langauge "SIMPL" has been continually evolving since May 2013 - so I refer you my original blog post - and you can follow the progress from there.

At the moment it is coded in C for portability, and it sets up a virtual machine on the target processor. I have ported it to everything from Arduino ATmega, STM32xxx and MSP430. 

SIMPL is based on a virtual stack machine - which makes it very suitable for "Forth - like" languages. Many of the ideas in SIMPL were borrowed from Forth, and the SIMPL vocabulary is almost a subset of Forth. 

I am now working towards porting SIMPL onto the J1b Forth Processor - to get blistering performance from a specialised, but simple open core cpu.

In the future, I see SIMPL as almost equivalent to a bootloader - in that it is a tiny program, loaded into the target microcontroller once at the start of the debug session - and from that point on it gives you access to a series of debugging resources, a user interface and the means to write interactive interpreted code to exercise whatever code that you are working on.

Any microcontroller, once procgrammed with the SIMPL kernel will be able to interpret the SIMPL commands - a form of bytecode - either typed from the terminal or loaded from a file.

What Next?

Today I received another Papilio Duo FPGA board from my friends at Gadget Factory. This is the Spartan 6LX9 FPGA connected to 2MB of fast static RAM.
I opted for the offer of the free "Computing Shield" - that was available as a special deal a couple of weeks ago.
The computing shield allows connection of the following hardware:
VGA output  RGB 4:4:4
PS/2 Keyboard and Mouse
micro SDcard
RS232 COM Port
2 Atari Games controllers
2 Audio channels
4 User LEDs
4 User Switches
Reset Switch
1 "Grove" connector
With this hardware it should be possible to recreate a comfortable computing environment.

No comments: