Slashdot Mirror
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."
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!
> "...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.
I bet it rips mp3s like a motherscratcher. Oh, you said "office"...
We really need your help
http://www.gofundme.com/help-sherry
I've read up on AMD's and Intel's 64 bit computing and its improvements over 32 bit. But the improvements over 32 bit just aren't worth the extra cost and administration time that home and small business users can afford. Lets wait until most large businesses that can afford the extra cost and hassle adopt 64bit before we home users do. Just wait and look for real advantages over 32 bit before we all jump on the 64 bit bandwagon.
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?
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...
Save your wrists today - switch to Dvorak
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.
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.
Furthermore, Intel supposedly has a fairly simple hack that they could implement to allow their 32-bit systems to address up to 512GB of memory. Still, the cleanest and most future-proof way to address the 4GB ceiling is a larger pointer
They forget to mention that even if you can have more than 4gb on xeon machine you cannot address any single block of more than 4gb. Forget about putting your oracle db into memory.
love is just extroverted narcissism
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
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 ;-)
Code, Hardware, stuff like that.
"Why not do it?" is usually a bad question, but in this particular case, I think it's a good one. If there is no performance penalty when running in Legacy Mode, and if the Hammer is going to be cheap (read: reasonably priced compared to the P4), why NOT buy it?
It doesn't hurt, and it prepares you for the future, a future that will come, now or later. This way there'll at least be a chicken... then we can just wait for the eggs to appear. It's foolish to think that any eggs will appear before the chickens do. Afterall, the only place you can get a chicken from before there are eggs, is from AMD's chicken replication facility.
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?
Accentuate the positive, don't waste your mod points on the negative.
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.
I'm not an engineer.
What I got from this article (well written, BTW) is that 64-bit processors provide more processing power--a concept different from speed. For instance, a Porsche can fly down the highway, but its engine has insufficent power to tow a 5th wheel RV. A Mack truck isn't speedy, but has a strong engine that can tow the heaviest loads up the same speed--more work is performed.
That would be why Apple's PowerPCs are still in the running, despite their clock slowness. They are falling behind fast as, after a point, speed does matter, in combination with improved processor power in the latest 32-bit Pentiums, and certainly the Xeon. Vector processing, such as Altivec, helps keep Apple competitive with their current chips--just barely. Many in the PC community await AMD's offering while IBM works on blending its POWER chip technology into a 64-bit PowerPC, with Altivec.
Imagine making the Porsche's engine more powerful but maintaining its speed advantage so it can haul ass as well as tow. Add nitro for extra ooompf (vector processing) and you have a dream machine. That's why it seems that 64-bit apps and processors seem to be such a holy grail.
That's my take on it. Clarification is always appreciated.
Vos teneo officium eram periculosus ut vos recipero is.
"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.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
but I'll be buying them if and only if they don't include TCPA/Palladium/Trusted PC Platform/Name of lockdown scheme of the week.
/. a while ago clarified this point quite a bit.
I dunno, TCPA seems kinda cool & useful. It doesn't lock down anything, it is basically just a way to encrypt/decrypt data without having the keys on a local file system (i.e. keys are stored on a black-box hardware). Spreading popularity of TCPA might also render Palladium and other DRM methods worthless. TCPA != DRM. Some IBM articles reported on
With TCPA, *you* would hold all the keys (since you can access your own hardware, hopefully), and no centralized entity (*cough* ms *cough*) would have anything to say about it.
Save your wrists today - switch to Dvorak
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.
A couple of months ago I bought used Digital AlphaServer 2000 5/250. I am running Tru64 5.1B(former Digital Unix) on it. I really like Tru64. It is very reliable, efficient, has great administration tools and excellent documentation.
The best thing however is that Tru64 and Alpha hardware are very well integrated. OS can detect and configure hardware automatically. It can also (together with the great SRM firmware) monitor various components in case of a (very rare) hardware failure.
One of the worst things in x86 world is BIOS. It's limitations practically force operating systems not to use its services. On the Alpha however OS can rely on SRM console. This is a very nice thing. Two examples (AlphaServer 2000 has these nice features):
1. SMP CPU failover: AS2000 tests cpus when it is doing its hardware diagnostics and if it finds a cpu that is broken it simply disables this cpu (provided that there is another cpu to use as the primary cpu).
2. Memory failover: AS2000 can detect bad pages in RAM and disable them.
Most x86 systems don't have these features, Alpha and Sun systems have. Linux is not the primary problem here, clumsy x86 hardware is. I have read somewhere that Linux can do something like memory failover (something similar at least), but my point is that the hardware (and BIOS) should do it, not the operating system. X86 would be so much better if BIOS was replaced with OpenFirmware or something similar.
There's more to this chip than that, too. The HyperTransport bus architecture they have created is very cool. Cheap, fast, and scalable for medium-sized SMP boxes. And 64-bit addressability, despite your assertion, is indeed useful today for servers, which routinely hit the 4GB barrier.
Backward compatibility is important, not only for existing software, but for existing compilers. Supporting long mode is nearly trivial. Just add the REX prefix in the appropriate places, remove deprecated instructions, support RIP addressing, and implement the ABI. Ok, that sounds like a lot, but compared to IA64 it's a cinch.
I'm under NDA, so I can't say much more, but I really like this architecture, and I want to get a dual myself for home use.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Since the Pentium Pro, there's been a feature called PAE (Physical Address Extensions) that allow for up to 64GB of memory to be supported on a system. The logical address space is still 4GB (typically 2GB of user space). Essentially there is an additional level of page translation which tends to slow things down somewhere between a lot or a little depending upon the application. It's never been all that popular -- supposedly because the applications that can use a lot of memory (e.g. large databases) tend to fall into the group of applications that slow down quite a bit under stress.
Does this chip support tcpa (and thus palladium) ? I think this is a kind of an important detail on the new cpu.
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...
It does when buying all new hardware is MUCH less expensive than buying all new software.
If buying a new machine means you need to replace every single piece of software you use, possibly losing access to old data in the process, most ppl are just not going to buy it.
-1 Uncomfortable Truth
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 :)
Cryptic Allusion - New Mac and Dreamcast Games!
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.
Gotta get me one of these!
Because the machine code *has* to change in the process, you can take the opportunity to redesign your instruction set to make it possible to design faster chips that use it. In AMD's case, they've added some registers and presumably cleaned up the sillier bits of the x86 instruction set. Intel has taken a different tack - they basically decided to wipe the slate clean and start again. As it turns out, they haven't really been able to make their clean-sheet design work very well yet.
Going to 64-bit code has its costs, also. Code density (the amount of machine code needed to do a task) goes down, so your memory system doesn't work as well. If a crucial bit of your program that fitted in the instruction cache in 32-bit mode doesn't in 64-bit mode, the 64-bit code would run considerably more slowly.
Speed is not the real issue here. The ability to work with large RAM sizes is.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)