[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The Linn Rekursiv Story -REPOST
Rekursiv Architecture - A Scalable Architecture
The design of the Rekursiv board was guided by 80s ideas of CIM
(Computer Integrated Manufacture). Linn the hi-fi company required a
computer inventory system i.e. a CIM solution. David Harland, a Glasgow
Uni. lecturer, was enlisted by the company to provide such a solution.
Being a bit of a boffin (nerd, geek, weirdo, enthusiast -to you americans)
he suggested that all approaches up till that point in time ~ 1985 had
been going in the wrong direction. The bare bones of a CIM system was in
fact a distributed system supporting OOP, polymorphism etc.
To this end an OOP language was implemented called Lingo. Lingo was
first implemented on a VAX and then on a Symbolics Micro-codable
processor. It ran very slowly indeed. Instead of giving up Dave Harland,
and the two directors of Linn got the idea that if they were to build a
computer system that would run Lingo fast enough they would rule the
world i.e. corner the CIM market.
An object-oriented tagged memory architecture chip set was developed to
provide support for persistent object oriented languages. The board ran
Lingo at an acceptable speed. Unfortunately message sending was still
implemented by the Lingo microcode in a conventional manner. Speed-up
through the use of threaded code had been overlooked and therefore was
not taken advantage of. A threaded-code version of Lingo, Sun Lingo,
was implemented on Sun 3s. This ran twice as fast as Rekursiv Lingo.
Nevertheless this was an unfair comparison, because Rekursiv Lingo also
supports a persistent store, whereas Sun Lingo does not. This comparison
was just the excuse the accountants at Linn needed to wind-down the
Moral of the story
Do not invest all your effort in fancy hardware because conventional
hardware always overtakes its speed advantage within months.
[ eg. "Shit I knew I shouldn't have brought that graphics accelerator board. ]
The mistake was to invest so much effort in hardware - hardware that was
going to get superseded pretty quicky anyway. Effort should have been
invested more in the development of software and efficiency gains should
have been sought through software.
Yes the Rekurisv Board has its limitations in terms of performance, but
I feel that these performance comparisons are somewhat misguided. For
what it does the Rekursiv is a very elegant architecture.
Its realization through the Rekursiv board was flawed in a few ways, which
have already been described by Mario Wolczko, such as object paging
being transparent to the microcoder (provides for easier microcoding, but
f's up chances for multi-tasking).
A list of the advantages and disadvantages of the Rekursiv Architecture:
+ Uses object identifiers not memory addresses i.e.
everything withn the system has a name.
+ Scalable because object ids allow for the spanning of
very large "address" spaces.
+ Distributed, since object ids are position independent
+ Threads and processes.
- Run time efficiency
A list of the advantages and disadvantages of the Rekurisiv board:
+ runs a persistent object-oriented system at an
+ Bridging of the Semantic Gap.
+ Microcodable - roll your own instruction sets.
- I/O bottleneck the Rekursiv VME board communicated
with the Sun host via a narrow bandwidth, which acceptable
for research purposes was not acceptable for any commercial
- Objects paged in on demand one at a time
- Overlooked compiler efficiency improvements such as
- IT MIGHT BE SAID THEY MARKETED A PROTOTYPE - TYPICALLY BRITISH
____ ___ ___ ___ ___
/ /__/ /_/ / / /
/ / / / | _/_ /_\/ Tariq Hamid
Dept. of Comp. Sci.
_ _ ___ ____ ___ __ Paisley College
/__/ /__/ / / / / / \ Paisley
/ / / / / / / _/_ /__/ Scotland PA1 2BE
Telephone :- [+44] (0)41 - 848 3328
Fax :- [+44] (0)41 - 887 0812
e-mail :- email@example.com
Cc: Dave Harland, E.D.R.C, Glasgow, Scotland.