Path: utzoo!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!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: 13 Mar 91 08:12:32 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> <06545.AA06545@babylon.r Organization: Not an Organization Lines: 41 In article <06545.AA06545@babylon.rmt.sub.org> rbabel@babylon.rmt.sub.org (Ralp >In article , cg@ami-cg.UUCP (Chris >Gray) writes: > >> 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). > >"dynamically-created code"? Chris, I guess you've been doing >too much compiler development lately! :-) Naw - working full-time on a MUD for the Amiga - all interpreted. >> The technique does not break on systems with caches, [...] > >I think it does. Here's the scenario: > >1. Process P1 executes its code in memory chunk M; >2. Parts of chunk M will be loaded into the code cache; >3. Process P1 terminates; >4. The memory area occupied by P1's code segment (including > chunk M) is released to the free-memory pool; >5. Process P2 allocates a fake seglist; let's assume this > seglist happens to be located in chunk M; >6. The code to be executed is copied to M, but this copying > does _not_ update the _code_ cache!!! >7. Since CreateProc() doesn't clear the code cache, it will > read the _old_ code from process P1 when entering the > fake seglist. > >> It is NOT because it breaks on CPUs with caches, > >It does break on CPUs with _separate_ code and data caches. Ok, you win - I wuz wrong. Sigh. In reality I would guess that the I-cache is flushed by CreateProc and/or LoadSeg, so it wouldn't matter, but I agree we are talking principles here. -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA