Gear & Gadgets —

An Introduction to 64-bit Computing and x86-64

When I first heard that AMD had plans to extend the x86 ISA to 64 bits, I …

When I first heard that AMD had plans to extend the x86 ISA to 64 bits, I thought it was a terrible idea. Though x86 is the world's most successful ISA, it's also the world's most widely disparaged. Programmers, analysts, architecture buffs, and enthusiasts often see x86 as a leaden albatross around the neck of the entire computing industry, and like the Mariner's albatross we were all hoping it would just fall off at some point and slip quietly into the deep. But in spite of such hopes, I really knew better. In fact, I've argued elsewhere that x86 isn't going away anytime soon, and it no longer makes any real sense to gripe about its quirks from a performance perspective. I won't recap that argument here, but I can sum it up briefly.

Most of us would probably assent to the following statement: "there's a huge global market for mainstream business and consumer software, and the overwhelming majority of that software just so happens to use the x86 ISA." This statement is true, as far as it goes, but framing x86's role in the software industry this way misses an important point. In my article "The Future of x86 and the Concept of the ISA," I argue that a statement like the following would provide a more relevant assessment of the true state of the software industry: "There's a huge global market for mainstream business and consumer x86 software, and several smaller markets for software written to other ISAs." All discussions of the desktop prospects of widely ported operating systems (i.e. Linux) or of the possible effects of greater open source market penetration aside, this statement should still ring true to anyone who's acquainted with the present realities of the installed base of IT and consumer software.

If we think realistically about most of the world's commercial software not as "software" in the abstract but as x86 binary code, then it becomes apparent that improvements to the x86 ISA represent one of the most practical and cost-effective ways to advance and expand the x86 software market. Indeed, Intel's continuing extensions of additions to the x86 ISA prove just this point. Consider the move from 16 bits to 32 bits, the addition of the x87 floating-point instructions, and the addition of integer and then floating-point SIMD instructions. All of these modifications of x86 helped bring new capabilities to the PC, allowing it to find new applications and enter new markets. Thus, the ongoing adaptation of the x86 ISA to ever newer technological contexts has been one of the essential subplots in the past two decades' story of the "information revolution."

The present article outlines what AMD hopes is the next step in x86's evolution: x86-64. As we'll see, x86-64 is more than just a 64-bit extension to the 32-bit x86 ISA; it adds some new features, as well, while getting rid of some obsolete ones.

Note that this article deals with the x86-64 ISA only. The sequel will cover the specific implementations (Hammer, Opteron, etc.). And note also that the general discussions of 64-bit computing that make up the first half of the article are applicable to 64-bit platforms, not just x86-64. So those of you interested in the implications of a possible Apple move to a 64-bit platform like the PPC 970 might want to read at least the first half of the article.

Why 64 bits?

The question of why we need 64-bit computing is often asked but rarely answered in a satisfactory manner. That this is so is evidenced by the fact that the question keeps coming up again and again in online discussions of AMD's upcoming Hammer processor. There are good reasons for the confusion surrounding the question, the first of which is the rarely acknowledged fact that "the 64-bit question" is actually two questions: 1) how does the existing 64-bit server and workstation market use 64-bit computing, and 2) what use would the consumer market have for 64-bit computing. People who ask the 64-bit question are usually asking for the answer to question 1 in order to deduce the answer to question 2. This being the case, we'll first look at question 1 before tackling question 2.

What is 64-bit computing?

If you've read my introduction to the basic concepts in microprocessor technology, "Understanding the Microprocessor," then you're familiar with the code/data distinction and its implications. (If you haven't read that article, you might want to at least skim it and look at the diagrams before going any further.) Simply put, the labels "16-bit," "32-bit" or "64-bit," when applied to a microprocessor, characterize the processor's data stream. Although you may have heard the term "64-bit code," this designates code that operates on 64-bit data.

In more specific terms, the labels "64-bit," 32-bit," etc. designate the number of bits that each of the processor's general-purpose registers (GPRs) can hold. So when someone uses the term "64-bit processor," what they mean is "a processor with GPRs that store 64-bit numbers." And in the same vein, a "64-bit instruction" is an instruction that operates on 64-bit numbers.

In the diagram above, I've tried my best to modify an older diagram in order to make my point. A quick recap, in case you don't remember the original diagram: black boxes are code, white boxes are data, and gray boxes are results. Also, don't take the instruction and code "sizes" too literally, since they're intended to convey a general feel for what it means to "widen" a processor from 32 bits to 64 bits.

You should notice that not all of the data in either memory, the cache, or the registers is 64-bit data. Rather, the data sizes are mixed, with 64 bits being the widest. We'll discuss why this is and what it means, shortly. (I should've made the outgoing data stream on the 64-bit processor a mix of 64-bit and 32-bit data, but it would've been too much work to go in and change all of those boxes like that. As it is, I just used the resize function the whole batch and left it at that.)

Note that in the 64-bit CPU pictured above, the width of the code stream has not changed; the same-sized opcode could theoretically represent an instruction that operates on 32-bit numbers or an instruction that operates on 64-bit numbers, depending on what the opcode's default data size is. (Fore more on opcodes, see this page. We'll talk about the specifics of x86-64 opcodes in the next section.) On the other hand, the width of the data stream has doubled. In order to accommodate the wider data stream, the sizes of the processor's registers and the sizes of the internal data paths that feed those registers must be doubled.

Now let's take a look at two programming models, one for a 32-bit processor and another for a 64-bit processor.

The registers in the 64-bit CPU pictured above are twice as wide as those in the 32-bit CPU, but the size of the instruction register (IR) that holds the currently executing instruction is the same in both processors. Again, the data stream has doubled in size, but the instruction stream has not. Finally, you might also also note that the program counter (PC) is doubled in size. We'll talk about the reason for this, shortly.

Now, what I just told you above was the simple answer to the question, What is 64-bit computing? If we take into account the fact that the data stream is made up of multiple types of data—a fact hinted at in the first comparative diagram above—then the answer gets a bit more complicated.

For the simple processor pictured above, the two types of data that it can process are integer data and address data. Ultimately, addresses are really just integers that designate a memory address, so address data is just a special type of integer data. Hence, both data types are stored in the GPRs, and both integer and address calculations are done by the ALU.

110 Reader Comments

Hannibal, you wrote:"Note that I attributed the CS performance increase to x86-64's larger number of registers, and not the increased register width. On applications that do not require the extended dynamic range afforded by larger integers [...], the only kind of performance increase that you can expect from a straight 64-bit port is whatever additional performance you get from having more memory available."

This may not be entirely true. There certainly *are* other opportunities to take benefit of the extended dynamic range.

For example, I have seen implementations of 3D engines based on fixed-point arithmethic. The idea is to avoid the relatively slow fp operations, which are too accurate for gaming anyway. Fixed point math can be done in general purpose registers, the only limitation is the risk of overflow or underflow. With 64 bits GPRs that risk is obvously much smaller.

Also, you're assuming that game engines do not already use 64 bit math via a pair of 32 bits regs. This may not be true either. On i86 it's quite common that you end up using both edx:eax for a 32 bits mul or div instruction. Would that still be necessary on x86-64?

quote: So when you read Hannibal's article; you get the basics of the technology, and a rather one-sided view of what it will mean to Macs.

Time out. This was an article about x86-64. Exactly what does x86-64 have to do with Macs?

I'll give you a second to think about it.

If you guessed "absolutley nothing", you win a cookie. How can someone have a one-sided view of an issue that doesn't even exist?

This guy took one sentence from Hannibal's article ("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.") and is reacting to it like Hannibal was bashing the PPC archetecture, which, in typical maclot fashion, he must defend to the death.

Even though no one was attacking it.

Mind you he does bring up some interesting points as to the potential impact on the IT industry as a whole, but as soon as I read

quote: Since the PowerPC does not have an ISA (Instruction Set Architecture) designed in the 70s and 80's, and does not have register limitations that the x86 does, it already sees those potential performance gains. Even with the release of x86-64 the PPC will still have more registers and a cleaner and more advanced ISA.

I stopped taking him seriously. I mean, "duh." Since "it already sees those potential performance gains", Hannibal said that the Mac won't see the same gains that x86 does when going to 64bits. He even mentioned that the x86 archetecture is the most denegrated archetecture out there. He pointed out the biggest limitation, the lack of registers, and, because this article was about x86-64, how x86-64 works towards reparing that limitation by adding more registers. I don't remember reading anything like "OMG PPC SUXORRS" or "x86 OWNXORS POWERPC" in Hannibal's article, but maybe I missed it.

Oh, and Mr. Every, I hate to break it to you, but you're not going to be getting a Power4 in your next Mac. It'll be a PowerPC 970. Faster than a G4, mind you, but I'll give 10:1 odds that there'll be a few chips out there made by silly little companies like Intel and AMD, and based on an arcaic, limited archetecture that was designed in the 70s and 80s that will take your beloved PPC970 to school. In the real world it doesn't matter if something is better or faster in theory if it's not better or faster when you actually build it.

Edit: He also spends much of the article talking about how Hannibal is wrong because of the huge improvments we'll see from the 970 because of the improved memory (I assume 970 can actually make use of DDR?) and better ALUs over the G4. That's all fine and dandy, but what does that have to do with going to 64bits? Hannibal never mentioned the potential perfomrance benefit of, say, Hammer's integrated mememory controller or the 1MB L2 that will be available on SledgeHammer, because that's an improvment to the chip, not the archetecture, which is what the article was about.

As TigerKR said:

quote:Except for the fact that the CPU will be running (even with a longer pipeline) at a higher clock frequency, with additional L1, L2, and L3 cache, and on a faster bus! Smile All of which has inherantly nothing to do with a move to a 64bit CPU, but still, I'd say there are going to be performance gains from the other improvements coming to the 970.

Indeed, the PPC970 will be faster than the G4. It would still be faster than the G4 if it was a 32bit proc.

So yes, Mac users will se a performance boost when they switch to a 64bit processor...because the 64bit processor that they'll be switching to is faster than the current 32bit processor, not because of any improvements to the archetecture.

The point is that it's doubtful that recompiling 32bit code as 64bit code on the PPC970 will give any performance benefit over simply running the 32bit code with no changes. On the Hammer, however, as shown by the CS server, it does give a benefit..a big one in some cases.

When I first saw TigerKR's comments, I thought, "He's right. I should clarify that quote to make it clear that I'm only talking about ISA-related performance gains that come from software porting; I'm not passing judgement at all on the 970's microarchitecture or even on any of the other benefits associated with a larger address pointer."

But even so, I thought that the quote was clear enough--I'm basically saying that the PPC ISA is fine as it is, and doesn't need the kind of overhaul that x86 needed. I think that this implication is clear to anyone with a brain who's read the whole article. TigerKR is the only one who's commented on this, and he saw quite well what I was talking about--he merely pointed out how some might (and in fact did) take it.

Still, I should've corrected it earlier, before DKE got his panties in a wad over it and wasted hours of his life "refuting" me. Oh well, he'd have probably written the article anyway, and besides, it's best for society if such people keep themselves occupied in pointless but harmless pursuits--like flaming on the Internet.

quote:Time out. This was an article about x86-64. Exactly what does x86-64 have to do with Macs?

I'll give you a second to think about it.

Then Macs shouldn't have been mentioned at all. There is little use in arguing it any further. It's that simple.

quote:This guy took one sentence from Hannibal's article ("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.") and is reacting to it like Hannibal was bashing the PPC archetecture, which, in typical maclot fashion, he must defend to the death.

On the other hand we can always say that it seemed a bit careless of of Hannibal to even pass mention of it. I mean it depends on how you want to bake it, eh? Let's not start a flame war here. I'm just making some observations and some points.

quote:Oh, and Mr. Every, I hate to break it to you, but you're not going to be getting a Power4 in your next Mac. It'll be a PowerPC 970. Faster than a G4, mind you, but I'll give 10:1 odds that there'll be a few chips out there made by silly little companies like Intel and AMD, and based on an arcaic, limited archetecture that was designed in the 70s and 80s that will take your beloved PPC970 to school.

Well, you keep right on believing that lol Where is the focus and direction and commitment in moving the Wintelon *desktop* to 64-bit in the near future? There isn't any. Where are all the apps going to come from? Again, Hannibal never mentiond any of this. I'll break it down for you...

First, It's my belief that Intel is a little more than rattled now that IBM is getting back into the desktop game. Intel sees a huge shadow lurking over them - that of the IBM behemoth. You mention all this great gee-wiz-bang, great technology coming from AMD (where is Intel?), but what good is it going to be if the chicken-and-egg situation has arisen?

I'm going to copy-paste snippets from various posts from other forums I've posted to for simplicity's sake. Make of it what you will. Poke fun, whatever. The fact is that the underlying argument and reasoning still hold. Judge for yourself...

The fact is that Intel and the Windows world are the ones that seem to be in a bind. There are several significant articles that you should be made aware of. The Win-tel-on platform seems to be in a pickle, and I'm not so sure we'll be seeing a 5 GHz. Pentium within the next year or maybe even longer, and besides, what's it going to get you in terms of realized performance other than a bigger number to sticker onto a piece of silicon?

At this particular moment, It looks like a LOT of developers (and users) have hitched their wagon to a couple of "dead horses" so to speak -- the dead horses in this case seem to be Intel and Microsoft, BUT before you spark-up your flame-throwers, read the articles and my reasoning and then you be the judge.

(A little late with ditching the BIOS stuff aren't they? Anyway, it just sounds like a proprietary hack on OPEN Firmware... After all they NEED those DRM features, eh? It also implies that this feature is going to be implemented on their 32-bit CPUs first because Palladium/Longhorn (a 32-bit OS) will require it.)

Intel: Beyond gigahertzhttp://techupdate.zdnet.com/techupd...2902061,00.html(Funny how they seem to be parroting what Apple has been saying for YEARS already -- typical AND it would seem that the MHz. thy've been preaching for so long will likely come around to bite them ;-)

I've hinted at all this before -- prior to any of those articles even being written. I've brought it up on various other message boards and now Intel goes and makes it *official* with their latest comments to the press. The fact is that the Windows world (with respect to it's users) is in a bit of a bind, and Windows doesn't seem to be as *portable* as Microsoft had boasted. It would appear that you guys were sold on a rather dubious idea over a long haul. In any event current users of Windows desktop configurations may very well be stuck at 32-bit for quite some time -- until the end of the decade or even longer. Imagine that.

That means 32-bit Pentium4's for the foreseeable future for anyone running ANYTHING on desktop Windows. Currently, there is only a 64-bit SERVER version not meant for the desktop. Anyway, Let's look at the debacle a little closer.

Apparently 4 separate teams at Intel were given the task of coming up with a 64-bit desktop solution. After running a LOT of simulations they all decided that such a move would not be feasible -- for *them*. Here's the basics why:

There is no 64-bit desktop version of Windows (and it's unlikely that one is planned given Intel's latest press comment). So, the only 64-bit version of Windows is Windows Server 2003 and it only runs on the *Itanium* line and is only meant for *servers*. 32-bit apps running through emulation on the Itanium platform are EXTREMELY SLOW and anymore hacks to get it to run faster will likely increase the price and complexity and simply add to the gremlins that plague it, not to mention the additional expense/cost that it might incur.

Itanium systems start at over $10,000. Not only that, but IA-64 is a completely different architecture from what's already out there. In effect, it essentially *orphans* a whole TON of applications already out and running on Windows 32-bit boxes. And here's where it gets even more squirrelly for Windows users...

AMD *is* planning on offering a 64-bit desktop processor, but it's 64-bit server line has already been ignored by Microsoft. For the desktop AMD-X86-64 would be yet another completely different architecture from Intel's IA-64 or even Intel's Yamhill-X86-64. Will Microsoft begin to support and develop *another* version of Windows for Intel and another for the AMD x86-64 platform? It isn't clear that they will. It will more than likely be either one or the other... All while maintaining a whole sh!t-load of legacy 32-bit AMD and Intel boxes. In the end, it might leave AMD's platform to the LINUX camp. Offering yet another version of Windows for a completely different platform will just ADD to the confusion that a lot of endusers already face. Compatibility issues across each of those platforms will likely skyrocket as well. But this is only the start of the horrid situation. Consider that if it will be a considerable task for Microsoft *and* Intel to deliver a 64-bit *desktop* version of their wares (at a reasonable price to desktop-endusers) then where does that leave developers? A: In an even worse situation...

Developers will be asked to support, maintain and ensure complete compatibility of their drivers and apps across 3 different versions of Windows from legacy to the new current architectures. That's a LOT of versions for the same "Windows" platform! Win32, WinIA-64 and WinX86-64-AMD and WinX86-64-Intel (if it ever makes it).

What's more, none of these apps have even been dreamed up yet, and remember, emulation is out of the question because it yields poor performance for the $$ ;-) AMDs mode-switch doesn't seem to be that elegant of a workaround either. In the end, I doubt many developers will offer multiple versions of their applications for the same Windows platform. This leaves Windows users (and developers) stuck at 32-bit for quite some time since the developers have effectively limited their options by supporting what seems to be an increasingly stagnating platform. Intel has stated it, and Microsoft has stated it. There will be no 64-bit desktop version of Windows for the desktop or an Intel chip aimed at the desktop for quite some time. Period. And at the moment, AMD seems to be left with a processor but no apps. Then there is IBM...

IBM is offering the PowerPC 970. A 64-bit chip aimed directly at desktop workstations in multi-proc configs that will run older 32-bit code natively and arguably even faster at the same clock-speed given the overall processor improvements - a chip that Apple is likely to adopt for *their* desktop workstations. Furthermore, Apple is ALREADY running a UNIX-based OS with many commercial applications available.

Now, Suppose AMDs desktop CPU takes off and Microsoft endorses it with some as-yet-to-be-dreamed-up X86-64 version of a desktop Windows OS and developers all line up with their applications all debugged and ready to go -- In less than 3 years? Where does that leave Intel, the company *hell-bent* on making Itanium succeed? It forces Intel to come up with ANOTHER HACK that keeps the company solidly bound to the *x86 specter* for quite some time and they will need to go back to the drawing-board this late in the game. If Microsoft decides to chance support for *multiple* versions of their OS for different platform architectures while attempting to secure, bug-fix and ensure compatibility across said versions, then developers and consumers will be rewarded with even MORE of that confusion and chaos. Let's not forget Windows Palladium/Longhorn (32-bit) and the ton of Digital Right Management that's expected to be built directly into the hardware so the newest versions of Windows will be able to run. This will most likely be implemented on the 32-bit processors FIRST and the OS that requires it isn't expected to debut until 2005... That's 2 years.. Then there is the laptops to worry about. Can't put an Itanic or AMD-64 in one of those yet so, again, a fork... I mean let's face it, if FOUR (4) separate teams at Intel ran simulations and delved deeply into when 64-bit Wintel desktops will be viable and ALL came to the same conclusion that it will happen by the end of the decade at the earliest, then it's safe to assume that it is indeed the case.

I don't know what current AMD and/or Intel engineers beat you up and stole your lunch money every day when you were in primary school, but....damn, dude. Chill.

I'm not even going to bother countering anything. You win. There's a reason I never venture into the Battlefront.

Edit: No, actually, I will counter a couple things:

quote: IBM is offering the PowerPC 970. A 64-bit chip aimed directly at desktop workstations in multi-proc configs that will run older 32-bit code natively and arguably even faster at the same clock-speed given the overall processor improvements - a chip that Apple is likely to adopt for *their* desktop workstations. Furthermore, Apple is ALREADY running a UNIX-based OS with many commercial applications available.

You do know that that can be phrased ever so slightly differently:

"AMD is offering the Opteron and Athlon 64. 64-bit chips aimed directly at desktop workstations and low-end servers in multi-proc configs that will run older 32-bit code natively and arguably even faster at the same clock-speed given the overall processor improvements - chips that many OEMs and even some top tier vendors with much larger market shares than Apple are likely to adopt for *their* desktop workstations and servers. Furthermore, many of these OEMs already sell their computers runing a UNIX-like OS with many commercial and open source applications available."

So what was the point of that paragraph, again?

The lack of x86-64 Windows doesn't matter much. Linux has just as much, if not larger, market share on the desktop, and an insanely larger marketshare in the server rack than Apple could ever hope for. Even if Linux is the only x86-64 OS (and it won't be), nothing's really changed much. Perhaps it will be a waste in the consumer space, but Hammer looks to be a good performer in standard x86 code, anyway. x86-84 is just the icing on the cake.

But I don't think it's going to turn out like that. I'm not a psycic, but I'm willing to wager that x86-64 will be sucessful, and eventually, IA-64 will be forgotten. x86 and x86-64 will hold the low and mid end server market, Power will continue to reign supreme in the high-end server market, and PowerPC will continue to bask in the glow of an 18" Cinema Display running Photoshop.

Ok, Ed, so the overall point that (I think) you're trying to make is sound, and a good one. However, there's a few glaring errors in the stuff you copied from other forums.

1: "AMD *is* planning on offering a 64-bit desktop processor, but it's 64-bit server line has already been ignored by Microsoft"

See the link in the above post.

2: "In the end, I doubt many developers will offer multiple versions of their applications for the same Windows platform."

Why not? Cause it's hard to change a couple compiler options and recompile? You could even include the x86 and x86-64 binaries on the same media, and make it an install-time option.

3."There will be no 64-bit desktop version of Windows for the desktop."

AMD has stated that the Athlon 64 will be delayed until Q3 2003 for the release of a desktop 64bit Windows. Wether or not that's the true reason for the delay is debateable, but they have essentially admitted that there will be 64bit desktop Windows.

3. "It forces Intel to come up with ANOTHER HACK that keeps the company solidly bound to the *x86 specter* for quite some time and they will need to go back to the drawing-board this late in the game."

Yamhill's done, off the drawing board. It's even rumored, though not proven and highly unlikely, to be included but disabled in Prescott.

4. "If Microsoft decides to chance support for *multiple* versions of their OS for different platform architectures while attempting to secure, bug-fix and ensure compatibility across said versions, then developers and consumers will be rewarded with even MORE of that confusion and chaos."

Windows has a neat and even clever trick up it's sleave called the HAL, or Hardware Abstraction Layer. This makes it realitivly easy to port it across different platforms. You only have to make a custom HAL for each platform you want, and then, in theory, you can leave the rest of the code unchanged. This is why there was a Windows NT for Alpha available. It's relativly easy to port Windows, absurd as that may seem.

You are correct in that it takes some time for bug testing and validation, however.

5. "Let's not forget Windows Palladium/Longhorn (32-bit) and the ton of Digital Right Management that's expected to be built directly into the hardware so the newest versions of Windows will be able to run. This will most likely be implemented on the 32-bit processors FIRST and the OS that requires it isn't expected to debut until 2005"

Ok. For one, if there's going to be an x86-64 version of Windows available this fall, it won't be Longhorn. So it would follow that there will be an x86-64 version of Longhorn when it is released. Secondly, It's been rumored that Hammer includes some type of DRM and the last time I checked, Hammer was a 64bit processor.

But really, what logic is in that statement? The DRM required for Longhorn will be implemented on whatever processors their manufacturers want to run it. 32bit, 64bit, 42bit, 128bit, whatever. No one is going to say, "Let's ignore our 64bit processors and only implemnt DRM on our 32bit processors," because that would be beyond fucking stupid.

6. "Then there is the laptops to worry about. Can't put an Itanic or AMD-64 in one of those yet."

Yes, Itanic is way too big and hot for laptops, and the task they are designed for is not something you do with a laptop anyway, so I'll give you that.

However, AMD has already demonstrated SledgeHammer based laptops, and they will likely be available closely folling the Athlon 64 launch.

7. "I mean let's face it, if FOUR (4) separate teams at Intel ran simulations and delved deeply into when 64-bit Wintel desktops will be viable and ALL came to the same conclusion that it will happen by the end of the decade at the earliest, then it's safe to assume that it is indeed the case."

Viable for Intel, maybe. But AMD has proved on more than one occasion that they are not Intel, and don't play by Intel's rules.

8. "There is no 64-bit desktop version of Windows (and it's unlikely that one is planned given Intel's latest press comment). So, the only 64-bit version of Windows is Windows Server 2003 and it only runs on the *Itanium* line and is only meant for *servers*. 32-bit apps running through emulation on the Itanium platform are EXTREMELY SLOW and anymore hacks to get it to run faster will likely increase the price and complexity and simply add to the gremlins that plague it, not to mention the additional expense/cost that it might incur."

And

"Itanium systems start at over $10,000. Not only that, but IA-64 is a completely different architecture from what's already out there. In effect, it essentially *orphans* a whole TON of applications already out and running on Windows 32-bit boxes."

Yep, Itanium blows goats. EPIC and IA64 are cool tech on paper, but even as Intel improves the chips, I don't see it suceeding. It may hold on to a niche in the server space, but it's a really safe bet that you'll never see IA64 on the desktop (no matter how badly Intel may want it there), which is exactly where x86-64 is aimed. So what, exactly, does Itanium have to do with the sucess of x86-64 on the desktop?

Isn't overflow when a number gets too large (either positive or negative) and underflow when a number gets to small (has a large negative exponent)?

The article states: "Such situations [overflow/underflow] are very, very rare in integer applications. As an engineering student I never ran into this problem, although I did run into the somewhat related problem of floating-point round-off error a few times."

Since integers don't suffer from underflow, it would be a rare event indeed. The "somewhat related problem" sounds a lot like underflow. At least that is the way I learned it -- perhaps I misled?

quote:Originally posted by Hannibal:Should Apple move from 32-bit PPC to 64-bit PPC, Mac users should not expect the same kinds of ISA-related performance gains that x86 software sees when ported 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., because the PPC ISA doesn't really need these kinds of revisions to bring it into the modern era.

Thanks for the clarification. I knew you weren't talking about raw performance between the 7457 and the 970, but I wasn't sure about whether or not you thought there were serious problems with the PPC ISA. I know (based on your first 970 article) that you were somewhat critical of some of the design paths that IBM chose to take, and I wasn't sure if you thought that there were more possible problems for the 970 (that would need to be overcome).

I hope it wasn't my comment that got DKE all sparked up.

Back in the mid 90s B.A. (Before Ars), I thought DKE has some great articles at Macakaido (sp?). Its too bad he doesn't have the calm, focus, and integrity that he used to have.

jeffe -- you're confounding integer overflow with floating point overflow (non-normalizing floating point is bizarre and I won't talk about it.)

Basicly, integer overflow is an attempt to use the sign bit as a "value" bit, while floating point overflow is an attempt to do an "integer overflow" of the exponent field. Integer underflow is an attempt to "borrow" from the sign bit to go more negative, and floating point underflow does this to the exponent field.

I wouldn't tell anyone how to spend their time, but I will try to save you from wasting some of yours. You probably shouldn't bother with this Ed M. guy. He's a known Mac troll who posts prolifically everywhere, and even has occasion to email me with various Mac boosting (and PC-bashing) comments, to which I no longer respond. You could go round and round with this type of person for days before finally giving up. People like him and DKE are out to provoke people and to draw attention to themselves, and responding to them only eggs them on.

Yeah, judging from the style of that one post, I should have known better than to get into it with him in the first place. But, I just can't bring myself to let blatant FUD go unanswered, which is why I never venture into the BF. (or the Soapbox...or even certain threads in CPU/Mobo, for that matter) I'm weak.

Hannibal and c^2... You guys have me all wrong. Hannibal called *me* a troll? Yeah, right. First, I haven't resorted to name-calling. I figured Hannibal was bigger than that. Hopefully we'll have no more of it... Usually you'll find me on Mac-centric sites since I tend to ignore the PC-centric ones. Still I wonder if owning a PC or 2 along with a Mac is cause to stereotype someone as a troll? Anyway, I'll take it with a grain of salt. On another note, you guys might be interested in this *new* post over at iGeek. It's worth checking out

Oh, and c^2? Nice try at a rebuttal, I'll believe it when I see it. I won't even get into it with you about LINUX so, rest assured, it ends here. However, things aren't that rosy for the Windows crowd as per the reasoning above. Don't expect to see Windows desktop-64 anytime soon. Microsoft isn't about to burn their best-buddy, Intel by supporting AMD, first or otherwise without also supporting Intel. Anyway.. You'll see.

quote:Originally posted by c^2:Windows has a neat and even clever trick up it's sleave called the HAL, or Hardware Abstraction Layer. This makes it realitivly easy to port it across different platforms. You only have to make a custom HAL for each platform you want, and then, _in theory_, you can leave the rest of the code unchanged. This is why there was a Windows NT for Alpha available. It's relativly easy to port Windows, absurd as that may seem.

The viability of "Windows-64" (my nickname for "the 64 bit Windows variant for 'x86-64") will not depend on the HAL or the ease of porting the core system.

It will depend on the portability of 32 bit drivers. Imagine a driver that expects addresses to be 32 bits in size, that has to read input from an address beyond 4GB or write output there. Someone has to convince me that Microsoft has an ingenious solution to that problem, otherwise I predict that Windows-64 will take off slower than you expect. It's another hen/egg problem. There'll be third party hardware with no drivers, and not enough of an 'x86-64 market to make production and QA of drivers worthwhile.

I haven't been around long enough to know the history of Ars and DKE. I do realize, though, how dangerous it is to speak out for DKE here on Ars. :-)

So let me say just this: his style is occasionally demanding a lot of patience from readers. Maybe I'm too indulgent, but when DKE links cropped up over here, I actually bothered to read his texts, in whole, and I did not regret it.

The questions he asks are often worth thinking about, no matter wether you like his answers to them.

This specific article linked above is your special chance to read a DKE piece that has all the nice food for thought but none of the ... er ... obstacles for readers. DKE is a good writer when he takes the time to do it right.

DKE's article is reasonable (for once), but also slanted with his usual spin. He says that Macs will see the benefits from 64 bit computing much sooner than PCs....what he doesn't realize is that the benefits are limited to a relatively small fraction of apps that need the larger address space, and if you're desperate for 64 bit you will write your app for x86-64 (or much less likely IA-64). Whether everyone is using long mode a few years down the line is irrelevant, the point is that 64 bit will be used where its needed and nowhere else.

quote:Originally posted by IlleglWpns:the point is that 64 bit will be used where its needed and nowhere else.

No doubt about that. But the part about "where it is needed" is variable, not fixed.

Another point is that programmers at large will not start dreaming up new uses for 64 bit systems until they are available at large.

Yet another point is that 64 bits are needed even today in more niches that people are aware of. I can only speak for medical imaging where I have a bit of experience, but believe me, we are running into the limitations of 32 bit systems today. This will only become worse as the resolution of diagnostical imaging devices increases further.

Many of us everyday computer users have already run into various 2GB or 4GB limits of filesystems. Or we ran into limits of the tools processing those files. Sure, every one of those bugs can be fixed fairly easily. But on a 64 bit system, those bugs aren't there in the first place. The vanishing of these little quirks will be the smallest benefit of 64 bits that "mere users" will see.

I haven't read all the articles on your site so I'm going strictly on what you've written in your latest article. My point still stands btw. You say that Macs will have an advantage in porting apps because of the small userbase and tight control by Apple, which is true. But in the end the only apps that are going to be 64 bit are those that absolutely require it, rendering the whole argument moot. Whether the bulk of the code base uses long mode further down the line is immaterial because x86 processors already perform very well on 32 bit code.

quote:Originally posted by hobold:It will depend on the portability of 32 bit drivers. Imagine a driver that expects addresses to be 32 bits in size, that has to read input from an address beyond 4GB or write output there. Someone has to convince me that Microsoft has an ingenious solution to that problem,

They do. It's called a compiler. Together with header files that declare that pointers and things derived from them, like handles, are 64 bits wide. You do realize that unilke apps, you can't just run a 32-bit driver on the 64-bit OS? It has to be recompiled, just as the OS did. The only thing that will break here is stupid code that assumes that pointers are the same size as ints and longs.

quote:Originally posted by hobold:It will depend on the portability of 32 bit drivers.

They do. It's called a _compiler_. Together with header files that declare that pointers and things derived from them, like handles, are 64 bits wide. You do realize that unilke apps, you can't just run a 32-bit driver on the 64-bit OS? It has to be recompiled, just as the OS did. The only thing that will break here is stupid code that assumes that pointers are the same size as ints and longs.

Yes, I do happen to know what I'm talking about (to answer an implicit question). :-)

I you do, too, you know that a simple recompile still has to be thoroughly tested. A new compiler might introduce new bugs (or merely uncover existing hidden bugs in your source). Tha same goes for a new API, even if the changes are as small as a change in data type width. These are the resources any third party will have to spend.

Also note that there will be 32 bit apps running on a 64 bit OS. So there will already be mechanisms present that interface between 32 bit and 64 bit "views" of (portions of) main memory. Microsoft would be a lot better off if they could use those mechanisms to trick 32 bit drivers into running on a 64 bit system. Even if that meant that only 32 bit apps could initially use hardware with legacy drivers.

quote:Originally posted by hobold:you know that a simple recompile still has to be thoroughly tested. A new compiler might introduce new bugs (or merely uncover existing hidden bugs in your source).

The compiler has already been used on the 30+ million lines of code in the OS, so it's not like it's brand new. And it isn't that different from the x86 compiler, you know?

quote:Tha same goes for a new API, even if the changes are as small as a change in data type width. These are the resources any third party will have to spend.

Sure. On the other hand, you're overestimating the difficulty greatly. Porting drivers to x86-64 is very easy.

I wouldn't be a bit surprised if Driver Verifier on x86-64 doesn't have some features to help catch bugs in this area, too.

quote:Microsoft would be a lot better off if they could use [the WOW64] mechanisms to trick 32 bit drivers into running on a 64 bit system. Even if that meant that only 32 bit apps could initially use hardware with legacy drivers.

Here's where I have trouble with your assertion that you know what you're talking about, at least in terms of driver interfaces and environment. What you're describing isn't possible without a major architectural change in the OS. Drivers get involved with pointers to routines, and drivers and the system routines they call are loaded into system address space... which on x86-64 is outside of the 4 GB range that x86 code can address. Same for the data structures the driver allocates for itself out of nonpaged pool. Same for the OS-allocated buffers that are used in what we call "buffered IO". The file system cache, too, lives in system address space and a lot of IO is requested to and from that region, rather than to the buffer asserted by the requestor. etc.

Nor would it be possible to run a 32-bit driver in the "upper half" of the 4 GB address space allocated to a process running a 32-bit app. It might seem possible at first to implement such a scheme, but it isn't. The address range from 80000000 to FFFFFFFF is already spoken for, for good and sufficient reason. Exactly how it will be used, I don't think I can say; but I think several folks who have posted in this thread will like it a lot. Trust me on this.

quote:Originally posted by DriverGuru:On the other hand, you're overestimating the difficulty greatly. Porting drivers to x86-64 is very easy.

Porting is easy, we are in no disagreement there. My claim is that quality assurance will slow down third parties in providing Windows-64 drivers.

Remember, porting drivers was easy already in the days of WinNT on Alpha. Yet there were almost no drivers. Of course, the lack of masses of Alpha machines out in the wild didn't help the situation. But we'll face exactly the same hen/egg problem.

quote:Here's where I have trouble with your assertion that you know what you're talking about, at least in terms of driver interfaces and environment. What you're describing isn't possible without a major architectural change in the OS. Drivers get involved with pointers to routines, and drivers and the system routines they call are loaded into system address space... which on x86-64 is outside of the 4 GB range that x86 code can address.

You actually strengthen my point (of Windows-64 being adopted slowly) by hinting at the difficulty involved in convincing legacy drivers to function.

I didn't claim it was possible, but I do claim that AMD and Microsoft would be a lot better off if they found a clever hack that allowed them to close the "driver gap".

quote:Same for the data structures the driver allocates for itself out of nonpaged pool. Same for the OS-allocated buffers that are used in what we call "buffered IO". The file system cache, too, lives in system address space and a lot of IO is requested to and from that region, rather than to the buffer asserted by the requestor. etc.

Some very creative virtual to physical memory mapping would be the least thing necessary to get old drivers to work, I presume. And it might well be impossible, with the limited segmentation of 'long mode'.

But my point remains non-technical. What about the market adoption of Windows-64 boxes that cannot easily be fitted with third party hardware from the existing commodity pool?

quote:Originally posted by hobold:You actually strengthen my point (of Windows-64 being adopted slowly) by hinting at the difficulty involved in convincing legacy drivers to function.

I don't see how, since my remarks in that area were only concerned with the difficulty of getting 32-bit driver binaries to function. There are no analogous issues in simply recompiling them.

quote:I didn't claim it was possible, but I do claim that AMD and Microsoft would be a lot better off if they found a clever hack that allowed them to close the "driver gap". Some very creative virtual to physical memory mapping would be the least thing necessary to get old drivers to work, I presume. And it might well be impossible, with the limited segmentation of 'long mode'.

Segmentation doesn't enter into it; on NT on x86 it's practically turned off as it is. (99.9% of the time you're running in a common hardware task in which all the segment descriptors have a base address of 0, and size of 4 billion bytes.) But the only way I can see to make it work would be to constrain the OS, all OS code, all driver code, all OS data structures, etc., to 2 GB of address space. This would obviate many of the advantages the OS gets from running in long mode. Since we're doing this to better support 32-bit drivers used only by 32-bit apps... we might as well stay on x86.

quote:But my point remains non-technical. What about the market adoption of Windows-64 boxes that cannot easily be fitted with third party hardware from the existing commodity pool?

I think you're overstating the problem. The initial market for Opteron servers is not interested in buying a sound card at Fry's, a NIC from CDW, and a video card from whomever pricewatch.com says has the lowest price this week. They're going to be calling an OEM and ordering a complete box. And the box will ship with drivers for everything in it.

You're also underestimating Microsoft's commitment to x86-64. They were never strongly commited to supporting Alpha. Alpha (and, more important, its first few platforms) were really designed before NT showed up -- the first two editions of the Alpha Architecture Reference Manual didn't even mention the NT PALcode. So porting NT to Alpha, and maintaining the ports, wasn't a slam-dunk. DEC supplied most of the resources for the HAL ports and when Compaq lost interest MS said "ok, see ya."

But MS has a strong interest in not allowing one company (Intel) to control the hardware platforms on which their software runs. And supporting x86-64 is very different from supporting Alpha -- from everything I can see it looks like it was tailor-made to run an NT-family OS. I wouldn't be a bit surprised if AMD had gotten some input from the NT kernel team.

Now given that there is sufficient level of commitment from MS, they have a trivial way to ensure x86-64 support for drivers: Make it a requirement for certification and logo use. This should make drivers more stable even on x86; being able to recompile and run on x86-64 (and still pass all Driver Verifier, etc., checks) says a lot of good things about the code.

quote:Originally posted by c^2:Windows has a neat and even clever trick up it's sleave called the HAL, or Hardware Abstraction Layer. This makes it realitivly easy to port it across different platforms. You only have to make a custom HAL for each platform you want, and then, _in theory_, you can leave the rest of the code unchanged. This is why there was a Windows NT for Alpha available. It's relativly easy to port Windows, absurd as that may seem.

But it isn't THAT easy. The HAL is actually where chipset and bus interface dependencies go, and for most architectures (x86 vs. Alpha vs. etc.) there are several different HALs for different platforms.

But the kernel is where things like thread context switches happen and that stuff has to change too. The rest of the OS (called the executive - ntoskrnl.exe contains both the exec and the kernel), and all the other stuff like the API DLLs, drivers, and so on, in theory, only need to be recompiled. I expect that each time they do a port they find a few places where there are hidden hardware dependencies, and that these get fewer in number with each port.

I also expect that the Alpha 64-bit port was an easy stepping stone to 64 bits, because they already had a fully working Alpha 32-bit port and they only had to worry about the issues added by going to 64-bit addresses. Then when they did the Itanium port, the kernel and HALs needed to be changed for the new CPU and platform, but most of the 64-bit issues had been found and fixed.

DriverGuru, I think you are missing the point on a few things. The point that Holger, myself and DKE are attempting to make is that it will be a LONG time before we see X86-64 on the *mainstream* desktop. Intel already stated that Itanium wasn't going to migrate to the desktop at all, which is probably why they mentioned it in the articles I posted earlier. They specifically stated "by the end of the decade" at the earliest. AMD is another story.

Why hasn't Microsoft publicly and officially endorsed supporting AMD's X86-64 architecture for a 64-bit *desktop*? They don't even support them on the server level -- Remember, Windows-64 is strictly Itanium-based. Still, having 64-bit in a "desktop-style" computer IS NOT the same as having a 64-bit *MAINSTREAM* / consumer-oriented system. This is where the confusion seems to lie. I believe photo (Photoshop) and VIDEO will be what drives 64-bit on the consumer desktop. I've had past discussions with Chris Cox and he specifically said that 64-bit for Photoshop "would be nice" and well, we know where Apple stands with respect to desktop video.

You also mention that ". In the meantime the folks who really need it can just run the server-branded OS on the desktop. "

Well, that's all well and good if the apps they require are available, but then there might be another limiting factor... Price.

Again, I think Apple will have the upper hand this time around after adopting the 970. Also it's worth keeping in mind that the 970 is only the beginning of a new family of processors. There will surely be others to follow. A Power5 derivative is no doubt already in the works... Which raises another question... If we stop and think about it, what's stopping Apple from licensing OS X to run on IBM's mid to high-end hardware? I'm betting it could be a possibility. Just some musings.

quote:Originally posted by Ed M.:DriverGuru, I think you are missing the point on a few things. The point that Holger, myself and DKE are attempting to make is that it will be a LONG time before we see X86-64 on the *mainstream* desktop.

What does "mainstream" desktop mean? In terms of availability and affordability, I think it'll be around the end of the year.

In terms of share of installed base, certainly it will be a LONG time -- as well it should be -- since the current *mainstream* desktop user doesn't tax a fractional-GHz PIII.

Anyway, so what? Does it need to be found routinely on desktops to succeed? What's the high-end desktop user's alternative going to be? Itanium? Sure....

quote:Why hasn't Microsoft publicly and officially endorsed supporting AMD's X86-64 architecture for a 64-bit *desktop*? They don't even support them on the server level -- Remember, Windows-64 is strictly Itanium-based.

In its current releases, yes.

You really have no evidence here, only a lack of evidence from MS. Exactly what level of "support" are you expecting, given that the hardware hasn't shipped yet? Is there any motive you can intuit from MS's lack of public announcements here, OTHER than "Microsoft isn't going to support it at all?"

You don't think it's coincidence that Opteron's planned launch date, and that of Windows Server 2003, are just two days apart?

If MS isn't planning to support Opteron in servers, why is there support for x86-64 in the debugging tools package? You think someone there just did the debugger support on a whim?

quote:You also mention that "In the meantime the folks who really need it can just run the server-branded OS on the desktop. "

Well, that's all well and good if the apps they require are available,

Remember, it will run existing x86 apps. Faster than an x86, apparently. The OS benefits from running in a larger address space and from the additional registers. From the architecture manual, it looks like a lot of things like thread context switches and page fault resolution are really tailored for the NT family too.

quote:but then there might be another limiting factor... Price. [link]

Maybe I missed it, but I didn't see any evidence there that the Opteron version would have a particularly high price. If MS wants to push it you'll be able to buy a low-end "server" box, with the server edition bundled in, for some ridiculously low price compared to the OS's list price.

quote:Again, I think Apple will have the upper hand this time around after adopting the 970.

And when will that happen? And how long after that before 970-based Macs are on the *mainstream* desktop?

quote:Also it's worth keeping in mind that the 970 is only the beginning of a new family of processors.

And the Opteron isn't? Ok, it isn't a totally new architecture, but you don't think this first one is the only one they'll make?

quote:There will surely be others to follow.

My thoughts exactly.

quote:If we stop and think about it, what's stopping Apple from licensing OS X to run on IBM's mid to high-end hardware? I'm betting it could be a possibility. Just some musings.

Of course it's a possibility. Will that hardware run existing Apple apps? If not, where are the apps? And what does this have to do with the viability of Opteron?

quote:Originally posted by DriverGuru:Now given that there is sufficient level of commitment from MS, they have a trivial way to ensure x86-64 support for drivers: Make it a requirement for certification and logo use. This should make drivers more stable even on x86; being able to recompile and run on x86-64 (and still pass all Driver Verifier, etc., checks) says a lot of good things about the code.

You are right. I overlooked the obvious possibility of using a non-technical solution to a non-technical problem.

And your point about additional 'stress testing' of the driver code is also a good one. When all third parties are forced to do the work, they are at no competitive disadvantage with respect to each other (with respect to Microsoft, well ...).

It's weird that Apple would switch to x86 from PPC. You would think that they would have gone to x86-64 instead of taking a step backwards. It doesn't make sense to limit your self in processing. Technology should always move forward.

Originally posted by Althage:It's weird that Apple would switch to x86 from PPC. You would think that they would have gone to x86-64 instead of taking a step backwards. It doesn't make sense to limit your self in processing. Technology should always move forward.

The Intel Core processors are x64, and OSX was a 32bit application on PPC. It's rumoured that 10.6 might be 64bit only, but, as with all future plans Apple, that's just a rumour.