Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mpirbn!p554mve
From: p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Code generation
Message-ID: <1315@mpirbn.mpifr-bonn.mpg.de>
Date: 17 Oct 90 17:59:51 GMT
References: <512@cbmger.UUCP> <14827@netcom.UUCP>
Reply-To: p554mve@mpirbn.UUCP (Michael van Elst)
Organization: Max-Planck-Institut fuer Radioastronomie, Bonn
Lines: 23

In article <14827@netcom.UUCP> mcmahan@netcom.UUCP (Dave Mc Mahan) writes:
>Do what?  I have never used LoadSeg(), but my book says that it just loads
>a module into memory and links the scattered segments together.  All it does
>is load.

The operation performed by LoadSeg() is strictly 'self-modifying' code.
(At least if you reuse memory for a new program). Self-modifying code
leads to problems when you have a non-transparent cache like in the
68020/68030 where code could be changed in memory but old code could
be still executed out of the cache. The Kickstart 1.3 LoadSeg() does
nothing to prevent this but the sheer length of the LoadSeg routine
will force the obsolete contents of the cache to be flushed (== replaced
by the LoadSeg code). I think Kickstart 2.0 does better things since
the cache is supported by new Exec system calls, this allows for larger
caches where you can't trust that executing code of the size of LoadSeg()
will invalidate old cache entries.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."