Re: [9fans] integer width on AMD64 (was: Re: AMD64 system)

[Charles Forsyth <charles.forsyth@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

many existing C programs (and not just on Plan 9) think long is 32 bits, or
don't care.
those that do care don't work. for those that don't care, it doesn't matter.
it's quite difficult to decide automatically (eg, in a compiler) into which
category a program falls.
a compiler can't easily detect that a program expected 32 bits only and
will malfunction with 64.
libflate was full of that, but it wasn't the only one. of course, in time,
those can be changed to using
u32int (or u64int) to make intentions clear.

by contrast, if long remains 32 bits (thus satisfying most existing
programs for integer operations),
but pointers are 64 bits, it's easy for a compiler to spot conversion of a
pointer to an integer type that
is too small, and the plan 9 compilers will do that. there are very few
such cases in the plan 9 code, and
thanks to the compiler diagnostic, we know exactly where they are and
whether they matter, and have
converted them to use uintptr.

if it's performance you're worried about, for programs that don't care
about width, i'd expect 32 bits at least
to match performance with 64 bits (if there's a measurable difference). for
one thing, cache lines will contain
more values, and several will be fetched at once when cache lines are
filled.

[-- Attachment #2: Type: text/html, Size: 1495 bytes --]