Programmed code generation: Native vs. Pcode

[Richard A. O'Keefe]

>From: pardo at june.cs.washington.edu (David Keppel)
>Many Lisp (Prolog, Smalltalk, ...) systems generate a pseudocode
>rather than native instructions.  The p-code is run by an an
>interpreter rather than the hardware.  Thus, as far as the hardware is
>concerned, it is only the interpreter and NOT the p-code that is being
>executed.

(1) There are a couple of commercial Prolog systems which generate native
    code.  In the interests of higher performance for large programs on
    small (4-8Mbyte) machines, Quintus Prolog is _not_ one of them, but
    that is another (and perhaps more interesting) story.
(2) All the commercial Prolog systems that I know of offer an interface
    to some other language (Lisp, C, or Pop).  So even the systems which
    use pseudocode rather than native code aren't off the code-modifying
    hook:  if you want to be able to load C code at run time you still
    have to make additional parts of your address space executable.
    (But once a region of the address space has turned into code, it need
    never be changed again.)
(3) VMS, SunOS 4.0, and I believe Apollo's AEGIS support dynamic extension
    of programs by mapping *shareable* library code into a program's
    address space (System V.3 on a 386 sort of kludges this in too).

Would anyone care to explain what architectural features are needed for
efficient dynamically mapped shared code?  Is position independent code
essential, or only better?  What popular architectures couldn't do it?
If SPARC can do it, is there anything about RISCs which makes it easier/
harder?