OK !
>.......
.........<
A BRIEF READ
-----------------------------------------------------------------------------------------------------------
Architectural implications
Processor registers are typically divided into several groups: integer, floating-point, SIMD, control, and often special registers for address arithmetic which may have various uses and names such as address, index or base registers. However, in modern designs, these functions are often performed by more general purpose integer registers. In most processors, only integer and/or address-registers can be used to address data in memory, the other types cannot. The size of these registers therefore normally limits the amount of directly addressable memory, even if there are registers, such as floating-point registers, that are wider.
Most high performance 32-bit and 64-bit processors (some notable exceptions are most ARM and 32-bit MIPS CPUs) have integrated floating point hardware, which is often but not always, based on 64-bit units of data. For example, although the x86/x87 architecture has instructions capable of loading and storing 64-bit (and 32-bit) floating-point values in memory, the internal data and register format is 80-bit wide. In contrast, the 64-bit Alpha family uses a 64-bit floating-point data and register format (as well as 64-bit integer registers).
Currently, most proprietary x86 software is compiled into 32-bit code, not 64-bit code, so it does not take advantage of the larger 64-bit address space or wider 64-bit registers and data paths on x86 processors, or the additional registers in 64-bit mode. However, users of most RISC platforms, and users of free or open source operating systems (where the source code is available for recompiling with a 64-bit compiler) have been able to use exclusive 64-bit computing environments for years. Not all such applications require a large address space nor manipulate 64-bit data items, so they wouldn't benefit from the larger address space or wider registers and data paths. The main advantage to 64-bit versions of such applications is the ability to access more registers in the x86-64 architecture.
x86-based 64-bit systems sometimes lack equivalents to software that is written for 32-bit architectures. The most severe problem in Microsoft Windows is incompatible device drivers. Although most software can run in a 32-bit compatibility mode (also known as an emulation mode, e.g. Microsoft WoW64 Technology for IA64) or run in 32-bit mode natively (on AMD64), it is usually impossible to run a driver (or similar software) in that mode since such a program usually runs in between the OS and the hardware, where direct emulation cannot be employed. Because 64-bit drivers for most devices were not available until early 2007, using 64-bit Microsoft Windows operating system was considered impractical. However the trend is changing towards 64-bit computing as most manufacturers provide both 32-bit and 64-bit drivers nowadays. Though Microsoft Windows systems may have problems with the drivers availability due to the manufacturers ignoring this architecture then it must be noted that linux/unix operating systems do not have such problems since driver is only a compile away from 64 bit version.
Because device drivers in operating systems with monolithic kernels, and in many operating systems with hybrid kernels, execute within the operating system kernel, it is possible to run the kernel as a 32-bit process while still supporting 64-bit user processes. This provides the memory and performance benefits of 64-bit for users without breaking binary compatibility with existing 32-bit device drivers, at the cost of some additional overhead within the kernel. This is the mechanism by which Mac OS X enables 64-bit processes while still supporting 32-bit device drivers.
Converting application software written in a high-level language from a 32-bit architecture to a 64-bit architecture varies in difficulty. One common recurring problem is that some programmers assume that pointers have the same length as some other data type. These programmers assume they can transfer quantities between these data types without losing information. Those assumptions happen to be true on some 32-bit machines (and even some 16-bit machines), but they are no longer true on 64-bit machines. The C programming language and its descendant C++ make it particularly easy to make this sort of mistake. Differences between the C89 and C99 language standards also exacerbate the problem [11]
To avoid this mistake in C and C++, the sizeof operator can be used to determine the size of these primitive types if decisions based on their size need to be made, both at compile- and run-time. Also, the <limits.h> header in the C99 standard, and numeric_limits class in <limits> header in the C++ standard, give more helpful info; sizeof only returns the size in chars. This used to be misleading, because the standards leave the definition of the CHAR_BIT macro, and therefore the number of bits in a char, to the implementations. However, except for those compilers targeting DSPs, "64 bits == 8 chars of 8 bits each" has become the norm.
One needs to be careful to use the ptrdiff_t type (in the standard header <stddef.h>) for the result of subtracting two pointers; too much code incorrectly uses "int" or "long" instead. To represent a pointer (rather than a pointer difference) as an integer, use uintptr_t where available (it is only defined in C99, but some compilers otherwise conforming to an earlier version of the standard offer it as an extension).
Neither C nor C++ define the length of a pointer, int, or long to be a specific number of bits. C99, however, stdint.h provides names for integer types with certain numbers of bits where those types are available.
in most programming environments on 32-bit machines, pointers, "int" types, and "long" types are all 32 bits wide.
However, in many programming environments on 64-bit machines, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an LP64 data model. Another alternative is the ILP64 data model in which all three data types are 64 bits wide, and even SILP64 where "short" variables are also 64 bits wide[citation needed]. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit. "LL" refers to the "long long" type, which is at least 64 bits on all platforms, including 32-bit environments.
Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP-UX, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types.
Note that a programming model is a choice made on a per-compiler basis, and several can coexist on the same OS. However typically the programming model chosen by the OS API as primary model dominates.
Unfortunately, the ILP64 model does not provide a natural way to describe 32-bit data types, and must resort to non-portable constructs such as __int32 to describe such types. This is likely to cause practical problems in producing code which can run on both 32 and 64 bit platforms without #ifdef constructions. It has been possible to port large quantities of code to LP64 models without the need to make such changes, while maintaining the investment made in data sets, even in cases where the typing information was not made externally visible by the application.
Most ints in existing programs can remain as 32 bits in a 64-bit environment; only a small number are expected to be the same size as pointers or longs. Under LP64 very few instances need to be changed.
With ILP64, most ints need to change to __int32. However, __int32 does NOT behave like 32 bit int. Instead __int32 is like short in that all operations have to be converted to int (64-bits, sign extended) and performed in 64-bit arithmetic.
So, __int32 in ILP64 is not the same as int in ILP32, nor the same as int in LP64. These differences will predictably cause subtle hard-to-find bugs.
ok so... you ask
The programming model choice described in the last section can be made individually by each of the system vendors, or jointly through an implementers agreement amongst multiple vendors. I argue that the application developers, are best served if there is a single choice widespread in the emerging 64-bit systems. This removes a source of subtle errors in porting to a 64-bit environment, and encourages more rapid exploitation of the technology options.
Also, this is an opportune moment to make such a direction is all.
ILP32 or ILP64 or LP64 what model do you want to stay at.
Finsih the other half of 64 including the missed pieces ported from 32 and you will have a 110% winner
