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.

Re:Looking forward to it

[e8johan]

It would be truly ironic if Intel adopted AMD's extensions, but it would only show that AMD dared to go against Intel and do the right thing. From a business point of view, it was a brave move and I believe that it will be the best move that they have made in a long time.

Re:Looking forward to it

[Miguelito]

Speaking for myself... I hate it so far because it's useless. I've had a demo dual 900MHz box in house for months.. even installed a pre-release of the RH Advanced Workstation mentioned in another recent post. The box sat still almost the entire time because there still aren't any damn apps for it yet! I support IC designers, and we couldn't get a single IPF version of their tools.

I'm really looking forward to x86-64. We'll be able to slide it in alongside our existing (growing) linux compute group, and use it for 32bits now, and get 64 bits as time goes on. Can't do that with Itanium.. 32 code runs so slow on there it's pathetic.

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?

Crap article.

[Anonymous Coward]

The article claims that since an address is just an integer, larger integers would mean more address space. And then it briefly mentions that the x86-64 has 40 bit addresses. I.e. not the entire 64 bit integer is used for the address. However, 32 bit x86 systems has 36 or 40 (not sure which one) bits adresses. The address space has nothing to do with the size of the data.

On the other hand, the 16 bit x86 processors could address 1MB, which is a 20 bit address space. 8 bit processors, like the one used in the old Commodore 64 could address 64KB, a 16 bit address space.

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

Re:Crap article.

[FyRE666]

If you'd actually READ the article (and understood it) you'd see the author was differentiating between the adressable range and the number of bits that could be stored in an address. Obviously the old 8 bit CPUs used to combine registers (eg, the Z80 had the IX and IY if I remember correctly - probably not as it was so long ago!) - if they didn't they'd have 256 bytes of RAM! The old segmented address space of the x86 was just bizarre, due to the way the segment registers were used. The segment register was 16 bit, even though you only needed the top 4 bits, so you could access the same address space in thousands of ways, but were confined to a "window" of 64K in any segment ;-)

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.

Possible x86-64SX

[zubernerd]

I remember when I got my first 386 based computer, it was a 386SX (40 MHz - by AMD); which used a 16-bit data bus on the "outside" and 32-bit internally. Do any of you think there will be a x86-64SX, that will work on today's 32-bit motherboards, while giving some of the advantages of 64-bit computing?

Re:Possible x86-64SX

[Psiren]

Do any of you think there will be a x86-64SX, that will work on today's 32-bit motherboards, while giving some of the advantages of 64-bit computing?

Nope, what would be the point. Motherboards are not really that expensive, you can pick up a high-end board for less than £100. If you can afford to buy a 64bit CPU, you can afford to buy a board to put it in.

Re:PPC

[arthas]

I agree. X86 should be dead by now. Why can't Intel or AMD build something like Alpha? It is very clean and efficient 64-bit architechture and it has been around from 1992.

Re:Processors like businesses

[RoLi]

What will make it collapse? [..] A completely new, simpler software design paradigm?

Exactly. OpenSource.

Linux runs on all major and most minor CPU-architectures out there. With Linux rapidly emerging as the standard (just forget about your stupid Winmodem, take a step back, take a deep breath and look at the big picture: *ALL* major chipmakers are supporting Linux from day 1. (IBM, AMD, Intel) Linux runs on everything from mainframes to embedded systems. Microsoft is still dominating the desktop, but on the desktop, there are already several signs of weakness: Linux becoming the standard-OS for 3d-modelling desktops is just one, Linux being adopted by a lot of governements another.), binary-backwards-compatibility will soon become much less important than it used to be and the way will be free for real new, real innovative CPU architectures.

64bit performance is ...

[nimrod_me]

The only good reason to switch to 64-bit computing is *memory*. The 4GB limit is a real problem for modern CAD tools.

Where I work (a semiconductors company) we use Sparc64 systems exactly for that reason.

In fact, the CAD tools manufacturers admit that their 64bit versions are *slower* than their 32bit software. The only reason a 64bit version is available is because a lot of customers are hitting the 4GB limit.

The reasons for the performance loss? Well, 64bit software may address more memory but it also CONSUMES more memory.

More importantly the processor's cache can now hold only half the data (if the same program is just recomplied its working set of int's is doubled!).

So for a given processor that have both 32 and 64 bit modes (Sparc, Hammer, PowerPC) the 32 bit mode is preferrable if the application can live with it...

Long mode and vm86 mode?

[frohike]

Maybe I missed it somewhere in the article, but I was kind of disturbed by the diagram showing what's possible in what modes. What it looks like they are saying is that in "legacy" mode, you can only run 32-bit code, and you must run a 32-bit OS. And in "long" mode, you must run a 64-bit OS, and v86 mode is not supported at all.

If a new x86-64 OS that takes advantage of the 64-bit extensions can no longer run v86 code, then this is going to be a serious hamper on adoption! There are still tons of reasons to run 16-bit code, like the BIOS-init in XFree86, DOS emulators, and of course we all know about Windows (though that is changing mostly with the adoption of NT as a home platform). I mean over time things are going to support 32-bit/64-bit code more and more (in the bios and such) but I thought the compatability was the whole point here...

Is this going to require some sort of trick like IBM used on the 286 with OS/2?* Can someone in the know post about this?

* Back when the 286 was brand spanking new and IBM was developing OS/2, they of course wanted to use the new protected mode. Only problem was, Intel didn't build in a way to switch out of protected mode! So if they wanted to run an old fashioned 8086 task (or any 8086 code) they ended up doing something that was described by the developers as "turning off the engine at 60mph" -- they'd actually completely reset the CPU and put in some glue to make it jump back into the OS image instead of the BIOS. Which is how it exited 286 protected mode :)

Intel's absurd plan for 64-bit

[Lank]

When I was an intern at Intel (summer 2000), I attended a small presentation at the end of the summer where they pitched 64-bit computing. One of the questions at the end was when it will be available on the desktop, and the answer, amazingly enough, was that it wouldn't be in the foreseeable future. And I'm just sitting there thinking "Bad move". Because they completely ruled out the geek factor. So I'm glad AMD is there to clean up after Intel's mistakes, and offer us a 64-bit desktop solution.