Reasons For 64-bit: A Digest

Michael Stum wrote:

So - beside all that marketing hype - WHY should you care about 64 Bit?

First of all, you are of course, absolutely right about your observation that a 64-bit Pointer is twice the size (and thus twice the distance) of a 32-bit pointer. But this isn't the only factor.

I really wish the "64-bit Lobby" had made a digest of our arguments while we were fighting to get a native 64-bit compiler on the Road Map..

But as I recall Will DeWitt did a pretty good job of explaining the reasons. Eric Grange did well also.

If you google on:

64-bit registers memory group:*delphi* author:Will author:DeWitt

- you will get some cogent answers. Unfortunately you'll also need to wade through the "64-bit Wars", between the 64-bit Lobby and those opposing them, to get at the information. So here is a quick digest from the google search I mentioned above (from Will's posts and some of my own additions):

But in a nutshell,

- twice as many registers: double the number of general purpose registers and double the number of XMM registers.

- double the number of registers means(among other things) more data can be kept closer to the CPU for quick reuse and access.

- assembly programming assumptions on x64 that can't be made with x86 programming such as knowing such assembly constructs as (F)CMOVcc, CMPXCHG8B, MMX, and SSE/SSE2-- are standard on an x64 processor (not so on x86).

- Expanded address space so instead of being limited to 4 GB of memory you're limited to terabytes of memory. There are markets for these improvements. On the Home front: Networked Video (for the HOME!), 3-D Gaming; and the professional Graphics market will also play a role. On the server side, Several Application scenarios can take advantage of very large in-memory databases:
- financial analysis applications
- enterprise resource planning;
- decision support;
- scientific and engineering applications such as computational fluid dynamics or finite element analysis;
-etc.
So, in these cases in-memory processing compensates for the far greater latencies found in hard-drive and other mass storage devices...

- And, not least, PC and Chip vendors are phasing out 32-bit PCs. At that point, we Delphi developers will still be able to run our executables on 64-bit machine under WoW64; but we won't be able to fully benefit from the 64-bit architecture (more memory and easier to
access, new registers and more chances for optimization by the compiler
(not to mention yourself via BASM)). Meanwhile, our VC++ cousins will have a distinct competitive advantage, since they've had 64-bit VC++ compiler for over a year now... And 64-bit Linux C++ compilers have been available for at least two years... Now, having only a native 32-bit compiler in a 64-bit OS world, will put us Delphi developers in a very untenable position; because we will then be prey to any whims by MS that might decide to curtail 32-bit support on its 64-bit OSes at any time in the future. So *not* having a native 64-bit compiler on the Road Map would be a *very* bad sign.


I should point out that 32-bit developer have options available to them to access greater memory. In the short-term it is possible to alleviate the 3 giga-byte memory addressing limitation (when using the /3GB entry in Boot.ini); by utilizing an advanced API in the more recent Windows Server OSes, called the Address Windowing Extensions (AWE) API. Theoretically, at least, this API, allows you to access physical non-paged memory beyond the 32-bit virtual address space and to have window views to this physical memory from within your application.

So even with, say 32-bit Windows 2003 Server, it is possible to circumvent the memory limitations of the x86 3 GB flat virtual address space. I seem to recall Thorsten Engler (NexusDB Architect) mentioning this strategy for implementation in a next release version SKU of NexusDB...

Even several months after Borland has announced its Road Map with a native 64-bit Compiler placed firmly on it, this issue is still the highest voted QC item ever, weighing in with a whopping 735 votes:

http://qc.borland.com/wc/qcmain.aspx?d=7324

I invite other "64-bitters" (as were affectionately dubbed by the "other side") to fill in any gaps I missed. (I'm in a hurry, gotta run).


hope that helped.

-d





Dennis Landi- guid:7515937E-20C5-4CB1-8F61-E26E2844C6F7
.

Relevant Pages

  • Re: use mx=mx to find maximum
    ... Actually the Visual C++ intrinsics work without any libraries. ... compiler makes no attempt to optimize inline assembly blocks. ... the intrinsic types allow you to pass registers by ... memory operation to the compiler, which it will always obey - to the ...
    (comp.lang.asm.x86)
  • Re: Dell wakes up
    ... But what about the Intel Coreseries? ... Depends on what you mean by "move data" - data pulled out of memory will ... the compiler to split the operation across 2 registers and will force the ... And the compiler might not be all that great too, ...
    (rec.sport.football.college)
  • Re: Code review request: small optimization to localtime.c
    ... Now, an optimizing compiler might put a and b into registers, ... Also, on some architectures, the caching structure may cause writes ... parts of memory, if you're unlucky. ...
    (freebsd-arch)
  • Re: Code review request: small optimization to localtime.c
    ... Now, an optimizing compiler might put a and b into registers, ... Also, on some architectures, the caching structure may cause writes ... parts of memory, if you're unlucky. ...
    (freebsd-arch)
  • Re: INTERNAL COMPILER ERROR
    ... >It think he is talking about the compiler crashing. ... >me once or twice. ... I would get a message in the output window that said ... When I build my latest PC, I got corrupted memory. ...
    (microsoft.public.vc.mfc)