CS452 - Real-Time Programming - Spring 2009

Lecture 29 - History : Controllers

Hardware for Real-Time

First Generation

Big mainframe computers
- transaction processing
- try to be fast, but it's up to the human to wait
Finite state machine controllers
- real-time
  - machines don't wait
- primarily focussed on small scale control
  - washing machines
  - transmissions
  - artillery shells
  This was previously done by special purpose mechanical, clockwork, electric & hydraulic devices
  - continuous control
    - Watt's governor
  - discrete control
    - dishwasher
      - open and close valves
      - turn pump off & on
      - open the soap door
    - espresso machine
  - Immediate ancestors of the computer
- usually represented as directed graphs with conditions
  - states are nodes
  - edges are transitions
- simple translation of mechanical hardware to software
  - discrete components, SSI, with program designed into the circuit
- run on a fixed clock
  - evaluate conditions
  - change state
- real-time is put in by hand, painfully
  - could be extensively tested

Second Generation

Big mainframe computers
- transaction processing
- multi-user executives
  - first multi-programming
  - the multi-tasking
- humans still wait, just not as long
Mini-computers
- real-time
- primarily focussed on large scale control
  - chemical plamts
  - trains
  - telecommunications
  always backed up by physical failsafes
- extremely rudimentary single threaded operating systems, to support
  - polling loops
  - cyclic execution
- interrupt service routines without operating system support
- Multiple tasks, when required, were programmed ad hoc using more than one computer
  - communication managed by hand
  - no explicit support for real-time
- Unix came into being on a minicomputer
  - as a response to the all-singing, all-dancing operating systems of mainframes
  - many Unix-like descendants
- DEC was the leading manufacturer
  - RT11 (real-time for PDP11) was the operating system it supplied
    - MS-DOS was pretty much a clone of RT11
    - second generation via Gary Kildall,
      - who couldn't be bothered to come to the phone when IBM called,
      - which may be an urban legend
  - PDP11-23 used the first fully-integrated 16-bit CPU on a chip.
  - What were the 8-bit CPUs doing?
    - The 6809 was the most common computer in the world for over a decade
    - after it overtook the 6502
    - and before it was overtaken by the ARM
- Distributed computing is obvious in retrospect but few saw it at the time.
  - Gentleman, Malcolm & Cheriton were among the first to see it
  - The result is CS452
Other tools, such as state charts
- real-time
- state machines with states that are Cartesian products
- focussed on small scale control
  - digital watches
  - traffic lights
  extension of clocked controller
- program was in ROM
  - called firmware
- cyclic execution
  - hardware-clocked

The Transputer: a Second Generation Offshoot

Use many co-operating, medium capability microCPUs to do a big job.

An idea whose time has now come.
Google

Problem is communication

Big granularity (thick client: MS, Google)
- minimizes communication
- maximizes replicated data
- The Google approach: a problem nobody thought about.
Small granularity
- minimizes replicated data
- maximizes communication
- Your system, like threading solutions, relies on shared memory for communication
  - The return of the FORTRAN common block
  - How would you handle caching?

Comminication requires either

a common bus, star topology
- system bus,
- LAN
- internet
passing messages along
- emphasizes the switches

The transputer was an early, now vanished, example of the latter

CPU, memory, switch on one chip
chips connected in an array
presumably a run-time system decides where tasks will go in order to
- maximize CPU throughput
- minimize communication overhead

Occam 2

Basic idea

processes (tasks)
- may be named, take arguments and return values
channels
- need a protocol (for type safety)
- must be named
time

Combining processes

sequential
conditional
- if/then
- selection by case
looping
- without test/break
- with test/break
parallel
- initiated when the keyword PAR occurs.
alternation
- guarded alternatives
- if more than one guard is true then select at random
  - can be prioritized

Channels

input
```
channel ? variable
```
- variable type must match protocol
- real-world hardware acknowledged by the anarchic protocol
- blocks when channel is empty
output
```
channel ! value // the value of a variable or the result of an procedure
```
- variable type must match protocol
- blocks until an input process accepts the data
input & output provide synchronization
- similar to sockets except for output blocking

Time

timer returns time as channel input
```
clock ? now
```
AFTER can be used to combine times
```
IF now AFTER yesterday THEN
```
AFTER can make timer input blocking
```
clock ? AFTER tomorrow
```

The Result

You can write a type-safe server, BUT

all possible clients must be known at compile time.

Program structure is more static than is allowed in your system.

This might be a good thing.

Third Generation

Multi-CPU servers
- more or less tightly coupled
- dominated by RPC and its relatives
Micro-computers
- many (most?) were used in real-time applications
  - point-of-sale systems
  - games
  - telephone switches
- supported by DOS (still in use!)
- much ad hoc intercommunication
  - as with mini-computers
Micro-controllers
- including DSPs

Fourth Generation

Multi-(multi-core CPUs) called servers
- communicate and synchronize using shared memory
  - using techniques from CS343
  or using RPC
  - using techniques from CS454
- multi-core, cache, and shared memory don't play well together
- performance limited by threading
  - explicit support for threading, e.g. register windows (Sun) increases performance hugely
  - communication still costly
Multi-core microprocessors
- performance strongly hampered by difficulty of multi-threading
- multi-core, cache, and shared memory don't play well together
Stream processors
- good for SIMD

Return to: