Slashdot Mirror
AMD Sledgehammer (64-bit CPU) Preview
ruiner writes, "There's a sweet AMD Sledgehammer preview up at AMD Zone. They discuss the need for a 64-bit CPU, and what operating systems would support it. "
← Back to Stories (view on slashdot.org)
Even NFS, which can be implemented using very little memory for the application size, the computer doing the serving can really use lots of RAM. Why? Cache. Disks are much slower than modern networking. If you have four gigabit ethernet connections coming out of a host, that's a maximum throughput of 500M/sec. MAXIMUM SCSI rates are in the 160M/sec rate nowdays. And that's not taking into account latency and stuff. On the server side, cache really, really helps out. So, many times it's beneficial to stick several gigs of ram into the machine. Even if you're only using, say, 64M for program space, having the additional 15.9 G for cache can really help out.
-- Erich
Slashdot reader since 1997
I do not see the poor x86 performance as a serious issue. GCC has already been ported to produce native code, and Linux is ready to go. There is presumably a bit of glibc work left but I fully expect that a full native distribution will ship the same day as the CPUs. Full native == no x86 performance problems, and full native == full software availability. The real problem with Itanium is that its performance is going to disappoint, even in native mode. By the time Intel works out the problems inherent in any new processor, not to mention the problems with their supply chain, their competitors will be well ahead of them, shipping stable, mature products with superior performance and, thanks to not having to supply two chips in one, at lower cost as well.
Add a little "64-bit" gloss to Windows 98, and AMD might gain some serious market share here.
Who's going to do this? Microsoft doesn't have any incentive to do it; they're already selling all the winblows 98 they want. They're going to be far too busy trying not to lose their shirts to Linux in the IA-64 sphere to give two shits about a warmed-over 64-bit AMD with miniscule market share. Anyone expecting to see winblows on native Sledgehammer is in for a nasty surprise. Linux probably will be ported at some point, but by that time I doubt it will still be in production.
If it's priced the same as Intel's 32-bit chips
It won't be. You know it, I know it, AMD knows it.
On the other hand, if it's more expensive than a 32-bit chip and doesn't offer any real advantage to the average user, what's the point?
Bingo. This is a product in search of a market. The engineers (and probably the lawyers too, but that's just rampant speculation) told the droids that it would be easier to produce a 64-bit x86 processor than an IA64-compatible one. So that's what they're going to do. I don't think AMD ever even considered something non-Intel compatible, it was more a question of which Intel to be compatible with. They just wanted to say "we have a 64-bit processor too." Well, big deal, AMD; everyone has a 64-bit processor these days. Having the weakest one of all isn't going to turn any heads, unless it's at the next shareholders' meeting.
Really? I don't think so. I think they can gain little but lose a great deal. The ultra-low-end market is their strong point, which will be totally unaffected by IA64 for at least 5 years. The high end, which is supposedly targeted by IA64, already has a strong competitor, Linux. If M$ gets their act together, they can possibly hold their current market share. If not, their days of producing anything but low-end software for home users will be over. They aren't going to gain much, no matter what happens. First, Itanium won't offer the performance of its "traditional server vendor" rivals. So it's not going to grab much share from them, if any. Most of the IA64 share will come out of the existing peecee market. People running Linux on peecees aren't going to run out and buy M$ for IA64. The most M$-optimistic outcome is that current enntee users migrate en masse to IA64/enntee. In which case M$ holds its current market share, which, in this environment, isn't very high (37% or so last I saw). If any current enntee/peecee user needs more performance but is unwilling to leave Intel, he may find that his only choice is Linux - that is, if M$ doesn't get their IA64 OS done in time. In that case, M$ loses more market share to Linux and misses the opportunity to gain a foothold in the IA64 world.
So what can they gain? Not much. They might convince a few of the dumber IT manglers that Itanium + enntee can compete with traditional high-end solutions, or maybe that it's better than Linux (unlikely given current trends), but this certainly isn't going to help them very much. At best, they stand to gain a very small chunk of the market. At worst, they stand to lose their entire presence in the non-home market. Given this fact, I join you in surprise at their decision making. Not because they have so much to gain but because they have so much to lose.
If anyone comes out of IA64 a big winner it will be Linux, which will be the only option that runs on current peecees, future peecees, and the majority of the workstions/servers using non-Intel CPUs as well. It certainly won't be M$, and it probably won't be Intel. During this time I fully expect Intel to lose a good chunk of their customers to the traditional RISC vendors (Sun, SGI, etc) and people like IBM. Itanium will flop initially at least, and Intel isn't going to come out of it looking good. Nor is AMD, especially if this Sledgehammer really represents their primary plan.
I sorta wonder if the whole "Sledgehammer" hype is just FUD smoke that AMD is blowing at IA-64.
Seems like a pretty good theory. But I'd FUD better than that if I were AMD. Of course, there are plenty of good reasons to have F, U, and D about Itanium that have nothing to do with AMD.
The article did mention AMD adding support for 16 or 32 directly addressable floating-point registers, which would help in large part to relieve the register pressure of IA-32.
-- Too lazy to get a lower UID.
I forget what they were called, now, but Intel's version of the future was *not* the 8086, but the 8600 (?). The 8086 was just supposed to be a transition chip for which 8080 code could be easily cross-compiled. But silly IBM made a PC with the thing, and those three letters took over . . .
The 186 was meant for controllers, but Radio Shack and a couple of others used it in desktops.
The 286 would buy a couple of more years, and iirc, the 386 was supposed to be the flat-out end of the line (and a lot further than had been planned at the time of the 8086).
Then a team managed to come up with the 486, and kept going a while . .
AMD doesn't have the market presence to make a new standard archtitecture. They don't have the legal rights to make a clone of the IA-64 chips. Thus, they have to stick to the x86.
They have extended x86 to include a 64-bit mode. No, the instruction set isn't really "RISC", but that doesn't mean much anyway. The internals of x86 chips for some time have been RISC-like processors, with complicated decode/translation units on the front-end.
The instruction set that you use to program a chip says little about the instructions that are actually getting executed by the core. In the decode, the x86 instruction is cracked into smaller instructions to do a simple load, store, or compute. I believe that AMD has done this since the K5, and Intel has done this since the PPro.
Even the old VAX (whose instruction set was as CISC as CISC got) translated its instruction set down into microcode for what was essentially a load/store back-end. That is when people realized that that decode complexity could be moved into the compiler instead, and everyone started talking about RISC.
AMD has already worked out the problems of dealing with an x86 instruction set. Decode on the Athlon is nastier than it should be as a result, but it works. The technological problem has been solved. To AMD, a more complex decode unit is a small price to pay for compatibility with the massive x86 code base.
Given Intel's slip-ups with Merced, its just possible that AMD might gain some marketshare with this architecture. From an aesthetic point of view, it is unfortunate that it is still a child of the x86, but that is the fate of the PC. IBM made a standard with DOS/x86, and that standard holds to this day in Windows/P6.
--Lenny
We're seeing a true fork in the development road, and I wouldn't expect an application compiled for a 64-bit AMD processor to execute at all on a 64-bit Intel processor. And an app compiled for a 64-bit Intel processor certainly will not execute on a 64-bit AMD processor.
Intel (& HP) started with a fresh instruction set architecture for IA64 -- which means they don't need to worry about dedicating transistors or limiting design considerations to supporting decisions made 25 years ago (though I understand Itanium will have an IA32 emulation mode). Further, IA64 is using an advanced form of VLIW. AMD is creating a 64-bit extension to IA32 -- superscalar, not VLIW. Which is why they will be mutually incompatible. Sledgehammer will be to the today's AMD & Intel processors what the 386 was to the 286. Itanium will be to today's AMD & Intel processors what the 68K was to the x86.
Christopher A. Bohn
cb
Oooh! What does this button do!?
In the sense that Sledgehammer is supposed to be a 64-bit extension to IA32 (similar to the 386's extension to the 16-bit instruction set in the 286), the existing gcc will compile code that would execute on Sledgehammer (just as code compiled for the 286 would execute on the 386 -- heck, I've got code compiled for my old 8088 executing on a Pentium). It won't be the most efficient use of processor or memory, but it'll execute. I'd also expect that 1) a 64-bit extension to the IA32 will quickly find its way into gcc even without AMD's help, and 2) AMD will help -- it'd be the smart business decision.
Christopher A. Bohn
cb
Oooh! What does this button do!?
The upcoming 2.4 kernel will handle 64 GB of RAM.
But to do it right you do indeed need a 64-bit processor.
As for there being no memory limits with 64-bit processors, oh really? The people who put together data warehouses can put the lie to that one!
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
It definately was a good survey piece, but anyone notice that there were wayyyyyy to many WAGs (wild-ass-guesses) in the article?
(Offtopic): Does anyone know where I can find a good technical description of AMD's roadmap? I'm trying to figure out what kind of SMP Athalon I can expect to possibly buy in Q4, what the new chip designs will incorporate, L2/Bus combinations, etc.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
The 68000/68010 had 16-bit internal data paths and three 16-bit ALUs. Motorola advertised it as a 16/32-bit processor. The 32-bit features were done with microcode. The 68020 was the first fully 32-bit member of the 680x0 family.
Mea navis aericumbens anguillis abundat
Check AMD old PR. One of the first presentations on Sledgehammer was actually given to Alan Cox and Co. If not the first one.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Correct. Bseides the most important point. No more of this ugly emulation of a HP calculator for FPU. It is at best inappropriate for the modern world.
On the less important points - 32 to 64 integer and 32 to 64 addresses:
have a look at the 386-Pentium tech reference. You can see that almost anything besides a few control registers and some stuff related to wierd 48 bit addressing modes can be happily extended to 64 bits.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
In the market will exist two mainstream 64-bit processors, the AMD Sledgehammer using an extended x86 instruction code and the Intel Itanium using the IA-64 instruction code. Consumers are screwed. Right now the P3 and Athlon are rad because they can run all the same binaries. In the 64-bit universe you'll have two options, chip optimiuzed code or huge binaries with 32-bit x86 instructions and a few optimized 64-bit instructions (like writing a binary with support for SSE and 3DNow!). My guess is that the software guys will tell the chip guys what they can do with their silicon. Current software and OSes will fork into at least two camps. The only recourse for people will be open sourced software or NeXT-ish packages containing binaries and libraries optimized for said processor. This is going to create so much damned market confusion. In a couple of years there's going to be half a dozen different hardware architectures in the mainstream market, again. I wonder if this is a good or bad thing, I suspect for most people it might be a bad thing being as some software companies will only support x number of OSes and chip architectures. I figure what will probably happen is smaller software companies that can only support one or two different systems will get eaten up by the Microsofts because they won't be able to afford to stay competitive in enough markets. Hmmm.
I'm a loner Dottie, a Rebel.
Although I found the non-x86 FPU and flat FPU details interesting, there is a lot more to all this.
I think the site is unaware that GCC has been capable of 64-bit compilation for a long time and that 64-bit Linux is already here with the Alpha (several years mature, thanks to an industry who is using it). The basic IA-64 port and compiler is already completed (with optimizations slowly but surely being added). 64-bit Linux has a solid foothold in IA-64's release.
But does that count AMD out? No. I do not see it too difficult for AMD to _extend_ the 32-bit GCC compiler to support its 64-bit extensions. It won't be a full-up project like the IA-64 port and compiler which has radical differences. Remember, Sledgehammer is all about compatibility, and that is in AMD's favor. It will be easy to extend Linux to support some of the 64-bit functions of Sledgehammer, first starting with the kernel, then the apps later on (as 32-bit x86 dies).
But the true irony of all this is that it is in Microsoft's favor too! Almost a catch-22 if you dislike the Wintel duopoly. If IA-64 succeeds, Linux has that much more of a chance of wiping NT off the planet in the server and workstation relm. If Sledgehammer succeeds, Windows has a much better chance of going 64-bit with the little effort traditionally found in their Windows products.
It's going to be interesting to see how this all unfolds. But on thing is for sure, just like the Alpha, Linux will allow IA-64 to sell regardless of any Windows support.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
this is so discussion is so lame.. *sigh* ...
Then why participate at all?
SCO Unix was XENIX, which was a Microsoft Product.
Partially true, however XENIX was a 16 bit product at the time that Microsoft sold it off to SCO. Also by the time the product was renamed 'SCO UNIX' and became 32 bit, the XENIX kernel had been largely replaced by SVR2 code. The closest XENIX came to 32 bit when it was still a Microsoft product was the 68K versions, which were a 32 bit internal and 16 bit external processor (the first true 32 bit 68K, the 68020, wasn't out at that time). XENIX was also itself largely based on the Bell Labs Version 7 experimental version of UNIX, so Microsoft can't really take much more credit than having done a port.
The truly sad thing is it took so long from the time Microsoft abandoned XENIX to the time that NT came out, which was around 10 years. Microsoft certainly could have had a 32 bit OS in 1986 or 1987 when the 386 started showing up had they been on the ball. Heck, they bailed out on OS/2 before a workable 32 bit version of it came out, which is part of the reason they were so late to the 32 bit game.
We didn't see a true 32 bit OS until NT came out.
Actually, that would be better worded as "The Microsoft world didn't see a true 32 bit OS until NT came out".
There were a lot of true 32 bit OSes out before NT, even on the x86 (SCO UNIX, Microport UNIX, Interactive UNIX, etc). On non-x86 processors there were dozens, dating back to at least the mid 70's. Since you mention DEC specifically, an example would be VMS. For that matter, they had Ultrix (which started as a thinly disguised 4.3BSD port) out in the mid 80's.
I'm actually sure you already knew that, but some of the people out there who know nothing but Microsoft might not.
As others have mentioned, the Itanium and the Sledgehammer will probably not play well together at all. What I have read says that the Sledgehammer will be leaps and bounds better than the Itanium at running existing 32 bit apps. This is due to the fact that AMD is building on top of x86 and Intel is starting something entirely new. There was a great article on Toms Hardware about how Intel is very afraid because the 32 bit performace of the Itanium is just piss poor. The theory is that Itanium is a server CPU and should only be running a handfull of apps. But sooner or later those server CPUs trickle down to consumer CPUs. And consumers tend to frown on replacing every app they own.
-B
I can just imagine the amazing confusion that will happen when they get around to trying to explain to the average consumer about "this type of 64 bit computer" as opposed to "that type of 64 bit computer". And how much heartache it will cause consumers to try to figure out *which* applications they can run.
It seems to me that AMD, by choosing a non-IA64 architecture to compete with Intel's 64 bit processors, is basically splitting the market for themselves. Average consumers looking for a next-gen processor will most probably not understand the difference, and (maybe) pick one randomly or (maybe) go with the one with the better known name (Intel, right now). Much confusion abounds.
Also, by using an extension of x86, AMD puts software vendors in a bind as well. Instead of allowing all the vendors to just recompile their software IA-64 compatiable, they'll have to keep Sledgehammer and IA64 versions. Much confusion abounds again.
I think that if they could, AMD should have joined the IA-64 alliance, and released a IA-64 compatitable processor.
If I were AMD I would be working fast in the SMP motherboard. I'm positively sure that everyone is interested in them.
Good question. I think it's fairly safe to assume that they will only be compatible in the 32-bit modes. For 64-bit purposes, add one more architecture that will have to be supported, if successful. In reality, of course, it is usually not that bad, as this may increase the chance that another 64-bit architecture will fall by the wayside.
Geeky modern art T-shirts
The author mentions the need for a single process to map over 4GB of ram. This is really only a very small piece of the puzzle though. The OS can really benefit from seeing more than 4GB. Win2k supports Intel's PAE (36-bit addressing on IA32) for up to 64 GB of memory. Win64 on Itanium/IA64 supports up to 16 TB of memory. This greatly reduces swap and allows massive disk caches. Programs can be left in memory all the time. Swap is the biggest killer of time, cpu, and overall performance. File system caches can grow so that the second time a program or library is loaded it comes right out of cache.
Consider a WebServer/Database system. The web server can keep all of its static files in memory. The database can keep all its structures in memory. In Win2k applications can allocate physical memory that will never be moved or swaped out. This gives applications that need it total control. Memory is the only really fast component in the system. The more memory a system has the less often it has to access its disks.
-- soldack
Yeah, so this article wasn't too techie.. big deal.. there's no way an article this far ahead of the release could be very techie.. I don't think Intel and AMD are sharing all their secrets like good little children.
The article does make some good points.. and shows a way that AMD could really get some market share. I know all of you aren't going to like it, but it's a good idea. I'm talking about this part : Compaq has said that it will not support a 64-bit Windows for its Alpha servers, which leaves Microsoft looking for some way to get into the server marketplace. Enter the AMD Sledgehammer. Microsoft could develop a 32-bit extended version of Windows that it could, over time, turn into a native 64-bit OS. If AMD splits Microsoft and Intel over the 64-bit OS issue, it would do some damage to both Intel and Windows' collective solidarity. I know.. our little cinderella AMD would be getting in bed with big bad Microsoft, but we've got to take out Intel and Microsoft out seperately, not together. Competition, enter stage right..
props to AMD.. for making the next few years of CPUs a little more interesting than the last few years of Intel MHz leapfrogging with no real breakthroughs.
//Phizzy
afterthought : AMD.. I'm Still pissed I can't get a dual athlon, if you're listening.
"Most European technology just isn't worth our stealing," -- Former CIA chief James Woolsey, referring to Echelon
I think it will be VERY similar to an Alpha chip. It will probably use an EV-7 Alpha bus, and may even be pin compatible. I saw a quote from AMD once that said something like this:
"Someday, when designing a system, the very last decision you will have to make will be whether to use an AMD or Alpha CPU."
I believe it was Jerry Sanders that said this. The sledgehammer and the new Alphas will be cousins. I'm pretty sure Compaq/Alpha and AMD are sharing lots of ideas.
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
1. Actually, the Athlon is selling better on the high-end than the low end. Last I heard, the Athlon had over 40% of certain high-end markets. The exception to this may be corporate IT departments, which are a little too set in their ways - i.e. Run windoze on an Intel processor or we'll have "compatibility" problems. Compatible with what? Windoze on an Intel processor, that's what.
2. The X-Box thing was mostly AMD's decision. AMD said that they could have gotten the X-Box, but they would have been "giving away their processors to do it." Which they weren't willing to do. I don't think they hold bad feelings toward Microsoft because of it. Actually, other recent interviews have indicated that Microsoft and AMD are still the best of buds.
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
From the article:
"This means in another 6 to 8 years, consumer-end computers will ship with 2 to 4GB of RAM, and high-end servers will need at least 16GB of RAM. A 64-bit processor can map thousands of terabytes, (1.84e7) effectively eliminating the 'memory limit' barrier."
a) 1.84e7 = millions of terabytes, 18.4 million
b) Why am I so suspicious of the statement, "eliminating the 'memory limit' barrier." ?
I guess 4billion * 4billion is an awful lot of bytes, but I clearly remember when the 386 came out and I was many years younger and more naive. I eagerly read every trade rag I could get my hands on, all of which happily gushed that nobody would ever need 4 gigs of RAM.
Now that we've found applications for which we do need 4 gigs of ram, what kind of apps would it take to use 18.4 million terabytes?
As I can see, AMD had only two possible choices
Continue with an x86 arch and hack it once again. That's the way they have chosen.
Design a new, but not-Itanium-compatible 64-bit CPU. Technically, a far better choice. But they knew they haven't Intel's marketing strength to impose this new arch to the world.
Lots of comments have said that this choice is the result of AMD's will to dissociate themselves from Intel. I wouldn't say that : in my opinion, it comes from the fact that it would be impossible for AMD to impose a new CPU architecture.
What do you think ?
Stéphane
Instant Karma's gonna get you, Gonna knock you right on the head (John Lennon, 1970)
Hm. And just how much can a 90-year-old on steroids achieve?
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Whether AMD can do better remains to be seen, of course.
At least with this product they are not strictly following intels direction. But I don't think they're heading toward RISC specifically. The "Details" section on the site has a blurb aboput Sledgehammer bridging between 32 and 64, but not with the standard RISCesque architecture. Seems like more of an x86 on steroids.
More race stuff in one place,
than any one place on the net.
The 64-bit chip will also allow for much larger memory addresses. The upper limit of the current 32-bit processors is 4 gigabytes. Of course, who the heck has 4GB of RAM? If you do, please call me, we need to talk. High-end servers are right now shipping out with about 1GB of RAM. The ability to map only 4GB of memory will start to become an issue sooner than some people would like to admit. Eight years ago most computers contained between 4 and 16MB of RAM, but today it is commonplace to see computers with 64 to 256MB of RAM, a sixteen-fold increase. This means in another 6 to 8 years, consumer-end computers will ship with 2 to 4GB of RAM, and high-end servers will need at least 16GB of RAM. A 64-bit processor can map thousands of terabytes, (1.84e7) effectively eliminating the 'memory limit' barrier.
:-)
This is a snip from the article that was sort of bothersome and or frightening to me.
Okay as a software engineer in my limited experience here if a server needs 16GB of ram as this guy predicts things are going to be moving to a VERY server centric environment or.. there is some SERIOUS bloatware being written.
It is sad to actually say we need more and more and more ram just to accomodate bloatware. When is gates law gonna start falling off??
I can imagine it but how many servers are gonna need much more than 16Gig of ram...
Then I look over at my webserver who is using 800MB of ram and I sigh.. How soon before the NT box eats all its phsyical ram and starts swapping and dies?
The whole reason we added more ram to the machine was so that it would stay up another 10 hours so we did not have to reboot so often.
Enter the hell that is 'modern' software that slowly chews up memory and never returns it.
Note the two Unix webservers I have use 1/4 of the ram this NT box does and go down FAR less often and serve equal or greater loads some days.
*sigh*
Thanks AMD you will allow me to not have to reboot so often, G.
First the article says
If we ignore AMD's many non-CPU products, there is still the AMD29k, a fine RISC CPU that had some great success in the printer market, and a few other embeded markets before it was discontinued.
Shortly after that the article says:
The IA-64 is definitly not a RISC. It has a few similar features, like being a load-store archature, but it has a lot of unRISCy features. The instruction decode looks very very complex (for no good reason). The modulo-scheduled register file while having some resemblence to SPARCs register windows are really a whole diffrent beast (ironicly having more resemblence to the AMD29k's "local" registers!). It is chock full of out and out scheduling restrictions (not as in "do this and it is slow", but "you can't do that", "if you do this who knows what happens").
There are lots of intresting ideas in IA-64, many that may actually pan out. But calling it an "EPIC" rather then "RISC" isn't marketing speak, it really does have a lot of non-RISC attributes.
I understand that Intel have been very helpful in porting Linux to the Itanium. Obviously, its in their best interests. Will AMD be as helpful? I'd like to hope they will. A positive commitment from AMD for Linux would bring a welcome boost to their sales methinks.
Now weary traveller, rest your head. For just like me, you're utterly dead.
I've read /. and AMDzone for a while now. I use and advocate for the use of AMD products. When reading previews of new tech, I like to know who wrote the piece, and what the connection between the tech and the author is. AMDZone is ran by Chris Tom, aka ruiner. Highlight the name attached to most posts on the site and check the email address. The site ruiner.net makes reference to his work on AMDZone.
The intentional use of "they talk about" in the post here, which indicates to the reader a separation between the poster and the site referenced, is definitely misleading. There is only one thing worse than faking impartiality, getting caught doing it. No, this is not a major sin, but it is a common marketroid sin, and it is one I prefer not to see either of my regular reads getting into. Ya gotta teach'em while they're stil youngins, else they never learn.
This is just an FYI for those of us who know preview is another word for marketroid. There is probably some meaty goodness in the article, but remember the source.
Never send anything unencrypted that you don't want to have appear in court.
The first real 32-bit process from Intel maybe. Dec released their first 16 bit processor in 1970. I'm sure that by the time the 386 was introduced, they'd been doing 32 bit for ages and were starting to move to 64 bit processors. Never mind that a machine with one of those processors would have a six digit price tag.
But the second bit of the quote is actually more interesting. We didn't see a true 32 bit OS until NT came out. The 95/98 archetecture still requires you to thunk back to 16 bits today, 3 decades after DEC introduced their first 16 bit chip. OS/2 also had a 16 bit device driver model to start out with. We didn't start using the full IA32 capabilities for years after it was introduced. AFAIK Linux and NT are the only two 32 bit OSes for IA32 (Well maybe SCO but I'm still amazed that anyone actually buys that stuff.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
This article (from AMDZone, I know) seems to forget that this new AMD CPU is one more hack to the x86 architecture.
Intel, with the Itanium, did the right thing and designed their new processor from scratch. Do we really need a new x86 chip, with its horrible design, when the open source concept allow you to recompile virtually anything in seconds, provided a compiler exist ?
Personally, I can't imagine how AMD can success with this.
Stéphane
Instant Karma's gonna get you, Gonna knock you right on the head (John Lennon, 1970)
AMD has finally decided not to be the bridesmaid. This is the first real offering that doesn't mimick the direction set by Intel. With Sledgehammer being the only targeted 64-bit architecture from the big three that doesn't move to RISC. Speeds at close to 2Ghz and not using RISC architecture will open up a part of the market and allow AMD to bet the leader for once. Opening up the portability between 32-bit and 64-bit computing is goint to give AMD a huge advantage at least for the short term. Now let's see how they deliver, hopefully they learned from the Coppermine like failures with logistics and get the product to the shelves when they say they will.
More race stuff in one place,
than any one place on the net.
I really appreciated the chart that compares the different CPU architectures. I teach Computer Science classes, and you won't believe how people judge a CPU only by it's rated MHz. For them, K6/2 500 == Athlon 500 == Alpha 500.
I'm just wondering, now that AMD is working on a 64-bit chip without having an Intel counterpart to base itself on, how compatible will they both be when they hit the market??