On 5/27/2011 12:28 AM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message4DDEFDBC.7050403@comcast.net you wrote:
I really STRONGLY disagree with this statement. If you actually needed 64 bit variables, fine use them. But as I have already shown, you do not need them in general. We are computing a 32 bit result. There is some entropy argument that says you shouldn't need 64 bits to do so. Another way to look at it is that converting the top 32 bit word and the bottom 32 bit word to ms separately can be easier than doing them both together at once. However, as we will see below, I do agree we need two 32 bit words to make this process go smoothly. I just don't agree that they should/will constitute a 64 bit binary word. See below.
And I disagree with this.
Hi Wolfgang, OK, I hear you.
Yes, that is the problem. I have come to the view that two 32 bit words are the best approach. Note that the lsb may actually not fill the full 32 bits. The top 32 bits are the rollover count and the bottom 32 bits are the current counter. If the counter is a full 32 bits, so much the better. Again, one could put them together inside the interrupt routine , but it is easier to check for a changed value if you don't do this.
It's even easier if you use a single 64 bit variable, because then you can simply use ==.
In general, no you can't, or at least you probably don't want to. . If you are reading a 64 bit performance counter, it is quite likely that you cannot read it twice without the "clock" having "ticked". If the CPU executes 1 instruction (or fewer(if an SPR/memory reference is involved?) per performance counter tick, which is the goal of the performance counter, == is an infinite loop!!!! A similar condition exists if you are combining a software counter with a fairly fast hardware counter. It might require flipping the hardware counter (if it is a down counter) and a 64 bit multiply add, which must be done in software/a subroutine if the cpu has no 64 by 64 multiply. By the time that is done, the timer LSB may have ticked. Consider the m68K case.
Otherwise, you have to check both words. It also makes the isr faster.
Drop any thoughts about "make FOO faster" for now, please. Especially at this stage it is much more important to have a simple and clean design. If split in two variables, even a simple read access will turn into code like
do { upper = timebase_upper; lower = timebase_lower; } while (upper != timebase_upper);
This is not exactly as simple as you claimed.
True, but if you look at a lot of 64 bit performance counters, that is EXACTLY what the handbook book recommends on how to read them. There is no atomic way to read them both at once, and reading one half doesn't freeze the other half. This code is also required if timebase_upper is altered in the interrupt routine. YMMV, but in a lot, dare I say most, cases this is required anyway. And while the code is more complex than a simple assignment statement, it is not very complex.
Best Regards, Bill Campbell
Best regards,
Wolfgang Denk