peltz@cerl.uiuc.edu (Steve Peltz) (11/09/89)
In article <8632@microsoft.UUCP> w-darekm@microsoft.UUCP (Darek Mihocka) writes: >Is the 68000 (or higher) smart enough to not perform a write operation on >commands like BSET, BCLR, ASL, ROL, ROR, LSL, etc... if the value that it >is about to write is the same value it just read. It isn't even smart enough to not read the original value when you execute a CLR instruction! A MOVEQ #0,xxx is much faster than a CLR.L xxx, for example. I believe this was fixed in the 68020 and above. The only case where this fix would break anything is if an i/o port was expecting the read followed by write. In almost all cases, the code would be using MOVE instead of CLR specifically to avoid reading the port, so that wouldn't cause a problem. As someone else already pointed out, with BSET etc. an i/o port might be depending on the read-then-write. In my opinion, it should have been left undefined whether it wrote to it or not, with the only safe operation to an i/o port being a MOVE. Note that depending on how the microcode and internal registers are organized for any particular processor, it may actually take more time to do the test than it does to simply write it out unconditionally (or they may simply run out of room in the microcode!). -- Steve Peltz (almost) CFI-G "Monticello traffic, Glider 949 landing 18, full stop"