[email protected] said: > That's perfect if it works like it seems it should. The problem with modern > CPUs is finding an instruction sequence that does the read-write-read in > that order, allowing each to complete before doing the next. The write is > the biggest problem. Writes are often buffered, and even when you can find > an instruction which stalls until it clears ...
I'm far from a wizard in this area, but I used to work with people who were. The rules for things like PCI cover that case. If you do something like write to a register to clear an interrupt request, you have to follow it by a read to that register or one close to it. As you hippity-hop through bridges and such, the read gets trapped behind the write and doesn't happen until the write finishes. > When using the CPU cycle counter as a system clock source it is common to > find that the two reads in a read-write-read sequence are only a cycle or > two different even when you know the write is crossing an interconnect with > 10's of nanoseconds of latency (not that 10's of nanoseconds is bad...). That's reasonable if the read-write-read were to cycle-counter, someplace-else, and cycle-counter. The write has been started. It's in the piepline, but you haven't told the memory system that you need it to finish. Try read-write-read-read where the outer reads are to the cycle counter and the inner write-read both go to the same IO device. -- These are my opinions. I hate spam. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
