IBM 610 workstation computer 3454

KR Williams

I will describe a machine I was programming in 1993. The main processor was an Intel 8080 which controlled the applications hardware via its 8 bit ports. One of its application units was being replaced. (We kept the 8080 because because redesigning the interfaces of 3 shelves of electronics was too risky, the 8 bit 8080 bus was too weird.)

Up to date electronics allowed a single circuit board to replace several old circuit boards whilst providing more function. On the circuit board there was an Intel 386 microcontroller, Motorola 68k microcontroller and a FPGA. Each of the 3 microprocessors had it own bus and they were interconnected via dual port stores.

Description of a dual port store.

Dual port stores are designed to ensure that the address information on one side does not leak over to the other side. Anything still in the L2 cache is unavailable to the other CPU. Information and commands were pbutted using messages, the first byte acted as a lock. The messages had to written to and read from known locations so the software knew when it was processing private data and when communicating.

Caches work when you have 1 CPU. They are a small amount of memory between you and your rom. When the binary code of programs lives on disk the virtual storage system uses ram to simulate rom.

Caches can also improve the handling of loop variables and temporary locations. Given sufficient registers loop variables could live in registers but since few processors have 60+ registers the values have to be written back to ram.

If the software wishes to cache an I-O record it should claim ownership, read the entire record into private ram, perform the update and then write the record back. Any locks should then be released.

From the view point of the disk most software works in the following way: First It reads the program into virtual memory and opens the files. It then goes into a loop.

Read a record off the transaction file. Read the appropriate record(S) from the master file. Update the record(s) and write back to the master file (or new master file). Append a record to the print file. Repeat the loop.

When all the data has been processed the file headers and tails are updated, all the buffers are emptied and the program tell the operating system it has finished.

Only one CPU and process must update the data at a time. Consequently there is a swing door at every yard line. When just reading data the guy runs through the doors. If he wishes to change the data he must lock the door(s) behind him. The locked door will stop the next player. When the update has been completed he drives back unlocking the doors as he goes.

If the player falls over the referee has to unlock the doors.

Yes. Inter-process data needs locks on it too, frequently in the disk device handler. Where processes communicate through ram the processes need to set and clear locks. Depending on the instruction set and design of the bus the lock setting code may need to inhibit interrupts.

I used a machine with 6 off X86 in it. When we were setting the inter-processor lock variables the bus did not lock. It took us months to find what was causing the intermittent failures.

Andrew Swallow