Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!iuvax!pur-ee!a.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <76700032@p.cs.uiuc.edu>
Date: 13 Jul 88 01:27:00 GMT
References: <5254@june.cs.washington.edu>
Lines: 29
Nf-ID: #R:june.cs.washington.edu:5254:p.cs.uiuc.edu:76700032:000:1443
Nf-From: p.cs.uiuc.edu!gillies    Jul 12 20:27:00 1988


I think many rules have an exception (e.g. "gotos considered harmful").
There is a difference between self-modifying code and non-reentrant
code.  Today, people are finding new uses for self-modifying code that
were unforseen 20 years ago:

1.  Simple programs that need OPTIMAL speed, and would be outrageously
expensive on ANY machine.  The major example is BITBLT, a subroutine
with about 10-15 parameters that does a massive amount of linear-time
work.  If the BITBLT subroutines generates the machine code expressly
for the particular arguments, you can save a factor of 3 or more in
speed.  This is very important for interactive graphics.

2.  Peter Deutsch and PARCPLACE systems used a new technique to speed
up Smalltalk on conventional computers.  When a subroutine is
executed, the types are checked and if possible, the subroutine is
compiled for speed & executed.  Then this compiled code is cached for
possible use later, when the arguments have the same types.  This also
gave a very large constant speedup to the smalltalks marketed by
ParcPlace systems.

I think papers on both these techniques appeared in the first OOPSLA
conference.

In light of these new techniques, I believe it's time to reexamine
our opinions about self-modifying code.  

Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies