🚀 go-pugleaf

In article <1990Jul6.201743.24777@csmil.umich.edu> chymes@fribourg.csmil.umich.edu (Charles Hymes) writes:
>Oh great gurus, enlighten this poor soul who hath not programmed in
>Holy Assembler sence the loly 6502 was mighty.
>Yea, I pray that thou dost not blast my humble screen with mighty
>blasts of searing, wrathful flame, but knowest this, that I hath donned
>the sacred absphestos suit, and awaitest thou's marvelous revalation.
>
>I'd really like to know.
>
>Charlweed Hymerfan A Major (but humble) Dude

OK, OK, you can get up off your face, we won't hurt you... :-)

IMHO, the biggest and best reason not to allow self-modifying code is
that your running program doesn't match your source code.  This
complicates debugging to a large degree; I had to deal with
self-modifying stuff regularly, a few years ago.  Not again.

There are other reasons too.  A good thing to do in multi-tasking
systems is keep one copy of a program in memory, and have several 
tasks run it, right where it sits.  A program which has modified
itself isn't going to work for several tasks at the same time
(probably).  Another reason is that in some cases, on many different
machines and for many different reasons, it doesn't work or is
unreliable.  The 68030 instruction cache is a good example, but most
microprocessors have some kind of instruction prefetch mechanism.  If
you modify something very near to the current PC, it may be too late,
it's already in the pipeline.  Sure, you can measure the pipeline, but
it can *change* from one generation of your CPU to the next, and now
your code doesn't work anymore.
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                                    \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/