Slashdot Mirror
More Details Emerge on AMD's Hammer
Diabolus writes "Anandtech have more information on AMD's upcoming Hammer processors. " Talking with several engineers who are in the know about it, the Hammer looks pretty frickin' amazing. Itanium will have a run for its money, I suspect.
Has AMD unfairly optimized the processor for Quake 3?
[/sarcasm]
Why is AMD making these things so sensitive to heat? I'll bet they're also sensitive to vibration, electricity, and about anything that its competitors handle every day. Most hammers can resist hundreds of degrees before they melt/disentigrate.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
I know Linus's been talking NUMA for 2.5 - looks like there's more and more reason for it ... still historically it's been a hard nut to crack well
From the look of it, both the Hammer and the G5 can run old, 32bit code natively. This means that today's apps will continue to be able to run at top speed on the new chips, because the instructions still exist in hardware. This is definitely good for people with lots of older apps(ie, almost all of us.) However, a lot of the reports on the Itanium seem to indicate that, in making a completely clean break, it is forced to emulate older 32bit instructions, resulting in an actual -slowdown- for many programs. Eventually, Intel's clean break might give it some advantage, and that advantage might come quickly for the big metal server market. However, it seems that AMD will be able to win out on the desktop. Of course, here we are comparing rumors on a rumored chip to a different unreleased chip, only Bob knows exactly what will happen between now and release time...
The limited number of PCI slots (on home systems) vs ISA slots makes it an issue for people who want to have a system like this
- PCI SCSI
- PCI Modem
- PCI Firewire
- PCI IDE Accelerator
- PCI NIC
- PCI Sound Card
- etc
I presume the video is AGP.Yes I know people who would do things like that. Ultimately this one guy will have his capabilities spread over two systems, because he cannot fit it all into one, not with a major balancing act.
"It is a greater offense to steal men's labor, than their clothes"
Even before the processor is out, NetBSD already runs on it. See here
I remember in the late 50's and the 1960's, when computing technologies were dominated by the Universities and the public ethos was uppermost. Freedom of information reigned, and thousands of little computing groups competed to bring the new era.
What the hell are you talking about? Can you say "IBM"? That was the era of "you can have any color you want as long as its blue", unless you went with one of the seven dwarfs. Universities didn't contribute jack to anything. IBM invented just about everything during that time.
Unix, Multics, CP/M, Hard Drives, the Mouse, CRT displays, all these and more were made during this time.
...by corporations. Perhaps you've heard of AT&T (Unix, Multics)? Hard drives -- IBM. CRT -- who knows. Mouse -- this might have actually been invented at a university, I can't remember.
The socialist control of the means of production of hardware will allow for innovation in that realm, just as the socialist control of the means of production in software has i thanks to the GNU liscence.
Yeah, I know this proves it was a troll, but just in case anyone was going to believe any of that historical bullshit.
Sometimes it's best to just let stupid people be stupid.
Each feature of the Hammer taken alone is evolutionary, but the overall effect should be revolutionary (at least with regard to Intel server market share;).
AMD stock is looking like quite a bargain at around $10/share... :-)
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
...Can't touch this?
The Kruger Dunning explains most post on
So intel's plan to bolster their flagging market share is to introduce an entirely new platform that's not backwards compatible?
Yup, and it would have worked too (if it wasn't for you pesky kids) had the chip come out when it was supposed to. Two, maybe three years ago, with the current level of performance.
Part of what pisses me off about this whole IA-64 thing is that it was actually quite a good idea.
Dave
I write a blog now, you should be afraid.
This has nothing to do with what bus is supported. Hammer is continuing and expanding on the x86 instruction set. It has nothing to do with the old ISA (Industry Standard Architecture bus).
Motherboard makers are free (or not) to put an ISA bus on the board. I'd be surprised at the time of Hammer to see such a board, though
Don't you think that we've hauled along the old 8086/XT baggage long enough? Do we really need a 64-bit 2GHz processor that can still run an MS-DOS 1.0 executable file, or that needs a multi-stage boot loader to crawl its way up the evolutionary ladder from 16-bit to 32-bit to 64-bit "mode", accompanied by a BIOS that has 6 different ways to map a 400G hard-drive into a 1024x16x63 parameter space?
:-)
I feel that at some point the best thing to do is walk away from the old architecture and make a fresh start with a new one. Commodore did this when they went from the C-64 to the Amiga. Users grumbled for a while, but I think that in hindsight it turned out to be the right choice - once people began to exploit the capabilities of the new platform, compatibility with the old one became irrelevant. And there's always software emulation for those cases when you really do need to preserve the old stuff.
Note that I don't actually know how much "legacy" x86 code is in the Hammer, but even the article's little picture of the register structure makes be think the answer is "too much". Anyway, when did a lack of factual knowledge ever stop someone from ranting on Slashdot?
The ability to build a desktop workstation with the ability to run all my old x86 crap, fast, and move into 64bit software, also fast, is highly attractive. Athlon or P4 will undoubtably be the choices for the next year, but when AMD gets the Hammer out into the mainstream with a mainstream price, Intel watch out.
Lastly, Microsoft, last I read, didn't indicate any interest in doing a version of XP for the Hammer. Perhaps that hasn't changed. If not, there's a potential hole through which someone may exploit Microsoft's disinterest. Linux, sure, AOL, Hmmm, you know that's a mean fight going on between Reston, VA and Redmond, WA, if the Hammer is attractive to home users, don't be surprise if AOL chooses to support it. It's entertaining to think about, anyway, however you feel about the combatants.
A feeling of having made the same mistake before: Deja Foobar
Buy a heatsink, you cheap bastard, and install it.
Yeah, but remember, choice is a good thing. Without AMD nipping at their heels, and spanking them occasionally by getting a faster processor out first (and dodging stupid desperate attemtps like the 1.13Ghs PIII), would Intel be prompted to innovate (granted the P4 just looks like it was the birth of a schizophrenic engineering and bombastic marketing, but I digress, it's something to sell for a while.) In the chess-piece-moving that has become the rolling out of CPU's, the competition has made it interesting and provided some damn fast and inexpensive hardware. Read: Consumers are actually winning, the way it's supposed to be.
A feeling of having made the same mistake before: Deja Foobar
There isn't any mention in the article about the expeted prices of the Hammer, so I thought I'd ask here. What are the price expectations for a processor like this? I mean from the specs alone (with so much stuff integrated into the die), it's going to be a fairly big beast.
Does the fact that it is new technology, and that it's a big (or bigger) die size automatically mean it's going to be very high priced? I remember when the P2 came out, I paid CAD $1200 for the 300Mhz, about 2 weeks after it was released. Now the P4 costs about the same (although a bit less than that) for the highest speed (2Ghz?)
So my question is this: will this processor be affordable (somewhere between a top of the line Athlon and a P4), or is it going to be much more? I think it's a very safe bet to assume that it will cost more than the Athlon.
If somebody has a real answer for this, please reply. It would be interesting to hear some opinions from the more knowledgeable.
Where's the need for 32-bit desktop chips?
That's exactly the problem I'm talking about:
Intel: Here's a cool 32-bit chip, somebody write some software.
Microsoft and IBM: We don't need to support 32-bit for the next 10 years, so you get a bunch of crappy compatibility hacks and spurious "out of memory" errors. The hacks will make it _more_ difficult to support 32-bits in the future. Enjoy!
Now, the exact same thing is going to happen all over again for 64-bit chips. And I'm supposed to be excited?
Whenever I hear the word 'Innovation', I reach for my pistol.
I have considered this myself.
;)
With regards to locking a processor into a particular memory architecture, that shouldn't be a huge issue. For one, most processor architectures stay with the same memory architecture in the chipsets for a useful span of time. So a non-issue that way, IMHO.
Now, about changing CPUs and getting a better memory architecture, that's not extremely likely. A newer memory architecture will probably have different shielding/terminating/etc. requirements. The l33t motherboard manufacturers will probably make their boards have enough headroom that it might be able to take the new memory architectures.
But that's virtually impossible to work. If it works on my buddy's p1mp ASUS motherboard, so if I have a cheappie bargan-basement motherboard, I'll expect it to work. Except that the cheappie motherboard wasn't designed with headroom.
AMD nets one happy customer and one very pissed off customer. So they will probably change things or put configuration pins in there so that the first crop of DDR333 motherboards will do a maximum of DDR333, no matter what.
Plus, most rational people upgrade processor and motherboard at the same time anyways.
So it's probably a non-issue. I personally think the integrated northbridge has been a good idea for a while. I want a 4 or 8 CPU Hammer.
Gentoo Sucks
I don't know -- Windows is one of several OSes competing for Itanium mindshare right now. Don't forget Linux Trillian, for example...
/Brian
Hard to say, the cost of the motorola chips at the time, to the cost of intel(who was just about out of bisiness, and Pratically gave the first chip to IBM), may have stiffeled the begining of the PC.
The Kruger Dunning explains most post on
Yeah, I've seen the benchmarks. An 800 MHz Itanium is trounced by a 133 MHz Pentium when it comes to running x86 code. This hardly passes for backward compatibility.
It's likely that the K9 (I hope they have a dog or dental-related sort of codename for it. ;) ) will be dependent on how the Itanium and Hammer do on the market.
If the Hammer cleans up, the K9 will build on it, leaving any possibility for a whole new platform to the K10. If the Itanic architecture starts to gain speed, the K9 will probably be an IA64 machine.
I think the key thing is that the instruction sets are mattering less. You can put optimizers in hardware that convert a messy x86 architecture to a nice RISC one. Think of the x86 arhictecture as a compression format for nice RISC opcodes. Or you can do various kinds of software morphing, which are getting more advanced as time goes on. The only real advantage to the IA64 is that it has the likelyhood of allowing the compiler to make better optimizations that will leaverage the processor more.
Gentoo Sucks
As to the comment about allowing memory architecture without CPU change, it's highly unlikely. Even with the northbridge on the CPU, different memory architectures are rarely ever pin-compatible. So, in essence, both CPU and motherboard absolutely must match in terms of memory, whereas before you could theoretically have either AMD or Intel with, say RDRAM or SDRAM (though RDRAM is really stupid..)
XML is like violence. If it doesn't solve the problem, use more.
All of teh above run perfectly fine in 64bit compiles. KDE has issues when using the cc included with Solaris, but gcc does the job well enough.
Rod Taylor
As far as I knew McKinley was not going to have backwards support. IA-32 support is an optional part of the IA-64 spec, and probably only Itanium will implement it.
Also, Apple's software emulator ran the 68k code on PPC at speeds that were roughly equivalent to the 68k. Itanium, when running 32bit and 64 bit programs at the same time, performs very poorly. Itanium also does not have the benefit of the MacOS engineering team that did a remarkable job making the transition seamless...
I hope that Intel finds a way to reduce the power consumption of their 64bit chips.
someone has to say the "M" word...marketing.
I have yet to see an AMD commercial, and word of mouth (yes, even mine) only carries so far.
AMD processors are simply increadible, IMO, but how to get the word out? Marketing, commercials and ads.
It is a simple question, really. What is the point of having such a great processor, if no one knows it?
I think a simple commercial like this would work wonders:
Open on a little tv playing the p4 "blue man group" commercial....have a "sledge hammer" and a "claw hammer" (both with big AMD stickers) smash the tv into oblivion.
(fade to black with the AMD logo and a "well known voice")
The AMD Hammer series and XP series, smashing 'you know who's higher numbers".
Power is *sexy*, AMD.
Or, as a demo, us the the ending of "The fast and the Furious' " car race.
Amd would be the Black Toranado(?) and Intel the Honda(?)...Raw Horsepower vs high rpm and technology+"cheats" (inflated Ghz = NOS, perhaps.)
Essentially, it was a tie.
Draw your own conclusions, or come up with something better.
Moose, out.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
Speaking of the uninformed.. let me suggest that one reason we can't switch to a new architecture is because everybody and their mother runs Windows (ignore the recursiveness of that statement!). Moving from C-64 to Amiga had people grumbling, but moving from x86 to something else is going to have people NOT BUYING. We're talking people who don't have a clue about megahertzes not mattering, new architecture is going to confuse the hell out of the normal web surfer and they likely won't buy it. These companies are of course after profit, and so have to stick with x86
--------
It's OK to be social, just don't tell anyone about it.
I had to do a review of IA64 and I wanted to know what was AMD's response to Intel 64bit CPU and what was behind the "old" generations.
....
Currently, 2/3 of a CPU is used to analyse/understand/reschedule the code send to the CPU. This part is very important and AMD seams to be better at this game than Intel. The code has to be reschedule so the different parts of the CPU that can work at the same time are efficiently loaded
OK, let stop right now : why isn't the code already efficient ? Because the compiler does NOT care about the inner structure of the CPU so the CPU has to do all the real work.
By keeping with the "good old architecure", AMD is trying to do in hard and in real time what a software (let's say a compiler:)) can do much more easily in a very long time. And a CPU can't see more than a few operations ahead whereas the compiler can see the WHOLE code.
So, by removing all the optimisation crap from the CPU and showing the compiler what's reallly inside, Intel is on the right way. In current CPU, you have more than 40 registers, but you can access only 8 of them and the CPU has to "guess" what could be the best use of them.
So, I think Intel's approch is the right one. Just recompile all your software : to run old stuff, use old hardware.
I have datasheets and documents to comment about this and I would glady do it.
So did DEC (later Compaq) with the Alpha. It was pretty much the fastest single CPU for floating point over most of it's life span (sometimes a new CPU would come out and beat it, but normally there would be a new Alpha within a month or two to smash it). Similarly for integer performance, but not quite as well (for example the fastest P4 systems have been beating the dead bloated corpse of the Alpha for a while in integer, but still lose out in FP). If ditching the old in favor of the new works, why are we not running Alpha machines now?
Personally I hate the x86 instruction set. I really do. I also think AMD's choice of doing the x86-64 rather then Intel's choice of doing the iTanic is a great business choice, even though it dooms us to spend another decade with the crappy 8086 compatible instruction set. Gack.
I'll spare the "look where it got them" bit, and just go for...nah, just look where it got them.
Of corse as a counter point we have the Mac and it's total incompatibility with the Apple II...unless you count sharing of the ImageWriter...
I for one think that its cool that we are using a vestige of the first microprocessor at 5 orders of magnitude faster speeds. It's a tribute to the human ability to create a good kludge. I wouldn't want it any other way.
Probably 90% of all consumers. Ever hear of windows millenium? That new fangled OS that I don't yet need to upgrade to? It still supports all those ugly 16-bit DOS features.. Sure they did away with the DOS boot-process. But DOS is most certainly there.. And until DOS is gone (a la NT / XP), CPU manufacturers still have to support it. Never mind the fact that even Linux is based on an initial x86 boot-process. (Though obviously it's not tied to it given it's multi-platform support). But out-of-the-box x86 Linux wan't 16-bit x86 supports.
Sure win 9x is "mostly" 32 bit if not all. But it most assuredly supports the sort of legacy x86 features that both software and HARDWARE developers take advantage of.
The AH,AL 8 bit registers you see are essential to call the CPU an x86 anything. If for no other reason than IO support (don't remember the exact instructions.. it's been a while since I've read an 8086 assembly book). Note that IO is pretty much unchanged in the Athlon (since so little actually uses it anymore; relegating to windows drivers and shared memory regions).. Interrupts are also used by these 8-bit registers. In fact, pretty much anything relating to the hardware drivers (minus AGP) depends on it.
I think the loss of the ISA slots should help ease the transition.. PCI with plug and play shouldn't be too hard to port to which-ever technology superceeds. But my point is that there isn't an absence of current-market vendors that still depend on these legacy features.
Aside from hardware, x86 had lots of macro-instructions, such as using CX as a 16 bit counter, and SP, BP for string comparisons. I'm sure these are micro-op vectors in the Penium on, but they still need to be emulated and debugged somehow, thus the register set still needs to be in tact. The real question is whether they make 64bit the fast-path (requring an extra logic probagation for 32bit), or if 64bit is considered the exception.
Aside from that, I agree with you that "staging out" is the way to go. XP should help (sadly) most consumers get rid of any remaining ties to the hardware (via hardware abstraction layers; assuming that's still there). But MS has no vested interest in making the same OS for servers as for consumers. They'd love to have a win3k that only runs on expensive hardware (where they can charge a premium), with their win4Suckers running on a legacy platform that allows them to boast over 1 trillion apps served. You can't buy that sort of marketing. Heck their current strategy is to not even acknowledge that other OS's exist. When was the last time you saw an MS commercial advocate themselves over someone else. (Like AOL still has to do. "No wonder we're number 1").
Sure Linux'll support what-ever and when-ever.. That's one of it's trademarks. But 64bit has a couple down-sides (including memory / cache requirements), and having a 64bit time-stamp or file-descriptor just isn't going to impress the other 99% of the code enough to run faster - the key is going to be end-user benchmarks and or raw MHZ. That's what draws peoples attention. And people's attention is what draws MicroSoft. And as we all know.. MicroSoft rules the world. (well, it's own world at any rate).
-Michael
-Michael
Reading the discussion of improvements to the branch prediction, I had an idea: might it be useful to add some new branch instructions, which serve as hints to the branch prediction hardware?
Suppose you have a branch on checking the error code returned by a function. That is what the article called a "static" branch: it almost always branches one way, assuming the function rarely fails. The Hammer will try to detect static branches, but might it be useful to let the compiler use different instructions, the static branch instructions, to tell the branch prediction hardware to assume a certain branch is static?
I guess I don't have a good handle on how difficult it is for the branch prediction hardware to sort out static branches vs. the other kind. Would the new instructions help enough to be worth the costs of extra instructions?
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
OSes and Compilers. If MS doesn't support the hammer architecture in its OSes and compilers, then AMD is screwed. You can talk all you want about "here's a great chance for Linux to hit the desktop." Ain't gonna happen. Look, I love Linux as much as the next guy, but it's not ready for the desktop. The people that run Linux are primarily programmers and geeks.
For a really viable chip, you need the support of the mainstream, and like it or not, that's Microsoft. If they don't support it with their OSes and compilers, then this will be the death of AMD. I'd hate to see that, but those are the facts.
http://www.x86-64.org/
An AMD sponsored web site with the goal of porting free/open-source software to x86-64. Self-serving publicity stunt? Maybe, but it's nice anyway, and certainly more than we can ever expect to see from Intel.
What do you think they are doing with this whole AOL interface?
A few years back I was in a discussion with some guy with blinders on who issued a statement that no home-user would ever need a system with 1 Gig of memory. The old 640k-should-be-enough-for-anyone quote mis(?)attributed to Mr. Gates is dredged up as an example of shortsighted thinking. Same for this fellow, as he had no concept of where sound and video would go, and subsequent demands on memory. Ok, maybe you have a 1.8GHz P4 or a 1.5GHz Athlon smoking through your sound/video/apps/whatever, but, as I've learned over the years, no architecture remains fast for long. Eventually applications come along, which were written off as impractical or impossible before, and tax the resources to the max.
Imagine AOL viewing Hammer-based systems and the thing with enough horsepower to provide some service while Microsoft views it beneath their dignity to do a port of XP. If it draws customers you'll see some real change in the thinking in Redmond. I think the Hammer is another excellent move by AMD, as it's likely to hit the consumer market, perhaps not first, but with a lot of force when it does.
A feeling of having made the same mistake before: Deja Foobar
On the one hand you have Intel, who is trying to move into *completely* new territory, at least as far as breaking with the x86 past. Scary? Very. When Apple transitioned from the 68K to the PowerPC it was rough going for a long time. The PowerPC was much better for native applications, but those took their time in showing up. And it was much, much slower than a real 68K machine when it was emulating older code.
AMD is taking the incremental improvement route, which makes a lot of sense. But can the non-standard x86 extensions--practically a whole new processor in itself--ever be more than a niche? The 3DNow! extensions were more a novelty than anything else. Some drivers used them, most programs didn't. It's difficult as it is to support all the different computers running similar chips without getting into extensions that only work on a certain percentage of them. Is it worth shipping 64-bit Hammer code just for one market segment? It's not just a recompile; it's an entirely separate QA cycle. Thinking about hobbyists: Will they have both Itaniums and Pentiums around for testing?
And then there's the nagging doubt that we're talking about chips that are already so fast that no one cares--except a certain fanboy crowd--so now we're talking about the difference between 10x more speed than I know what to do with and 20x more speed than I know what to do with. Sure, games and some crazy high-end airflow simulation, but this begs the question of "Is it worth overturning the entire PC market just for those two minorities?"
Never mind the fact that even Linux is based on an initial x86 boot-process. (Though obviously it's not tied to it given it's multi-platform support).
One of the nicest things about using Linux on a non-x86 platform is that you often get to use a much more advanced bootloader. E.g. on the (now defunct) StrongARM-based Netwinder, you could do a diskless boot (TFTP+NFS), specify the name of the kernel image you wanted to run (dynamically, instead of having to put it in a conf and run 'lilo'), get full serial-console support, etc. Similarly for the Mac's "Open Firmware".
The only reason x86 Linux uses the "16 bit" cruft is because it has to.
As for the Windows market, they're moving to a "subscription" model anyway in order to get a more continuous revenue stream. Once consumers are in the habit of updating all their software every (x) months whether they need it or not, it becomes easier to switch the underlying architecture. You'd use a software emulator or 'virtual machine' model to support the "legacy" software. Sure it would slow down the old apps a lot, but that's what the manufacturers want anyway so they can sell you a new chip / application with 'go faster stripes'.
Interesting points about how all the registers are used... I've never actually been brave enough to get into x86 assembly. I have a Motorola background, so I'm used to things like a flat 4G address space, "data" registers and "address" registers, and memory-mapped IO. My brain just balked at the x86 world of "memory segments", "al/ah/ax/eax", etc.
Well, friend, I happen to run C64 and Apple ][ (6510/6502) emulators on my Pentium laptop because there's still some enjoyment in fiddling with stuff on them. Of course there's little new 65xx software out today, and once an architecture like that of native 64 bit Hammer takes hold, expect fewer 32bit apps to come out. The interesting bit of course is the fork in 64 bit style between Intel's path and AMD's path. AMD is poised well, if Hammer is inexpensive, to carve a large chunk of market out of Intel. I'm still waiting for a shoe of Intel's to drop, because you know once the Hammer comes out that P4 just won't be the coolest toy, and nobody is going to sit still for an Itanium grinding slowly through x86 instructions, etc. Heck if that were such welcome idea, half of the world would be running the cheap Alphas (where you had to convert your executables, whee!) Even the ill-fated Amiga computer, with it's x86 bridge card shows you can't put two processors in a machine, sell it for twice as much and expect it to take the world by storm. (I never understood why they actually considered that, myself, I bought an Amiga to run my Amiga stuff, not act like a goofy PC.) If you can run a 64 bit OS with 32bit windows and stuff in it's own little environment window, and provide an easy pipe between, that even Joe Goldenparachute can use with ease, you've got it made.
A feeling of having made the same mistake before: Deja Foobar
The "right choice" eh? Tell me then, how come both the C64 and Amiga are dead?
The Amiga is dead primarily for marketing/mismanagement reasons, but also in part because it tied its OS very tightly to custom hardware. This gave it an early advantage, blowing almost everyone else out of the water in terms of graphics, sound, multitasking, etc. However it became a liability as time went on and the competing hardware improved - certain parts of the Amiga were still tightly tied to the old custom chipset. I do not believe that "inability to run C64 programs natively" was a significant factor in the ultimate demise of the Amiga.
As for why the C64 itself died, mainly just because it reached the end-point of its evolution, and the rest of the world moved on. It was an 8-bit machine, and that imposed certain fundamental limitations on it. Yes they could've clocked it up to 25 MHz, strapped on big-ass heatsinks, and added more and more bank-switched RAM, but it just wasn't worth it. Sometimes you have to walk away and start from a clean slate.
Nowadays, both the C64 and the Amiga can be emulated in software. I don't remember what capabilities the Amiga had for emulating the C64. Quite frankly, I didn't really care anymore after I had had the Amiga for a while.
If you're trying to advance technology, no we don't need that.
If you're trying to sell a product and make money, Yes, you definately need that.
Intel and Microsoft have proven it over and over and over: the market does not want progress. The market will only accept incremental evolutionary change.
Somehow Intel has forgotten this, and they are going down the road to technology instead. Meanwhile AMD is going to "out-Intel" them and get all of Intel's customers.
>
Yes, but you're a damn fool idealist who likes computers and wants to see them run well. You're not trying to sell chips. So while Intel goes off to recreate the marketing success that Commodore had in the 90s, AMD will go off to recreate the marketing success that Intel had in the 90s.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
What do you think they are doing with this whole AOL interface?
/. isn't going to disagree that increases in processor speed and memory compacity are a regular event and there will never be "enough" of either.
Oh come on... An operating system == AOL interface? I understand where you are going with your idea but I still doubt that AOL is going to want to support an entire operating system.
A few years back I was in a discussion with some guy with blinders on who issued a statement that no home-user would ever need a system with 1 Gig of memory. The old 640k-should-be-enough-for-anyone quote mis(?)attributed to Mr. Gates is dredged up as an example of shortsighted thinking. Same for this fellow, as he had no concept of where sound and video would go, and subsequent demands on memory. Ok, maybe you have a 1.8GHz P4 or a 1.5GHz Athlon smoking through your sound/video/apps/whatever, but, as I've learned over the years, no architecture remains fast for long. Eventually applications come along, which were written off as impractical or impossible before, and tax the resources to the max.
Where are you going with this? I think anyone with half a clue on
Imagine AOL viewing Hammer-based systems and the thing with enough horsepower to provide some service while Microsoft views it beneath their dignity to do a port of XP. If it draws customers you'll see some real change in the thinking in Redmond. I think the Hammer is another excellent move by AMD, as it's likely to hit the consumer market, perhaps not first, but with a lot of force when it does.
Windows XP should run just fine in 32 bit mode on the Hammer like linux runs in 32 bit mode on some 64 bit chips. The whole point of Hammer is that it is so backwards compatible compared to Itanium that it won't be a big pain to upgrade for the end user. Anyone have any proof that XP is going to have a hard time running on Hammer? If I were running Microsoft I'd have someone keep up to speed on Hammer. Then if it is released as expected and sells well I'd make sure we support the processor in 64 bit mode. It shouldn't be too hard after all because Microsoft is working on the Itanium support. What advantage does Microsoft get by supporting Hammer right now?
What I don't see is how you think Hammer suddenly makes possible for AOL a number of things that aren't possible today. I think the big break throughs will come with inexpensive and highly accessible bandwidth. The bandwidth will make the difference for AOL - not the cpu speed. In either case high speed CPUs will be here no matter what...
Because success of the underdogs, splits the industry and makes it less committed to any one party. Right now, the 386's instruction set is king of binaries. But in a future world of two mutually-incompatable descendents of the 386 duking it out, software companies will be less able to be able to commit to one or the other.
And if they don't/can't commit to a single instruction set, then they're going to have to deal with their problem some way. Scrapping the idea of native binaries, is one way of dealing with the problem. Ship source that the user has to compile, or ship some kind of intermediate pcode or Java bytecode that is cross-platform. Once the need for binary comformity is broken, then you can buy a real computer and run mainstream software on it.
Or maybe stay with binaries, but accept that you have to deal with more than one. Computer dudes only know three numbers: Zero, one, and many. You can get away with telling your customers "We only support one architecture and if you don't like it, then your money is no good here. We don't want the expense and complexity of dealing with more than one." But once you have to handle the situation of more than one, then you can also handle three or ten. Surely you can see where that could lead...
So back the underdog. AMD's success (and I think they will flourish with this CPU) will hold back progress for a while, but as long as it doesn't completely clobber Intel, and instead they end up splitting the market between them, it could lead, long-term, to progress.
Yes, and they have it: legacy speed. Gee whiz, you think AMD overheating problem is really a big deal? Consumers have long tolerated silly things like that. If people cared about heat, most people would be running PPC or MIPS right now. They're not. If people cared about short lifetimes of computers, then most would be running something other than MS Windows. They're not.
But you're right, those things matter a little, I guess, so Intel will have some customers. Good. If there's no clear winner, then the winner is us.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
> keep the simple instructions and emulate the
> rest (such as those used to handle BCD
> arithmetic, hardly used today)
In fact, in Hammer's 64-bit mode, the BCD instructions (and some others) are not supported.
> the drawbacks are evident: higher complexity,
> power dissipation, etc.
Check out the heat dissipation on Itanium! One guy I know has a box that puts out 120W per CPU.
A simpler architecture is a nice thing, but experience seems to have shown that it doesn't matter that much in practice.
> AMD is trying to do in hard and in real time
> what a software (let's say a compiler:)) can do
> much more easily in a very long time.
NO. It is very hard for a compiler to accurately predict what will happen at run time (for example, which loads will hit in the cache and which will miss). It is much easier for the CPU to collect, predict and use this information at run time.
IA64 pushers talk all the time about how smart the compiler "can" be, but they don't actually have any such smart compiler. That is why their performance sucks.
Furthermore compilers are not going to get much smarter in the near future; just because the technology is needed does not mean it will suddenly appear. Compiler researchers aren't stupid and they haven't been sitting on their hands for the last forty years.
> And a CPU can't see more than a few operations
> ahead whereas the compiler can see the WHOLE
> code.
... until the program makes a call into a shared library that was compiled by someone else.
> Just recompile all your software : to run old
> stuff, use old hardware.
Uh huh. So every single time a new chip comes out, Microsoft et al are going to release new compiled versions of all their software. I don't think so.
A circle with a circut for directing in the center. Operate the traffic cop at high speed and everything is happy.
Spring is here. Don't believe me, look outside!
Mckinley is the day after tomorrow.
'There is a Light that never goes out.'
I have been working for SuSE Labs on the X86-64 port for about a year now, and I thought you might be interested in hearing about the state of the port.
Back in march we saw the first printf ("Hello World\n") succeed in the simulator. This is quite a big thing because it needs a working compiler, binutils, glibc and kernel. Since then we have steadily improved the system. By now we're running a full fledged Linux system in the simulator. The system is partly 64 bit and partly 32 bit. We will use the native 32 bit capabilities of the chip to use 32 bit binaries when that makes the most sense (who needs a 64 bit ls when a 32 bit ls does 64 bit filesystems fine).
By now gcc (C and C++ support), binutils, glibc, gdb, the kernel, ncurses, bash, util-linux, vim etc. have all been ported almost completely. And X runs happily in 64 bit too. Now we need the desktop systems, apache, databases etc.
Shameless plug: I'm giving a one-hour talk about Linux on X86-64 at Linux World Frankfurt next tuesday, october 30th. Here I'll show the system running, give an overview of what porting Linux is and describe the new features for Linux that we have implemented.
Bo Thorsen,
SuSE Labs.
The Commodore 128 was backwards compatible with the C-64. And at the source level , the Commodore 64 was largely backwards compatible with the Commodore PET and Vic 20, if not as fully as the C-128's "GO 64" command. (source code... :P just be careful what you POKE and where you PEEK.)
But this point mmontour was trying to make could have been better made with the transition from Apple's ][ series to the Macintosh architecture. Other than a few hardware interfaces, there was almost no backwards compatibility, and Apple planned it that way.
The Amiga was not developed by Commodore as a break from their venerable C-64, rather, the Amiga was a distinct machine from a failing company which Commodore bought, and then championed as superior to their previous offerings. Unfortunately, they just succeeded in carrying on the Amiga curse.
I never had an Amiga... I couldn't betray my Commodore 64 by dating its sexy cousin like that. Instead, I later ended up skulking around with some skanky PC I picked up at CompUSA's red light dictrict. I'm sure fond of that slinky Mac, and PCs can keep my attention by parading around in NetBSD, or some indecent Linux rags. But even in the face of a new 64 bit whore of a PC, my true love will always by my Commodore.
I dream in 8 bits.
It has 64bit support, just because Intel thought it would be great to put it in, but the MAIN point about the Itanium is the EPIC instruction set: move back to simple RISC like instructions and let the compiler do all the math about branchprediction etc etc. F.e.: when you have a program compiled with a good EPIC compiler, you'll have 8 instructions executed PER CLOCK, thus in theory running your program on 8 CPU's at once. It's 64bit too, but that's just a 'nice feature', not the main issue.
Then looking at the hammer: AMD offers 64bit as its main new feature, but keeping the fat x86 instructionset. Nice, but not a product that will survive for at least 10 years from now, resulting in a quick set of bucks fast, but a slow death in the long run...
Never underestimate the relief of true separation of Religion and State.
- 4004 [4 bit word]
- 8008 [8 bit word]
- 8080 [8 bit word]
- 8085/8086/8087 and 8088
- 80186 (Loser)
- 80286
- 80386/80387
- 80486 sx/dx
each step was somewhat a logical progression. Now we have Pentium's pentium II, Pentium III and Pentium IV; mix in MMX in some, and Xeon branchings in the Pentium series. So do we say at least a plain Pentium, or Pentium MMX? How about a Pentium II?Actualy I think Intel should rot in hell for putting the CPU vectors at the top of memory space at 1 Meg and working down instead of the more logical bottom working up.
as a ps the only reason I have a windows partion is to run one win16 application.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Abandoning a user base is an extremely dangerous thing to do.
DEC orphaned a whole platform (MIPS DECStation) with a long stream of broken promises when Alpha was brought out. The seeds of Alpha's destruction were sown the moment of its birth. If DEC had been wise enough to develop an FX!32 for MIPS and an ability to run Ultrix binaries under OSF/1|Digital UNIX|Tru64, then the end of Alpha might have been a very different story indeed.
And now Intel/HP/DEC/Compaq has aspirations of repeating this sad history.
If AMD can deliver on even half of their promises, then Itanium is finished.
Are you willing to spend over $3000 for P100 speeds for your x86 code?
Neither is anybody else. The emperor has no clothes.
And the next time you change the internal structure of your CPU, everyone with binaries optimized for the older structure are screwed unless they recompile...
In other words: Some diehard fans actually found it worth it...
While the C64 and Amiga scenes may be mere shadows of what they were in the past, they still exists.
By the way, does anybody know if I can run Hammer in 32 and 64 bit modes "simultaneously" so that I have some of my apps fully 64 bit and other legacy apps? Does it hurt my task switching performance seriously that processor is running in different modes with different processes? Will Hammer be faster for 32-bit or 64-bit code? If I don't need 64-bit address space should I compile my code for 32-bit instead for better performance? I would guess that even though 64-bit instructions are a bit harder to execute due to 2x memory requirements the increased register count would balance the things.
According to the article when Hammer is working in MP system each CPU handles part of the memory; should OS be able to send an application to specific processor according to physical memory it has allocated instead of current load of processor for best performance? If so, does any OS currently support this kind of arrangement? How hard it would be to make Linux support this?
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
What I think needs to be done to the next couple generation of Athalons is to allow programs to bypass the x86 decode stage and access the RISC core directly. This will allow the chip to run legacy x86 executables, as well as new RISC executables in a completely transparent manner. After a couple of years, the x86 decoder can be phased out of the primary product line. This would reduce cost significantly, considering that (IIRC) about 20% of the transistor count on the Athalon is dedicated to the x86 decoder.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
(Why partition registers by functionality?)
Well, simply it makes for faster CPUs. (unless most of the time you're physically interchanging from GPR to Address Registers). The Digital Alpha, for example, went even further and utilized two completely separate register sets for GPRs. I don't remember if the programmer was required to not perform operations that would pull from both register sets or not (e.g. was it just a caching localization, or was the bottom half and top half of the register address space physically separate).
The main advantage is a minimazation of ports on the register set and a reduction in the number of buses. Each execution unit typically requires one write port for each register. If you have 6 integer execution units, then that's 6 write ports (and probabably something like 6 read ports, but in theory 12 read ports). Each port requires an address decoder and extra levels of probagation in the register fetch stage.
Back in the old days, where we didnt see heavy pipelining (especially in first generation 68K), this was expensive and slow. The 68K was clean in many ways, which included separation of dissimilar functionality to segregated addresses and buses (and possibly execution units). Since there's no contention between addressing and general ALU operation, it's closer to true divide and conquor. Mix in the fact that the 68K CISC core could utilize op [Mem] = [Mem], [Mem], the load on address registers and logic was pretty heavy (at least in comparison to RISC architectures).
I once did a simple CPU design project which unified the FP regs and the int regs. The focus was on interchangability of data-types, and simplicy of design.. But what I quickly found was that in almost all cases (except register exchange) things were worse off.. The large register set had to have exteraneous fields to handle the various datatypes (even if they weren't used 99% of the time). That logic took extra probagation layers. Additionally, the number of address bits in the assembly code was upped (since fp ops couldn't assume a separate address space than int ops). Plus I found that the number of ports I had was horrendous.
Arguably, address calculation more regularly requires utilization of integer units, and thus there will be a significantly higher percentage of swapping betwen GRP and AR than between FPR and GRP. None the less, Motorola found it advantageous to do it that way.
Once Load/Store become popular (as with the PowerPC), the benifits of separate addressing fell off. (Number of mem accesses / instruction was now well below one).
-Michael