Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!sumax!thebes!quick!srg From: srg@quick.COM (Spencer Garrett) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <4849@quick.COM> Date: 29 Aug 89 23:45:14 GMT References: <5990@pt.cs.cmu.edu> Organization: Quicksilver Engineering, Seattle Lines: 29 Summary: Instruction restart can get nasty on a CISC Instruction restart on a CISC can cause grevious problems when there are side effects to reading or writing certain addresses. Consider, for instance, the following instruction which reads a device register and stores it into memory. (This is 68xxx code.) movb a0@(2),_memloc This instruction could fault after the read of the device register if either _memloc or the tail end of the instruction isn't resident. Many devices will clear interrupt bits when you read their status register or shift in the next byte when you read their data register, so repeating the entire instruction doesn't give equivalent results. One could code this (in C) as register char temp; temp = dev->reg; memloc = temp; and hope the compiler doesn't optimize too agressively, or maybe (someday) use "volatile" to indicate to the compiler that dev->reg is special, but I wouldn't bet any current compilers take instruction restart into account when generating code for volatile data fetches. For the moment this isn't a major problem, since Unix device drivers usually run in physical memory (so any fault that occurs is fatal, and won't be rerun), but I long for the day when this isn't necessarily so.