Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!hp4nl!philapd!ssp1!roelof From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Summary: Not a rumour Message-ID: <255@ssp1.idca.tds.philips.nl> Date: 11 Sep 89 17:57:05 GMT References: <1790@cs-spool.calgary.UUCP> Organization: Philips Telecommunication and Data Systems, The Netherlands Lines: 27 In article <1790@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: |In article <3267@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: |>Now, my point: how about shared memory? (SysV-type shared memory, not |>multi-processor-type shared memory.) With instruction restart, the value in |>$300 could have changed, while, with instruction continuation, it doesn't |>matter. How do various OS's and hardwares handle it? |Gad. How about a hardware FIFO? How about a serial receive buffer on |your generic serial chip? I really doubt this rumour, unless some special |trick (like maybe modifying the actual instruction in the code cache |before the restart to skip the allready done part, yes, sorry, sick idea) |was to be done, it just has too many differences from the current 030 |and 020/851 setup to be possible. | I'm pretty sure the 68040 will use instruction restart and yes, some read accesses can occur more than once because of the instruction restart model. What the solution is for your hardware fifo is something I'm still trying to figure out :-) I don't see the shared memory as a real problem since if you had accessed that location just an instant later the value would have changed anyway. I doubt that any application would depend on such microsecond timings. -- wiskunde: Dutch for mathematics. Literally: Knowledge of certainty wis: certainty kunde: Knowledge Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof