Lisp, the machine language. Was Re: Hallelujah!

From: ss_at_allegro.com <(ss_at_allegro.com)>
Date: Tue Apr 6 13:44:32 1999

Re:

> At 11:47 AM 4/4/99 -0400, Max wrote:
> >So, an assembly language program for them would look like lisp, as opposed
> >to MOVs, ADDs, and so forth?
>
> Nearly, the trick is that the machine code instructions are designed with
> the high level language constructs in mind. So on a LISP machine there
> might be an instruction: next ptr, ptr
> Which follows a LISP list construct to the next element.

At about the same time as UCSD Pascal was being developed, Bill
Gord of the UCSD Computer Center invented a LISP P-Code as the
target "machine" for the BBN LISP (later INTERLISP) compiler that
we were working on for the Burroughs B6700. Since Bill and I
officially worked for Dr Ken Bowles (head of UCSD Pascal), I
assume that Bill and Ken talked about the two "P-systems"...but I
don't know which came first. I still have the source for our LISP ->
pcode compiler, somewhere.

BTW, one of the motivations for P-Code (for Pascal *and* LISP)
was security / data integrity.

Jim Madden (of UCSD Computer Center) had ported Wirth's Pascal
to the Burroughs B6500 / B6700 only to realize that the lack of
compiler-enforced security checks on the tagless variant record
concept meant that programmers could generate their own values
for pointers ... which would allow them to defeat the largely compiler-
based security on the B6700. The B6500 line had no real hardware
security (e.g., ring levels, page-level protection, etc ... it was nearly
100% software-enforced secuirty. ALGOL's pointers were restricted
to point only within an array...which had hardware bounds checking.
 FORTRAN and COBOL didn't have pointers, and (with hardware
bounds checking) had no method of generating random data
addresses ... this meant that security on the B6700 was reasonably
good. Unless you could generate your own code somehow :)
(Normally, modifying existing program files would cause them to be
marked as non-executable)

Anyway, the P-Code implementation provided a means of
implementing a language *and* having 100% control of the data
accessed by the programs written in that language. This was
probably one factor, in addition to the obvious portability aspects,
that influenced the P-Code project.

SS
Received on Tue Apr 06 1999 - 13:44:32 BST