Flex machine
The Flex Computer System was developed by Michael Foster and Ian Currie of Royal Signals and Radar Establishment (RSRE)[1] in Malvern, England, during the late 1970s and 1980s. It used a tagged storage scheme to implement a capability architecture, and was designed for the safe and efficient implementation of strongly typed procedures.
The original Flex hardware was custom and microprogrammable, with an operating system, (modular) compiler, editor and filing system all written in ALGOL 68RS.[2]: 3–4, 12, 19
There were at least four incarnations of Flex implemented using hardware with writable microcode. The first employed 64-bit microinstructions.[3]: 25 This was followed by a design employing 80-bit microinstructions built around the Am2900 bit-slice family, developed by RSRE as a "laboratory model" and then refined by Logica with the aim of producing a "reliably reproducible" prototype. A 24-bit processor word size was supported by this design, with 24-bit pointers referencing byte-addressed memory, although the unit of data transfer to memory was a 32-bit word consisting of four bytes. This word, augmented with tag and parity bits for each of its bytes, was constructed from four 10-bit memory devices. Integer arithmetic involved 24-bit values, whereas floating-point arithmetic involved 48-bit values.[2]
Alongside these early implementations on dedicated hardware was another, targeting a microcoded machine known as GEMINI that had been developed by RSRE and Plessey Electronic Systems to emulate legacy systems in process control and other applications. This machine employed 48-bit microinstructions and was designed to support 16- and 32-bit computers.[3]: 25–28 A subsequent implementation used the ICL PERQ and was known as PerqFlex. Due to the design of the PERQ, PerqFlex could not provide additional tag bits in the memory data path and thus incorporated a single tag bit within the 32-bit processor word to distinguish between pointers and non-pointers. This slightly impacted integers and floating-point numbers, but more seriously impacted the storage and access of boolean and character values, necessitating the introduction of special blocks or regions for packed boolean and character values.[4]: 3 [5]
The microcode enforced a tagged architecture to distinguish between different types of data, described as providing "a protection structure equivalent to that of capability machines", and it alone was responsible for storage allocation, deallocation and garbage collection.[2] By tagging pointers, the microcode could make them "unforgeable" by program operations, and this immediately precluded a whole class of errors arising from the misuse (deliberate or accidental) of pointers, or from compiler bugs.[3] Memory was allocated in blocks of different types that supported only certain kinds of operation. Block types were divided into two principal groups: those concerned with procedures and those concerned with data. Procedures were described by closure blocks that referenced the code, non-locals and constants, and could only be invoked. Invocation would cause a workspace block to be allocated containing local variables and the evaluation stack for a procedure.[2][4]: 10–11 Data would reside in dedicated blocks, with pointers only able to reference whole blocks without supplementary information. Individual data values would be accessed using a reference involving a pointer and an offset or displacement within a block. Elements in a vector would be accessed using pointer and displacement constrained by an upper bound, and array access would involve pointer, displacement, bounds and stride information.[4]: 34–35 [6]: 25
The whole scheme allowed abstract data types and for interfaces to privileged code to be safely implemented, as data items and the procedures permitted to access them could be bound together, and the resulting capability passed freely around. The capability would grant access to the procedures, but could not be used in any way to obtain access to the code or data.[2] Indeed, just as the operating system could employ such mechanisms to uphold its privilege and be protected from callers, procedures in user programs could similarly employ these mechanisms to act like an operating system to their own callers.[7]: 14 Since such mechanisms were provided at the hardware level, as opposed to depending on code generated for any particular programming language, information hiding restrictions stipulated by languages such as Modula and Ada could not be circumvented by interfacing to code in these high-level languages with code in low-level or permissive languages that did not support such restrictions.[6]: 5
A notable feature of Flex was the tagged, write-once filestore. This allowed arbitrary code and data structures to be written and retrieved transparently, without recourse to external encodings. Data could thus be passed safely from program to program.
In a similar way, remote capabilities allowed data and procedures on other machines to be accessed over a network connection, again without the application program being involved in external encodings of data, parameters or result values.
Another notable feature of Flex were the notion of firm and shaky pointers, the latter acting as a form of weak reference, used to point to blocks of memory that could be freed at the next garbage collection if all pointers to such blocks were marked as shaky. This is used, for example, for cached disc blocks or a list of spare procedure work-spaces.[6]: 11–12 [4]: 5, 16
COMFLEX, a packet switching network capable of transmitting data at magnetic-disc speed, was developed alongside Flex. It made feasible the use of remote file-stores, remote capabilities, and remote procedure calls.[8]
See also
[edit]References
[edit]- ↑ Terry, Phil F.; Wiseman, Simon R. (June 1988). On The Design And Implementation Of A Secure Computer System (PDF) (Report). Royal Signals and Radar Establishment. RSRE Memorandum No. 4188. Archived (PDF) from the original on 3 May 2014.
- 1 2 3 4 5 Foster, J. M.; Moir, C. I.; Currie, I. F.; McDermid, J. A.; Edwards, P. W. (October 1979). An Introduction to the FLEX Computer System (PDF) (Report). Royal Signals and Radar Establishment. Report No 79016. Retrieved 23 July 2026.
- 1 2 3 "Two implementations of the 'FLEX' machine" (PDF). IEEE MICRO 14: Proceedings of the 14th Annual Workshop on Microprogramming. 1 December 1981. Retrieved 23 July 2026.
- 1 2 3 4 Currie, I. F.; Foster, J. M.; Edwards, P. W. (December 1985). PerqFlex Firmware (Report). Royal Signals and Radar Establishment. Report No 85015. Archived from the original on 6 February 2018. Retrieved 6 February 2018.[dead link]
- ↑ Tombs, D. J.; Bruce, D. I. (November 1991). The Evolution of Ten15 (PDF) (Report). Royal Signals and Radar Establishment. Archived (PDF) from the original on 24 September 2015.
- 1 2 3 Wiseman, S. R. (July 1982). Two Advanced Computer Architectures: A Study of Their Support for Languages and Operating System (PDF) (Report). Royal Signals and Radar Establishment. RSRE Memorandum No. 82013. Retrieved 25 July 2026.
- ↑ Foster, J. M.; Currie, I. F.; Edwards, P. W. (July 1982). Flex: A Working Computer with an Architecture Based on Procedure Values (PDF) (Report). Royal Signals and Radar Establishment. RSRE Memorandum No. 3500. Retrieved 24 July 2026.
- ↑ McDermid, J. A. (November 1980). "Design and use of Comflex - a hardware-controlled packet switch". IEE Proceedings E - Computers and Digital Techniques. 127 (6): 233. doi:10.1049/ip-e.1980.0048. Archived from the original on 13 February 2018. Retrieved 12 February 2018.
Further reading
[edit]- Martin C. Atkins: An Introduction to Ten15 - A personal retrospective.[permanent dead link] (includes a section about RSRE's Flex)