|
These are the passages from the intro that made me say that: "So a supercompiler does not transform the program by steps; it controls and observes (SUPERvises) the running of the machine that is represented by the program; let us call this machine M,. In observing the operation of M1, the supercompiler COMPILES a program which describes the activities of M1, but it makes shortcuts and whatever clever tricks it knows in order to produce the same effect as M1, but faster." "A supercompiler would run M, in a general form, with unknown values of variables, and create a graph of states and transitions between possible configurations of the computing system. However, this process (called driving) can usually go on infinitely." This implies, to me, a compile, execute, profile, re-compile cycle. But, that conflicts with the understanding of the technique that I described above. If that does not describe a compile, execute, profile, re-compile cycle, then I'd like to know both what, exactly, the author meant by the above, and why he chose to phrase it as such. |
In particular: "run M, in a general form, with unknown values of variables" would probably be called abstract interpretation today.
(I'm only fudging because I haven't read the rest yet myself. :)
Edit to add something I forgot to mention, but should: There's a(t least one) useful PDF of slides in the repository from the originally linked project.
I did go through that, in something of a hurry -- it walked through the rewriting of a naive function to append 3 lists [ app3(a,b,c) = app2(app2(a,b),c) ]into one that executes with a single pass.