From Ars Technica: “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.“
An Introduction to 64-bit Computing and x86-64
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
One of the most well written and informative articles I’ve seen on modern processors and 64 bit computing *ever*. Read this article and then go and read Linus criticism of Intel and the Itanium again. This article makes very clear that AMD is likely to have a market busting product coming up. Intel better pull some heads out of the sand
In the part of article that quotes Tim Sweeny:
“And our next-generation engine won’t just support 64-bit, but will basically REQUIRE it”
Well, from the frame rate im getting running unreal 2 i would it already does 😀
In the part of article that quotes Tim Sweeny:
“And our next-generation engine won’t just support 64-bit, but will basically REQUIRE it”
Well, from the frame rate im getting running unreal 2 i would *SAY* it already does 😀
Intel can’t possibly be stupid enough to think that people won’t buy 64-bit desktop processors if they are affordable like Athlon XPs are today. Having tons of RAM is the best thing you can do to improve performance in these days of highly abstract programming frameworks (Java, .Net, etc.). I bought a new 512MB DDR stick for about 100 bucks at the local shop the other day, and now I can multitask much smoother than I could with just 256MB of RAM. Imagine being some kid devloping games who uses Photoshop, 3D Studio Max, Unreal content tools, etc. As Tim Sweeney from Epic said (as quoted in the article), people like this are already encountering limitiations with 32-bit. You think some poor teen game developer in Iowa is going to shell out 4000 bucks for an Itanium CPU (the CPU alone!). No! He is going to buy an affordably priced and compatible with 32-bit, 64-bit CPU. Ahem, Hammer! Anyway, I imagine Intel has something in the skunk works and will pounce with their own similar solution if AMD gains a lot of momentum on this. If they don’t, well, Intel is not going to be looking so healthy for much longer …
I believe that some of the features that AMD has removed should continue and be extended to 64Bit, like protected mode segments and so. These features were really handy, and allowed easy isolation of tasks. I am an OS developer myself and allways considered pm segments to be extremely useful. Taking this, nothing else stops me from moving to another architecture like PowerPC in IBM’s Power 970 (64Bit) has it as the same features and a faster CPU.
…AMDs 64-bit processor is going to have a total of 16 general-purpose registers.
That brings it on the level of, say, a 68000 from 20 years ago.
nothing outside FPGA reconfiguring hardware impress me now. looking at processor news lately is like reading a specialised magazine about paint sold at renovation store.
Ho, and bring me base 3 logic!
I always enjoy reading Hannibal’s articles, check out his other articles eg. about the G4
I agree, this article is very easier to understand and read. Thanks Kenny for submit this article!
I’m pretty sure Intel has stuff working at one of their Fabs… Don’t worry, Intel’s R&D team probably already whipped up an x86-64 Pentium 4 just in case, among other things of course.
The Hammers are making quite a stir in the media, but acceptance is still quit low (though this could change, AMD’s CEO claimed they are working with the “BIG 5”).
If the 64-bit desktop market ever looks good to the guys at Intel to make a strategic move on it… They will.
AMD has to be the one that makes the right moves… Another delay, another mistake, another bug, can pretty much wipe AMD off the map for a while.
@Lars: Didn’t you read the article? x86 chips have a lot more than 8 registers. It’s just that only 8 (now 16) are visible to the compiler.
@SomeGuy: So are you guys (and by “you guys” I mean the five people in the world that actually *like* segmentation) a close-knit group? Do you have like GDT-parties and stuff? Segmentation is the worst monstrosity ever invented. Paging rightfully killed it. I don’t think that any other modern architecture (PowerPC, Alpha, MIPS, Itanium, SPARC) has a segmented mode. As an OS developer, I think what you really like is not segmentation, but extra VM features beyond standard paging. Almost every other architecture (especially Itanium) has extended VM capabilities that are extremely useful for sharing between protected memory contexts. The only thing similar in x86 is the segmentation mechanism, which is why some kernels (like L4) use it to accelerate operations like message passing. Unfortunately, segmentation is already pretty useless in modern x86 chips. Any non-trivial use of the segmentation mechanism (changing segment registers, for example) incurs a significant performance penalty, and high-speed trap instructions like sysenter/sysexit basically ignore everything except ring 0 and ring 3.
Apparently, I’m spreading misinformation. The PowerPC does indeed have something of a segmentation mechanism. However, it doesn’t appear to be much like x86’s mechanism. It seems like it’s more akin to the BAT registeres, which allow large blocks of addresses to be mapped to specific regions. This type of stuff is useful for stuff like mapping in the kernel, which is large, contiguous, and static. Can anybody with more knowledge of PPC segmentation chime in here?
What exactly is the problem with segmentation? I’ve never heard a good answer to that. I don’t buy the “it has overhead” part because paging does too. Accessing a different segment is no worse than accessing a different page. And “it has overhead” has never stopped people from using higher level languages.
I think people associate segmentation with a fixed size of 64k, and that’s where all the hatred for it comes from.
I think people associate segmentation with a fixed size of 64k, and that’s where all the hatred for it comes from.
In short: Yes.
It’s not such a terrible idea in itself, it’s just that the Intel implementation was so bad.
> It’s not such a terrible idea in itself, it’s just that
> the Intel implementation was so bad.
I don’t really think the intel implementation was bad, but I do believe it could be just a little bit better. 🙂
> incurs a significant performance penalty, and high-speed
> trap instructions like sysenter/sysexit basically ignore
> everything except ring 0 and ring 3.
You don’t really believe that, do you? You can’t possibly be thinking that all OS’s are unix like and written in C or something like that… I said I’m an OS developer, not a *nix kernel developer.
The fact is that most of the *nix were made portable, and therefore protected mode segmentation could not be used because it only exists in x86. That doesn’t mean segmentation ain’t good. I believe segmentation IS GOOD.
You don’t really believe that I would be developing an x86-only OS and not be using the full power and features the architecture has to offer, do you? In fact i’m combining every feature the architecture has that can improve my OS performance and features, I’m even combining segmentation and paging. And I bet that if AMD developed x86-64 with 64Bit segmentation, they could do it a LOT BETTER than Intel did, make it a lot faster and eliminate a lot of overhead. Don’t you?
> Do you have like GDT-parties and stuff?
I resent that!
> Segmentation is the worst monstrosity ever invented.
Well… try it. But try it hard.
> As an OS developer, I think what you really like is not
> segmentation, but extra VM features beyond standard
> paging.
Wrong. What I really like is the complete task isolation and control, by providing each task it’s own 4GB addressing space. Message passing and other stuff can allways be provided easily, and paging can be used in conjuction with segmentation to obtain the perfect model.
Didn’t you read the article? x86 chips have a lot more than 8 registers. It’s just that only 8 (now 16) are visible to the compiler.
And that’s the point. All these registers exist only behind the scenes with the sole purpose to squeeze performance out of programmer architecture which was already braindead by the time it was developed. They do nothing to remove the register bottleneck in the first place. The programmer/compiler has no direct access, but instead has to hope that next chip generation’s implementation doesn’t mess up his code, carefully constructed to tickle the best out of the register renaming machine.
Stupid. Stupid. Stupid.