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