From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1411330.QJAbfBr5F9@blitz> References: <1411330.QJAbfBr5F9@blitz> Date: Sat, 5 May 2012 18:48:37 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0015175cbab28cc1b804bf4da513 Subject: Re: [9fans] integer width on AMD64 (was: Re: AMD64 system) Topicbox-Message-UUID: 841c95b2-ead7-11e9-9d60-3106f5b1d025 --0015175cbab28cc1b804bf4da513 Content-Type: text/plain; charset=UTF-8 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. --0015175cbab28cc1b804bf4da513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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&= #39;t care, it doesn't matter.
it's quite difficult to de= cide automatically (eg, in a compiler) into which category a program falls.=
a compiler can't easily detect that a program expected 32 bits onl= y 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 program= s for integer operations),
but pointers are 64 bits, it's eas= y 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 fe= w such cases in the plan 9 code, and
thanks to the compiler diagn= ostic, we know exactly where they are and whether they matter, and have
converted them to use uintptr.

if it's pe= rformance 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 line= s will contain
more values, and several will be fetched at once when cache lines are = filled.

--0015175cbab28cc1b804bf4da513--