🚀 go-pugleaf

In article <697@mips.UUCP> mash@mips.UUCP (John Mashey) writes:
>In article <1115@masscomp.UUCP> hank@masscomp.UUCP (Hank Cohen) writes:
>>In article <5100133@ccvaxa> aglew@ccvaxa.UUCP writes:
>>>
>>>There has been some discussion of delayed branches in this newsgroup;
>>>can anybody say anything useful about delayed load/stores? Ie. memory
>>>access functions that are defined to work the same way as delayed
>>>branches, not to take effect until after a few more instructions.
>>
>>An even thornier problem arises if you allow self modifying code to be run
>>on your machine. i.e. You build a real Von Neuman machine.  The problem of
>>detecting stores into the instruction stream of  a pipelined processor is
>>even more difficult than detecting data interdependencies.
>
>A pleasant thing about doing an architecture from scratch is the ability to
>forbid the use of stores into the instruction stream.

For an example of something useful to do with self-modifying code on a
pipelined machine, see September Dr. Dobbs Journal, pp 114.  Motorola
gave the capability to forbid stores in the code area, but few people
use it.  (Is anybody out there using the FC lines to write-protect
code memory?)  If Mota had been on time with an MMU that utilized the
FC lines, they would have been useful, but most designers ignored
them.

I think the best policy is "caveat emptor", let the programmer beware!
Note that an explicit cache flush should be provided on heavily
pipelined/cached machines that allow code writes.  The 68020 has this,
the 680[01]0 does not, but neither waste time *detecting* this
condition, which I agree with wholeheartedly.  The DDJ code cited
depends on the ability to change the opcode of the instruction that
has already been prefetched.
:::::: Artificial   Intelligence   Machines   ---   Smalltalk   Project ::::::
:::::: Jan Steinman		Box 1000, MS 60-405	(w)503/685-2956 ::::::
:::::: tektronix!tekecs!jans	Wilsonville, OR 97070	(h)503/657-7703 ::::::