Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!jwmills From: jwmills@iuvax.cs.indiana.edu (Jonathan Mills) Newsgroups: comp.arch Subject: Re: "General-purpose" architectures and symbolic languages Message-ID: <17832@iuvax.cs.indiana.edu> Date: 22 Feb 89 14:35:14 GMT References: <28113@ucbvax.BERKELEY.EDU> Reply-To: jwmills@iuvax.cs.indiana.edu (Jonathan Mills) Organization: Indiana University, Bloomington Lines: 70 In article <28113@ucbvax.BERKELEY.EDU> vanroy@bellatrix.uucp () writes: >Present-day general-purpose architectures will naturally favor the imperative >language in a comparison of this sort. This is because the traditional notion >of "general-purpose" architecture is not truly general-purpose. It emphasizes >numeric calculation and does not do the things that symbolic languages require >such as tag manipulation and multiway branching. Therefore I propose that the >notion of "general-purpose" be extended to include support for symbolic >languages. >At Berkeley, we are developing such an architecture for the Prolog language. >We are designing it from the start as a complete system, i.e. compiler, >instruction set architecture, and (single-chip) implementation are being >developed together with feedback in all directions. In this way we hope to >overcome some of the limitations of previous implementations of Prolog. > Thanks for any pointers, In response to the queries about extending the definition of "general purpose" architectures to include symbolic processing, it's been done, and the results are very exciting. I have a single chip design for a Prolog machine, and frankly think it's pretty good (but we know it could be improved, don't we?) Because the design was closely tied to discussions and experiments with Kevin Buettner, the author of Applied Logic Systems Prolog compiler, the architecture is the first "native code" Prolog processor below the level of the WAM that is tied in to the optimizations that a Prolog compiler would typically perform. I've been flogging the notion of a Prolog RISC since 1986, and have evolved a design which we are building now at Indiana University with some support from Motorola; Frank McCabe & British Aerospace have been influenced in some small part by my earliest LOW RISC I, and have independently come up with a similar design (the DLM, a very nice machine based on the little-appreciated sigma machine). Because of the similarity in designs, and because there is only so much you can do in a limited instruction set, I'd argue that we already have a good notion of what a general purpose processor needs. First some history: 1985 - WAM taken apart, pieces used to build a Sub-WAM for Ken Bowen's ALS PC Prolog compiler. Fast implementation; taught us how to compile Prolog to native code. 1986 - LOW RISC I. Arcane 7 opcodes. Verified need for integrated tag & value processing; had problems with excessive branching & deref loops 1987 - LOW RISC II. Simulated, nominal speeds 300 - 800 KLIPS. Still had excessive branching problems (particularly in unification). - 88000e. Brian Short extended the 88000 to a tagged architecture. Similar performance to LOW RISC II. His thesis is an excellent piece of work, but you have to sign a non-disclosure to get it. Try calling Sam Daniel, Motorola GEG, (602) 897-3010 if you want a copy. It might not be releasable until late 1990, though. 1988 - LIBRA. A "balanced" RISC with 35 instructions. ("Balance" is a concept described by Michael Flynn of Stanford and others - I recall a BISC described at a DoD conference). The LIBRA runs WAM macros with 2.3x fewer cycles than the PLM, but code optimizations can improve this even more. Every opcode is conditioned to reduce branch frequency (a la the ARM), and branch frequency is further reduced by a single cycle partial unifier. It is possible that an ECL gate array version with an instruction prefetch buffer, an ECL cache, and interleaved 100ns RAM could nominally run over1,000,000 inferences per second, and could max out on the inner loop of NREV at more than 5.7 MLIPS (but not much more). The architecture of the LIBRA is discussed in more detail in the following posting, derived from an article being written for IEEE Micro.