> I don't know the range of numbers that we deal with, but floating numbers > may not exactly represent integers. It is possible to construct integers > > 2^53 which are not exactly representable, I think (2^53)+1 cannot be > represented exactly. In fact, in such a case, 'a++' might end up equal to > 'a' itself.
I'm pretty sure that we won't run into this. There are 31.5 Million seconds/year. Or 31.5e15 nanoseconds per year. 2^53 is 9.0e15. That means that you'd have to increment that counter every nanosecond to hit the problem in four months. Now in theory, if you were to increment by 1000 once per nanosecond for 3 hours and then you tried to increment by one, the 1 would be lost. The question then becomes, would that just be noise? (I'd think so). > Now such huge numbers can be reached if the simulation were to run for > months (assuming only increments by one are made). Therefore it might not > be a problem. But floating point addition is costly compared to integer > addition, then why go for floating point? Is it really true that floating point adds are much more expensive than integer ones these days? Anyway, I'm quite happy for you to try changing it to an int64_t and thoroughly test the results. I think that Counter was once indeed int64_t. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
