davidb@inmos.co.uk (David Boreham) (05/29/90)
I think that the reason why the 68K and '11 do a read/modify/write on clear instructions is because they use the XOR ALU function to perform the clear. The microcode simply performs a read, XOR with its self, then write. On machines with no clear, XOR is a good bet instead. This used to be common in Z80 code and I'm sure in many other machines. On the subject of ``errant memory cycles'' I think that most CPUs perform these somewhere or other. For instance a common one with transputers is that when a block move is timesliced (by the microcode), the instruction is restarted possibly by performing a second read to a location perviously accessed. This means that using the block move instruction on FIFO chips can get really interesting :) David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos.com!davidb +44 454 616616 ex 547 | Internet: davidb@inmos.com
henry@utzoo.uucp (Henry Spencer) (05/31/90)
In article <7101@ganymede.inmos.co.uk> davidb@inmos.co.uk (David Boreham) writes: >I think that the reason why the 68K and '11 do a read/modify/write >on clear instructions is because they use the XOR ALU function to >perform the clear... I can't answer for the 68k, but on the 11 end: "XOR? What's that?". The early 11s didn't have an XOR at all. Many 11s did r-m-w on CLR simply because all the other single-operand instructions in that category needed r-m-w, and it saved microcode space and time to do them all the same way, with only the ALU operation chosen specially for each one. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu