Rekursiv - Revision history

AnomieBOT: Dating maintenance tags: {{Clarify}}

2024-10-06T05:58:03Z

Dating maintenance tags: {{Clarify}}

← Previous revision		Revision as of 05:58, 6 October 2024
Line 28:		Line 28:

	===Microcode===		===Microcode===
	The processor's instruction set was stored in a dedicated area of static RAM known as the "control store". It was accessed via a dedicated 16-bit bus, organized as 16,384 words of 128-bits each. A separate "control store map" section of SRAM holds a numbered table of entry points into the microcoded routines, mapping a 10-bit [[opcode]] onto one of 2,048 entities.{{clarify\|reason=A 10-bit value can only address 1024 entities.}} In a conventional processor, the map would normally be implemented in hardwired logic in the opcode decoder.{{sfn\|Pountain\|1988\|p=349}}		The processor's instruction set was stored in a dedicated area of static RAM known as the "control store". It was accessed via a dedicated 16-bit bus, organized as 16,384 words of 128-bits each. A separate "control store map" section of SRAM holds a numbered table of entry points into the microcoded routines, mapping a 10-bit [[opcode]] onto one of 2,048 entities.{{clarify\|reason=A 10-bit value can only address 1024 entities.\|date=October 2024}} In a conventional processor, the map would normally be implemented in hardwired logic in the opcode decoder.{{sfn\|Pountain\|1988\|p=349}}

	Opcodes could be parts of objects and stored in the same way that any other data would be using Objekt. For performance reasons, a separate memory bank known as NAM (and NAMARG) reserved 524,288 40-bit words storing 10-bit opcodes and 30-bit arguments. NAM connected directly to the processor via its own bus, making it act more like a cache in modern architectures.{{sfn\|Pountain\|1988\|p=349}}		Opcodes could be parts of objects and stored in the same way that any other data would be using Objekt. For performance reasons, a separate memory bank known as NAM (and NAMARG) reserved 524,288 40-bit words storing 10-bit opcodes and 30-bit arguments. NAM connected directly to the processor via its own bus, making it act more like a cache in modern architectures.{{sfn\|Pountain\|1988\|p=349}}

UnladenSwallow: /* Microcode */

2024-10-06T05:37:42Z

Microcode

← Previous revision		Revision as of 05:37, 6 October 2024
Line 28:		Line 28:

	===Microcode===		===Microcode===
	The processor's instruction set was stored in a dedicated area of static RAM known as the "control store". It was accessed via a dedicated 16-bit bus, organized as 16,384 words of 128-bits each. A separate "control store map" section of SRAM holds a numbered table of entry points into the microcoded routines, mapping a 10-bit [[opcode]] onto one of 2,048 entities. In a conventional processor, the map would normally be implemented in hardwired logic in the opcode decoder.{{sfn\|Pountain\|1988\|p=349}}		The processor's instruction set was stored in a dedicated area of static RAM known as the "control store". It was accessed via a dedicated 16-bit bus, organized as 16,384 words of 128-bits each. A separate "control store map" section of SRAM holds a numbered table of entry points into the microcoded routines, mapping a 10-bit [[opcode]] onto one of 2,048 entities.{{clarify\|reason=A 10-bit value can only address 1024 entities.}} In a conventional processor, the map would normally be implemented in hardwired logic in the opcode decoder.{{sfn\|Pountain\|1988\|p=349}}

	Opcodes could be parts of objects and stored in the same way that any other data would be using Objekt. For performance reasons, a separate memory bank known as NAM (and NAMARG) reserved 524,288 40-bit words storing 10-bit opcodes and 30-bit arguments. NAM connected directly to the processor via its own bus, making it act more like a cache in modern architectures.{{sfn\|Pountain\|1988\|p=349}}		Opcodes could be parts of objects and stored in the same way that any other data would be using Objekt. For performance reasons, a separate memory bank known as NAM (and NAMARG) reserved 524,288 40-bit words storing 10-bit opcodes and 30-bit arguments. NAM connected directly to the processor via its own bus, making it act more like a cache in modern architectures.{{sfn\|Pountain\|1988\|p=349}}

Autarch: /* History */ Rm WP:PEACOCK.

2023-09-30T23:03:24Z

History: Rm WP:PEACOCK.

← Previous revision		Revision as of 23:03, 30 September 2023
Line 6:		Line 6:
	The Rekursiv project started as an effort to improve the [[assembly line]] controls in Linn's factories in [[Glasgow]], [[Scotland]]. Their lines were automated using a suite of [[VAX-11]] systems, but these were slow and very difficult to program with the flexibility that Linn's founder, [[Ivor Tiefenbrun]], desired. By the early 1980s, Tiefenbrun had become convinced that [[object-oriented programming]] would offer solutions to these problems.{{sfn\|Pountain\|1988\|p=341}}		The Rekursiv project started as an effort to improve the [[assembly line]] controls in Linn's factories in [[Glasgow]], [[Scotland]]. Their lines were automated using a suite of [[VAX-11]] systems, but these were slow and very difficult to program with the flexibility that Linn's founder, [[Ivor Tiefenbrun]], desired. By the early 1980s, Tiefenbrun had become convinced that [[object-oriented programming]] would offer solutions to these problems.{{sfn\|Pountain\|1988\|p=341}}

	In 1981, Tiefenbrun hired a number of programmers to write a version of the ~~seminal~~ [[Smalltalk]] language for the VAX systems, borrowing some syntax from [[ALGOL]]. Known as LINGO, the system worked but ran very slowly on the VAX platform. Tiefenbrun concluded the solution to the performance issue was not to improve the language on the VAX but instead produce an entirely new CPU dedicated specifically to running object programs.{{sfn\|Pountain\|1988\|p=341}}		In 1981, Tiefenbrun hired a number of programmers to write a version of the [[Smalltalk]] language for the VAX systems, borrowing some syntax from [[ALGOL]]. Known as LINGO, the system worked but ran very slowly on the VAX platform. Tiefenbrun concluded the solution to the performance issue was not to improve the language on the VAX but instead produce an entirely new CPU dedicated specifically to running object programs.{{sfn\|Pountain\|1988\|p=341}}

	In 1984, Tiefenbrun formed the wholly owned subsidiary Linn Smart Computing under the direction of [[University of Strathclyde]] professor David Harland and the Rekursiv project was born. The first version of the system emerged in 1988.{{sfn\|Pountain\|1988\|p=341}} A small number of prototype [[VMEbus]] boards, called ''Hades'', comprising these four chips plus 80 MB of RAM were produced. These were intended for installation in a host system such as a [[Sun-3]] [[workstation]]. Although the Rekursiv was never fully developed and was not a commercial success, several Hades boards were used in academic research projects in the [[UK]]. The last known copy of a Rekursiv computer ended up at the bottom of the [[Forth and Clyde canal]] in Glasgow.<ref>{{cite web \|url=https://www.slideshare.net/sebrose/rekursiv \|title=Rekursiv \|first=Seb \|last=Rose \|date=19 April 2011 \|website=slideshare.net \|publisher=Slideshare \|access-date=27 February 2017}}</ref>		In 1984, Tiefenbrun formed the wholly owned subsidiary Linn Smart Computing under the direction of [[University of Strathclyde]] professor David Harland and the Rekursiv project was born. The first version of the system emerged in 1988.{{sfn\|Pountain\|1988\|p=341}} A small number of prototype [[VMEbus]] boards, called ''Hades'', comprising these four chips plus 80 MB of RAM were produced. These were intended for installation in a host system such as a [[Sun-3]] [[workstation]]. Although the Rekursiv was never fully developed and was not a commercial success, several Hades boards were used in academic research projects in the [[UK]]. The last known copy of a Rekursiv computer ended up at the bottom of the [[Forth and Clyde canal]] in Glasgow.<ref>{{cite web \|url=https://www.slideshare.net/sebrose/rekursiv \|title=Rekursiv \|first=Seb \|last=Rose \|date=19 April 2011 \|website=slideshare.net \|publisher=Slideshare \|access-date=27 February 2017}}</ref>

152.37.103.61 at 08:13, 14 April 2023

2023-04-14T08:13:00Z

← Previous revision		Revision as of 08:13, 14 April 2023
Line 56:		Line 56:
	\|date=November 1988		\|date=November 1988
	\|pages=341–349		\|pages=341–349
			\|url=https://ia803000.us.archive.org/19/items/eu_BYTE-1988-11_OCR/BYTE-1988-11_OCR.pdf
	}}		}}
	*{{cite newsgroup		*{{cite newsgroup

OAbot: Open access bot: doi added to citation with #oabot.

2023-01-29T18:40:17Z

Open access bot: doi added to citation with #oabot.

← Previous revision		Revision as of 18:40, 29 January 2023
Line 110:		Line 110:
	\|pages=3		\|pages=3
	\|s2cid=17125054		\|s2cid=17125054
			\|doi-access=free
	}}		}}
	*{{cite journal		*{{cite journal
Line 124:		Line 125:
	\|pages=70		\|pages=70
	\|s2cid=14704178		\|s2cid=14704178
			\|doi-access=free
	}}		}}
	*{{cite news		*{{cite news

73.66.89.38: /* Microcode */ Change "access" to past tense.

2022-05-15T22:10:25Z

Microcode: Change "access" to past tense.

← Previous revision		Revision as of 22:10, 15 May 2022
Line 28:		Line 28:

	===Microcode===		===Microcode===
	The processor's instruction set was stored in a dedicated area of static RAM known as the "control store". It was ~~access~~ via a dedicated 16-bit bus, organized as 16,384 words of 128-bits each. A separate "control store map" section of SRAM holds a numbered table of entry points into the microcoded routines, mapping a 10-bit [[opcode]] onto one of 2,048 entities. In a conventional processor, the map would normally be implemented in hardwired logic in the opcode decoder.{{sfn\|Pountain\|1988\|p=349}}		The processor's instruction set was stored in a dedicated area of static RAM known as the "control store". It was accessed via a dedicated 16-bit bus, organized as 16,384 words of 128-bits each. A separate "control store map" section of SRAM holds a numbered table of entry points into the microcoded routines, mapping a 10-bit [[opcode]] onto one of 2,048 entities. In a conventional processor, the map would normally be implemented in hardwired logic in the opcode decoder.{{sfn\|Pountain\|1988\|p=349}}

	Opcodes could be parts of objects and stored in the same way that any other data would be using Objekt. For performance reasons, a separate memory bank known as NAM (and NAMARG) reserved 524,288 40-bit words storing 10-bit opcodes and 30-bit arguments. NAM connected directly to the processor via its own bus, making it act more like a cache in modern architectures.{{sfn\|Pountain\|1988\|p=349}}		Opcodes could be parts of objects and stored in the same way that any other data would be using Objekt. For performance reasons, a separate memory bank known as NAM (and NAMARG) reserved 524,288 40-bit words storing 10-bit opcodes and 30-bit arguments. NAM connected directly to the processor via its own bus, making it act more like a cache in modern architectures.{{sfn\|Pountain\|1988\|p=349}}

Explicit: Removing link(s) Wikipedia:Articles for deletion/Persistent object store closed as soft delete (XFDcloser)

2021-08-11T23:42:25Z

Removing link(s) Wikipedia:Articles for deletion/Persistent object store closed as soft delete (XFDcloser)

← Previous revision		Revision as of 23:42, 11 August 2021
Line 14:		Line 14:
	==Description==		==Description==
	===Basic concepts===		===Basic concepts===
	The underlying concept of the Rekursiv platform was to provide a hardware-assisted [[persistent object store]], constantly and invisibly writing the memory state to disk without intervention from the [[operating system]] or the user's program. One reviewer described it as "an object-database engine for creating and managing persistent objects".{{sfn\|Pountain\|1988\|p=348}}		The underlying concept of the Rekursiv platform was to provide a hardware-assisted persistent object store, constantly and invisibly writing the memory state to disk without intervention from the [[operating system]] or the user's program. One reviewer described it as "an object-database engine for creating and managing persistent objects".{{sfn\|Pountain\|1988\|p=348}}

	To make such a system work with reasonable performance while running complex programs, Rekursiv was designed to allow the programmer to write their own [[instruction set architecture]] (ISA) dedicated to the language they were using. The [[microcode]] instruction set was stored in [[static RAM]].{{sfn\|Pountain\|1988\|p=342}} There was no default ISA, although Linn supplied one for running programs in the [[C programming language]].{{sfn\|Pountain\|1988\|pp=348-349}}		To make such a system work with reasonable performance while running complex programs, Rekursiv was designed to allow the programmer to write their own [[instruction set architecture]] (ISA) dedicated to the language they were using. The [[microcode]] instruction set was stored in [[static RAM]].{{sfn\|Pountain\|1988\|p=342}} There was no default ISA, although Linn supplied one for running programs in the [[C programming language]].{{sfn\|Pountain\|1988\|pp=348-349}}

Amazomagisto: fix typo and whitespace error

2021-07-07T04:05:12Z

fix typo and whitespace error

← Previous revision		Revision as of 04:05, 7 July 2021
Line 14:		Line 14:
	==Description==		==Description==
	===Basic concepts===		===Basic concepts===
	The underlying concept of the Rekursiv ~~plaform~~ was to provide a hardware-assisted [[persistent object store]], constantly and invisibly writing the memory state to disk without intervention from the [[operating system]] or the user's program. One reviewer described it as "an object-database engine for creating and managing persistent objects".{{sfn\|Pountain\|1988\|p=348}}		The underlying concept of the Rekursiv platform was to provide a hardware-assisted [[persistent object store]], constantly and invisibly writing the memory state to disk without intervention from the [[operating system]] or the user's program. One reviewer described it as "an object-database engine for creating and managing persistent objects".{{sfn\|Pountain\|1988\|p=348}}

	To make such a system work with reasonable performance while running complex programs, Rekursiv was designed to allow the programmer to write their own [[instruction set architecture]] (ISA) dedicated to the language they were using. The [[microcode]] instruction set was stored in [[static RAM]].{{sfn\|Pountain\|1988\|p=342}} There was no default ISA, although Linn supplied one for running programs in the [[C programming language]].{{sfn\|Pountain\|1988\|pp=348-349}}		To make such a system work with reasonable performance while running complex programs, Rekursiv was designed to allow the programmer to write their own [[instruction set architecture]] (ISA) dedicated to the language they were using. The [[microcode]] instruction set was stored in [[static RAM]].{{sfn\|Pountain\|1988\|p=342}} There was no default ISA, although Linn supplied one for running programs in the [[C programming language]].{{sfn\|Pountain\|1988\|pp=348-349}}
Line 21:		Line 21:
	The system did not provide the analog of a memory address to the programs running on it, instead, objects were given a 40-bit identifier which the Objekt chip hashed and used as a pointer to physical memory.{{sfn\|Pountain\|1988\|p=346}} Objekt also handled the mapping of the object memory to [[hard disk]] for permanent storage, implementing a [[virtual memory]] system. To handle [[Garbage collection (computer science)\|garbage collection]], Objekt divided the provided [[dynamic RAM]] (main memory) into two halves, using one for new object creation and leaving the other unused. When a new object would require more memory than was free in the used portion, Objekt paused the system, copied any object with a valid pointer to it to the unused half of memory, and then switched to make the formerly unused half the active portion. In extremely memory-limited cases, Objekt would first attempt to spool some objects to disk, and if that failed to free up enough room, would use both halves of memory.{{sfn\|Pountain\|1988\|p=347}}		The system did not provide the analog of a memory address to the programs running on it, instead, objects were given a 40-bit identifier which the Objekt chip hashed and used as a pointer to physical memory.{{sfn\|Pountain\|1988\|p=346}} Objekt also handled the mapping of the object memory to [[hard disk]] for permanent storage, implementing a [[virtual memory]] system. To handle [[Garbage collection (computer science)\|garbage collection]], Objekt divided the provided [[dynamic RAM]] (main memory) into two halves, using one for new object creation and leaving the other unused. When a new object would require more memory than was free in the used portion, Objekt paused the system, copied any object with a valid pointer to it to the unused half of memory, and then switched to make the formerly unused half the active portion. In extremely memory-limited cases, Objekt would first attempt to spool some objects to disk, and if that failed to free up enough room, would use both halves of memory.{{sfn\|Pountain\|1988\|p=347}}

	Objects are composite structures with multiple values within them, which in most systems are implemented as a series of pointers to the memory locations holding the values. In Rekursiv, the addresses are replaced by 40-bit object IDs pointing to a section of memory allocated by Objekt. The [[most significant bit]] (MSB) of the 40-bit pointer was set to 1 if the value was an object identifier, or 0 if it was an untyped binary value. The later was used to store large unformatted data, like the data for a digital image, and could only be used within objects.{{sfn\|Pountain\|1988\|p=347}}		Objects are composite structures with multiple values within them, which in most systems are implemented as a series of pointers to the memory locations holding the values. In Rekursiv, the addresses are replaced by 40-bit object IDs pointing to a section of memory allocated by Objekt. The [[most significant bit]] (MSB) of the 40-bit pointer was set to 1 if the value was an object identifier, or 0 if it was an untyped binary value. The later was used to store large unformatted data, like the data for a digital image, and could only be used within objects.{{sfn\|Pountain\|1988\|p=347}}

	In the case of a full object, a further simplification was available to store short fields as values within the pointer itself. This was indicated by setting the second MSB to 0 as well. In this case, the following five bits indicated a type, defined by the program's ISA, which might be "integer" or "string fragment". The actual value of this "compact object" was placed in the lower 32-bits of the pointer. This allowed such simple values to be immediately presented to the processor without the need to follow a pointer to the physical location, which saved memory and improved performance.{{sfn\|Pountain\|1988\|p=347}}{{efn\|The 33rd bit is not mentioned in any of the sources and appears to be unused.}}		In the case of a full object, a further simplification was available to store short fields as values within the pointer itself. This was indicated by setting the second MSB to 0 as well. In this case, the following five bits indicated a type, defined by the program's ISA, which might be "integer" or "string fragment". The actual value of this "compact object" was placed in the lower 32-bits of the pointer. This allowed such simple values to be immediately presented to the processor without the need to follow a pointer to the physical location, which saved memory and improved performance.{{sfn\|Pountain\|1988\|p=347}}{{efn\|The 33rd bit is not mentioned in any of the sources and appears to be unused.}}

Monkbot: Task 18 (cosmetic): eval 10 templates: del empty params (1×); hyphenate params (2×); del |ref=harv (2×);

2021-01-13T21:55:10Z

Task 18 (cosmetic): eval 10 templates: del empty params (1×); hyphenate params (2×); del |ref=harv (2×);

← Previous revision		Revision as of 21:55, 13 January 2021
Line 56:		Line 56:
	\|date=November 1988		\|date=November 1988
	\|pages=341–349		\|pages=341–349
	\|ref=harv
	}}		}}
	*{{cite newsgroup		*{{cite newsgroup
Line 65:		Line 64:
	\|message-id=33000@castle.ed.ac.uk		\|message-id=33000@castle.ed.ac.uk
	\|url=http://groups.google.com/group/comp.arch/msg/991720740417ec42		\|url=http://groups.google.com/group/comp.arch/msg/991720740417ec42
	\|ref=harv
	}}		}}

Line 75:		Line 73:
	\| last = Harland		\| last = Harland
	\| first = David M.		\| first = David M.
	\| ~~authorlink~~ = David M. Harland		\| author-link = David M. Harland
	\| title = Rekursiv: Object-Oriented Computer Architecture (Ellis Horwood Series in Computers and Their Applications)		\| title = Rekursiv: Object-Oriented Computer Architecture (Ellis Horwood Series in Computers and Their Applications)
	\| publisher = Ellis Horwood Ltd		\| publisher = Ellis Horwood Ltd
	\|date=August 1988		\|date=August 1988
	\| pages =
	\| isbn = 0-13-771965-5		\| isbn = 0-13-771965-5
	}}		}}
Line 97:		Line 94:
	\|author2=Gunn, Hamish I. E. \|author3=Pringle, Ian A. \|author4=Beloff, Bruno		\|author2=Gunn, Hamish I. E. \|author3=Pringle, Ian A. \|author4=Beloff, Bruno
	\|title=The Rekursiv: An Architecture for Artificial Intelligence		\|title=The Rekursiv: An Architecture for Artificial Intelligence
	\|~~booktitle~~=Proc. AI Europa		\|book-title=Proc. AI Europa
	\|date=September 1986		\|date=September 1986
	}}		}}

Citation bot: Alter: template type. Add: s2cid. | You can use this bot yourself. Report bugs here. | Suggested by AManWithNoPlan | All pages linked from cached copy of User:AManWithNoPlan/sandbox3 | via #UCB_webform_linked 935/2623

2020-10-24T10:39:48Z

Alter: template type. Add: s2cid. | You can use this bot yourself. Report bugs here. | Suggested by AManWithNoPlan | All pages linked from cached copy of User:AManWithNoPlan/sandbox3 | via #UCB_webform_linked 935/2623

← Previous revision		Revision as of 10:39, 24 October 2020
Line 112:		Line 112:
	\|doi=10.1145/18981.18982		\|doi=10.1145/18981.18982
	\|pages=3		\|pages=3
			\|s2cid=17125054
	}}		}}
	*{{cite journal		*{{cite journal
Line 125:		Line 126:
	\|doi=10.1145/24714.24723		\|doi=10.1145/24714.24723
	\|pages=70		\|pages=70
			\|s2cid=14704178
	}}		}}
	*{{cite ~~article~~		*{{cite news
	\|title=Rekursiv		\|title=Rekursiv
	\|first=Seb		\|first=Seb
Line 132:		Line 134:
	\|url=http://www.slideshare.net/sebrose/rekursiv		\|url=http://www.slideshare.net/sebrose/rekursiv
	}}		}}
	*{{cite ~~article~~		*{{cite news
	\|title=Object-Oriented Computer Architecture: - Concepts and Issues - The REKURSIV Object-Oriented Computer Architecture		\|title=Object-Oriented Computer Architecture: - Concepts and Issues - The REKURSIV Object-Oriented Computer Architecture
	\|first=David M.		\|first=David M.

← Previous revision		Revision as of 23:03, 30 September 2023
Line 6:		Line 6:
	The Rekursiv project started as an effort to improve the [[assembly line]] controls in Linn's factories in [[Glasgow]], [[Scotland]]. Their lines were automated using a suite of [[VAX-11]] systems, but these were slow and very difficult to program with the flexibility that Linn's founder, [[Ivor Tiefenbrun]], desired. By the early 1980s, Tiefenbrun had become convinced that [[object-oriented programming]] would offer solutions to these problems.{{sfn\|Pountain\|1988\|p=341}}		The Rekursiv project started as an effort to improve the [[assembly line]] controls in Linn's factories in [[Glasgow]], [[Scotland]]. Their lines were automated using a suite of [[VAX-11]] systems, but these were slow and very difficult to program with the flexibility that Linn's founder, [[Ivor Tiefenbrun]], desired. By the early 1980s, Tiefenbrun had become convinced that [[object-oriented programming]] would offer solutions to these problems.{{sfn\|Pountain\|1988\|p=341}}

	In 1981, Tiefenbrun hired a number of programmers to write a version of the ~~seminal~~ [[Smalltalk]] language for the VAX systems, borrowing some syntax from [[ALGOL]]. Known as LINGO, the system worked but ran very slowly on the VAX platform. Tiefenbrun concluded the solution to the performance issue was not to improve the language on the VAX but instead produce an entirely new CPU dedicated specifically to running object programs.{{sfn\|Pountain\|1988\|p=341}}		In 1981, Tiefenbrun hired a number of programmers to write a version of the [[Smalltalk]] language for the VAX systems, borrowing some syntax from [[ALGOL]]. Known as LINGO, the system worked but ran very slowly on the VAX platform. Tiefenbrun concluded the solution to the performance issue was not to improve the language on the VAX but instead produce an entirely new CPU dedicated specifically to running object programs.{{sfn\|Pountain\|1988\|p=341}}

	In 1984, Tiefenbrun formed the wholly owned subsidiary Linn Smart Computing under the direction of [[University of Strathclyde]] professor David Harland and the Rekursiv project was born. The first version of the system emerged in 1988.{{sfn\|Pountain\|1988\|p=341}} A small number of prototype [[VMEbus]] boards, called ''Hades'', comprising these four chips plus 80 MB of RAM were produced. These were intended for installation in a host system such as a [[Sun-3]] [[workstation]]. Although the Rekursiv was never fully developed and was not a commercial success, several Hades boards were used in academic research projects in the [[UK]]. The last known copy of a Rekursiv computer ended up at the bottom of the [[Forth and Clyde canal]] in Glasgow.<ref>{{cite web \|url=https://www.slideshare.net/sebrose/rekursiv \|title=Rekursiv \|first=Seb \|last=Rose \|date=19 April 2011 \|website=slideshare.net \|publisher=Slideshare \|access-date=27 February 2017}}</ref>		In 1984, Tiefenbrun formed the wholly owned subsidiary Linn Smart Computing under the direction of [[University of Strathclyde]] professor David Harland and the Rekursiv project was born. The first version of the system emerged in 1988.{{sfn\|Pountain\|1988\|p=341}} A small number of prototype [[VMEbus]] boards, called ''Hades'', comprising these four chips plus 80 MB of RAM were produced. These were intended for installation in a host system such as a [[Sun-3]] [[workstation]]. Although the Rekursiv was never fully developed and was not a commercial success, several Hades boards were used in academic research projects in the [[UK]]. The last known copy of a Rekursiv computer ended up at the bottom of the [[Forth and Clyde canal]] in Glasgow.<ref>{{cite web \|url=https://www.slideshare.net/sebrose/rekursiv \|title=Rekursiv \|first=Seb \|last=Rose \|date=19 April 2011 \|website=slideshare.net \|publisher=Slideshare \|access-date=27 February 2017}}</ref>