Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!sarah!bingnews!kym
From: kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Newsgroups: comp.arch
Subject: Re: What the compiler CAN do for you
Message-ID: <1991Mar1.042434.9601@bingvaxu.cc.binghamton.edu>
Date: 1 Mar 91 04:24:34 GMT
References: <8890@exodus.Eng.Sun.COM>
Organization: State University of New York at Binghamton
Lines: 32

In article <8890@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>So, given this, if someone were designing a return-of-the-revenge-of-
>CISC architecture, any ideas what it might look like?  One approach to
>this problem might be one that was tried for APL -- identify a set of
>100 idioms that "covers" 99% of most APL programs, and then target
>each of those patterns with carefully thought-out code.  The resulting

Why resort to idioms?

One of the things I tried when I was young(er) and brash(er) was
making a more-or-less gp theorem prover (with a few bb heuristics
thrown in) generate code for simple register-oriented machines.
The idea was, if this is getting a bit unclear, to write each
machine-level construct as an `axiom' and try to prove an hll
program as a `theorem'. (If you think it's crazy, you're in good
company -- a logician I explained it to at the time didn't seem
to like the idea either).

The big problem was finding a convenient notation for the `axioms'
and `theorem' (and would conceptually sit somewhere between these
two). Try expressing the semantics of jumps in predicate logic!
(It can be done in several ways).

Although this typically ran orders of magnitude (at LEAST) slower
than the (then) worst (alternatively, read `best') optimizing compilers the 
approach looked promising for the days when clock cycles might drop below 500 
ns and machines might cost less than 100k.

-kym

p.s. The tp did use unification and there's several very cheap but
	little-known algorithms for dealing with cycles.