64 bit

[John Ralls]

On Jul 25, 2014, at 8:50 PM, Robert Heller <heller at deepsoft.com> wrote:

> At Fri, 25 Jul 2014 14:03:19 -0500 Jeffrey Ollie <jeff at ocjtech.us> wrote:
> 
>> 
>> On Fri, Jul 25, 2014 at 1:34 PM, John Dablin <jdablin at ntlworld.com> wrote:
>>> On 25/07/14 08:46, John Ralls wrote:
>>>> 
>>>> It might be. I don't think anyone has tried. Mingw64 would be required.
>>>> Note that I also don't think that there's any good reason to, as GnuCash's
>>>> data fits easily in a 32-bit address space.
>>> 
>>> This is pure curiosity, but the maximum value of a 32 bit signed integer is
>>> 2,147,483,647, so if that were cents it would represent $21,474,836.47. My
>>> bank balance will never grow that high, worse luck, but a medium sized
>>> business might have totals of that order. Does Gnucash use multi-word data
>>> types to handle this, or would it cause an error?
>> 
>> The 32 bits in a 32 bit operating system refers only to the amount of
>> address space (RAM) that a process can access.  It has nothing to do
>> with the number of bits in data elements used by a program, which can
>> be 64 bits, 128 bits, or even more.
> 
> It also refers to the integer CPU register size (and the native single1
> instruction ALU ops) and also refers to the width of the data bus (how many
> bit can be transfered in one cycle, although with modern '32-bit' processors
> this is somewhat meaningless, given caches and pipelines, and such). All
> *modern* 32-bit C/C++ compilers support 'long long int', which is 64-bits on a
> 32-bit machine. Most modern scripting languages also support (at least) 64-bit
> integers as well (and some have support for some flavor of 'bignum', which is
> an integer that has as many bits as it needs, dynamically growing as needed).
> 
> So yes, the only real hard limitation of a *modern* 32-bit processor (eg an
> Intel i686 type processor), is virtual address space, which is about 3.5G
> (about .5G is 'lost' to PCI address space). (The latest incarnation of the
> i686's include PAE, which includes x86_64/amd64 processors in 32-bit mode,
> which actually allows more *system* memory, but each *user-land process* is
> still limited to just under 4G.)
> 
> The only restriction with running 32-bit x86 apps on a x86_64 processor
> running a 64-bit operating system is the presence or absense of the 32-bit
> system libraries. Some of the latest 64-bit Linux distros don't bother to
> install the 32-bit libraries *by default*, but they can be optionally 
> installed if needed.  I'm guessing the 64-bit Windows 7 and 8 do install the 
> 32-bit libraries.  I don't know what MacOSX 10.9 does, but I believe up though 
> 10.8 has both 64 and 32 bit libraries.

We use MinGW on M$Win, which for the most part supplies its own 32-bit libraries for everything except low-level graphics, which are provided by a package called Cairo. Microsoft so far supplies both 64-bit and 32-bit libraries that Cairo can work with, so there's no problem there. Note that no-one has reported having built GnuCash with Microsoft compilers.

OSX supplies both 32-bit and 64-bit libraries in all SDKs up through OSX 10.10 (Yosemite) and has never indicated that they're going to stop doing so. I build the OSX bundle in 32-bit in order to support users with older machines which don't support 64-bit; I also build a PPC bundle for users with venerable antiques, so long as they can run OSX 10.5.

Linux packagers are free to build either 32-bit or 64-bit as they need. GnuCash builds and runs fine in 64-bit on Linux.

Regards,
John Ralls