Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Self-modifying code
Message-ID: <1989Oct13.174542.940@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1080@mipos3.intel.com> <1989Oct11.013553.3893@esegue.segue.boston.ma.us> <527@eedsp.gatech.edu> <1989Oct12.184824.2465@esegue.segue.boston.ma.us> <46852@bbn.COM>
Date: Fri, 13 Oct 89 17:45:42 GMT

In article <46852@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>>>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?
>
>All the PDP/11's that do prefetching or instruction caching DO check
>for possible writes to the next instruction, and flush/refetch/etc to
>make it work, simply because it isn't specified NOT to work...

I think that can fairly be considered an oversight by the 11's original
designers.  IBM did not make the same mistake on the 360 series.  If you
read the 360/370 "Principles of Operation" -- still a model of how to
document a processor -- you will find quite a bit of very carefully
phrased verbiage describing *exactly* what you can and cannot assume
about self-modifying code.  Even that is rather more generous than a
modern designer would be, though, since the 360 series arose at a time
when self-modifying code was still common practice.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu