Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!psuvax1!rutgers!cbmvax!cbmehq!cbmger!peterk
From: peterk@cbmger.UUCP (Peter Kittel GERMANY)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Code generation
Message-ID: <515@cbmger.UUCP>
Date: 16 Oct 90 14:41:21 GMT
References: <512@cbmger.UUCP> <14827@netcom.UUCP>
Reply-To: peterk@cbmger.UUCP (Peter Kittel GERMANY)
Organization: Commodore Bueromaschinen GmbH, West Germany
Lines: 25

In article <14827@netcom.UUCP> mcmahan@netcom.UUCP (Dave Mc Mahan) writes:
> In a previous article, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>>Again that old theme '(self) modifying code': When I think about it,
>>there HAS to be a clean way. How else could a debugger or a machine
>
>2.  The second method used works only with debug code in RAM.  The debugger is
>    instructed by the user to replace the instruction at the desired address
>    with an illegal instruction (usually, the ILLEGAL instruction itself!  This
>    is a real op-code, haveing a value of 0x8AFC.  Look it up!)

Stop. Here you again poke simply two bytes into RAM and hope they will
get executed. But in the days of (separate) data and instruction caches
you can't be sure that the CPU will see this!

So again, the only official method to bring executable code into
memory and execute it there is to LoadSeg() it. So this function
must be the BIG exception that is capable of some magic trick to
circumvent this cache problem under any circumstance.
Simple question: How?
2nd question: If we know this trick, would it be also applyable
for our own hacks/monitors/code generators?

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk