Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <6471@pt.cs.cmu.edu>
Date: 10 Oct 89 19:25:15 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:
>
>Could any experts out there educate me WHY and HOW does self-modifying code use?
>What the advantage of using self-modifying code that non-self-modifying code
>cannot achieve?

In prehistoric times, self-modifying code was used to make up for
machine limitations. This led to snarled messes, and today, the
practice mostly survives in three areas:

Copy protected PC software: the obscurity treated as virtue.

Debuggers: a debugger may write e.g. traps into the code area, and
may fill little buffers with code (and then execute the buffer).
(Note that typical hardware features, such as trap-after-each-
instruction modes, have NOT obsoleted this practice.)

Interpreters: some interpreters will actually compile little code
sequences, and then run them on the spot. Some APLs did this.  (APL
compilers aren't possible because you run into expressions whose
meaning isn't known until you compute the value of some previous
expression. So, the interpreter would just compile up-to-there, run
that, and then go back around.)
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science