Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!jwmills
From: jwmills@iuvax.cs.indiana.edu (Jonathan Mills)
Newsgroups: comp.lang.prolog
Subject: Re: logic programs -> procedural lang?
Keywords: Logic Programming Compilers (Prolog), RISC, LIBRA
Message-ID: <26742@iuvax.cs.indiana.edu>
Date: 28 Sep 89 10:24:36 GMT
References: <27335@shemp.CS.UCLA.EDU> <869@gamera.cs.utexas.edu> <1989Sep25.182448.2441@indetech.com> <7152@ulysses.UUCP>
Reply-To: jwmills@iuvax.cs.indiana.edu (Jonathan Mills)
Organization: Indiana University, Bloomington
Lines: 26
In article <7152@ulysses.UUCP> garym@cognos.UUCP (Gary Murphy) writes:
>
>There is yet another alternative: wasn't there a posting a while ago
>gloating over a prolog-based cpu? That's the one _I_ want! :-)
>
If it's the LIBRA, we're working on it. The VLSI prototype of the datapath
unit is due back from MOSIS by October 2nd, and we will be testing it in
both a pipelined & non-pipelined mode. If it works, the next step will be
to put 10 slices on a chip to get tag, garbage collect & value ALUs on 4
chips.
We are also experimenting with an automatically derived version of the
LIBRA using Steven D. Johnson's Digital Design Derivation system (DDD).
Although DDD cannot yet handle pipelined architectures, it has the benefit
of producing designs that are correct with respect to their original
specification.
Finally, in my dissertation I described a clause compiler that emitted
opcodes for an early version of the LIBRA, and which did NOT post-process
WAM code, but instead built a DAG attributed with properties of each token
in the Prolog clause, "head/body", "nesting level", "". WAM code
could easily have been output from this structure, but there was no need,
particularly since I was interested in generating RISC opcodes.
Jonathan Wayne Mills (812) 331-8533/855-7081