mch@ukc.ac.uk (Martin Howe) (05/17/89)
Hi there. Some time ago I read in Electronics & Power (an IEE journal) and later in BYTE about a Scottish hi-fi manufacturer called Linn who have deigned a very high level CPU for their in-house computing work. This CPU, much in the spirit of the Intel 80432, is a recursively microcoded object-orientated machine, currently implemented as the "Hades" a triple width VME Eurocard stuffed with WIETEK chips (I think) plus some associative memory devices. I have for some time been interested in the RISC vs CISC debate and have often wondered why no one has tried this approach before (apart from Intel's 432, and I don't know HOW similar that was to the Rekursiv architecture). I was quite amused at a quote made by a Linn employee in the E & P article to the effect that current CISCs are the worst of both worlds -- too high level for fast execution of INDIVIDUAL instructions, while these instructions are not powerful enough to justify their (relatively) slow execution time. The Intel 80486 will have made *some* nonsense of this with the [expected] very wide prefetch bus (at least from the cache) and RISC core etc, but overall that statement summed up feelings that I have had for some time. Does anyone care to comment on the current state of the art in High Level CPU's (object orientated or not) or even better, suggest a few reasons why this sort of thing isn't more common (without starting another flame war of course :-) ? For my money, I'd be interested to see what happened if Intel had a go. "One segment per object" has been debated recently and if Intel have any sense, 32-bit segment values for the 86 series can't be far off, [unless Intel wants to let it die a natural death after the 80<whatever>86 so to let the i860 take over]. This would make it interesting to try piggybacking a Linn style object descriptor system onto the (32 bit) segmentation mechanism of the 80?86. With the technology available for 1MTr (MTr = Mega Transistor :-) chips, RISC cores and the like, who knows, the 80432 might even have been a viable proposition had it been designed this year or last. Please note, that I'm predominantly interested in the technical aspects of all this, rather than commercial ones, so if anyone has any LONG commercial discussion to add to this, I'd be grateful if they could use a (slightly) different follow-up heading. Anyone ? -- Martin Howe (This posting is private, and NOT on behalf of UKC)
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (05/18/89)
BiiN, an Intel and Siemanns spinoff is producing a chip, based on the 80960 I think, that includes fault tolerence features ``from the '432''. -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu
mcg@mipon2.intel.com (05/30/89)
In article <GRUNWALD.89May18103213@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: > >BiiN, an Intel and Siemanns spinoff is producing a chip, based on the >80960 I think, that includes fault tolerence features ``from the >'432''. The fault-tolerant features are also provided in the 960MC, documentation for which is available from your friendly Intel sales droid. The interesing aspect of the BiiN chip is an object-oriented, capability- based addressing and memory-management scheme. This has allowed them to implement an operating system with network-wide VM in a 56-bit address space (24 bits of object number, 32 bits of address space per object). Objects are simple, paged, or bi-paged. A variety of protection mechanisms are implemented. The architecture appears to be sufficient to implement a secure operating system. Many of the things that people have been gushing about for years in this group and unix-wizards such as mapping files (and everything else) into the address space has already been implemented by the BiiN folks. Their files are all just objects, which are either passive (on disk) or active (in memory). While I did not work on the 432, I will say that while the 432 and 960 shared some engineers, the architects were completely different. This is not a discourse on BiiN's system - for more information, give them a call. S. McGeady Intel Corp. [I am not an employee of BiiN, though I do work on the 960 processor. The information presented here has previously been made public, and is available to anyone by calling BiiN. My comments do not represent an official statement by Intel Corp.]