Dear "J. William Campbell",
In message <4ddefdbc.7050...@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.
> 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 ==.
> 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.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You can only live once, but if you do it right, once is enough.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
