Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!diku!thorinn
From: thorinn@diku.UUCP (Lars Henrik Mathiesen)
Newsgroups: net.arch
Subject: Re: Storing into pipeline (was Delayed Loads)
Message-ID: <2623@diku.UUCP>
Date: Mon, 22-Sep-86 15:12:21 EDT
Article-I.D.: diku.2623
Posted: Mon Sep 22 15:12:21 1986
Date-Received: Mon, 22-Sep-86 21:24:53 EDT
References: <5100133@ccvaxa> <1115@masscomp.UUCP> <697@mips.UUCP>
Organization: DIKU, U of Copenhagen, DK
Lines: 19

In article <697@mips.UUCP> mash@mips.UUCP (John Mashey) writes:
>In article <1115@masscomp.UUCP> hank@masscomp.UUCP (Hank Cohen) writes:
>>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. [Obviously, you must
>be able to create executable code, but you can require a system call to
>indicate weird cache manipulations.]

An example of this is the VAX *family* architecture - the instructions executed
are "UNPREDICTABLE" if they were written since last context switch OR return
from interrupt; this allows demand paging, but not self-modifying code, (at
least not without faking an rti). (ref: VAX-11 Architecture Reference Manual,
rev. 6.1, section 2.7: Separation of Procedure and Data.)
--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark		..mcvax!diku!thorinn