Introduction to 64-bit Computing and x86-64

James writes "Ars Technica has an article up explaining 64-bit computing from the x86 angle, specifically from the angle of AMD's Hammer. The article explains the details in that usual Ars style, and I found it very useful for thinking about what kinds of applications I may want to put to the test on one of these when we get a box in the office. Even non-x86 freaks may appreciate this, since it breaks down some of the basic advantages of 64-bit computing, and just who can expect to see gains in the near future."

Comments

Looking forward to it

[dreamchaser]

While IA-64 isn't as bad as many here like to paint it, I'm looking forward to x86-64, if for no other reason than the continued pressure and competition for Intel.

We've all heard the rumors that Intel has a 'secret' project to produce a P4 that executes x86-64. I have a feeling that they might have to unveil it, if only for marketing reasons. Wouldn't it be ironic, Intel adopting AMD's extensions to the x86 instruction set!

Re:Looking forward to it

[MSTCrow5429]

InStat/MDR thinks that Intel will adopt x86-64. As an AMD shareholder, I think that would be great, but I'm not sure I share InStat/MDR's optimism. Athlon 64 will not only have to be equal to the P4, it will have to blow it out of the water. Maybe InStat/MDR knows something I don't.

Mix code in long mode?

[SynKKnyS]

After reading the topic article (of which I saw on HardOCP yesterday), I was left with one question. Can you mix 32 bit and 64 bit code inside of ONE process? I know the OS can support 32 bit and 64 bit processes under Long mode, but can you mix code in a single process? It would be nice to know if you could build an application, query the CPUID feature flags, and then produce optimized code paths for both 32 bit and 64 bit. This would be nice because you can just supply one set of binaries to your customers instead of two seperate binaries. Anyone have any experience with the Opteron who can answer this?

Coding styles

[ultrabot]

The main perk of popularization of 64 bits is, if we think of the future, that more source code will be written with 64 bit capability in mind. Long ints will be used where they seem to be needed, etc. Open source movement is probably the most obvious benefactor, considering how harnessing that extra mile is/will be a trivial matter of recompiling. If we get a fast, cheap, non-x86 64 bit system in the future, all the better. But 64 bit capability should definitely be available on the desktops of the masses also, whether they needed 10 gig databases or not! More power for AMD!

I'm looking forward to industrial strength, rock solid Opteron servers to finally put to rest all the speculation how Linux on x86 machines is not up to all the tasks of Solaris/HP-SUX systems...

plenty of potential customers

[g4dget]

Just about anybody who runs Beowulf clusters or does scientific computing on Linux is a potential customer for these. Many people run into the dreaded 4G barrier, but Itanium is too costly and too much of a jump. With the x86-64, moving to 64bit is essentially no-risk--you know that at worst, you just get a really fast x86 machine.

But what will be really interesting is when operating systems will be specifically designed for this. With 64bit, a lot of the cruft in 32bit operating systems can finally go away. For example, memory mapped I/O finally becomes useful again, shared libraries don't clash as easily, etc.

Wrong about underflow

[stewartj]

a small point, but the author is wrong about underflow. from the review:

you get a situation called either overflow (i.e. the result was greater than the highest positive integer) or underflow (i.e. the result was less than the largest negative integer)

underflow is when you're trying to represent a fractional number smaller than the smallest floating point number available. ie: you went too close to zero.

Re:Crap article.

[Anonymous Coward]

Do you know what you're talking about? By math speak most addresses are just integers, but in computers a (void *) can be cast to a unsigned long without any loss of data, but thats not the point. x86-64 can only access 40bits of physical/virtual address space, even though internal datapaths can handle 64bit. He says that the biggest improvement will be large math and double the registers. As for x86, it's always been a hack. Im not a 16bit x86 buff, but it used switchable banks of memory. At no point could you address more than 64k in a segment. In the pentium, Intel added PSE (page size extensions) with allow 36bits total memory, but only a 32bit address space. Thats why you can configure a x86 linux kernel to handle 64gigs of High Memory. This is useless for any kind of IO address space, and still only 2^32 can be seen by any process. In the Pentium Pro they added PAE (physical address extention) which again lead to 36-bit addressing, but if your EIP register is only 32 bits long, how do you represent code in 0xfffffffff? Extended addressing on the x86 has always been a hack. Finally with x86-64 programs will be able to see more than 4gigs (minus what the OS steals. Win2kPro takes 2gigs, but Win2kServer and Advanced Server can take 1). Even alphas only have a 43bit phy/vir address space. When the time comes when it's cheap to have a terabyte of ram, Im sure they will increase the address space. This time it's not a hack though

Will Microsoft survive the 64-Bit transition?

[RoLi]

The 64-Bit transition comes with a lot things, all bad for Microsoft:

• For the first time in computing history AMD and Intel no longer see Microsoft as the sole software provider. Both Intel and AMD support Linux from day 1 on their 64-chips. I repeat: That did not happen before. So far, Linux was never available on a chip's introduction.
• On Operon and Itanium, Linux is available before Windows.
• In the first 1 or 2 years, 64-chips will be mainly used on servers, where Linux is already strong.
• To use the additional features/registers, a recompile is neccessary - OSS will use those features right away, while CSS vendors will take quite some time to release a 64-Bit version and will probably want some money for the upgrade.
• The traditional Windows-on-servers customer is a very conservative market segment not likely to jump on the 64-Bit bandwagon very early.

To summarize, Microsoft might run into a chicken-and-egg problem on 64-Bits: Nobody runs Windows on 64-Bits because it's not faster -> Nobody makes Win64 software -> Nobody runs Windows on 64-Bits.

Add into that the fact that Microsoft is traditionally very incompetent and slow when it comes to adopting new architectures and you get the idea.

I think that Microsoft will lose the majority of their server marketshare and a large chunk of their desktop marketshare during that transition. Simple market inertia will prevent Microsoft to be thrown out of the desktop market, but because of the 64-Bit transition, the Linux desktop market might finally gain critical mass and endanger the Windows domination in the long term.

PPC

[Duncan3]

"Should Apple move from 32-bit PPC to 64-bit PPC, Mac users should not expect the same kinds of performance gains that x86 software sees from the jump to x86-64. 64-bit PPC gives you larger integers and more memory, and that's about it. There are no extra registers, no cleaned up addressing scheme, etc."

Well yea, they already have more then 0 general purpose registers, and a flat memory space, like every other chip besides x86 has had for the last 20 years now. The embedded chips I've used on projects that cost $7 a piece even have more registers then x86 does.

64bit is about the memory, and using that memory, plain and simple. x86 just happens to be using this as a chance to catch up with the cutting edge concepts of the 1980s.

As for x86 needs to die once and for all, it's hacked, hacked again, and hacked yet again. x86 was and is a 16bit system. And now AMD wants to hack it yet again. Can anyone doubt that 80% of the silicon is for supporting legacy apps at this point? Are people that damn lazy they can't type 'make' on a new system? It's not like anyone uses "int" anymore and assumes it's N bits long.