From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 5 May 2012 13:42:03 -0400 To: 9fans@9fans.net Message-ID: <63e3e767f10817e7dc730180cf1605e5@kw.quanstro.net> In-Reply-To: <1411330.QJAbfBr5F9@blitz> References: <1411330.QJAbfBr5F9@blitz> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] integer width on AMD64 (was: Re: AMD64 system) Topicbox-Message-UUID: 8417232a-ead7-11e9-9d60-3106f5b1d025 > pardon silly question, but... why, on 64bit machine, P9 uses 32bit ints and > longs? > > my impression is, int was supposed to match machine's preferred (best > performance etc.) integeral datatype, and long was supposed to be enough to > hold a pointer? (i.e., sizeof(long) >= sizeof(void*)) charles could provide a more complete answer, but http://en.wikipedia.org/wiki/C_data_types is a good summary of the general rules. long is only >= 32 bits. there are no other restrictions. it does not have to be big enough to hold a pointer. while the original idea for int was that it was the natural word size, things are no longer quite that simple. int must be >= 16 bits, so if you were to do c on, say, a 15 bit machine, int would need to be simulated to be standard, but i doubt anyone would bother slaving to the standard so. and on a x86_64 what is the "natural size" of an integer? since it's not risc, there is no penalty for doing 32-bit calcuations. heck, the docs call a 4-byte integer a "double word" and an 8-byte integer a "quad word". i suppose you could make an argument for 16-bit int on intel! - erik