NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/pop/194

Internet Message Format | 1993-01-10 | 7.9 KB

Path: sparky!uunet!pipex!warwick!uknet!bhamcs!axs
From: [e-mail] (Aaron Sloman)
Newsgroups: comp.lang.pop
Subject: Why Poplog Pop-11 was never implemented in C
Message-ID: <[e-mail]>
Date: 10 Jan 93 12:38:08 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: School of Computer Science, University of Birmingham, UK
Lines: 154
Nntp-Posting-Host: emotsun

[e-mail] (Ray Dunn) writes:

> Date: 9 Jan 93 01:39:23 GMT
> Organization: Not Philips.

> ....

> Having been hacking in 'C' for the last ..cough.. years I can't understand
> why there wasn't a 'C' implementation of POP done a long time ago.

> I hope the work on Pepper is being done in a portable fashion.

The Mac Alphapop implementation was done in C by Cognitive
Applications Ltd in the mid eighties, but it turned out not to be
easily portable because it was too dependent on idiosyncratic
features of the C compiler used, and perhaps too closely tied to the
Mac operating system. It was very well integrated with Mac graphics,
menus, etc., I believe. (I've never used it.)

Alphapop compiled to an intermediate code which was then
interpreted, as was also true of the DEC PDP-11/40 version of Pop-11
implemented a decade earlier by Steve Hardy in PDP11 assembler.

Using an interpreted intermediate level makes porting very much
easier, but the cost is speed of execution.

By contrast Poplog Pop-11 compiles all the way to machine code,
making porting to a new machine non-trivial.

Most of Poplog Pop-11 is implemented in Pop-11, so that porting is a
bootstrapping operation. Some bits are implemented in C. The rest
uses assembler for efficiency. E.g. the stack pointer, which is used
all over the place, should be in a global register and you can't
have global register variables in C (or couldn't when I last heard
this point discussed -- I am not a C programmer.)

The main obstacle to portability is not the language used: it's the
fact that Poplog Pop-11 is compiled to machine code for maximum
speed of execution. In particular it has an incremental compiler
which has to generate machine code for the current machine at "run
time", i.e. when user procedures are compiled.

The compiler itself (actually a family of compilers, as explained
below) is written in a special extended "system" dialect of Pop-11
with C-like pointer manipulation facilities and other extensions for
efficiency. It would be much harder to implement such a
sophisticated compiler in C, which is a far less rich language.

Most of the Poplog compiler is machine-independent. Source code (in
any of the Poplog languages, i.e. Pop-11, Prolog, Lisp, ML, or
user-defined languages) is first compiled to a "high level" Poplog
virtual machine (PVM), using a language-specific compiler (often
implemented in a mixture of Pop-11 compiler routines and a parser
written in the source language, e.g. Prolog). This bit is
language-specific, but machine independent. Porting the Poplog
languages therefore requires porting the Poplog virtual machine.

That does not need to be done explicitly, because a
language-independent and machine-independent compiler (implemented
in extended Pop-11) compiles from the PVM to a low level Poplog
Implementation Machine (PIM), which is roughly at the level of a VAX
instruction set. This means that only the PIM has to be ported to
each new machine, which is not very hard.

For each machine a machine-specific "translator" generates machine
code to go into procedure records. This has to be architecture
specific, and is one of three main components that has to be re-done
for each architecture, Modifying that translator for a new machine
can take about a month's work if done by an expert.

In theory that back-end compiler could be produced automatically
from a specification of the target machine. In practice that`s a
very hard problem because of the variety of machine architectures
(numbers and types of registers, addressing modes, types of cache,
etc.) so porting well requires some creativity.

The Poplog system sources written in extended Pop-11 are compiled
using a slightly different route from user procedures, because the
system can't assume there's already a working Poplog running on the
target machine. Nevertheless most of the compilation process is the
same though there's more optimisation between the PVM and the PIM
because system procedures can make assumptions that would not be
applicable to user procedures. But that's all machine independent.
However, instead of generating machine code directly from the PIM
level, the final stage of the compiler generates assembler for the
machine, so that the system can be built on one type of machine to
be run on another. The assembler files are then assembled, linked
and run on the target machine. (Occasionally there are unimaginative
manufacturers who won't release an assembler, even when they use one
in-house, because they think only high level languages should be
used by their customers!)

The second back-end compiler, which outputs assembler, is also
written in extended Pop-11, and should not normally take more than a
month or so to re-target for a new machine.

As I said before, there are also some hand-coded assembler files,
mainly to do with control of the stack and also providing some
frequently used routines that have to be very fast. The assembler
files can usually be rewritten for a new machine in a few weeks.

The other component that's host-specific and has to be changed for
each port is the interface with the operating system, which is very
rich in Poplog, including system calls, procedures for creating,
reading and writing files and directories, object file formats,
dynamic linking of "external" programs (e.g. object files produced
by C, Fortran, etc.), access to system libraries, spawning
sub-processes, pipes or mailboxes, etc. etc. Porting the operating
system interface can be a matter of a few days, if it's to a new
dialect of Unix close to one that's been done before, or it can take
several weeks.

Thus, where all goes well a complete port, including modifying
run-time code generator, assembler generator and OS interface, and
re-writing a few assembler files, requires only three to four person
months, and that work then ports all the Poplog languages (including
any languages users have implemented in Poplog), the editor and,
with luck, the X interface.

Unfortunately it can take longer where there are bugs in the target
host's linker, assembler, operating system, or hardware.

Such bugs have caused delays since Poplog ports began in the early
80s. Trouble arose with various systems (including Apollo, HP,
GEC-63 (now defunct) Fairchild Clipper, DEC RISC+Ultrix and MIPS)
causing what should have taken little more than three months to be
drawn out over a longer period, the original RISC DECstation being
one of the worst. Poplog finds the bugs other applications don't,
apparently.

Poplog used to be much harder to port. The increase in portability
is due to work by John Gibson at Sussex University, especially
separating the PVM and the PIM so that the bulk of the translation
between them is both language and machine independent, and also
extending the Pop-11 system dialect to provide very efficient
mechanisms in a portable fashion, so that less and less machine
specific stuff had to be written in assembler or C (which is not
always fully portable).

For more information see:
R. Smith, A. Sloman, J. Gibson `POPLOG's two-level virtual machine
support for interactive languages' in
    Research Directions in Cognitive Science Volume 5: Artificial
    Intelligence,
eds D. Sleeman and N. Bernsen, Lawrence Earlbaum Associates, 1992
(Also Cognitive Science Research Paper 153, University of Sussex,
Jan 1990).

Aaron
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL   [e-mail]  OR [e-mail]
Phone: [phone]       Fax:   [phone]