Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!ucsd!ogccse!blake!uw-beaver!ubc-cs!alberta!calgary!enme3!deraadt From: deraadt@enme3.ucalgary.ca (Theo Deraadt) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <1790@cs-spool.calgary.UUCP> Date: 5 Sep 89 15:14:54 GMT Sender: news@calgary.UUCP Reply-To: deraadt@enme3.UUCP (Theo Deraadt) Organization: U. of Calgary, Calgary, Alberta, Canada Lines: 14 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.