Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Summary: self-modifying vs self-generating
Message-ID: <16212@vail.ICO.ISC.COM>
Date: 13 Oct 89 21:36:06 GMT
References: <1080@mipos3.intel.com> <48682@ricerca.UUCP> <236@bbxsda.UUCP> <9850@pucc.Princeton.EDU>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 34

EGNILGES@pucc.Princeton.EDU (Ed Nilges) writes:
> I have followed this discussion with interest.  In modern very-high-
> level interpreted languages like REXX, an interesting variant of the
> SMC issue emerges...
>...   INTERPRET expression
>...evaluates "expression" and executes it as a REXX statement...

It's not a very new idea, though.  It exists in LISP (apply/eval) and
SNOBOL (compile()), both of which go way back.  It exists in the UNIX
shells (eval and ``).  The hardware analog, as others have noted, is the
EXECUTE instruction on some older machines.

It may be useful to make a distinction between self-modifying and "self-
generating", for want of a better word.

About objections to self-modification:
>      2.  It breaks associated technology.  Traditional SMC breaks
>          instruction caches and other such contraptions, whereas
>          use of INTERPRET breaks compilers.  This last point is not
>          a necessity, since the compiler could generate code for
>          lazy evaluation of the expression, but the only current
>          compiler for REXX simply prohibits INTERPRET.

In hardware, you just need a way to say "clean these things out of your
cache".  It shouldn't be hard, but it has to be provided.  It helps the
tradeoff at which generating code is practical if it isn't a privileged
instruction.

INTERPRET, or eval or compile or whatever, should not break a compiler.
There's no excuse for it--as Nilges says, you just have to handle it
correctly.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.