Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!uwm.edu!rutgers!mit-eddie!uw-beaver!ubc-cs!alberta!ami-cg!cg From: cg@ami-cg.UUCP (Chris Gray) Newsgroups: comp.sys.amiga.programmer Subject: Re: Starting another copy of your own code Message-ID: Date: 11 Mar 91 18:15:26 GMT References: <63329@eerie.acsu.Buffalo.EDU> <19578@cbmvax.commodore.com> <06417.AA06417@babylon.rmt.sub.org> <18cb4d63.ARN0b56@swinjm.UUCP> <1991Mar9.170859.4810@Sandelman.OCUnix.On.Ca> <06493.AA06493@babylon.rmt.sub.org> Organization: Not an Organization Lines: 44 In article <06493.AA06493@babylon.rmt.sub.org> rbabel@babylon.rmt.sub.org (Ralph Babel) writes: [edited down, but you'll all remember it!] >This is not true! It's always the function that brings the >code into memory (e.g. LoadSeg()) that is supposed to keep >the code cache up to date, not the function to execute this >code (e.g. CreateProc()). The same code might be executed >several times (even concurrently), so clearing the cache >every time would be wasteful. > >These are the only legal ways of bringing code into memory: > >- ROM-code >- DAC_WORDWIDE >- DAC_BYTEWIDE >- DAC_NIBBLEWIDE >- MakeFunctions() >- MakeLibrary() >- SetFunction() >- LoadSeg() > >Putting an entry into the Captures/KickTags and rebooting >the system _might_ also be considered safe. 2.0 provides a >few additional functions (e.g. InternalLoadSeg()) plus some >cache control calls. > >Sorry, self-modifying code. Even if Leo did it. :-) Ralph is saying that the technique of building a SegList structure at run-time and then using it with CreateProc is self-modifying code. I won't argue the definition (I don't think it is, I think it is dynamically created code). The technique does not break on systems with caches, whereas the usual forms of self-modifying code will. If Commodore wants to explicitly say that the technique is invalid (Ralph suggested an alternative), that is their right, but they should be clear on why. It is NOT because it breaks on CPUs with caches, but because they don't want it done. There may be good reasons for not doing it, like future considerations of MMUs and execute-only status. I waited for someone else to jump on this, but nobody did, so I had too. I've likely just crossed in the postings with half-a-dozen other replies. -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA