Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch
Subject: Re: Instruction (dis)continuation (
Message-ID: <265@ssp1.idca.tds.philips.nl>
Date: 2 Oct 89 12:00:44 GMT
References: <2353@oakhill.UUCP> <261500010@S34.Prime.COM> <34701@apple.Apple.COM> <2451@wyse.wyse.com> <477@ctycal.UUCP>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 56

In article <477@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
>
>As an alternative, do the following:
>    MOV       addr1,R1      (ie Move data found at addr1 into register R1)
>    STO       R1,addr2      (store register contents in addr2)
>Even if the fault occurs during the read of addr1 (a bit odd since
>peripheral memory locations are usually non-pageable) then the access will
>still only occur once.  If the page fault occurs during the store then
>we similarly don't care since addr2 will also only be accessed once (in my
>example its just memory but could conceivably be another peripheral).
>
That the peripheral memory location could page fault is only part of
the problem (and as you rightly point out perhaps a not very realistic
one at that).

Because (out of order) pre-fetching can be done you can have:

 	MOV	any_old_addr1,any_old_addr2
	MOV	peripheral_addr,R1

Because (out of order) pre-fetching can be done you can have peripheral_
addr1 being accessed before one of the any_old_addresses.
Now if either of the any_old_addresses are not accessible and (out of order)
prefetching is allowed you can have a problem even if peripheral_addr _is_
accessible.

And how about dual pre-fetching for both taken and not taken path streams?
(Again a 68040 special).
If the memory-mapped io instruction is the first instruction in each of
the branches then in my book you've got a problem.
 
I'ld like to bring back in memory a quote from an execellent posting from 
Steve Melvin from the University of California Berkeley 2 weeks ago on this 
subject:

"...there are many sides to this issue, but I don't
think it's fair to say that load/store *architectures* make life simpler for
systems programmers; using simple loads and stores is pretty much of a
requirement as has been pointed out, regardless of whether memory to memory
instructions exist.  But which instructions are used and what restrictions
need to be placed on them is secondary to the real issue here.  The bottom
line for an I/O instruction is that it represents a synchronization point from
the perspective of the hardware.  That is, all unconfirmed operations have to
be verified before the I/O operation can take place.  All predicted branches
have to be confirmed, all pending memory reads and writes have to at least be
translated to verify that they can be completed and all operations that can
generate exceptions have to be executed.  Generally this means that the entire
pipeline has to be drained.  This is a simple fact, there is no way around it
(at least not as long as reads have side-effects and there is no "undo"
function.)"

-- 
"Geld groeit me niet op de rug." Literally: "Money doesn't grow on my back."
(Often overheard at the supermarket counter from mothers to their kids.)
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof