64-bit/32-bit compatibility

64-bit/32-bit compatibility

Posted Jan 21, 2006 10:02 UTC (Sat) by mingo (subscriber, #31122)
In reply to: 64-bit/32-bit compatibility by roelofs
Parent article: The high-resolution timer API

There are two "models". Every architecture picks a model at build-time, and sticks to it - the model's format is compiled into the kernel, and ktime inline functions behave differently in both models.

the first one is the 'scalar' model, which is used on 64-bit platforms, where the 64-bit value contains nanosec values, and if we ever get seconds values from userspace, it's converted into nanosecs.

the second is the 'union' model, where the 64-bit word is split into two 32-bit fields, the upper one holds seconds, the lower one nanoseconds. ktime_t values are always in 'normalized' form: the lower 32-bit must only contain values up to 10^9. (I.e. the range 0x3b9aca00-0xffffffff is excluded from the lower 32-bits, only range 0x00000000-0x3b9ac9ff is allowed.) The 64-bit word can also be accessed as a whole, via a union field in the ktime_t structure.

you might ask: what is the win opposed to having two separate 32-bit fields? Even though values always have to be normalized after operations on them (addition, subtraction), it's still beneficial to do arithmetics on the 64-bit field:

/* add 'delta' to 'ktime' */

ktime.tv64 += delta.tv64;
if (ktime.nsec >= 1000000000) {
ktime.nsec -= 1000000000;
ktime.sec++;
}

note that in the above op there is no division nor multiplication, and since both ktime values were normalized, only a single-step normalization is needed afterwards.

---

(Log in to post comments)