Yes, the advantage of associative memory for object-oriented systems is pretty old. The earliest theoretical look at it I've found is JK Iliffe's Basic Machine Principles, which discusses the design principles behind his theoretical Basic Machine. If I recall correctly, Iliffe actually suggested a single hardware instruction for associative lookup; this was before pipelining, so a single instruction was probably a single cycle on those machines back then. He also compares the ability to develop high level languages with such dynamic memory usage to the designs of COBOL and FORTRAN, noting that their fixed allocation schemes prohibit them from even desiring such hardware instructions. He also covers fault tolerant linking of programs; as you say, today's "dynamically linked libraries" are not really dynamically linked but really based on a binary format that provides special codecs for locating streams of code, and the simpler solution is to remove the need for a codec (like ELF).
Iliffe came up with the ideas based on studying Bob Barton's Burroughs B5000 designs and gave advice on what Ferranti should do to compete with Burroughs' model. As it happened, both companies lost the hardware market, but Ferranti engineers never adopted Iliffe's model. Bob is a friend of Alan Kay's, they worked together, and Alan has mentioned the design of the B5000 before in interviews, noting how the machines rarely crashed [1]. Alan also provides the following insightful comments regarding IBM vs. Burroughs [2], the lesson of which was repeated 20 years later by Adele Goldberg at ParcPlace Systems [3]. You seem to want a current runtime you could use. Unfortunately, I am unaware of anything that does this. Mainly, if somebody is going to implement a runtime, they are being paid to do it, since it is a lot of work, and anyone paying to do it would likely want an architecture to support many current, modern (and thus outdated) backend languages with optimizations targeted toward von Neumann-style architectures. [1] http://lambda-the-ultimate.org/node/531 [2]* AK* [...] This happens over and over again. The languages of Niklaus Wirth have spread wildly and widely because he has been one of the most conscientious documenters of languages and one of the earlier ones to do algorithmic languages using p-codes (pseudocodes)—the same kinds of things that we use. The idea of using those things has a common origin in the hardware of a machine called the Burroughs B5000 from the early 1960s, which the establishment hated. *SF* Partly because there wasn’t any public information on most of it. *AK* Let me beg to differ. I was there, and Burroughs actually hired college graduates to explain that machine to data-processing managers. There was an immense amount of information available. The problem was that the DP managers didn’t want to learn new ways of computing, or even how to compute. IBM realized that and Burroughs didn’t. [3] See Points of View, the recent book mentioned on the mailing list, dedicated to Alan Kay; read Adele Goldberg's discussion of how they mismarketed OO by failing to realize organizations didn't complete their projects to the point that the marketing pitch was attractive On Fri, Jun 18, 2010 at 8:18 PM, Steve Dekorte <st...@dekorte.com> wrote: > > On 2010-06-18, at 3:50 PM, Jecel Assumpcao Jr. wrote: > > A single, huge associative memory would have the same problems as the > > von Neuman architecture even though you have moved some of the smarts to > > the memory side. Our brains are proof that you can have highly parallel > > associative memories and my RNA proposal is an attempt to see what the > > extreme case of that might be. Some hybrid scheme which replaced a > > single 1 GB associative memory with 1000 such memories of 1 MB each > > would be worth investigating. How would they collaborate? > > > More thoughts: IIRC, modern associative memories used in routers have > ~256bit keys. This extra space for "pointers" allows you to do neat things > like: > > 1) tagged memory - use part of the key to specify if the value holds a > pointer (another key). If the hw can quickly scan the keys and values, you > can implement a straightforward hw based garbage collector. > > 2) eliminating the MMU, radically simplifying dlls, linking, etc which are > all ugly hacks to get associative lookup behavior > > 3) having each process use a, say, random 64bit prefix (generated by the > OS/VM) for it's writes such that they would naturally be protected from > other programs without explicit memory protection. A pipe could likewise be > constructed and the keys for the pipe shared by the communicating processes. > Security would become both a simple and natural function of the hw. > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
