The AMD64 has native 64 bit instructions as well. It has a "legacy" mode which supports 16 and 32 bit effective operand sizes and "long" mode which supports effective operand sizes up to 64 bit. In addition, you gain fifteen 64 bit registers in long mode.

Yes, there are new instructions and new registers that support 64 bits. I'm staring at them in AMD's documentation.

You mean Seymour Clay's CDC 7600? 60 bits, actually. It ran at an equivalent of 37 MHz.

The AMD64 supports up to 64 bits of data without SIMD. With SIMD, it can process up to 128 bits of data.

For an example (the ADD instruction, with several opcodes including 64 bit operations), check out "AMD64 Architecture Programmer’s Manual Volume 3: General-Purpose and System Instructions", page 59.

It is an open architecture, just as the x86 was. You can spare yourself a lot of frustration by reading the documentation freely available from both AMD's and Intel's websites online.

Nope, the IBM 7030 Strech, made in 1960... 64 bit data word, 64 bit memory, 64 bit main core storage register, 64 bit index core storage register... instruction set 32 bit or 64 bit... lauch price, 13.5 million $$$

IA32 and IA32e ( EM64T and AMD64 ) have 128 bit instruction and register at well... SSE have 8 128 bit register in the case of IA-32 and 16 128 bit register in the case of IA-32e... on both integer SIMD operation are performed by the 64 bits MMX... so, any processor with MMX can process 64 bit data, any processor with SSE can process 128 bit data... it is not specific to the IA32-e ( EM64T and AMD64 ) architecture...

AMD 64 use hypertransport for access the memory... the funny thing is that hypertransport is only 32 bit wide... perfect for 32 bit... but it become more bad in 64 bit mode... in place of send one 32 bit word, two 32 bit word are send and one 32 bit control packet... 3 cyclus for two time more data... no really a win situation...

In my case, Xeon processor and FB DD2 ram, i have 1 bit lane... in reality, 4 time one 1 bit between the memory controler and the memory dimm... yet, they are serial interface... it is slower ? No really... usual DDR2 will need to be clocked at 4000Mhz for reach my ram speed...

We have a lot of serial bus in our computer... USB, SATA, PCI express, memory in case of FB memory, etc.... and nothing stop you for send 1024 bit on a serial bus... in some future, all the bus will be serial.... intern, processor will be xx bits... why xx ... because a processor is not only a core, it have other section at well like memory controller ( next generation of intel will have controller on the processor ), FPU, MMX, SSE ( 3Dnow ), cache... each part have his own bit range... but the core is always 32 bit... the core is the engine of your processor, memory controler, cache, FPU, MMX, SSE are option... one day, IA-64 will be used by everybody... and at this time,  we can speak of a processor where the core is 64 bit...

It seem that people think that they have a 64 bit processor because the memory address range is 64 bit... Hmmm, in so case, i choose to say that i have a 128 bit processor since my SSE3 is 128 bit !!! At the begin, intel was right... usual processor was called IA-32... the with 64 bit memory address, IA-32e... real 64 bit processor IA-64... but AMD have choose AMD64... and people have think that they have a 64 processor... after, intel have change IA32-e in EM64T... marketing question but not the reality...

And what  to say about people who have a old pentium processor, let say a pentium pro... with 36 bit address range ( allow 64 gb ram )... are they 36 bit processor ?

Let say that a guy have a P4 32 bit ( without EMT64 ) and that he have 32 GB ram... like say before, PAE is a option... but the more important is that devs of software have a other way who don't request user to modify some boot.ini ... Microsoft OS have the "Address windowing extensions" ( AWE ) ... in place of put data in the 2gb allocated to application, memory upper the 4 gb can be used for this... by example, in the case of sins, all the texture can be cached in the memory upper the 4 gb... of course, AWE code work only with windows... PAE with a lot of operating system...Sins exe is only a few megabyte... the rest is mainly data who can use the AWE from microsoft...

A other way is the overlay method...  this allow to run a program who is bigger that the main memory... The methode assume dividing a program into self contained object code block called overlay... Overlay programming require that the dev is aware of the size of each part of the program... assembler allow this... C++ don't allow enough control on the code size... and since few dev know assembler, almost everybody use the C programming language... overlay method is only used on very little with almost no memory like embedded system...

Since it is my last post on these topic, some interesting link for these who have a 32 bit processor without EM64T/AMD64 and who have 4gb ram or more :

- 4 gb tuning

http://msdn.microsoft.com/en-us/library/bb613473(VS.85).aspx

- PAE ( 4 gb or more )

http://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspx

- AWE ( for devs )

http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx

-

Sigh . . . I gave a link to the documentation, and even gave you the page number for a 64 bit ADD instruction as an example.

You are so focused on "winning" the conversation, you refuse to believe it may be possible you are wrong.

Relax, I've been wrong before as well, and I'm pretty stubborn. We're not perfect. We're human, we make mistakes. It happens. You have to learn to take a step back and ask if it is really worth it to "win" the conversation. It's something I struggle with myself sometimes.

I think it's important to point out here that, even with /PAE /3G /AWE extensions to the boot.ini, a game won't magically have 3GB to work with (possible exception for memory leaks).

In other words, the application/game itself has to be written/modified to take advantage of the increased virtual memory space.

I just don't want people running around adding these switches and end up doing more harm than good.  So caveat emptor, check with your application developer to be sure whether your applications will make use of those switches. (supreme commander is the only one I know off the top of my head where they provided patch to support the 3g switch)

PLEASE correct me if I am wrong, but GalCiv does not (currently) support the 3g switch.

The 64bit/memory discussion aside , may I suggest my solution  :

1. Install Microsoft Virtual PC on your Vista x64 machine. ( http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx )

2. Install Vista 32 bit on it (unless you have OEM license you allowed to do so ,or of course you probably have MSDN so no legal issues).

3. Install Cisco VPN on that 32 bit Vista and get from there into the same folder on youyr machine.

P.S.: Personally I actually have entire developer setup installed on VPC since installing Visual Studio, SQL Server and such on the home PC sometimes load too much on Windows reducing start up time etc.

Would a 64-bit binary for GC2 2.0 be too much to ask for? 

GalCiv 2 can really, really push that 2 GB memory barrier, and I still haven't tried TA (with it's new, bigger galaxy size).

Hard to say, depends on the flexibility of their development tools. It does appear that their future games will certainly have 64 bit binaries.

Speaking as a recent (less than a month ago) convert (to 64-bit, not to either GalCiv2 or to Stardock's products), there's less (far less) reason to fear 64-bit as a gamer than there was even a year ago.  Why?

1.  Hardware and driver devs (especially ATI/nVidia/Creative) have actually gotten a clue and realized just how deep 64-bit hardware reach actually goes.  (Unless you're pushing netbooks, there are very few non-64-bit processors sold in terms of general-computing use, and that is utterly regardless of what operating system you run, and that is irregardless of whether you're talking uber-high-end or even budget beater-boxes)

2.  Surprisingly, Vista has driven 64-bit mainstream *because* of that much-maligned (but utterly necessary) code-signing requirement for Premium-level drivers for 64-bit drivers, especially from those aforementioned major IHVs.  Demand for 64-bit driver support has only increased due to absolutely ridiculous pricing for system and graphics memory.  (Four gigabytes of DDR2 is usually between $60 and $70 for 800 MHz pairs, even at retail.)  Put the two together and the result is systems with 4 GB or more of system memory are becoming the standard, not the high end.

3.  This benefits Stardock because their products (and especially their games) are very RAM-thrifty.  (Unlike most other game developers, no Stardock game requires more than 2 GB of system memory, even at max-difficulty mode and with all the eye-candy turned on.  While some games (especially Sins of a Solar Empire) are thristier on system memory and resources than others, even the relative resource pigs among Stardock's titles are far thriftier than their counterparts from other developers, even under truly worst-case scenarios.)

GC II is a relative (compared to Sins of a Solar Empire) resource pig; however, even GC II is quite playable on a minimally-configured 64-bit system.  Naturally, as you upgrade such a system, it benefits far more than other games because of that same thriftyness.  Further, you can play the 32-bit version on a 64-bit OS with no changes (I do just that with GC II, as the 64-bit version is not currently available retail).  However, when the 64-bit Ultimate Edition is available, and after sufficient hardware upgrades are purchased, things will get snappier, and therefore better, for little additional outlays (none of which could even remotely be called *expensive*).