Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!nsc!voder!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <13984@apple.Apple.COM>
Date: 15 Jul 88 02:00:16 GMT
References: <5254@june.cs.washington.edu> <28200177@urbsdc>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 30

[]
>In article <28200177@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes:
>
>>Today, people are finding new uses for self-modifying code that
>>were unforseen 20 years ago:
>>
>>1. ... BITBLT ... 
>>
>>2.  Peter Deutsch and PARCPLACE systems used a new technique to speed
>>up Smalltalk on conventional computers...
>>

This was supposed to be a reply to Doug Pardo, but the Brain-Damaged-Mailer
bounced the reply, so I'm posting...

What about the case mentioned by someone for speeding up SmallTalk? In this
case, you're compiling a small routine, instead of the whole program, but
have the same information.
   HP used something like this for a fast APL compiler
long ago in a galaxy far away. They compiled code for adding to objects
according to the object types at compilation time, and the code included a 
check for just those types. If the check failed, it bounced back to the
compiler, which generated code for a more general case; so, for example,
the first time it might compile code for arrays of size i=constant, and if
the size changed, then it would compile slightly more general code for arrays
of size n=variable, then if that also failed, maybe for arrays of rank m=var,
size n=var, etc. It ran much faster than interpreters running on faster
machines so it can be a big win. Again, in all cases, you know which addresses
to flush before you branch to them.
  
--
{decwrl,hplabs,ihnp4}!nsc!apple!baum		(408)973-3385