Path: utzoo!attcan!uunet!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: Whats wrong with self Modifying Code? Message-ID: Date: 11 Jul 90 15:45:53 GMT References: <1990Jul6.201328.24660@csmil.umich.edu> <1990Jul6.201743.24777@csmil.umich.edu> <138523@sun.Eng.Sun.COM> <1990Jul9.163607.18336@sunee.waterloo.edu> <1990Jul10.201202.3378@sunee.waterloo.edu> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 30 In-Reply-To: gpsteffl@sunee.waterloo.edu's message of 10 Jul 90 20:12:02 GMT In article <1990Jul10.201202.3378@sunee.waterloo.edu> gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) writes: >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. The last two sentences in the paragraph cover that. You don't just branch into the code, you run it as a seperate task (or thread or whatever your favorite term is). If the OS fails to correctly deal with caches in this case, then it's got a _serious_ bug. After all you haven't done anything different from what happens when a shell starts an application. The OS may do a cache flush. Then again, it may not - it has more information about what's going on in the system than you do.