From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I30PB-0006Vd-Dg for qemu-devel@nongnu.org; Mon, 25 Jun 2007 22:03:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I30PA-0006VR-FB for qemu-devel@nongnu.org; Mon, 25 Jun 2007 22:03:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I30PA-0006VO-AU for qemu-devel@nongnu.org; Mon, 25 Jun 2007 22:03:44 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I30P9-0006hB-Qs for qemu-devel@nongnu.org; Mon, 25 Jun 2007 22:03:43 -0400 Received: by nz-out-0506.google.com with SMTP id 16so1017095nzp for ; Mon, 25 Jun 2007 19:03:42 -0700 (PDT) Message-ID: Date: Mon, 25 Jun 2007 22:03:41 -0400 From: "Karl Magdsick" Subject: Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200706252226.50773.michal.schulz@gmx.de> 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 Depends on if you're using the LP64 model (64-bit Linux, many other *NIX) or the LLP64 model (Win64). I guess Microsoft decided there was more code written for their system that assumed longs were 32-bit than code that assumed pointers could be stored in (unsigned) longs. For 64-bit MS Windows code, pointers are 64-bit, longs are 32-bit, and long longs are 64-bit. With proper support from the compiler, it's theoretically possible on x86-64 systems to use 32-bit pointers in long mode (16 general purpose 64-bit registers). (There's an instruction prefix that will cause the CPU to perform 32-bit pointer calculations in the 64-bit address space.) I'm not aware of any systems that use this, however. (Getting the speed boost from fewer register spills while not paying the space cost of 64-bit pointers sounds very attractive in many applications, though.) I'm not sure if any of the C standards forbid longs being larger than pointers. There are even more strange beasts out there. I think IBM AS/400 LIC uses 128-bit pointers. (The LIC code gets compiled to native code and appended to the LIC binary the first time the LIC binary is run on a new system, and IBM decided to build a lot of future compatibility into LIC.) I'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. In any case, I'm a big fan of using more descriptive types (such as the C99 types) to express yourself more clearly for both the compiler and for other coders. Cheers, -Karl On 6/25/07, Blue Swirl wrote: > On 6/25/07, Michal Schulz wrote: [snip] > > 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?