64-bit/32-bit compatibility [LWN.net]

64-bit/32-bit compatibility

Posted Jan 21, 2006 1:00 UTC (Sat) by roelofs (subscriber, #2599)
Parent article: The high-resolution timer API

On 64-bit systems, a ktime_t is really just a 64-bit integer value in nanoseconds. On 32-bit machines, however, it is a two-field structure: one 32-bit value holds the number of seconds, and the other holds nanoseconds. The order of the two fields depends on whether the host architecture is big-endian or not; they are always arranged so that the two values can, when needed, be treated as a single, 64-bit value.

Perhaps I'm missing something, but I was always under the impression that the number of nanoseconds in a second (10⁹) was not actually a power of two. Even if it were, it's not 2³²...

So how do we reconcile the two-32-bit-values-as-one-64-bit-value problem? Does the nanoseconds half count up monotonically for 4.3 seconds, at which point some weird adjustment is made? (No, that would seem to be incompatible with the 64-bit view of things.) Is the "seconds" half not really seconds but actually a count of 4.3[etc.]-second intervals? Or is the "nanoseconds" half not really nanoseconds but actually a count of 1/4.3[etc.]-nanosecond super-micro-jiffies?

Am I missing something obvious? (I didn't get much sleep last night, so I might be...)

Greg

(Log in to post comments)

64-bit/32-bit compatibility

Posted Jan 21, 2006 10:02 UTC (Sat) by mingo (subscriber, #31122) [Link]

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.

64-bit/32-bit compatibility

Posted Jan 21, 2006 18:43 UTC (Sat) by roelofs (subscriber, #2599) [Link]

Ah, I see now--thank you. I almost had the right idea, but I read too much into Jon's "single 64-bit value" comment.

Greg

64-bit/32-bit compatibility

Posted Jan 31, 2006 21:37 UTC (Tue) by efexis (guest, #26355) [Link]

heh, you could even use MMX or other SIMD to work on both halfs with one instruction ;-)

64-bit/32-bit compatibility

Posted Mar 20, 2006 16:01 UTC (Mon) by jengelh (subscriber, #33263) [Link]

And floating point is unfortunately a no-go in kernelspace.