Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!lotus!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <1989Oct12.184824.2465@esegue.segue.boston.ma.us>
Date: 12 Oct 89 18:48:24 GMT
References: <1080@mipos3.intel.com> <1989Oct11.013553.3893@esegue.segue.boston.ma.us> <527@eedsp.gatech.edu>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 21

In article <527@eedsp.gatech.edu> aaronb@lagrange (Aaron Birenboim) writes:
>In article <1989Oct11.013553.3893@esegue.segue.boston.ma.us> I wrote:
>>even the lowly 8086 can fetch up to 6 bytes ahead of where it is executing
>>[so if you store into the next instruction it will probably execute the
>>old version]
>Is this really true?  There isn't enough dependancy checking in the 8086
>instruction pipe to detect this type of operation, clear the pipe, and
>re-fetch the altered instruction, or some such corrective measure.

You bet there isn't.  Why waste all that logic to handle the .000001% of
programs that would want to store into the next instruction?  And you thought
the 8086 wasn't a RISC.  You can patch code reliably so long as there is a
branch executed between the patcher and the patchee, since all '86 processors
flush the prefetch queue on a branch.  The advisability of patching code
remains as dubious as ever, particularly on machines in the '86 series in
which the funky instruction encoding makes it tricky to identify the correct
location to patch.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
Massachusetts has over 100,000 unlicensed drivers.  -The Globe