Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Summary: A current use for it
Message-ID: <6481@pt.cs.cmu.edu>
Date: 11 Oct 89 11:53:06 GMT
References: <1080@mipos3.intel.com>
Organization: Carnegie-Mellon University, CS/RI
Lines: 25

In article <1080@mipos3.intel.com>, jpoon@mipos2.intel.com (Jack Poon~) writes:
> ...
> What the advantage of using self-modifying code that non-self-modifying code
> cannot achieve?
> ...

In combinator graph reduction execution of functional programming
languages, self-modifying code gives approximately a factor of
two speedup on almost any hardware.  This is because graph reduction
is by its very nature self-modifying.  My paper "A fresh look at
combinator graph reduction" in the 1989 SIGPLAN conference on
Programming Language Design and Implementation has details.

In my case, the self-modification is limited to changing the
addresses of subroutine call instructions.  If a RISC architecture
such as the R2000 had a jump to subroutine that took an address
out of the data cache (perhaps by using the suceeding word
in memory as an address, referenced through the data cache)
this would be good enough for my application.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor, and researcher at CMU.
I don't speak for them, and they don't speak for me.