In refd article, axs@cs.bham.ac.uk (Aaron Sloman) writes:
>pop@cs.umass.edu ( Robin Popplestone ) writes:
>>
>> Since not all of us were around in the sixties, I thought it might be
>> useful to point out that Ray Dunn was the person who really got POP-2
>> (complete with incremental compiler) to the state of being a tool that
>> worked well enough to support the work of one of the leading AI research
>> groups in the world.
>
>As one of the people who benefited from that work at the time, even
>though I was at Sussex not at Edinburgh, I can confirm this.
Well, my gosh! Such testimonials, and un-solicited too! I beamed all the
way to work through the snow this morning! Thanks Robin, Aaron, really
though, I've no idea how to suck eggs!
>Am I right in thinking that that version was mostly written in
>assembler?
I see that Pop... eh, Robin, has answered this question, and I'll add a few
comments to his posting, but perhaps here I'll write some comments on the
"incremental compiler".
On the 4100 and even carried through to the implementation on the DEC-10 by
Malcolm Atkinson and myself, the instruction set to which POP-2 compiled
was very limited, essentially only PUSH, POP, CALL, COMPARE, and
conditional and unconditional jumps. "Extracodes" on the 4100 (what we
might call software interrupts today - software executed opcodes) were used
for function entry and backward jumps, the latter to enable the stack
integrity to be checked.
I think the difference between a compiler and interpreter gets pretty fuzzy
under these circumstances, and even though immediately evaluated statements
were also translated into these instructions and "planted ahead" for
execution (the ultimate side-effect!), I still tend to think of this as not
so much a poor compiler but rather a good interpreter, with much of the
traditional interpreter's role distributed through the code of the standard
functions being called.
Having said that, the compiler was beautifully elegant and remained almost
unchanged from Robin's original design. It fascinated me, and although I
tinkered with the tactics, reduced the "core" churning, and made it very
much faster, the basic design, syntax analysis and precedence handling was
the part of the system that changed least over the years and was carried
through into the DEC-10.
Actually when it comes down to it, the basic framework of the design of the
rest of the implementation, the memory organization, double stack, garbage
collection, etc. also changed remarkably little from Robin's original
ideas, even though they were tuned and tuned and .....
Some compiled code "optimizations" were implemented towards the end of the
life of the 4100 system and on the DEC-10. Chains of jump instructions
produced by conjunctions, disjunctions and nested conditionals were
replaced by a single jump to the final destination, "erase" was replaced by
a stack ptr increment (such optimizations!), and PUSH/POP pairs were
replaced by LOAD/STORE (or MOVE/MOVEM) with associated logic which
remembered what was in the register to optimize subsequent PUSHes and POPs.
On the DEC-10, some lookahead was done on the instruction sequence to
improve this process. The improvement from all of this was probably
negligible, in POP-2 the CPU spends most of its time in the standard
functions!
On the DEC-10 we spent some time on the idea that the top of stack should
be held in a register but concluded it would make little difference to
performance and would complicated the code unduly. Instead, the standard
functions were written in a way which minimised stack manipulation - having
a standard interface which expected arguments on the stack and an
internally used entry-point which expected the first argument in a
register - this was a worthwhile tactic.
This "internal" interface idea was also used to optimize the procedure
calling mechanism between internal system procedures. External interfaces
used the link-onto-stack call and many internal calls placed the return in
a register (actually I think we systematically used three diferent calling
types).
One of the interesting aspects of that DEC-10 implementation was the heavy
use of fairly complex macros which allowed us to write for the DEC-10
assembler in a very similar way to writing POP 1.5 code on the 4100 - i.e.
functions were written with a function header that looked very much like
POP-2, and words, dictionaries, etc, were defined in the assembly source
looking very much like POP-2.
--
Ray Dunn at home | Beaconsfield, Quebec | Phone: (514) 630 3749
ray@philmtl.philips.ca | ray@cam.org | uunet!sobeco!philmtl!ray
|