[Pixman] RFC: Pixman benchmark CPU time measurement

[Ben Avison]

On Wed, 03 Jun 2015 08:40:37 +0100, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 02 Jun 2015 17:03:30 +0100
> "Ben Avison" <bavison at riscosopen.org> wrote:
>
>> If I were to make one change to gettimei() now, looking back, it would be
>> to make it return int32_t instead. This is because most often you'd be
>> subtracting two sample outputs of the function, and it's more often
>> useful to consider time intervals as signed (say if you're comparing the
>> current time against a timeout time which may be in the past or the
>> future). If gettimei() returns a signed integer, then C's type promotion
>> rules make the result of the subtraction signed automatically.
>
> Wasn't overflow well-defined only for unsigned integers?

You're right, I'd forgotten that aspect of C. To be fully portable, a
modulo-2^32-arithmetic comparison needs to be written

uint32_t time1, time2;
if (((time1 - time2) & (1u<<31)) != 0)

rather than

int32_t time1, time2;
if ((time1 - time2) < 0)

or

uint32_t time1, time2;
if ((int32_t) (time1 - time2) < 0)

even though the latter two are more readable and all three are actually
equivalent if you're using two's complement integers, which (nearly?)
everybody does nowadays.

Sometimes I wish C had an inbuilt modulo integer type. At the assembly
level for a lot of CPUs it's a third type of comparison with similar ease
of use as signed and unsigned comparisons, but it's a pain to express in
C.

Anyway, this doesn't change the fact that struct timeval currently uses
signed long ints, and will enter undefined behaviour territory in 2038. I
think it's reasonable to assume that in practice, tv_sec will actually
contain an unsigned long int value (albeit one that has been cast to
signed) after that, as that would break the least software.

Ben