This is the thread I told you will make.

I list some of 64bit characteristics here to discuss about.
EMT64 and AMD64 are very similar.

AMD x86-64 Architecture:-Fully x86 compatible.
-No performance sacrifice for either 32-bit or 64-bit computing
-Not forced to move to a new architecture. Seamless transition based on user's timeframe.

-Continued use of existing 32-bit applications, tools, and knowledge base.
-Full support for 16-, 32-, and 64-bit applications running concurrently.
-32-bit code runs unchanged. Designed to be easy to port applications that might benefit from 64-bit address space.

Other Vendor's 64-Bit Solutions
-Instruction sets are NOT x86 compatible.
-Compromises 32-bit performance. Smaller, less sophisticated, x86 engine causes speed penalty for legacy code. Future development is focused on 64-bit only performance.
-Forces the costly transition of many 32-bit applications that do not require 64-bits.
-Doubles investment: 2 instruction sets, 2 operating environments, 2 application
binaries, 2 development and support teams.
-Support for 16- and 32-bit apps only through emulation software or hardware.
-Must port 32-bit applications for full speed
execution. During transition years, must
manage 2 code bases.
--------------------------------------------------------------------------
64-Bit Mode
64-bit mode supports the following new features:

• 64-bit virtual addresses (implementations can have less).
• Register extensions through a new prefix (REX):
o Adds eight GPRs (R8-R15).
-Many program can benefit these new registers even if they were 32bit(They are 64bit)
o Widens GPRs to 64 bits.
-Makes 64bit operations possible:
-Using RAX instead of EAX:EBX for example.
-More complex and huge calculations are possible.
-Counters can count more.
o Adds eight 128-bit Streaming SIMD Extension (SSE) registers:
This is good for graphical or scientific programs:
-3D games.
-CODECs.
-3D modeling/animating.
-May be some 2D environments.
-Scientific programs that calculate a lot of numbers.
-Simulators.

• 64-bit instruction pointer (RIP).
-More RAM is possible (>4GB).

• New RIP-relative data addressing mode.
-Easier programming.
-Faster execution.

• Flat address space with single code, data, and stack space.
-Easier programming.
-Faster execution.

• 64-bit virtual address space.
-Programs feel more memory.

• Physical-memory support is expanded to 52 address bits.
-More physical memory is possible(>4GB).

CPU runs at two major operating modes:
Long mode
Legacy mode

Long mode
-This is 64bit mode.
-64bit OS and device drivers are needed.
-32bit Apps can also be executed in this mode (OS and CPU simulate a 32bit environment called "Compatibility Mode")

Legacy mode
-In this mode CPU is the same as a 32bit CPU.
-CPU starts up in this mode so legacy programs can work as well.
-Real mode, protected mode and virtual 8086 modes are supported

Conclusion

All programs can run faster (some more than others).

The code, CPU should execute, is less = Simple programs & Faster execution.

Backward compatibility: Older programs works without problem but makes CPU architecture more complex.

Nobody use this amount of addressable memory(at least for next ten years)

Is ($/performance) of it acceptable?

I myself am very optimistic about the move to 64-bit code/instructions. You've listed most of the enhancements that we'll see with the move, in addition to listing the fact that Intel's and AMD's x86-64 extensions will be 32-bit compatible. I think we'll need it. 32-bit code will take a loooong time to go away fully, mostly because older programs will still be used for awhile and partly because some smaller and low-funded programs will still be made for 32-bit. And let's face it, 32-bit still has some life left in it for non-power users. Win98 SE is getting to the point that it won't be used much longer, but the Win2K series and various 32-bit Linux kernels will remain functional for quite some time. Heck, some smaller businesses are still using 8/16-bit DOS systems! :rolleyes: Those are the same people who are thinking of upgrading their 386 systems to 486. :p

I do have some things to add to this. First of all, Intel's moniker is "EM64T", not "EMT64". It stands for Extended Memory 64-bit Technology, and is Intel's way of admitting that they simply boot-strapped 64-bit support to their old NetBurst microarchitecture in a sloppy way. They made it work, and it works well, but only because they worked hard on it and AMD gave them a good foundation.

The second point I'd like to make is that of performance. A lot of people are skeptical about 64-bit code/instructions because they haven't seen any performance increases with it. That's mostly because we don't have anything real to do! WinXP 64-bit Edition was a joke, simply because it was just a recompiled version that was made into 64-bit, it's not a fully optimized 64-bit-from-the-ground-up OS! So no, it's not going to do that well. Besides that, running 32-bit programs on a 64-bit extended OS is not a worthy contender for a 64-bit CPU like the A64! But despite the fact that these so-called "benchmarks" were poor excuses for showing off 64-bit code/instructions, the A64 was still able to pull a bit ahead. Long live AMD's K8 microarchitecture! :cool: Once we see some real 64-bit OS'es and programs, everyone who bought a 64-bit CPU last year will be well rewarded.

The third point is that of backwards compatibility. This is not difficult to do. In fact, that was Intel's plan all along when they designed the Pentium. Back in the days of DOS, 32-bit code/instructions were the new upcoming breakthrough, and there were many new things added to the mix in terms of what could be done. The Pentium could handle all of them, while at the same time remaining compatible with the old 8-bit and 16-bit code/instructions that used the Real Mode/Protected Mode junk. Interestingly enough, the new 32-bit instructions were simple enough that the majority of the Pentium's 3 million transistors were dedicated to the older instructions. 32-bit showed its efficiency factor early on, and everyone got excited. The other extensions like SSE were added later as sort of a RISC-based bundle of math add-ons to help the CPU do even more work. And of course the Pentium started the whole idea of having an 80-bit wide FPU path. We've just been adding on ever since. Until now with 64-bit.

Another thing I wanted to discuss here is how Intel and AMD differ in their CPU designs when it comes to 64-bit code/instructions specifically. Intel's NetBurst2 (updated microarchitecture used in all their 31-stage Prescott-based CPU's) and AMD's K8 (microarchitecture used in all their Socket 754, 939, and 940 CPU's) are extremely different.

Intel uses high clock speeds and deep pipelines and a huge front-end to get things done, while AMD relies on pure efficiency and relatively shallow pipelines. The way that Intel designed their NetBurst2 is that the x86 instructions get broken down into RISC-sized instructions, get reordered through the massive ROB, and then routed to the executions units' beginning stages. From these first early stages, the instructions get rerouted again to the appopriate pipeline, be it the ALU, FPU, or SSE units. The beginning stages, as well as the ALU pipelines, are double-pumped, so this keeps things going. But this can't fix the fact that the entry window for instructions is fairly narrow due to this all-encompassing sharing of the first few stages. When Intel boot-strapped 64-bit capability onto NetBurst2, this added another set of instructions that need to be shared with the first few stages. Intel did a good job of reducing congestion there, but even complex branch-prediction can't save NetBurst2 from the fate of ultra-dynamic instruction variations. The ROB is not equipped to handle that kind of traffic. That being said, NetBurst2 still does an adequate job of handling 64-bit instructions on top of ALU, FPU, and SSE instructions. But for the future, Intel plans on adding 64-bit support, and maybe even Hyper-Threading, to the Dothan core (Pentium M).

AMD's approach with their K8 microarchitecture was to solve the 32-bit vs 64-bit dilemma. AMD knew a lot about Itanium, and a lot about what it couldn't do. It was great at 64-bit, but really bad at lower bittage, having to resort to an emulator to execute 32-bit instructions at a serious performance hit. AMD knew that they had to make a 64-bit CPU that could execute 32-bit code just as fast - ie the number of executed instructions should remain the same whether they are 64-bit or 32-bit or even 8-bit. Using this mantra, AMD came up with a solution: make a 32-bit CPU that "opens up" to 64-bit instructions. Instead of adding another mode (which often means flushing the pipelines and resetting the core to switch modes) they just expanded the GPR's and added a prefix (which you mentioned) for accessing 64-bit resources. They also added some more GPR's under x86-64 extensions for more efficient executions, which helps more than register renaming because it doesn't require in-execution interference to clone a register. Another big difference between NetBurst2 and K8 is that the K8 doesn't have a shared front-end. ALU instructions go one way, FPU/SSE instructions go another. The ALU with the GPR's is fully 64-bit optimized, while the FPU shares space with the SSE in a way that makes sense. In essence, they are one unit within the K8 core because they both do high-end FP math. Whether or not a 128-bit FPU will ever be used in x86-64 extensions is another matter entirely! :rolleyes: But in any case, there's a clear definition in K8 between integer/GPR calculations and FP/SSE calculations. And since K8 has a much higher IPC with shorter pipelines, who's going to argue about the efficiency! :p

Oh, and about that question of who's going to use all that extra addressable memory, well... As a whole, computers and their users have always used more memory! If you give it to us, we'll find a way to use it! And with some of the things that are coming out, I have no doubt that power users in the near future will actually truly need more than 4GB of RAM. 64-bit is just icing on the cake when you see what's coming...

Windows Vista (just recently announced name for "Longhorn") is going to be requiring/recommending 1GB of RAM! :eek: With its DX9-based 3D-accelerated GUI, I don't doubt it. Not to mention it looks like it will be running small DB-class routines in the background for the new version of "My Documents" among other things. I think we will all shortly need 2-3GB of RAM for running Windows Vista.

Dual-core is the latest thing, and until 64-bit code/instructions become mainstream, this is the single biggest performance enhancing change to PC's right now. Perhaps even ever. And with multi-core being mentioned by Intel and AMD at every interview about their future plans, multi-tasking is taking on a whole new turn. Already with dual-core we've seen the advantages of being able to run many many apps at once, or two extreme apps at once (such as vid encoding & game playing) with no performance hit. As our systems get more cores, we'll be running more and more at once. This will undoubtedly require more RAM to keep things running at once. Sort of a catch-22. :p

Virtualization - If you haven't heard about it yet, you will very soon be bombarded with it! Virtualization is the latest technique being developed by the computing industry as a whole for running more than one OS at once. Yes, you read that correctly. Ever think of running WinXP and Linux at the same time? Not dual-booting mind you, but having both running at once. With a dual-core CPU, this is not unimaginable. Virtualization is a very real thing being developed for the mainstream. Great care is being taken to ensure that neither OS interferes with the other, and so far the results look good. They've actually managed to keep the system running when one app or OS crashes! :eek: Hard-boots may just go away for systems running 24/7 once Virtualization hits it big. And it's about time it did! In terms of pure power, modern hardware has more than enough to let a family of 5 surf the web together at 5 individual dumb-terminals running off one system. Virtualization will be the first step in allowing an entire family to buy a single multi-core system for all of them. Like your own mainframe supercomputer! :D And of course with multiple OS'es running at once, we'll need more RAM... ;)

Other Vendor's 64-Bit Solutions
-Instruction sets are NOT x86 compatible.
-Compromises 32-bit performance. Smaller, less sophisticated, x86 engine causes speed penalty for legacy code. Future development is focused on 64-bit only performance.
-Forces the costly transition of many 32-bit applications that do not require 64-bits.
-Doubles investment: 2 instruction sets, 2 operating environments, 2 application
binaries, 2 development and support teams.
-Support for 16- and 32-bit apps only through emulation software or hardware.
-Must port 32-bit applications for full speed
execution. During transition years, must
manage 2 code bases.

What other vendor?
It looks to me like you are including Sun Sparc series and Intels Itanium II series CPUs. These CPUs should not be included in this thread because they do not support EM64T or AMD64. They are real 64bit CPUs and were not intended to run 16bit or 32bit programs.
Programs written for computers running real 64bit processors will not run on EM64T or AMD64 capable processors even in 64bit mode

I myself am very optimistic about it too, but when we speak about good aspects, we should also talk about it's bad

ones.

About backward compatibility, yes, it is the only chance for 64bit to be popular.

I am sure that performance will be increased in 64bit systems, but as you noticed internal CPU designation is very

important.

About memory, yes it is needed, but it costs too much. You can't see all PCs with minimum 2 GBs of RAM until the

costs come down. And something that I forgot to notice is that CPU implementations usualy don't have as much as

that addressing space. But even 40 bits is too much more than users need (1 TB physical memory). It is not

important untill it makes the CPU more expensive (Does it?).

You noticed there is no optimized program for 64bit CPUs, yes, and this is one of the reasons that we shuold wait a

moment before buying it, and give time to programers to do their work, except for research and/or to get more

information from it if you are a programer for example.

About dual core, AMD's FX-57 does more in single tasks than it's same price dual core CPU. The bus interface

should be divided between cores.

Windows will use more system resources than an OS should really use, so it may use ten GBs of memory.

Would you explain some of Virtualization benefits?
If it runs two OSs at the same time it takes double CPU time and double memory usage, why should I do this?
When I say linux is better than windows for example it is because of it's more performance, but in Virtualization,
performance will be decreased significantly.

I imagined a day when there is a PC in each home and three or four keyboards and monitors attached to it. Then each

user has it's own working environment on a same computer. Yes it is good.

What other vendor?
It looks to me like you are including Sun Sparc series and Intels Itanium II series CPUs. These CPUs should not be included in this thread because they do not support EM64T or AMD64. They are real 64bit CPUs and were not intended to run 16bit or 32bit programs.
Programs written for computers running real 64bit processors will not run on EM64T or AMD64 capable processors even in 64bit mode

I just noticed that there are other 64bit CPUs, maybe more powerful.
But AMD64 and EM64T are x86 and backward compatible.
So yes we only talk about x86.

I read that it needs 512mb RAM off MS's site. I wanna see how it handles that.

About memory, yes it is needed, but it costs too much. You can't see all PCs with minimum 2 GBs of RAM until the

costs come down. And something that I forgot to notice is that CPU implementations usualy don't have as much as

that addressing space. But even 40 bits is too much more than users need (1 TB physical memory).
You really think ram is expensive? I though it to be very cheap these days. Even the newest ram seems to come down in price very quick. You can get 2GB of quality ram for less than $200, that isn't expensive in my book. ;)


123456 - You have a fire avatar, your the 1-6 evil bond villain, and 666 posts! :eek:

You noticed there is no optimized program for 64bit CPUs, yes, and this is one of the reasons that we shuold wait a moment before buying it, and give time to programers to do their work...I don't think there's any harm in being ready to run 64-bit code/instructions based on the lack of software available. If we all thought like that, the programmers and developers would never make 64-bit programs because nobody would be able to run it so no one would buy it! And don't forget that 64-bit support is coming at us from so many different directions in new CPU's that it's starting to become impossible to avoid it. :p And as long as EM64T and AMD-64 don't hinder 32-bit execution, I say why worry? If it's free, I'm taking it! :cool:

About dual core, AMD's FX-57 does more in single tasks than it's same price dual core CPU.Very true. But the only users who would benefit from buying a high-end single-core CPU for $1000 these days are extreme gamers - the ones after pure frame rates. The rest of us are better served with dual-core, even if we don't know it yet. We just haven't gotten used to the idea. Ever think of encoding a home movie while you play your favorite computer game? Or even on the pure gaming end... imagine being at a LAN party where you can host the server and play the game on the same system! Or in the sense of sharing a single computer, two people can use a dual-core system at the same time without interfering with eachother. Or in a single-user environment with heavy multi-tasking - dual-core is amazing at this. I'm not saying that single-core is dead yet, but Intel and AMD are united in their plans to kill it soon...

Would you explain some of Virtualization benefits? If it runs two OSs at the same time it takes double CPU time and double memory usage, why should I do this?Well right now, it really only makes sense for a server environment, but as more and more people go the home server route, virtualization will take on a more important role to the power user. On the other side, there's this neverending push from the computing world to put a single multi-media device into every home that handles everything - movies, music, web-surfing, distributed computing, etc. Virtualization and multi-core systems will make that possible. Until M$ comes out with a double-headed version of Windows Media Center, virtualization will go unnoticed for most people. Heck, even afterwards, it will probably remain one of those "buzz words" that people talk about. :p But as a power user myself, it sure would be nice to replace 2-3 secondary systems with one multi-core/multi-OS system that handles all of their duties. File server, tertiary web-surfing system, etc - all rolled into one. Individually these duties are lite on modern hardware, so I wouldn't be at all concerned with shuffling them onto one system. Plus, that saves money on the electricity bill because a single system, even a powerful one, eats up less juice than 3 separate systems. Granted that this virtualization stuff won't change the world, but it's just another way in which all these advancements (64-bit, dual/multi-core CPU's, tons of RAM expandability) will be put to use much sooner than most people realize...

Maybe it seems that I'm not agree with 64bit, but really I am.
I actually made this forum to discuss about benefits of 64bit processing and see the opinions about it's good and bad aspects. I didn't want to make this forum very technical, but it seems that I did.(not very!)
I think it is good to think (and takk)about:

For example does it increase performance by 70%(When an optimized program runs)?
Or why AMD still produces sempron?
What is the benefits of flat memory addressing?
Is Windows Vista optimized for this 64bit processors?
Does 64bit registers improve performance in all programs?
What is the other benefits of 64bit processors?
How is the performance in compatibility mode? (compatibility mode =32bit program in 64bit environment)

--------------------------------------------------------------------------
This image shows the registers of AMD 64bit CPU.
As you see old 32 bit register are expanded to 64bit in addition to some new GPR and SSE registers in long mode .(Dark parts)
The number can be kept in 32bit register = 2^32 = 4294967296
The number can be kept in 32bit register = 2^64= 18446744073709551616

Maybe it seems that I'm not agree with 64bit, but really I am.Oh I know. I just like debating. ;)

For example does it increase performance by 70%(When an optimized program runs)?
Or why AMD still produces sempron?
What is the benefits of flat memory addressing?
Is Windows Vista optimized for this 64bit processors?
Does 64bit registers improve performance in all programs?
What is the other benefits of 64bit processors?
How is the performance in compatibility mode? (compatibility mode =32bit program in 64bit environment)I think the performance boosts could be much greater than 70%, depending on what's being done. Remember that crunching a 64-bit instruction on a 32-bit CPU can take anywhere from 3-5 clock cycles due to having to separate the instruction, crunch it in smaller chunks, then put it back together. Not that a 32-bit CPU would be running 64-bit programs, but opening up the possibilities like this will let our computers do more with less clock cycles. Going the other way, perhaps a certain algorithm in a program takes 3 32-bit clock cycles to complete. Moving that up to 64-bit could very well reduce that to a single 64-bit clock cycle. Or in many cases, the sheer efficiency boost associated with 64-bit memory management alone will be enough to speed up programs!

Ooh ooh, take a look at my sticky (http://www.pcguide.com/vb/showthread.php?t=39018)! AMD gave back 64-bit support to the Sempron! Now they call it the Sempron 64. :rolleyes:

Flat memory addressing... That subject alone could take up an entire thread! Like so many of these topics. ;) This goes back to the memory management thing, and also leads people down the historical path of the Win9x kernel and all those "out of memory" errors that we were all so fond of... I won't lie and say that 64-bit flat memory addressing will fix Windows errors :p but it will allow the OS (like WinVista) to natively keep track of every single byte of memory without resorting to a small table of large chunks of memory. This will reduce the run-time overhead associated with memory management, and should at least help in the fight against memory leaking programs. That plus the NX & XD flag bits built into the latest CPU's will greatly help keep all programs in check.

I don't know if WinVista is fully 64-bit optimized or not, but it will definitely be better than WinXP 64-bit Edition. I think I've also heard news about M$ releasing two versions of Vista - one for 32-bit and one for 64-bit. If this is true, then I think Vista will be a very successful version of Windows. Even if it is a bit confusing, by the time it's released, all new CPU's will have 64-bit support. In fact, if you check my sticky, you'll notice that this month I have only one CPU recommendation that doesn't have 64-bit support, so it's starting already.

That last group of questions blends into eachother. 64-bit execution in general will be better when properly used. The extra registers and extra space in them effectively gives 64-bit CPU's 4 times the execution resources over 32-bit CPU's. You've got registers that are twice as wide, and there are twice as many of them. Even looking at those basic charts you can see the extra "space". Not only that, but in compatibility mode, you could theoretically have the upper registers being used by the 64-bit OS while the lower registers are being used by the 32-bit program in 32-bit mode (although the coding for that would be a nightmare!). Or even better, in a dual-core 64-bit CPU, you could have all the 32-bit programs operating on one core while the 64-bit OS and programs operate on the other core without any interruptions.

Another unseen benefit of 64-bit CPU's will be reduced SSE execution. :confused: Ok, I know that sounds weird, but let me explain...

Current 32-bit programs sometimes need a bit of extra muscle in doing large calculations. 32-bit integer execution is many times just not a good option. It's too limiting and complex to break down large calculations into small 32-bit chunks. So some programs have taken the route of shuffling large calculations to the SSE unit, which can crunch 128-bit executions. But the SSE unit is supposed to be for quick single- and double-precision FP execution, not large integer execution that won't fit into 32-bit form easily. Shuffling a 50-bit integer calculation, for instance, over to 128-bit SSE form is a waste of time for the SSE unit. Then again, since the SSE unit is separate from the ALU and its 32-bit GPR's, this larger calculation is essentially "free". Unless...

If this program happens to be a game or an encoding app, and it's using precious SSE clock cycles for menial integer tasks, then you're wasting resources. SSE is heavily used for programs like this, and you don't want to be using it up with even more calculations that it shouldn't be handling. By increasing the width of the GPR's and ALU to 64-bit, wasted SSE executions can be avoided.

It's great to see some of the board members who are so into the core technology - some of us have had to move our attention elsewhere (networking in my case) and being able to catch up on the new stuff is refreshing.

Looking at things from a simplistic point of view, I wouldn't advise anyone to buy less than 64 bit (AMD) right now - the difference in cost when you consider the lifespan (3-4 years unless you are a gamer) of the technology simply isn't worth the difference.
PCs are going to be used for streaming video, music etc around the home - what OS this will be on is open right now, but multi-core and 64 bit are definitely going to help.
As long as the manufacturers take care of present software, which AMD certainly seem to have done then the acceptance of 64 bit will be overwhelming - 32 bit processor will simply be like the old 16 bit stuff, relegated to embedded computers in control systems etc.
As for RAM requirements, well XP really needs 1GB already. anyone editing even jpegs and perhaps doing a bit of other image manipulation is going to choke with any less. Multi-core processors with oodles of RAM? bring 'em on!

one other point - RAM expensive? I agree that some of it is certainly not cheap, but it's all relative. When I bought a P75 in the 90s RAM was costing £35 sterling per MB (about $65) so I always smile when people worry about the cost of today's hardware :)

It is really a revolution if it doubles the performance.
I think a bad thing in these CPUs is that performance is very depending on program optimizations.
It means you never can be sure that you are gaining to maximum performance.

Microsoft only advertizes it's new 3D UI and it's new search engine(that are really not important) instead of explaining it's OS foundations. Finding this information is not impossible but is too hard. (at least for me! :( )

Why don't all of the PCs have 4 GBs of RAM?(32 bit PCs)
RAM is not expensive when you want to have 512 MB in your PC, it is expensive when you want to have 4GB (or more in 64bit PCs) ECC registered RAM in it!

A question: How dual core CPUs address memory? Do they double memory addressing space?
--------------------------------------------------------------------------

Now I want to explain how system boots with a 64bit CPU.(not in detail)
1 A BIOS does the POST.
2 Loads the operating system to memory and gives the control to it.
3
- If the OS is 32bit then it loads it self and 32bit device drivers, like there is no 64bit CPU. (May brings CPU in protected mode like Windows)

- If the OS is 64bit then it puts the CPU in long mode(64bit mode) and loads it self and 64bit device drivers.

Note: 64bit windows can also run 32bit programs. (in compatibility mode)

Vista 64bit support depends on WinFX API and it's optimizations for 64bit processors (AMD64 & EM64T).

If anybody knows anything about WinFX support of 64bit please let me know.
If you ask me, it is very important that how Vista deals with 64bit.

Why don't all of the PCs have 4 GBs of RAM?(32 bit PCs)The traditional answer to this is that memory controllers can't keep up! It wasn't until recently that the whole idea of having 4GB of RAM in a home computer became a reality. Before that, the memory controllers designed for chipsets weren't good enough to keep track of all that RAM and still be fast. The bridge chips that represent a "chipset" are also processors, and balancing their capabilities over how complex they are and how much heat they are allowed to dissipate has kept them bad, for lack of a better word. Now we've gotten to the point where four 1GB double-sided modules don't slow down the latest systems, and everyone is still getting used to it.

The other implication of this is that CPU's have long been capable of supporting far more than 4GB of RAM! :eek: From the Pentium II onwards, Intel has had 36-bit memory address controllers built into their CPU's, which means they can support up to 64GB of RAM! AMD's Athlon series can support anywhere from 16GB of RAM to 64GB of RAM, depending on the generation & core revision. Now with 64-bit capable CPU's, we're seeing 40-bit (or larger) memory addressing, and again the mobo's can't keep up. Adding more and more banks isn't always the answer, but I think memory controllers may be up to the challenge this time. Technology in chipsets has finally advanced to an acceptable level. I'll leave further memory controller discussion for another thread/topic...

As for Vista's 64-bit goodness, it's pretty clear that the two versions will ship separately, but no word on exactly how 64-bit instructions are implemented. At least I haven't seen anything. If it's at least tweaked a bit before being recompiled into 64-bit, it will be better than XP 64-bit Ed, but only time will tell. There's certainly a lot of room for extra "features" with 64-bit support, but then again the hardware DRM crap will be there regardless. :(

As you know AMD integrated Mem Controller in the CPU, but this didn't solve the problem.

The rev. E (or newer) K8-based CPU's have the improved memory controller that can effectively keep track of 4 double-sided modules, but all memory controllers are going to need to be better to handle the larger amounts of RAM in future systems. The DDR2 spec has room for much much higher chip densities than DDR could ever dream of. 16GB of RAM may soon be a reality for home computers. And with software like Windows Vista coming out, we'll need it! :p