From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I3BUu-0001Fx-9r for qemu-devel@nongnu.org; Tue, 26 Jun 2007 09:54:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I3BUt-0001FX-N1 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 09:54:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I3BUt-0001FU-Io for qemu-devel@nongnu.org; Tue, 26 Jun 2007 09:54:23 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I3BUs-0006VM-VN for qemu-devel@nongnu.org; Tue, 26 Jun 2007 09:54:23 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts Date: Tue, 26 Jun 2007 14:54:16 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706261454.16852.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > With proper support from the compiler, it's theoretically possible on > x86-64 systems to use 32-bit pointers in long mode. I'm not aware of any= =20 systems that use this, however. Vxworks does. We just finished doing the gcc port. From a software point of= =20 view ILP32 mode on a 64-bit CPU/OS is indistinguishable from regular 32-bit= =20 mode. > =A0I'm not sure how big longs are on those systems, but I > wouldn't be surprised if longs are 32-bits or 64-bits and pointers > 128-bits. I really hope not. > > > One from me, if you like... Just don't use the "unsigned long" type. > > > The intptr_t type would be better (it's 32-bit on 32-bit systems and > > > 64-bit on 64-bit systems). > > > > Nice, I didn't know about that. But how is this any different from > > unsigned long? The story behind this is that ISO C89 requires that "long" be at least as b= ig=20 as a pointer (ie. "void *"). The actual requirement is that it be possible = to=20 store a pointer in a standard integer type, and "long" is the largest=20 standard integer type. Unfortunately C99 relaxed this requirement, and allowed abominations like t= he=20 win64 ABI. This means you have a choice: Write standard conforming code (long) that wo= rks=20 on all known systems except win64, or use features that do't exist on many= =20 systems. IIRC C99 types like intptr_t are not supported on several fairly=20 common unix systems. It's ironic that the one system that requires C99 features explicitly does = not=20 (and probably never will) have full C99 support. Paul