Flex machine: Difference between revisions
No edit summary |
m Checkwiki error 52 + general fixes using AWB (8421) |
||
| Line 27: | Line 27: | ||
<references/> |
<references/> |
||
| ⚫ | |||
| ⚫ | |||
==Further reading== |
==Further reading== |
||
| Line 35: | Line 32: | ||
* Martin C. Atkins: [http://mca-ltd.com/martin/Ten15/introduction.html<cite> An Introduction to Ten15 - A personal retrospective.</cite>] (includes a section about RSRE's Flex) |
* Martin C. Atkins: [http://mca-ltd.com/martin/Ten15/introduction.html<cite> An Introduction to Ten15 - A personal retrospective.</cite>] (includes a section about RSRE's Flex) |
||
{{Refend}} |
{{Refend}} |
||
| ⚫ | |||
| ⚫ | |||
Revision as of 23:32, 17 September 2012
In computing, there have been multiple systems named FLEX.
Alan Kay's FLEX system
Alan Kay developed his Flex system in the late 1960s while exploring ideas that would later evolve into the Smalltalk programming language.[1]
RSRE FLEX Computer System
Michael Foster and Ian Currie of Royal Signals and Radar Establishment (RSRE) developed the Flex Computer System [2] in Malvern, England, during the 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 hardware was custom and microprogrammable, with an operating system, (modular) compiler, editor, garbage collector and filing system all written in ALGOL 68RS.
There were (at least) two incarnations of Flex, implemented using hardware with writable microcode. The first was supplied by Logica to an RSRE design, and the second used an ICL PERQ [1]. The microcode alone was responsible for storage allocation, deallocation and garbage collection. This immediately precluded a whole class of errors arising from the misuse (deliberate or accidental) of pointers.
Another 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.
The whole scheme allowed abstract data types 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 data.
See also
References
Further reading
- Martin C. Atkins: An Introduction to Ten15 - A personal retrospective. (includes a section about RSRE's Flex)