Well, that is the theory..
So how is all of this going to benefit MS Works, Nero, Stellarium, Zuma
Deluxe, online Bingo, Yahoo chat, Limewire, address book, Calculator,
Winzip, Blogger for Word..
Most of us are not running algebra computations, designing the wiring loom
for the Boeing 797, computing wind tunnel results for the Ferrari 2008,
putting together the next edition of the New York Times, monitoring the life
support systems of the Shuttle..
There is little enough incentive to move to the next OS..
"Test User" <> wrote in message
news:I5Umi.84$...
On Mon, 16 Jul 2007 19:59:53 -0400
"Mike Hall - MVP" <> wrote:
> Converting many programs to 64bit would show no benefit, so why do
> it. How much memory does MS Word or MapPoint realistically need.
> Games are realistic already. Most computer users will never require
> the kind of grunt that 64bit offers. Presently, I can't think of one
> mainstream program that seriously requires the 64bit touch, and until
> that program appears and can show visible benefits, 64bit will remain
> much as it is now..
>
Running linear algebra computations with maple on FreeBSD with
amd64-bits runs twice as fast as on the same hardware as i386,686, etc.
You don't need laborious benchmarks to see it. As for windows users,
some my find amd64 EVP beneficial.
AMD’s Enhanced Virus Protection acts as a preventative measure causing
the virus to be localized, short-lived, and non-contagious, eventually
being flushed from system memory.
Continued below:
http://www.amd.com/us-en/Weblets/0,,..._11105,00.html
You may also want to look at some benchmarks.
http://www.gen-x-pc.com/rev_amd64_3400.htm
http://www.thejemreport.com/mambo/content/view/74/
The real flexibility comes when the processor loads the 64-bit version of
Windows; in that mode, called Long Mode, the computer can run both 32-bit
and 64-bit Windows applications at full hardware speed. The backward
compatibility with 32-bit applications is provided by the AMD64 processor on
the hardware side; the operating system handles 32-bit calls by using a
special technology called WoW64, for Windows-on-Windows 64, that translates
32-bit pointers and arguments into 64 bits and back again.
(A 32-bit application can find out whether it's running under WoW64 by
calling the IsWow64Process function. Learn more about that function here.)
From a business and usability perspective, that means that users can keep
all their existing 32-bit Windows apps, while being able to take advantage
of the higher performance of any native 64-bit apps that they may own—and
that's definitely the best way for users (and businesses) to begin the
migration to the 64-bit world. And it eliminates much of the business risk
for developers, like you, to begin the migration as well, because you don't
have to convince your customers to walk away from their software
investments.
Why Port to 64-Bit Windows?
There are several good reasons to port to 64-bit Windows. Several billion
good reasons, in fact, including large memory!
The memory limitation for an application on a 32-bit legacy Windows platform
is two gigabytes, which must be shared by all the 32-bit processes that are
running. The limit can be raised to 3GB for some applications, but that's
the absolute maximum address space. On 64-bit Windows, that limitation is
blown out of the water—you're talking about a huge virtual address space,
and hardware support for terabytes of physical memory.
That's not all. When running with a 64-bit operating system, 64-bit
applications have access to 64-bit pointers, and many new 64-bit
general-purpose registers and 128-bit floating-point registers. That gives
your application much greater efficiency in performing complex operations
within the processor, using registers to store all the variables.
The upshot: Fast performance, even when you're not taking advantage of that
larger address space. Math-intensive operations, such as codecs, simulation,
3D, gaming, compression, and cryptography really fly using those extra
registers and instructions. In most cases, unless you're an assembly
programmer you won't have to worry about the details, because your AMD64
architecture optimizing compiler will help your app take advantage of those
extra on-chip resources.
Some Code Really Must Be Ported
If you're running 64-bit Windows on an AMD64 processor, you can generally
decide which applications should be ported to 64 bits, and which can be left
on 32-bit for the foreseeable future. While your 3D graphics apps would
benefit from 64-bit performance, for example, an email client might be just
fine on 32-bit. And of course, you can perform interprocess communication
and remote procedure calls between 32-bit and 64-bit apps running on the
same machine using operating-system calls or other middleware.
However, due to the architecture of the AMD64 technology, and of
Windows-on-Windows 64, there are some pieces of code that simply must be
ported to 64 bits, because Windows does not allow "thunking" (that is,
argument translation) at key areas that affect the operating system itself.
For example, device drivers must match the operating system's bitness: If
you're running a 64-bit OS, you need 64-bit drivers.
Also, although you can run both 64-bit and 32-bit applications
simultaneously on 64-bit Windows, each application must be pure—it can't mix
32-bit and 64-bit code. So, if an application that you're porting uses
external DLLs, components or libraries, you must obtain 64-bit versions of
that code prior to completing your port.
Plus, in most cases, you can use a single source tree for both 32-bit and
64-bit versions of your applications. Use different makefiles, with the
correct libraries (see "Some Code Really Must Be Ported") and compiler
switches to compile binaries for both 32-bit and 64-bit platforms.
Integer Data, Pointers, and Arithmetic
There's some excellent advice about the porting process on the DevX AMD
DevSource, so there's no reason to duplicate that advice. However, there are
some pointers that I'd like to share regarding porting C/C++ code to 64
bits.
First, bear in mind that programming for 64-bit Windows is basically
the same as programming for 32-bit Windows. You'll use the same APIs
and programming conventions. However, you will encounter a few new data
types. For example, int and long remain 32 bits, but pointers become 64
bits. That means that you'll have to be careful about finding, and
fixing, any implicit assignments between ints and pointers in the code.
To put it another way: do not cast pointers to int, long, ULONG or DWORD
http://developer.amd.com/articlex.jsp?id=167
--
Mike Hall
MS MVP Windows Shell/User
http://msmvps.com/blogs/mikehall/
Similar Threads
Linear Mode
