[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Apr 29 21:28:42 1997 
Subject:The future of POP-11 
From:Robin Popplestone 
Volume-ID:970429.07 

I don't know what the current state of the deliberations of the POP9x group
are, but I would like  to make a suggestion  about where (if anywhere)  POP
should go from here.

I am proposing to make my own work target the Java Virtual Machine, because
I think  it  is  going  to  be  a  highly  portable  and  efficient  target
architecture. I've talked to  the some of the  system types here and  they,
with some  caveats,  agree  -  there  are  problems  of  supporting  global
optimisation of  the kind  that  modern compilers  do, but  standard  local
optimisation should work ok.

Frankly, I think that we've lost  the battle of tagged architectures,  even
such slightly tagged architectures as the Poplog VM.

So, the JVM offers an approach in which there is a small number of "simple"
items in the original POP-2 sense (int, long, float, double). Any item that
is treated as an object (a compound item in the POP sense) is boxed.

Contrary to first impressions, the  JVM can support higher order  functions
(though of course Java itself does not  per se). The essential trick is  to
have a  Procedure class  that has  apply methods.  This is  not unlike  the
class_apply capability of POP-11. So  the POP-11 expression hd(x) could  be
equivalent to the Java:

    hd.ap1(x)

where hd is a Procedure object and ap1 is an apply method, while the POP-11
expression x::y is equivalent to:

    cons.ap2(x,y)

This cannot be made to work for POP-11 as is because of the open-stack, but
I think we  could keep most  of the language  features, and actually  get a
better language, by making some restrictions. Primarily it must be manifest
to the compiler who does what and with whom, that is the compiler must know
that f(x,y,z) means that f has  exactly three arguments. We could  preserve
the "open stack" aspects of POP, but they would have to be clearly flagged.
Thus the Java equivalent of:

    [% x, y+2 %]

would be something like:

    Stack.pushstackmark(); Stack.push(x); Stack.push(plus.ap2(x,y))
    Stack.sysconslist();

There is of course no need to have  a Java intermediate form - I just  give
it as being more digestible than the JVM instructions.

This way one  could make  POP applets  that would  autolink their  required
library support, which could be shared with other languages (e.g. I'd do my
Scheme in this new regime).

Currently, I'm working on  implementing the JVM and  Java in POPLOG,  which
should give  a  platform that  people  in  this group  could  work  within.
Matching the  Java  spec in  POPLOG  can't  be done  both  efficiently  and
accurately (for Java specifies floating point precision very tightly).  But
a workable (and quite fast) JVM could be achieved.

If, on  the way,  one is  able to  introduce simple  type constraints  into
POP-11, and exploit constant functions, one  might get quite good code  out
of POP. For example, having done:

sysunprotect("hd");
lconstant hd = front;

it is save to translate the POP-11 hd(x) as the field-access operation

    x.front

in Java (front being a field of an object of the Pair class).

Robin.