Newsgroups: comp.sys.amiga.tech
Path: utzoo!utgpu!watserv1!sunee!gpsteffl
From: gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler)
Subject: Re: Whats wrong with self Modifying Code?
Message-ID: <1990Jul10.201202.3378@sunee.waterloo.edu>
Organization: Gerbils On Speed Inc.
References: <1990Jul6.201328.24660@csmil.umich.edu> <1990Jul6.201743.24777@csmil.umich.edu> <138523@sun.Eng.Sun.COM> <1990Jul9.163607.18336@sunee.waterloo.edu> <MWM.90Jul9134559@raven.pa.dec.com>
Date: Tue, 10 Jul 90 20:12:02 GMT
Lines: 62

In article <MWM.90Jul9134559@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) writes:
>In article <1990Jul9.163607.18336@sunee.waterloo.edu> gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) writes:
>   A spread sheet program which must perform several thousand iterations
>   of a formula while recalculating.  The formula can be "compiled" to
>   the stack, and run such that the execution time is considerably less
>   than if the formula had been interpreted each time.
>
>Both examples are from a class that's often confused with self
>modifying code, but aren't really self modifying unless badly written.
>I call that class (until somebody suggests something better) self
>generating code.

Ok.  My goof.  The purpose of the article was to present a scenario
which almost "requires" code to be generated, and run from a non-code
segment, or some such.  I wanted someone to approach the article on the
basis of incompatability with hardware, like the instruction/data cache
separation, or the MMU non-cache feature.

>All programs of this class can be done without modifying code -
>remember, you're creating it, not modifying it! For the first example

Agreed, and I had stated this in my article.

>(several thousand iterations? trivial) I'd compile to interpreted
>stack-machine code to run. For large applications (popi, for instance)
>or those where speed is more critical (your video driver), compile to
>an array and tell the OS you're launching a task loaded into that
>chunk of memory, and use that. The OS should take care of making sure
>the code in that memory actually gets run, and not whatever you put
>there last time around.

Fine, thats what I would do if it were not for the problems that may happen
on machines which cache lots of memory.  If I recompile into the array 
and run code from it withouta a cache flush, the possibility of major
problems is quite large.

>Of course, for your video applications, you wouldn't want to use a
>soft solution anyway. Either a blitter, or a hand-coded library for
>all the common operations, or a graphics accelerator that does all the
>real work. In any of those cases, you never need to generate or modify
>code; that's already been done. For development, you'd want the
>support code that finally runs the code you're developing to be as
>straightforward as possible, and raw speed won't be that critical.

RAW speed is generally critical on slower archetectures, and in areas
of serious competition like spreadsheet recalc times etc.  Video drivers
tend to give the user more a feeling of how fast a program is rather than
its computational efficiency.

>	<mike
>--
>My feet are set for dancing,				Mike Meyer
>Won't you turn your music on.				mwm@relay.pa.dec.com
>My heart is like a loaded gun,				decwrl!mwm
>Won't you let the water run.


-- 
Co-Op Scum - U of Loo '91             "Bo doesn't know software" - George Brett

"If I could only flag her down" -- ZZtop Afterburner
                       Glenn Patrick Steffler
