To all of the you stated below, thanks for the valuable info sent. I'll try to
contact some of you for more specific topics, so please stand by.
Joaquim Baptista, Universidade Nova de Lisboa
John Connett, Concurrent Computer Corporation
Peter Deutsch, Sun
Tariq Hamid, Paisley College
Steve Majewski, Virginia University (is that right ?)
Andy Ormsby, University College of Wales
Philip Robar, Sun and
Al Underbrink, Boing Computer Services
Mario Wolczko, Manchester University (of course)
Rodrigo Borer, rodd(a)ele.puc-rio.br
PS: I enclosed a summary of the answers received so far for those who missed
any of them.
---------------------------------My message------------------------------------
Although a virtue of Self is to execute as fast as C, I am investigating
computer architectures with specific hardware support for Object Oriented
Programming. If you who have ever read (or researched) about tagged
architectures; O.O. memory menagement; bytecode emulating microprogramming;
and so, how about sharing your ideas ?
Any piece of information is appreciated.
------------------From: John Connett <jrc(a)concurrent.co.uk>--------------------
You did say any piece of information so here goes. It's been some time
since I looked at this area but here are some architectures that
attempted to support an object oriented approach in some way:
Intel 432 (deceased)
BiiN (deceased)
Linn Rekursiv (deceased)
Monads (Monash University, Australia)
Intel 960xx
Mushroom (Manchester University, England)
Whatever the technical merits of object oriented hardware architectures
the verdict of the marketplace seems to be "Not buying a RISC is a big
risk!". I like the idea of capability architectures but I've never had
the chance to actually use such hardware.
I'm fairly sure that Rekursiv is no more. If for nothing else I'll miss
the appalling names eg. Algorythms and Linngo (a language). For the
non-audiophiles among you Linn is parhaps best known for their very high
quality hi-fi equipment. That side of the business continues to
flourish.
All the above is from my rather unreliable memory. The papers are near
the bottom of my ever growing pile.
--------------------From: Joaquim Baptista <px(a)fct.unl.pt>---------------------
The book "Object-Oriented Languages, Systems, and Applications",
edited by Blair, Gallagher, Hutchison, and Shepherd, from Pitman
Publishing and dated 1991, has the following chapter:
"RECURSIV - Object-Oriented Hardware". This chapter references
a book, "RECURSIV, Object-Oriented Computer Architecture", by
D. M. Harland, published by Ellis Horwood in 1988.
I haven't read the said chapter, but it looks like a tagged
architecture.
Feel free to email for further info.
BTW, I guess that you should email a summary of your responses
to self-interest.
------------------From: Andrew Ormsby <aro(a)aberystwyth.ac.uk>------------------
The only reference to REKURSIV I have handy is:
@incollection{Harland91,
author = "David M Harland and Brian Drummond",
title = "RESKURSIV - Object Oriented Hardware",
booktitle = "Object-oriented languages, systems and
applications",
editor = "G Blair and J Gallagher and D Hutchinson and D
Shepherd",
publisher = "Pitman",
year = "1991"
}
Ellis Horwood also publish a book by Harland about the architecture.
I remember thinking that it looked quite elegant when I read about it,
but apart from a few evalutation kits being distributed to some UK
universities (not ours), I'm not aware of anyone using it.
---------From: Tariq Hamid <jpc9u050(a)computer-science.paisley.ac.uk>-----------
We at Paisley are still using it. Its architecture forms the backbone of the
distributed system that we have been developing (in lose conjuction with Linn)
for the past 3 years.
------------------From: Al Underbrink <al(a)hsvaic.boeing.com>-------------------
I presume you are familiar with the "Rekursiv" project? If not, here is
a beginning.
Rekursiv is a project which has been investigating the implementation
of object-oriented (and other) techniques in an integrated circuit chip
set. The effort is led by David M. Harland of Linn Smart Computing Ltd.
in Glasgow. A book published by Mr. Harland entitled "Rekursiv: Object
Oriented Computer Architecture" is available from Ellis Horwood Limited,
Market Cross House, Cooper St., Chichester, West Sussex, PO19 1EB,
England. The North and South American distributor is Halsted Press: a
division of John Wiley & Sons Limited, Baffins Lane, Chichester, West
Sussex, England. The textbook was published in 1988.
In the book, the author discusses instruction support necessary for data
abstraction, inheritance, etc. Object oriented techniques have some
additional instruction set requirements, but also do away with other
requirements (e.g., standard word lengths and short-term vs. long-term
storage). Overall, I find the ideas in the book fascinating.
This work is several years old and I confess to not keeping up with more
recent developments. In fact, I heard a rumor that the researchers at
Linn have moved on to other problems. Perhaps others on self-interest
can provide and update.
---------From: Mario Wolczko <mario(a)computer-science.manchester.ac.uk>---------
Linn Smart Computing, the subsidiary of Linn (who make top-end hi-fi)
responsible for the Rekursiv, was folded up, oh, about 18 months ago
I'd guess. Last I heard, Harland was at the Design Research Centre in
Edinburgh; I don't know what he was working on.
-----------From: Steven D. Majewski <sdm7g(a)aemsun.med.Virginia.EDU>------------
*Ancient* references:
Levy, Henry M., Capability Based Computer Systems. Digital Press 1984
Organick, Elliot I., A Programmer's View of the Intel 432 System.
McGraw-Hill 1983
I have not followed this subject seriously, lately. ( Though I have
*thought* about it in a few spare moments. ) If you get any more
up to date info - please send me a copy or repost it. ( Since it
is not of self-interest only, maybe you should post it to comp.object
or comp.arch usenet news groups. )
-----------------From: Philip Robar <Philip.Robar(a)Eng.Sun.COM>-----------------
> "Rekursiv" project
If I remember correctly there was an article in Byte on this project
serveral years ago. Seems to me it supported Smalltalk directly in
hardware.
---------------From: L. Peter Deutsch <Peter.Deutsch(a)Eng.Sun.COM>--------------
It *claimed* to support Smalltalk directly in hardware. I don't believe
they ever got a full Smalltalk system (as opposed to some small examples
that didn't deal with I/O or large-scale memory management) running.
---------From: Mario Wolczko <mario(a)computer-science.manchester.ac.uk>---------
Along with about 20 other groups, my group had a Rekursiv board for
evaluation (still do, but we don't use it). We had a researcher, Ian
Piumarta (ikp(a)cs.man.ac.uk), implement Scheme on it. Other groups
were working on Smalltalk, Eiffel, OODBs and other things. I don't
recall hearing of anything being made to work (apart from Scheme), but
I may be wrong. Eliot Miranda (eliot(a)dcs.qmw.ac.uk) was working on
Smalltalk -- are you out there, Eliot?
The hardware is microprogrammable, and provides direct support for a
virtual object memory (paging is transparent to the microprogrammer).
Most of the projects involved writing some microcode for an
instruction set that was deemed "appropriate" for the language, then
compiling to that instruction set. I believe Eliot was going to use a
threaded (micro)code implementation. One of Harland's publications (I
forget which) outlines the microcode for a few of the Smalltalk Blue
Book bytecodes. I don't know if a more complete implementation was
tried by Linn.
I believe the architecture has been to all intents discredited as a
way of building efficient object-oriented systems. (If there's anyone
out there who believes otherwise, I'd like to hear why. The lack of
published work is depressing. My group is as much to blame for this
as anyone, but the funding structure for the evaluation projects was
absurd, making it almost inevitable that many things didn't get
finished properly. But that's another story.)
One aim of the design was to make the microcoder's task easy, and I
think this was largely achieved (the name derives from the fact that
you can write recursive microcode). The price paid was that the
architecture is exceedingly complex. The board we received was a full
triple-height double-extended Eurocard (the largest board you can get
into a SUN rack) bursting with ICs, including four large custom chips.
The amount of logic is immense.
I believe much of the hardware does not "pay its way" in terms of
performance benefits. Just as an example, for every object access a
parallel unit does a bounds check to see whether the offset is valid.
For Smalltalk, most (~99%) of accesses are to named instance
variables, which are guaranteed by the compiler to have valid offsets;
the bound-check hardware can only be used for the at: and at:put:
primitives. So this piece of hardware will at best improve
performance by a fraction of 1%.
Other features of the design which I think were mistaken are:
1. I mentioned that paging is transparent to the microcoder. That's
because when an object is accessed that is not in memory, *the
clock stops* while some external mechanism (in our case a SUN
workstation) loads the object into the Rekursiv's memory. This
means that nothing executes for the duration of a page fault.
2. Paging objects one-at-a-time is great for memory efficiency (ie,
not much of primary memory is wasted), but is hopeless at keeping
the page fault rate down. This, combined with point 1, makes the
virtual memory hierarchy extremely slow. As part of our own
architecture work we did extensive simulations of this
object-swapping scheme (as used in LOOM also) vs conventional paged
memory and our own dynamically grouped virtual memory. The
object-swapper was worst, except when memory was ridiculously tight
(eg running Smalltalk in 16Kbytes).
3. The garbage collector was also implemented in the bowels of the
system, and was not really of modern design.
The bottom line is that a 5MHz Rekursiv gave a 25MHz SUN 3/280 a run
for its money, but was easily outperformed by a 16MHz SPARC. This
despite the Rekursiv using relatively sophisticated implementation
technology (the gate arrays were state-of-the-art).
---------------From: L. Peter Deutsch <Peter.Deutsch(a)Eng.Sun.COM>--------------
I read several Rekursiv papers, had several long talks with David Harland,
and remained unimpressed. The Rekursiv was an extremely elaborate design
with a very large amount of specialized hardware, some of it very
high-performance (e.g., the object table associative RAM). Comparing it
against software and commercial hardware technology of the same era,
assuming the availability of equal amounts of money to spend, made it look
pretty weak. A factor of 5 in raw processing speed and memory capacity
(which is about what you could buy in off-the-shelf components) makes up
for an awful lot of hardware/software misfit. In my opinion, the Self
compiler further strengthens the case for implementation on commercial
hardware.
Persistent object memories per se do not solve the hard problems in
multi-user, long-lived environments. The Rekursiv made no attempt to deal
with anything other than the single-user, single-machine world.
------------------From: Al Underbrink <al(a)hsvaic.boeing.com>-------------------
What about programs made possible by the Rekursiv CONCEPT? That is, all
von Neumann machines execute some sort of operating system which manages
memory, security, persistent store, etc. When hardware support is
tailored to object-oriented programs, the need for an operating system
goes away. Each object implements its own word size, storage format &
optimization, security measures, and so on. Further, the objects, with
their "OS" functions almost fully subsumed by their own implementation,
could be executed on distributed processors. This raises new control
issues, but the point remains (at least in my opinion): Rekursiv
explored a paradigm different from traditional von Neumann architectures
and programming approaches. This program paradigm transcends the issue
of hardware performance.
This thread may not be entirely appropriate for self-interest, but I
find it intellectually stimulating.
---------------From: L. Peter Deutsch <Peter.Deutsch(a)Eng.Sun.COM>--------------
> What about programs made possible by the Rekursiv CONCEPT? That is, all
> von Neumann machines execute some sort of operating system which manages
> memory, security, persistent store, etc. When hardware support is
> tailored to object-oriented programs, the need for an operating system
> goes away. Each object implements its own word size, storage format &
> optimization, security measures, and so on.
I think all you've done is moved the OS protection and resource management
issues into microcode and/or hardware, thereby making them far less
flexible, and more difficult to change and understand. Having an object
"responsible for its own memory management, resource allocation, and
security" is a contradiction in terms: memory management, resource
allocation, and security are by their very nature things that happen at the
level of interactions *between* objects in some *larger* medium. I.e., the
function of an OS is to manage resources that are intrinsically *shared*:
you can push the function around between implementation levels, but you
can't get rid of it.
I thought Mario Wolczko's point about the negative consequences of moving
paging and garbage collection down to the microcode level was a good
example of the kind of thing that goes wrong.
> Further, the objects, with
> their "OS" functions almost fully subsumed by their own implementation,
> could be executed on distributed processors.
I don't think that using "objects" (or capabilities, which is what people
generally call "objects" implemented at the OS level) addresses any of the
hard problems in the distributed domain -- the nature of object addresses
or references, remote execution vs. migration, synchronization, robustness
in the face of hardware and software failures, etc.
> This raises new control
> issues, but the point remains (at least in my opinion): Rekursiv
> explored a paradigm different from traditional von Neumann architectures
> and programming approaches. This program paradigm transcends the issue
> of hardware performance.
I agree that object-orientation changes the way one thinks about software,
often for the better. I strongly disagree that special-purpose hardware
gives one any advantage in supporting the object-oriented viewpoint.
