Path: utzoo!attcan!uunet!snorkelwacker.mit.edu!think.com!samsung!uakari.primate.wisc.edu!sdd.hp.com!apollo!rehrauer
From: rehrauer@apollo.HP.COM (Steve Rehrauer)
Newsgroups: comp.sys.atari.st.tech
Subject: Self-modifying code
Message-ID: <4e05f38c.20b6d@apollo.HP.COM>
Date: 15 Nov 90 15:25:00 GMT
References: <1990Nov11.013428.4566@cs.utk.edu> <2796@laura.UUCP>
Sender: root@apollo.HP.COM
Reply-To: rehrauer@apollo.HP.COM (Steve Rehrauer)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 29

In article <2796@laura.UUCP> klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes:
>In article <1990Nov11.013428.4566@cs.utk.edu>, andrew@.cs.utk.edu (Andrew
>Krzywdzinski) writes:
>|> I want to be able to write setup information directly to a program
>|> file.
>
>I once posted a fundamental (as I think) article against self-modifying
>code to this newsgroup. Here it is again - slightly generalized and of
>course open to consideration and discussion:

[ ...good reasons deleted... ]

And perhaps more immediately relevant to ST programmers: you will regret
writing self-modifying code when/if the TT is generally available.  S-M
code doesn't play well with instruction caches, which the 68020, '030
and '040 all have.  Even building code on the fly, e.g. in a stack buffer,
can cause havoc if you have both data- and instruction-caches and the
D-cache isn't a write-through cache.  S-M code is a "neat hack" that
probably everyone is intrigued by at some point, but: "Just say no!"

>	In most cases it is fully sufficient to maintain a configuration file.
>Keep an entry for every variable that needs to be modified permanently.
>Upon startup of the program the whole stuff is read in again and the
>program's variables are set accordingly. Simple, isn't it?

--
"I feel lightheaded, Sam.  I think my      | (Steve) rehrauer@apollo.hp.com
 brain is out of air.  But it's kind of    | The Apollo Systems Division of
 a neat feeling..." -- Freelance Police    |       Hewlett-Packard