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)
clever. Would have been cooler if it actually WAS first post. ;)
Trolling for Scooby doo!
This is definetly not in my nature.
How the fuck is this offtopic???? It's about AMD's CPU strategy...which is exactly what this article is supposed to be about. Fucking AMD loving wankers.
i poured a 64-bit bowl of hot grits down my pants just now. thank you.
re: faster than pentium on floating point..
could be but there's nothing published yet. check out http://www.specbench.org and the spec95 summaries. looks like alpha has a wisker's lead over the 800mhz pentium3 on floating point, with mips and sun's sparc trailing everyone.
I would never have believed it. But it's Christensen's correllary in action:
-- the interface that creates the largest market attracts the largest investment and improves on a moore's law curve steeper than everyone else.. meaning that what was the tortise (x86) now is moving at lightspeed relative to what was the rabbit (risc).
Ari
It's really sickening how someone has to mention a beowulf cluster whenever a new chip is talked about in an article. Get a life luser!
All these people crapping on x86. Sjeesj. ;-)
The sledgehammer will probably use register windowing, like all the other grownups, and thus be able to save different register states for it's different internal units. It's very complex to design, but if they can pull it off there is no reason why it should be any slower than the itanium.
The problem with the itanium is that it's a vliw chip. Why do you think they need these big compiler projects ? Because the compiler has to be VERY complex. Intel just moved to problem to software. They made a dummy processor that doesn't rearrange the instructions themselves and just executes everything in the order given to it. This means that it takes a lot of effort to produce all the instructions in the right (optimal) order, whereas with x86, and sledgehammer, you can basically reuse the existing compilers without much problems.
Itanium won't have a lot of compilers, because it takes a lot of money/effort to make one for it. (just look at the trillian project) I don't know if this is good or bad, it means there will be less compiler versions to worry about when you write your app, but it also means that basically intel has a foot in the compiler market now.
All the little compilers will probably use the engine of a bigger one, reduciing themselves to an IDE. Good or bad, I'm not calling it a name, but I AM afraid of it.
And all the people who already have apps... In the *nix world recompilation is easy indeed. But the big clout of users are in the windows world. And if they can just reuse their old apps (especially games) ontop of their novel OS/processor with even a big gain in speed, that WILL make them happy.
It IS the right thing to do to make a new design, technically, but economically it's not so sure to succeed. If there is one golden rule to computers, it is that you must stay compatible. That's the most important thing.
I'm not an expert, but I seriously have my doubts on intel's design. VLIW is a nice buzzword, but it has to prove it's usefullness first.
And as for me, I'll watch it out on an Alpha
P6 architecture : risc with a cisc forefront
...) have a lot of bloat today. Really, the risc-cisc wars have long been fought, and the winner was a hybrid.
Athlon : risc with a cisc forefront
Sledgehammer : risc with a cisc forefront, and maybe a way to use the risc directly
Itanium : vliw (not really risc, more of a variation)
From my point of view it's intel who's not doing the risc dance.
And x86 is basically risc today. Compilers only generate very few different instructions. They basically use a small and fast part of the x86 ISA, leaving the rest to decay. RISC only means to make use of a lot of small instructions, instead of a few big ones. The fact that x86 has the big ones doesn't mean it also has the little ones.
Actually, internal in the p6 and athlon they hardwired the decoding of the little instructions, without using microcode, so it's almost as fast as pure risc.
And the socalled pure risc procs (alpha, mips,
Well, for e-commerce, it will be needed, the servers of the future will need huge databases, it will need them in memory to keep them fast enough to keep the cutomers.
;)
Wave of the future, isn't it nice
I would go for Sun(Sparc) or IBM(Power) hardware if I ever needed a server of that power though.
Actually you just need a 36 bit addressbus, the next version of the MPC7400(AKA G4) will have that.
Intel's chip is expected to ship this year isn't it? I know some people already have test machines. Will it replace the PentiumIII? No more then the Xeon did. They are aimed at different markets. The point about the lack of 64bit apps just shows how out of touch the article was. None of these machines will be running games,quicken,Office or anything like that. They will be running server apps. Most of those apps will ship the day the servers do. Maybe Microsoft won't be ready but that's thier problem. I seriously doubt IBM or HP are really going to cry if they end up selling thier OSes instead of NT on this hardware.
That's likely because for most people, "performance" does not necessarily mean "floating point" performance. I wonder how the Suns, Alphas, etc. do running business applications, or video, or games, etc. Perhaps they outperform the x86 in everything, I don't know, but I think it more likely that the x86 has a different focus then the workstation processors. What then should be the most important factor gauging performance? FPU? Integer? Multimedia? Gaming Benchmarks? It depends what you want.
all x86 are RISC cores with CISC decoders. Agreed. What's the problem ? Personnaly, I like this very much. It gives all the power of RISC and the nice things of CISC (variable length instructions). The fact that x86 processors run at higher MHz than any other should be a hint for your pedantic biased mind.
Sure x86 would be better if it was designed NOW. But it's clearly not a 'pile of crap' and compares very well with new architectures.
Of course this is slashdot, so maybe I'll get moderated to -1 AGAIN for saying x86 is good. I'd like to know how many /. readers are using alternative platforms ?
If x86 is sooooo bad, don't wait and buy a fucking pink IMAC and stop BSing about something you don't know.
Where are the 1.0 GHz G3 ?? G4 ?? Come on this is RISC ! I was told it was better and faster !!
(please no ALTIVEC RuLeZ pathetic replies)
Athlon is *WAY* faster than any other x86 CPU at floating point ops.
I doubt these chips are going to start out in the consumer market. They'll start out in the high end workstation/server market. By the time they become priced for consumers, I'd imagine many of the issues you mentioned would be worked out. (eg. one will emerge as the more popular)
Even Pentium Pro had 36 bit addressing you MAC MORON.
You have to use the stack for any x87 op.
The author of the article is obviously clueless:
(1) AMD broke from Intel with 3DNow!, and that was at least as large a break as Sledgehammer.
(2) IA-64 isn't anything remotely resembling RISC.
(3) Willamette isn't just an Athlon competitor. Realize that when companies don't release on synchronized cycles, the company releasing first gets the "first mover" advantage, while the company moving last gets the technological superiority. Compare the PlayStation and N64 to the earlier Saturn. Sega got the jump on Sony and Nintendo, but they paid for it by having technology 1-2 years older than those two. Compare the PlayStation 2 to the X-Box, same thing.
Also realize that at 1GHz+, the Pentium III's outperform the Athlon. Every chip has a weakness.
So if I follow your reasonment, Pentium 3 was the first 128 bit processor, and you have no bragging rights about the WHOLE NEW *450 MHz* G4.
I'm talking about rampability here, not performance. But being more rampable gives you more performance.
I'm not talking about Alpha and Sparc because THEY DON'T PLAY IN THE SAME BALLPARK !! Open your eyes please, Sparc and Alpha are for servers, not for your desktop computer like Athlon/P3 and G3/G4.
And yes, bashing pink "iMac" is really funny and YOU KNOW WHY !! ahahahaha
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.
... adding another one would not hurt them too much.
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.
Hmmm, no, not quite.
All the existing 64-bit platforms + IA-64 are only marketed in the server and workstation market. I can hardly imagine a consumer who has (or will have in the next years) an Alpha, PA-RISC or Itanium as his/her desktop-only machine used for things like browsing, e-mail or games. The Sledgehammer on the other hand is AMDs Athlon-successor and will take its place (starting eith the enthusiast market and later trickle down in the value low-end). It will execute existing 32-bit apps as fast as you can expect from a next-gen x86-product plus it will have 64-bit capability. The average consumer will not be confused because he will only see one 64-bit product (Sledgehammer). And it will not be compared with the other 64-bit architectures but competing x86 ones (i.e. Intels Willamette processor) using existing x86 apps.
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.
Again it is a different market. The consumer market application vendors wont neither port their applications to IA-64 nor adapt them to Sledgehammer but rely on its 32-bit performance. And the higher-endish apps are already made portable for different architectures
You said: ;)
>As i once said: "WOW! a 1GB harddrive! imagine >the games you can store on that!"
>Everything will be obsoleted in time.
>Although i have to agree, 18.4MTB should take a >long time
Righ now, the business i work for doing image
analysis of human tissue
is capturing 4 to 6 gb high resolution images.
with 1 gb of ram on the PC's doing the capturing, we are *HURTING*,
fortunately we only have to do about 10 a day,
(thank god for tape storage onstream ADR cartridges rock!)
this time next year, we'll probably be doing
100 or more per day, and
those are just the 2d images, we'd like to
assemble those images of different sections
of tissue into 3d models. and then
do 100 of those 3d models per day,
and then have a searchable data base,
i'm not even sure how to predict how much
storage we'll need, (as much as we can afford)
nor how much ram we'd need to do realtime analysis, visualization, and some other things
of these images (at full resolution...)
18 Million terabytes would probably hold us for
a couple of years........
From what I understand, basically, applications created for IA-64 will be unable to run on the Sledgehammer without some kind of emulation. That's the direction of the Itanium -> moving away from the X86 architecture.
What this also means (and what the article on AMDZone talks about) is that Itanium's 32-bit perforance (Read: current X86 apps) is no better than current performance, because Itanium will have to emulate an X86 processor. Think of those PowerMacs with the add-in X86 boards.
The deciding factor here (i think)is going to be the application engineers...which ever platform (hopefully, both) they decide to develop for, will win.
Please, someone correct me if i'm off my rocker.
-Slyknie (too lazy)
Easy, simple steps -- yes, even you could do it:-
1. Moderate DOWN all posts questioning or saying negative things about Open Source, no matter how reasonable or accurate they may be.
2. Moderate UP all pro Open Source posts, no matter how stupid or inaccurate.
3. Moderate UP all posts from people saying nice things about VA Linux/Andover/Malda.
4. Watch VA/Andover/Slashdot stock $$$$ rise
and have a really good laugh at all those suckers who let them get away with it.
Apple put out the 128-bit G4 processor a few months ago, and AMD is bragging about this? Please.
Sometimes if takes a FEW SECONDS to render those huge .jpg files. I can't wait that lonf to see my pr0n! I need a Sledgehammer NOW!!!!!
750Mhz EV6 Alpha will bitchslap any fucken G4 , Intel whatever up and down the street. I wonder how a 750Mhz PIII compares to that? Not to mention that an Alpha is 64 bit.
Not a cinch exactly. With current RAM-speeds, it would take a couple of centuries to write to every memory location. (Writing 4 GB takes several seconds with todays hardware, and 4 billion seconds > 120 years.)
IA-64 uses a VLIW-ish architecture that Intel calls EPIC. It's the opposite extreme from RISC.
Look back at the architectures that have been released over the last few years. How many were RISC? Not many, because it doesn't fit the demands placed on modern hardware very well. Why should AMD use RISC when other manufacturers (Sun, Intel, etc) are using newer models like EPIC and VLIW?
One point for you, 68000 is easier but I never said the contrary. I just remarked that you can do whatever you want with x86 without much hassle and (but it is a personal opinion) I find CISC very convenient for the variety of instructions.
I agree. It's managed to stay relatively modern remarkable well. I think it would have been abandoned years ago if people didn't want 386 compatibility.
Compatibility is clearly the important thing here. You can say waht you want about the 'bloated-obsolete-crap-x86', AMD could NEVER succeed with a new instruction set.
Once again, I agree. I don't see how your opinion that the processor thats used in about 90% of computers is good is "Flamebait" of all things. Blame the moderators.
Well the tone of my message was a bit aggressive, but that's because I wanted reactions ;)
True, very few, and Slashdot is probably a stronghold of non-Intel CPU's. But thats because Intel is cheap.
Intel is cheap AND not as bad as some people here want you to believe (for reasons that are still unclear to me, is it "hype" now to have an Alpha at home ??).
Where are the 1.0 GHz G3 ?? G4 ?? Come on this is RISC ! I was told it was better and faster !!
Where's the 1 Gigaflops Pentium?
If you are talking agout 1 GHz : Nowhere to be seen. On the other side, 1 GHz x86 Athlons are available. And Intel has supply of P3s up to 800 MHz. That's still about twice the freq of the G4 (and NO, a 450 MHz G4 is *not* faster than a 800 MHz P3 or Athlon).
If you really mean Gigaflops, a 250 MHz P3 or Athlon with SSE or 3DNow! is capable of 1 GFLOP.
With SIMD, P3 can issue 1 instr on 4 FP numbers per clock, and Athlon does 2 instr on 2 FP number each.
Wake up.
And I suppose that will all this power they must really enjoy their DirectX games.
EV6 is really a work of art, but no one except slashdot readers, scientists or 3D artists want an Alpha at home.
And yes, bashing pink "iMac" is really funny and YOU KNOW WHY !! ahahahaha That says it all.
Did you really want me to start YET ANOTHER flamewar ??
a beowulf cluster of these!!!!!!!!!!!!! Remember if it's not LAMEX it must be FUD!
What other VLIW chips are there? I know that transmeta has been advertising theirs, and that TI has a DSP series based on this architecture, but those are the only two that I've seen recently.
What's your definition of "high-end"? People who screw together their own Quake boxes? $1500 Compaq Presarios?
AMD has no server market right now. Due to Intel marketing contracts, they barely have any of the corporate desktop market. They are barely in any laptops at all. Those are pretty much the three most profitable segments of the PC industry -- and AMD is MIA.
I'm waiting!
I hope to god that people start to realise that the x86 architecture is a pile of w*nk. It's a pain in the arse to deal with. From what I read in that article it appears that AMD might be moving away from Intel. I don't know how strictly they are following the Itanium plans. Hopefully they'll start moving towards RISC!!!
The x86 is very limited in registers. This causes problems in optimising for a branched pipeline.
The instructions are variable length which means that the fetch unit has to be much cleverer to deal with this
Only the AX (Plus DX) registers can be used for multiplies and divides, which makes a second multiplier or divider virtualy useless.
The integer unit uses 4 general purpose registers, plus some specialised registers, the FPU uses a logical stack which is stored in physical registers, and the MMX unit uses the floating point registers as numbered registers.
Intel should have realised they were heading towards a superscalar architecture when they designed the 386. Then modified the instruction set, and added some more registers at that stage. Nobody can run 16 bit applications in protected mode, except in virtual 8086 mode, so all the programs had to rebuilt anyway. This would have been the perfect time to do the modifications that they're doing now.
Spitfire is the name for UltraSPARC-Is and the MMU architechture in the I and II.
/proc/cpuinfo
[wesolows@pimp:~]$ cat
cpu : TI UltraSparc II (BlackBird)
fpu : UltraSparc II integrated FPU
promlib : Version 3 Revision 19
prom : 3.19.0
type : sun4u
ncpus probed : 2
ncpus active : 2
Cpu0Bogo : 398.95
Cpu1Bogo : 399.76
>>>> MMU Type : Spitfire
State:
CPU0: online
CPU1: online
As the writer touches on here, AMD has an excellent opportunity here. That opportunity is wasted if they simply make a 64-bit x86 CPU. This was a great idea when moving to the MIPS R10k. It was a great idea when moving from SPARC v8 to v9. These architectures were great to begin with, and have managed to maintain backward source and binary compatibility without adding cruft or useless compatibility logic. The x86 architecture, OTOH, is filled with cruft already. It has dozens of useless instructions, hundreds of artificial restrictions, and about as much non-orthogonality as anyone could want in a cautionary example.
If AMD simply warms over and extends this already much-maligned architecture, they will lose their big change to truly break away from Intel. Why not put out something genuinely creative? A new design? I know AMD can innovate, but I'm puzzled as to why they won't. If everyone is resigned to an architecture change anyway, why not give them something good to change to? AMD seems to be so accustomed to playing follow-the-leader that they don't know how to lead even when given the opportunity.
Get with it, AMD. Nobody is going to buy this processor. The improved FPU performance will be wasted on your market. These are peecee people; they don't care about vagaries like "computation." They want to play gamez and talk in chat rooms. Your puny FPU isn't going to touch the real workstation CPUs; the FPU performances of Alphas, SPARCs, and MIPS are dramatically above anything you can get with only 16-32 registers. So whom are you targeting? Hardcore Quake addicts?
It's time for something new, not the same old thing. If AMD does in fact follow this path, they will flop, and start all over again by reimplementing Itanium three or fours years after Intel, then spend ten more years playing catch-up. I can only hope that there's sufficient confusion to drive people into the arms of the workstation vendors, who have been producing consistently superior products for 10 or 20 years, maintaining or breaking compatibility at the right times and in the right ways. With any luck this will eventually be the death of the peecee.
They already did. The speed difference in FPU operations between the K6 and the Athlon is impressive, and I even often see an 500Mhz Athlon be somehow (feels 5-10%) faster than a 550Mhz PIII Xeon in some FPU intensive operations (mp3 compression with a nontrivial psychoacoustic model).
OG.
This article has an old feel to it. Especially where it talks about OSs for ia64. That was the state of affairs in december of 1999. Things have shifted somewhat with Turbo Linux releasing a full distribution for Ia64.
Sure it's only Alpha quality but the fact that it exists and includes all the major parts of a Linux system. The web server runs fast enough and the file server flies. The compiler exists and works but has not been optimized nearly enough. GCC's strength has never been speed anyway, just cross platform consistency.
Apart from that this was a decent and well researched article. Frankly I think it was either just published late or Slashdot waited a few months to pick it up.
--= Isn't it surprising how badly I spell ?
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Why use Intel PIII CPUs as the reference? You'd need to figure out how to scale other archs, so you'd need a benchmark. Probably the most widely accepted benchmarks are the SPECint and SPECfp benchmarks. I think it would make the most sense to use straight SPECint numbers for computer speed.
:)
I'm wondering how to include SPECfp numbers, though. Maybe we should choose a reference speed, as 47Ronin did, and assign it speed 1. Speed of other CPUs would be calculated by averaging the ratios SPECint(cpu)/SPECint(ref) and SPECfp(cpu)/SPECfp(ref). So the final formula would be:
speed(cpu) = speed(ref) * ( Sint(cpu)/Sint(ref) + Sfp(cpu)/Sfp(ref) )/2
This way, a CPU has a SPECfp rating twice as high as the reference, but only 3/4 the SPECint, would have speed=1.375, which seems reasonable. Obviously, you will still need to look at real benchmarks, not just a speed number, to see if a given CPU will do what you want, but at least it would give _some_ meaning to the numbers shown in ads
I think it would be necessary to pick a reference with a good balance between integer and fp, so things wouldn't be skewed. I think UltraSPARCs would be good for this, since x86 CPUs have too crappy FP, and Alphas have too good FP (relative to integer) I think. I'm sure there is a better choice though; Anyone want to tell me what it is?
That actually raises an interesting question: Will integer performance rise faster, slower, or equally to floating point performance in future CPUs? Which is easier to accomplish from a hardware design standpoint?
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Actually, I thought the bit about memory in this article was way off. Sure, 4GB may be a heck of a lot for the _desktop_ right now, but the article willfully included the server market in the "no 16GB for 6-8 years" schtick.
:) Oh, and they weren't web servers. These would typically be used as business transaction servers, corporate database servers, etc.
While I was at IBM working in system testing, I saw many AS/400 servers destined for customers with 20GB of RAM. That's right -- 20GB of RAM (you should have seen how much disk space these puppies had). And this was 3 years ago!
Note that these don't run NT
Maybe the article's author was using some definition 'high-end' that excludes anything non-Wintel. Well, hate to break it to them, but Wintel is barely entering into what might be laughingly called high-end (except by Intel's marketing department).
Anyway, the point here is that you definately need more than 32 bits of address space in the high-end server market here and now.
The enemies of Democracy are
From what I heard about microsoft they don't like to rewrite certain things that is why Windows of alphas sucks This might give them a chance to have a processor that will help not have to write most of thier code I could by wrong but you never know
http://theotherside.com/dvd/
Literally Apples and Oranges. Different OS's all around. Differnt amounts of memory, no mention of rating. There is much room for improvement on all the systems tested, and ways of bringing them more inline to the same specs. ATI for instance has Rage boards for both the PCs and the MACs. The same amount of memory would also be a good improvement. Same OS for the PCs. Not the best test environment to draw any real conclusions.
Time flies like an arrow;
Time flies like an arrow;
Fruit flies like a bananna
If Microsoft follows previous policies, AMD will need to pay them for a Sledgehammer port of Windows NT, or sign NDAs and do the work themselves. Compaq/DEC Alpha and Motorola/IBM PowerPC both went down this road, and found it to be economically infeasible to keep NT running on their CPUs.
Alpha/NT was a very established architecture, very fast, and had an entire MS BackOffice port running on it, and enough third party vendor support. Still, it didn't sell at all! I think it would be a horrible mistake for AMD to pour money down that hole -- the low-end server market seems more than happy with the performance range of x86.
So then the question is -- Who is going to buy this thing? I'd think the best bet would be to price Sledgehammer similarly to 32-bit chips like the Pentium IV. Perhaps they can get some game/video driver support and market it similar to the MMX/3DNow processor extensions. As long as it's seen as an extension of the traditional x86 market (price- and performance-wise), it will probably do OK. If it's marketed as a brand new architecture, it's DOA.
--
Business. Numbers. Money. People. Computer World.
But it could be a helluvalot faster if the same amount of time and money spent to squeeze some more performance out of a geriatric architecture had been spent on developing a new one.
True, but in the big picture, the world has collectively invested a quadrillion dollars into a bazillion x86 closed-source applications. It's hard to fight the economics of that, no matter how cheap+fast another CPU might be.
(I think that the only time anyone recently went up against Intel for the desktop market was the PowerPC in the mid-1990s. It's been faster and cheaper, but never quite enough to convert the commodity market.)
--
Business. Numbers. Money. People. Computer World.
I can see the "Extended 64-bit features that make Quake faster" approach when they are trying to market Sledgehammer to the Windows 98 crowd.
But, with Linux, why not put out a 100% 64-bit port? The source is there, and if they can't/won't make a native 64-bit compiler (gcc is the obvious choice) for Sledgehammer, why even bother designing the architecture?
Linux on Sledgehammer sounds nice -- but let's not kid ourselves -- it's not a big enough market to support an entire processor line. Either they price this thing so that it's competitive with the desktop market of Pentiums and Athlons, or they need to be very risky and go all out and try to get a broad range of server OS support (MS, Sun, IBM), the way that Intel is doing with IA64. An expensive chip that only runs Linux is doomed to failure.
--
Business. Numbers. Money. People. Computer World.
The 8086 was a hack. Intel knew it was a hack. The chip they really wanted to define their future was the 432
Unfortunately, the 432 was rediculously big, complex, and slow. It failed misserably in the marketplace.
Agreed. There was no preview of the processor or no new "News" in that article. No specs, no simulations. It looked liked AMD marketing trying to get people to talk about the product and raise awareness.
I must say that Raleel has it correct. I work for a DOE lab and the most memory we have in one of our machines is 2Gig, and it's not enough. We do finite element mesh generation, and the 100,000,000 element range requires more than 2Gig. I work on a Dec DS20, with 1Gig, and we're actively looking into upgrading it to its maximum of 4 Gig just so we can do at least part of these huge problems.
I believe they will be basing it on the Alpha chip-also a 64-bit chip IIRC. I can't wait to see one of these in my Linux box
-- DuckWing
The article talks about how FP on the x86 is stack based. However, I seem to remember intel switching to a stack/register model back in the pentium. I believe all the recent x86 chips have allowed you to address stack locations using F(1), F(0), etc. but you can still treat the registers as a stack if you want. I may be wrong though.
The most important detail that the article leaves out is how the new 64 bit extensions will work. Personally I'm hoping that AMD keeps the current instructions but creates 64 bit extensions that work in a more RISClike fashion. Something like limiting addressing modes to register and register+constant, do the more complex instructions in microcode, and most importantly add another 10 or 20 gp registers to the integer code.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
The widely-used M680x0 was a representative chip design for its time (1979 and on) and featured a full 32-bit internal architecture, although its data bus was only 16 bits wide. The 68020 (1984) had a full 32-bit data bus.
There are zillions of 32-bit operating systems for IA32. Some of the more well-known include the various BSDs, Linux, Windows NT, Solaris, and NeXTStep.
MJP
Don't try that "protecting the children" shit you people use to keep the tits and bad words off my TV. --Seanbaby
Yeah, now let's just all hope that apple doesn't sue them for infringing on the "sledgehammer" metaphore. Hehehhehehehe =:-)
---
Play Six Pack Man. I
I work in an enviroinment were real computing starts at 16 GB of RAM. Scientific computing. The funny thing is that it's not the programs. Often the programs take up a couple of hundred KB in memory themselves, but the data takes up huge quantities. I'll use an example I saw on some beowulf site...Los Alamos uses a beowulf to compute a nuclear explosion through 1,000,000 atoms....each atom takes up who knows how much. Even at a single K per atom, that's a gig. As I remember though, a single K would be kind of small for an atom. I didn't understand either until I saw it. It's just insane.
-- Who is the bigger fool? The fool or the fool who follows him? --
Well, the MHz vs. performance issue has finally been tested. Notice the speed differences between a 400MHz G4 vs. an 800MHz Athlon vs. a dual-600 PentiumIII system. Guess who comes out on top most of the time in real-world tests?
Bare Feats speed comparison of three high speed desktop systems
-----
Linux user: if (nt == unstable) { switchTo.linux() }
Those who laugh at you for you having a Mac.. are the people who constantly call you to fix their PC.
Considering that smaller, faster CPUs are running circles around chips with more MHz tacked on to their name, we need a new standard in selling computers to consumers.. something similar to how Rambus is listed as PC600/PC800 and DDR RAM is PC2100 (because it's inherently faster even though its clockspeed is slower). If say, a PIII runs at 800MHz it would be sold as a "CPU800" -- and a 500MHz G4 would then be listed as a "CPU850" or so, taking into consideration the architecture performance. Such a naming convention may help even the gap between all competitors as long as they are all tested against the same benchmark. Notice the speed differences between these desktops with wildly different clock speeds (400MHz G4, 800MHz Athlon, dual-600MHz PIII):
Real world speed test web page
-----
Linux user: if (nt == unstable) { switchTo.linux() }
Those who laugh at you for you having a Mac.. are the people who constantly call you to fix their PC.
Before you all go bashing on AMD, realize that this article is *NOT* AMD PR. This article was posted by one of the brothers who run amdzone.com. Look at the whois information on amdzone.com and you will see that it has *nothing* to do with AMD corporate. True, amdzone does post very substantial stuff, but this particular article isn't up to their standards imho.
djx.
the only trail worth taking is the one you blaze yourself
Whereas Intel has the IA64-ready compiler from the RedHat folks and so on (and puts less emphasis on the x86 compatibility of the Itanium), will AMD's x64 architecture get its own compiler or will the x64 end up as an marginal improvement to a dying breed?
--
If x86 is sooooo bad, don't wait and buy a fucking pink IMAC and stop BSing about something you don't know.
Why is the Macintosh the only other alternative to x86? How about Alpha or Sparc? Or was this just another opportunity for you to bash 'pink' iMacs?
(please no ALTIVEC RuLeZ pathetic replies)
You should go to arstechnica and check out the article comparing SIMD units. You'd be surprised. I'm not ragging on the x86 architecture, but you have some weird ways of determining performance (MHz only).
--
Don't lead me into temptation... I can find it myself.
And yes, bashing pink "iMac" is really funny and YOU KNOW WHY !! ahahahaha
That says it all.
--
Don't lead me into temptation... I can find it myself.
No, that wasn't my intention. Do you?
--
Don't lead me into temptation... I can find it myself.
Because it's not really true? Do a little math: let's take the memory size of "today" as 128meg (=2^27 bytes). That leaves 2^(64-27) = 2^37 memory size doublings before the 64bit memory space is full.
The article says memory size has increased by a factor of 16 in the last 8 years -- if we extrapolate that out, solving
it will take 37/4 = 9.25 8-year periods (or about 74 years, give or take) for memory sizes to reach 2^64bytes.Now, I am no means convinced that memory sizes will continue to be driven to increase at the same speed they have in the last 8 years. OTOH, any kind of sustained exponential growth will fill up the 64bit address space within a few centuries... (to be sure, not something we need to worry about any time soon)
-y
150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
It wouldn't be unlikely to see one of the companies take the Microsoft "Embrace and Extend" approach to the CPU market also. Where a program complied for and AMD would work on an Intel chip, but programs written for Intel would not work on an AMD.
I am not implying that Intel would do this, AMD could very easily do this also. This was merely an example showing that once binary compatibility is broken, it opens the way for one competitor to take very aggressive measures to ensure their own sucsess.
--------------------------------------------
Please give your mod points to others, Im at the cap. They will appreciate it more
Agreed, writing x86 asm is horrible. The machine has too few registers. I could use more registers instead of moving temporary results in and out of memory most of the time.
I have to side with Intel on this one. As much as I like the AMD x86's I'd like to see the architecture dead already and replaced by something better suited for modern applications. The x86 is carrying too much bloat. Perhaps a G4 or an alpha would be a good alternative.
One problem is that software vendors haven't written their programs with portability in mind. IMO fair practice in the software business would be that any user upgrading to a new architecture would get the application for that architecture for free as soon as available. This is one service that open source can provide and commercial applications can't. Backward compatibility sucks; closed source software has turned it into a ball and chain for both the CPU manufacturers and the users. Honestly, I think that AMD has a shot at winning this one, but I sincerely hope they do not.
He, I visited a short lecture on the x86-64 architecture last week at the GDC, and the guy who gave it specifically noted that the lack of registers on x86 was a pain in the butt... He also hinted pretty strongly about Sledgehammer supporting SIMD-type processing on double-precision floating point numbers. Cool!
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
ben voyons, Linux Tabarnak !
It's not just that. The development cycle on a hacked x86 architecture is bound to be shorter than that of a new architecture.
Also, (and I may be wrong on this one, so don't holler murder just yet) but I was under the distinct impression that the EPIC instruction set was public and already published.. just like the x86 instuction set. So AMD could build a chip too, they just chose not to.
Rami James
Altec Lansing R&D, IL
(All comments are my own, and not necessarily those of my employers.)
--
rJames.org - illustration
Mike Roberto
- roberto@soul.apk.net
-- AOL IM: MicroBerto
Berto
Oh, I believe it. Anyone using a PowerPC is well-aware of this. :) Comparing a 500 MHz G4 to a 500 MHz PIII is apples and oranges, but you can't forcefeed clues to anyone.
Constitutionally Correct
If your pr0n - er, sexy pics - are taking up more than 4GB of memory (64GB on 36bit) THEN you have problems... but since most JPGs aren't this big (I believe I remember the upper limit being 4GB, actually), I think you're still safe
my point is (aside from being snotty ;), 64 bit int units aren't gonna boost performance much, if at all, which is why most PCs are still 32 bit.
Sounds like AMD's going to speed their FPU up somewhat. It's about time. I've been cranking my K6/2 without any pipelining, and been feeling 1/3 the speed of an Intel.
"Evil will always triumph over good, because good is dumb." - Dark Helmet (Spaceballs)
Really in the current CPU market it is quite needed a CPU that can handle loads and levels such as these. With the line in between high-end server and high-end gaming becoming unclear (Friend and his pair of CuMine 700s for gaming) it is nice to see -- for now -- a pure business server CPU.
The ultimate network admin tool needs HELP!
In 2010, when the film industry wake up and I make my millions off a video streaming server, I will be wanting my most popular films in RAM, say 10 films. Soon after that when I begin streaming CD-quality music too (wav files not mp3's), I will need to keep the top 40 in RAM also. I can safely predict that I will need well over 16Gb of RAM to do that in.
If that's not the future of music and video then it damn well should be.
Gates law? I thought that was a sarcastic blow at MS for making software that requires twice the RAM every year. I think what the author meant was "Mores Law".
is any account I think 64 bits will bring on a new wonder full world of memory mapped file systems, 4 hours of DVD quality porn cached to RAM, and yet another excuse to buy a bigger badder "faster" computer.
-Jon
this is my sig.
this is so discussion is so lame.. *sigh* ...
SCO Unix was XENIX, which was a Microsoft Product.
-Jon
this is my sig.
As Gates once said: "640k should be enough for anyone".
;)
As i once said: "WOW! a 1GB harddrive! imagine the games you can store on that!"
Everything will be obsoleted in time.
Although i have to agree, 18.4MTB should take a long time
What matters to the market is speed and compatibility, not elegant design. (Otherwise, the x86 would be long dead.) Therefore, AMD can succeed, at least in the short and medium term, by selling a CPU that runs existing code faster than Intel's new CPUs. Even if the x86 market shrinks once IA-64 appears (and that's not a given), AMD can win big simply by claiming all of a smaller market, rather than part of a larger market.
``Life results from the non-random survival of randomly varying replicators.'' -- Richard Dawkins
AS I understood it, Intel was merely talking about the 64 bit, not the instruction set. After all, if they though it would be standard in 2005 to still have the same stone-age command set, why would the move away from it? And how could the old architecture become standard?
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
[]
It gives all the power of RISC and the nice things of CISC (variable length instructions).
The point is this: writing assembler code is nowadays not something many people do. A different command set would produce MUCH faster code on the same architecture, especially with good compilers. The thing the x86 are lacking most are general-purpose registers that could be used for compiler optimization.
The fact that x86 processors run at higher MHz than any other should be a hint for your pedantic biased mind.
And the fact that other architectures have higher performance despite running lower clock rates should be a hint to you.
Of course this is slashdot, so maybe I'll get moderated to -1 AGAIN for saying x86 is good.
Go run to your mommy. I'd like to know how many /. readers are using alternative platforms ?
The good thing about x86 is that it's cheap. It's also fast, sure. But it could be a helluvalot faster if the same amount of time and money spent to squeeze some more performance out of a geriatric architecture had been spent on developing a new one.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
This "preview" is pure vapor. There's practically no concrete information on the actual architecture of the chip, and without such information, there can be no real estimation of its performance. If I understand it right, they are in fact keeping the x86 instruction set, and that is a serious performance dampener.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Practically every good feature of it is an afterthought that would work much better in a completely new architecture.
The fact alone that all current x86 CPUS are actually internally RISC processors that have to translate a command set that is totally unfit for RISC methods should be telling enough.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
I thought this for a while, and then realised that there are 2 things that could redress the balance.
1. AMD are out of the server market for the most part. I don't think they have their sights set on it in the way MS do. Until now, AMD's main market is and always has been the home user. It would be interesting to see an AMD server solution, simply for the fact that it would be power at a better price. On top of that, the clock speed that the Sledgehammer runs to is likely to be a lot higher than Itanium, so 64-bit apps on Linux (as long as the compilers are there) shouldn't be a problem.
2. I doubt AMD are in a mood to do MS any favours at the moment, after going with Intel for the X-Box. It must be hard to forgive a corporation that strings you along like that (Although Intel's offer was too good to refuse, it was a nasty move that could only be made by the monopoly it holds).
- "How do we do it? Volume!" - The Bursar of Unseen University.
If this is going to be real, I'm wondering how difficult it's for linux to support such SMP system. Think how long it has taken for true SMP support that is promised to be in 2.4. Of course this could be emulated by motherboard as normal SMP system but I think that kind of mobos would not be cheap!
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
The silly thing I found in that article was the claim that Intel would be running x86 code through software emulation. My understanding is that the IA-64 uses hardware emulation, and that the big speed barrier they were having for running x86 code was clocking the chip up to speeds that didn't melt a hole in the motherboard...
I know the article is written with a very pro AMD point of view. But in the second paragraph of the details section, it speaks to the paraphrased statement from Intel that they don't expect this technology to become standard until at least 2005. I would take this as Intel is not working on marketing a chip of this flavor for now, but is looking at it by 2005. I didn't get the impression that Intel has abandoned or is about to abandon the architecture if they feel it will be standard in 2005.
More race stuff in one place,
than any one place on the net.
...is that Sledgehammer will continue to tie us to the (seriously stretched to its limits) x86 architecture, warts and all. I for one had hopes that IA-64 would give us a clean break in processor architectures, but Sledgehammer, if successful, will likely lead us into another decade chained to the x86 legacy. Hooray.
-- WhiskeyJack
>> I think that if they could, AMD should have joined the IA-64 alliance, and released a IA-64 compatitable processor.
I know Intel licensed X86 to AMD, but is AMD licensed to use IA-64 technology, or would it be a patent infringement?
--AROS is an Open Source AmigaOS clone, and source compatible with AmigaOS! Try the x86 build at http://www.aros.org
I remember writing a Rubiks cube solver as an AI project. The earlier versions essentially used a breadth first search, which meant that I quickly filled up my 8 Megs, and after about 10 moves I'd caused the 1 gig supercomputer that I had access to some serious thrashing. If I was writing a breadth first search for something that was more comlicated such as chess, then I should think that it would be a cinch to fill up a mere 18 exabytes
Point taken. Although breadth first searches are trivial to parallelise, so perhaps solving chess could be a task for a distributed network. Of course the amount of data here would be too large to send back.
FWIW, DEC introduced the 32-bit VAX processor in 1977, and the 64-bit Alpha in 1992; Intel intoduced the 386DX in 1985. Oh, and many of the systems using those processors had four and five-digit price tags, too :}
Information wants to be free -- but informants want to be paid.
I'm not sure yet how much swap space it will need though.
Help save the critically endangered Blue Iguana
This problem has been massaged and tweaked around in existing products (see on Compaq's Proliant 8500 server, which supports up to 16GB of RAM). The previous poster who bemoaned the need for so much memory has probably never had to deal with a very large database server (or any other application that benefits from extensive caching).
Help save the critically endangered Blue Iguana
I didn't really get how it's supposed to do 64-bits processing. :-) :-(
If it's like the 80386, they have to define 64 bit segments plus prefixes (some unused instruction, like 0Fh F0h) to get a 32 bit instruction in a 64 bit segment or the other way around.
And add a virtual 80386 mode
Or do they want to literally extend IA32? Then the first byte of the 64 bit instructions has to be F0h, for the second one there aren't many choices left, so this gets you very long binary instructions
Yes!
One day the world will be wonderfully open-source, but just at the moment it isn't. And speaking as a user rather than as a programmer, I can say that once I've got used to software, I want it to run forever. I have better things to do than learn a new set of bugs.Now (as a user) I don't care what my hardware is, as long as it runs the long-obsolete programs that I bought 15 years ago from a long-defunct supplier. Strictly speaking, you can give me x86 in software if you prefer - but do give it to me, because I want to buy your chips without thinking whether they'll work with my particular accumulation of stuff...
As a programmer my views might very well be different, of course!
[Remember that even having source code doesn't necessarily help. The supplier, and even the community, may be disinclined to make any necessary patches to what they consider to be an out-of-date version of the software-- which means that they won't help with my Wordstar 4 (1987: 5 and 6 were a mess), my Eudora 3 (4 is horrible), my Netscape 3 (ditto)...]
But I admit that I do only run 8080 CP/M programs (1980) about once a month or so, by now (the Pentium quite likes them, I think: gives it a feeling of continuity).
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? Coming from a high-end computer graphics standpoint I find that increased RAM generally affords me more flexibility and possibilities when designing algorithms than does extra CPU power. A great many optimizations are possible with 3D rendering when you can afford large caches and data structures. These optimizations can increase speed perforamance by orders of magnitude as opposed to the fractional speed increases we get from newer chips with higher clockspeeds. In general, any heavy computation on large data sets such as those found in computer graphics, science, medicine, etc... will benefit greatly from paradigm shifts in availble in a variety of subtle ways. Since available RAM in our machines seems to be increasing faster than CPU speeds we can opt to waste more RAM when trying to find the critical balance between speed and memory usage in our algorithms. Also, it is important to note that although many applications don't need to simultaneously access a lot of memory they could benefit from mapping a large data set into memory in order to avoid manually swapping the data. An example of this is the large data sets that are used in 3D rendering. These data sets often contain a lot of detailed geometry and high resolution textures. A given rendering algorithm probably doesn't need all of the textures and geometry when rendering a portion of the final image, but it's nice when you can mmap() the texture files and geometry into you r address space and not worry about loading and swapping the data manually. These data sets can easily grow larger than 4 gigs making it impossible to map the whole data set in to your process. It's always nice to have more headroom in your virtual memory space than you have in physical ram.
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 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!?
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/
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
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)
Whether AMD can do better remains to be seen, of course.
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??