Article View: comp.sys.amiga.tech
Article #4253Re: Self Modifying Code!
From: Dave Haynie
Date: Fri, 06 Jul 1990 20:44
Date: Fri, 06 Jul 1990 20:44
45 lines
2977 bytes
2977 bytes
In article <293@smosjc.UUCP> brett@smosjc.UUCP (Brett Coon) writes:
>Is there an acceptable means to write self-modifying code on the Amiga?
Overall, no. However, a side effect of using a 68000 CPU is that most,
but not necessarily all, self-modifying code tricks work. So, if you
test ExecBase->AttnFlags for 68000, and avoid the self modifying code
if you find you're not running on the 68000.
>Assuming for the sake of argument that I have a good reason to do such
>a thing (and there's a good chance I don't), can I do it without risking
>future compatibility?
Well, as you said, there's a good chance that you don't. An extremely good
chance. Because self-modifying code is never necessary. Sometimes it'll
allow a very specific thing to be done faster. In the general case, it's
foolish to risk limiting your product's market to old Amigas just to make
things go slightly faster. Providing redundant routines for the same operation
is probably the best thing you can do. As long as Motorola doesn't change the
68000 (which they certainly could, since they don't support self-modifying
code either, but probably won't, since they have better things to do), you're
OK if you run correct code when you find a 68020 or better in charge.
>What I envision is an operating system call to clear the instruction cache,
>or do nothing if there is no cache. Surely something like this is done by
>the loader, right?
Well, there is an OS call to clear the caches in 2.0, but that's still
something you shouldn't use execept when necessary. And you should realize
just what self-modifying code actually is. If you're choosing one of
several subroutines, you most likely aren't self-modifying. Assignment of
function pointers is done by hand in C all the time, and C++ actually
formalizes a similar mechanism via its virtual function mechanism. The
problem of self-modifying code occurs, from an application's point of view,
when the application runs through a code chunk, modifys that code chunk, and
then runs through it once again.
>Please, don't tell me the evils of self-modifying code, I'll only use it if
>I have to. Pretend this question is entirely academic.
My advice is to never use self modifying code, but also to make sure you
really know what constitutes self modifying code.
--
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
{uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy
"I have been given the freedom to do as I see fit" -REM
Technical Details
Message-ID:
<13091@cbmvax.commodore.com>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!cbmvax!davehReferences:
<293@smosjc.UUCP> <20214@grebyn.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: Self Modifying Code! Keywords: help, danger, cache, no flames Message-ID: <13091@cbmvax.commodore.com> Date: 6 Jul 90 20:44:49 GMT References: <293@smosjc.UUCP> <20214@grebyn.com> Reply-To: daveh@cbmvax (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 45