Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!rutgers!aramis.rutgers.edu!athos.rutgers.edu!webber
From: webber@athos.rutgers.edu (Bob Webber)
Newsgroups: comp.arch
Subject: Re: self-modifying code
Message-ID: <902@athos.rutgers.edu>
Date: 19 Feb 88 04:04:54 GMT
References: <486@taux01.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 28

In article <486@taux01.UUCP>, yuval@taux01.UUCP (Gideon Yuval) writes:
> Is good support for self-modifying code a real  issue?  all  CPUs  support  a
> "modify  code  -- invalidate all caches -- execute" cycle, which is enough to
> run  (say)  loaders &  debuggers;  i  THINK  this  is  enough  for  all  real
> applications, but want to be sure.
> 
> Are any exceptions to this (AI or other) known?

At most unix systems, the classic example of ``self-modifying'' code is
dynamic loading where you want things like the lisp interpreter to
be able to use compiled code while it is interpreting.  Similarly,
some people have used dynamic-loading by hand to simulate some of the
benefits of shared libraries (i.e., minimizing the size of executables
that are not being executed).

Incremental compilation is another place where one could imagine
self-modifying code being used to good effect.

Some people generate code that for floating point operations that modifies
itself depending on the availability of an fpa at execution time.

A number of people interested in object-oriented programming will
present algorithms.  When asked how they expect them to run as fast as
hand coded C, often they start talking about dynamic code generation
for common cases.  One even hears people contemplate about programs
that profile their own execution and optimize ``hotspots''.

------- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)