AMD's New SledgeHammer: 64 bit chip 211
ChickenBomb wrote to us with word that perennial battle between Intel and AMD is continuing with AMD unveiling plans for their new 64-bit microprocessor, code-named SledgeHammer. Heck of a lot better name then Itanium, IMHO.
Re:Best Chip on the Market? Not Hardly. (Score:1)
g3/4 are good chips. unfortunately I STILL havn't been able to find one I can put together myself.
as far as other hardware... I have either been not impressed by it... or it is way too expensive for the mogamips.
Re:VM's and new CPU architectures (Score:1)
If you write decent C then your code will work "anywhere" once "anywhere" has a C compiler ported to it. And your code (again if you write it decently) will take advantage of many of the innate features of the hardware. Plus a C compiler will be available long before a java VM...
Don't get me wrong, Java was/is a neat idea. But portable, available, source code is so much better.
Re:64bit vs. 32bit to end-users (Score:1)
REAL MEN USE SCALED INTEGERS - SUCKERS GO WITH FP!
(Oh, I meant games and 3d-stuff if you didn't get it)
Time to market, and if AMD was smart (Score:1)
The time to market for a flagship CPU is four to five years (from initial architecture design, to volume production). For a chip with a new ISA, it is longer (the article said Merced took six years, but it actually took over seven years). In other words, I don't see how they think they will get this out by 2001.
Since they are simply making the IA-32 architecture 64 bit instead of developing a new architecture, they will be hampered by the IA-32 instruction set (e.g. all of the different funny modes, space for obsolete instructions, difficulty of instruction decode, etc.) They have an opportunity (in theory) to make a new (and good) architecture, but they are choosing to use the most backwards and difficult one available. TRUE, this is good for backwards compatibility, however, IA-64 is also backwards compatible AND has a different architecture.
The reason this architecture will fail is that all the software makers have done ports to IA-64. I am especially talking about the non-x86 commercial Unix's. Porting things like HP-UX, Irix, AIX, and Tru64 makes as much sense as porting those to IA-32. In the more PC type market it is viable, but only just: again, it depends on support from software makers, and I really don't see why they would all want to go out and support ANOTHER architecture which is totally unproven. It also depends on support from VAR's: could you imagine IBM or HP using an AMD chip in their high profit margin workstations?
Finally, I have the following to offer: If AMD was smart, they would license an existing 64 bit architecture (say, Alpha), and then engineer a die which would put that together with their IA-32 bit stuff. This would actually be a serious threat to Intel (but what AMD has now is a joke). It would have the advantage of have existing 64 bit operating systems and it would also be quicker to market (it might be cheaper also, depending on the licesing costs).
Is Instruction Word Size important? (Score:2)
Question: What does instruction word size have to do with the quality of a processor? Address and data word size is the important part, AFAIK. "How much memory can you address?" and "How high can you count?" are the questions you are concerned with.
In fact, wouldn't a smaller instruction word size keep program size smaller?
Re:256-bit chip on the horizon? (Score:1)
Wow!
If I store a flag in 'int' I'll have 0.39% efficiency. Cool!
Re:Will AMD go the way of ZiLOG? (Score:1)
The 16032 and Z8000 were buggy chips. They died of self-inflicted wounds.
I don't see how anyone can seriously compete with Intel. Their chip designs may be mediocre, but who else has the process technology and fab capacity to produce millions of high speed chips?
Re:Back In The Good Old Days . . . (Score:1)
I would have guessed Hexium and Heptium etc. back then, but nope. Anyway - Itanium sucks, so does Sledgehammer. I'd prefer 'Brute' or something else I can relate better to ;)
--
"You rarely reach the target first by walking in another mans path"
Will AMD go the way of ZiLOG? (Score:3)
Then came the 16 bit revolution (when we really needed more - the 16-bit minicomputers running out of space should have been the clue.)
The competitors were:
Intel with the 8086
ZiLOG with the Z8000
Motorola with the 68000
National Semiconductor with the 16032 (later called 32016)
In technical terms, the order of merit was 16032, 68000, Z8000, 8086. In marketing the 8086 was way ahead, but I think the 68000 was next.
Only two of these gained any substantial market share, and the 68000 had the advantage of being really a 32 bit processor. The 16032 was a better 32 bit processor, but it was just too late arriving.
If AMD have some technical feature of the scale of 32 vs 16 bits back then, and they are also far enough along with the development that they can ship at most a few months behind Intel, they have a chance of competing in this space. The more likely outcome of developing an incompatible processor is that we will see them reinvent themselves in some niche market in a few years time as ZiLOG have now done.
The Open Source community may well be able to use SledgeHammer when it arrives, but the software shipped as binary will ship for itanium first (or only), and that will be what counts.
some context .... (Score:2)
This isn't so much a bad thing Merced was announced in a similar manner MANY years ago - people should take anything you heer this week about the distant future (ie 2+ years) with a grain of salt - chips take a long time to bring to market and always change a lot during the process - remember they are announcing their goal - not new silicon that's sampling to customers - these are VERY different things.
AMD alliances : Alpha ? Transmeta ? (Score:1)
AMD might buy some 64b technology from Compaq ?
Or maybe Transmeta really did some highly performant x86 emulator than AMD will use ?
Re:no specs... (Score:1)
Re:Interesting info/analysis at The Register (Score:1)
Re:SledgeHammer - Good idea? Bad idea? (Score:1)
well, I think yes. The only reason that people buy AMD is so that they can get relatively the same speed chip for a much lower price. They run the *same* programs, not *different* ones that their new 64bit will run. I really can't see developers *or* users wanting to buy a chip like this. The Macintosh may have been a better design, but who supported it, and where are they now?
640k (Score:1)
the 68k is another type of CPU the 'k' is sort for 000, ie 68000 68001, ect
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
Re:I must agree with Hemos (Score:1)
a little bit of 'Speedfreak,' and you could bet your sweet biffy i'd con my wife into letting buy one.
New Sledg-O-Matic Processor by Gallagher (Score:1)
Next time you go to buy a CPU, remember the Sledg-O-Matic!
Concentrate on the Athlon first? (Score:1)
Optimal word size (Score:1)
Flag - 1 bit used
Char - 8/16 bits used
Your average int - about 5-15 bits used....
There must be some data on average number (and dispersion for that matter) of USEFULL bits per a piece of computer data (word?) in average computing task.
Now it's obvious (for me at least) that if you'll get a 256 bit (or whatever) CPU - you'll actually be LOSING bandwidth compared to your average 32 bits one as you'll be tossing absolutely useless zeroes all around your computer.
Question:
Can someone calculate the OPTIMAL number of bits per word? Bandwidth-wise.
I hope (Score:1)
If they do make it to production, I know the Sledgehammer will be a superior chip, AMD has proven themselves many times in the past and won't let us down.
Dan
Re:Is Instruction Word Size important? (Score:1)
Say nothing about address spaces. If you want to address more than 4Gigs without kludges you'll need more than 32bits! (Or you should address words, not bytes - than you'll have 16Gigs, but that sucks also)
I must agree with Hemos (Score:1)
Now Sledgehammer is a great name. And instead of "Start me Up" by the Stones they could advertise with something by Motorhead! *wink*
Legacy... (Score:1)
1. 16 bit - 'real' mode
2. 16 bit - prot. mode
3. 32 bit - prot. mode
4. 64 bit
Gee. I'm glad it won't have UNIAC instruction set at least.
(Spelling could be wrong
Linux support (Score:1)
The AMD Press Release for SledgeHammer and LDT... (Score:1)
I find it a bit disappointing actually (Score:2)
Backwards compatability. From what I've been reading in the past about processors, this is the key "feature" that keeps system speeds down. It's one of the reason RISC processors are faster than their x86 counterparts.
Intel finally has the right idea by moving to a completely new 64 bit platform instead of just adding to the x86 chips. And now AMD is going to take a step backwards.
Ahh.. screw em both. I'm going to save up for an Alpha, or a G4 to run Linux on.
Re:Will AMD go the way of ZiLOG? (Score:3)
And so will, presumably, Willamette (which, at least as I infer from what I read in Microprocessor Report, will be the next IA-32 core from Intel; they may call it "Pentium IV" or whatever, but it appears it won't be a P6 tweak).
The questions then will be
Re:Concentrate on the Athlon first? (Score:1)
Hasdi
64-bit is needed (Score:2)
You forgot the biggest limitatation of 32-bit machines: Address word size. 32-bit machines can address a maximum of four gigabytes of memory. A 64-bit machine can address four billion times that. It is not uncommon to want 8GB, 16GB, or even more memory in servers these days. And it will only grow larger as disks get bigger. A 2500 GB disk array wants a lot of cache.
Possibly a bit stupid (Score:1)
--
Re:I find it a bit disappointing actually (Score:1)
As far as Linux use goes, and I think that's pretty important to a lot of people on this list, I do think that effort should be made to make sure new software will run on 486's, but going back further would probably be a waste of time, since a 486 PC can be had virtually free these days anyway. Heck, you can get a decent low-end pentium for next to nothing.
"The number of suckers born each minute doubles every 18 months."
And Microsoft lags behind... (Score:2)
This seems somewhat surprising, as I would expect Intel to pay close attention to the needs of their good pal, Microsoft. So now you'll need the competition's chip to run 32-bit apps more efficiently... If what AMD claims is to be believed.
And Microsoft is still years away from having a decent 64-bit OS.
With the competition following on Intel's heels, will Intel be forced to whip their 64-bit chips into gear? If so, will they be forced to toss their alliance with Microsoft to the pigs, and move on into the realm of alternate 64-bit OS?
If so, they'll get a lukewarm welcome, I'm sure. They're not nicknamed Wintel for nothing. I think as the possibility of 64-bit platforms becomes more and more a reality, the relationship between Intel and Microsoft is being detrimental to Intel. And they're both likely to lose ground.
I dunno; maybe I'm reading too much into it. Maybe Microsoft will come up with their Win64 platform, and people will consider crappy performance to be the norm, and nothing will change. That certainly wouldn't be anything new.
"There is no surer way to ruin a good discussion than to contaminate it with the facts."
Re:I find it a bit disappointing actually (Score:1)
Not to dis Linus and get my karma all beaten up and stuff. . .
"The number of suckers born each minute doubles every 18 months."
And it's a PROVEN strategy (Score:3)
It will work well for AMD because it is a compromise solution. The PC industry is completely built on compromises because the masses like to take small incremental steps. That's just how evolution works; large mutations are risky, and escaping a local optimum is expensive. It looks like Intel tried to introduce real technological progress, and now they're going to face a threat from someone who is going to use their very own stepwise refinement doctrine.
I don't know whether to be happy or sad about this. I hate seeing low tech win again, but there's such satisfying justice in seeing Intel stabbed with their own weapon, wielded by someone who uses their old(?) philosophy. Yes, I hope AMD goes ahead with this, and makes a mockery of the PC industry for another 20 years. Maybe that's my hatred talking, but I just can't help it. Even if the new boss is the same as the old boss, it's going to feel soooo good to see the old boss suffer.
---
All Well and Good but... (Score:3)
Re:I must agree with Hemos (Score:1)
Re:And Microsoft lags behind... (Score:4)
The 386 was released in 1986 IIRC. It wasn't until 1995 that Microsoft managed to release a broadly-accepted 32-bit OS. And the situation doesn't look any better today. But Intel can't wait ten years for Microsoft to get it's act together. This explains Intel's sudden support for Linux- it's one operating system that Intel can assure itself will be running on Merced (if you want something done right...). Intel already has had experience with the GCC compiler (remember pgcc), and once GCC is ported, even Linus agrees that porting Linux is easy.
Which processor to use. (Score:2)
But which one should someone use? I, for example, really hate using these Intel or AMD chips at the moment because they are x86 compatible (the problems with x86 have been discussed often enough yet).
Yes, you're right. Alpha Microprocessors are a high-performance way to go, but they are really expensive.
The only things which are _really_ interesting are the StrongARM (from intel/digital) and the PowerPC Open Platform developed by IBM.
StrongARM seems to be dropped by Intel because you don't hear anything at the moment. On the other side, Netwinder's seem to sell well. I don't know what to think about that.
IBM's PowerPC Open Platform hasn't launched yet and the website is rather small at the moment, but it looks interesting. Is it possible to escape from these old x86 times?
If I would have to decide which platform to buy at the moment, I wouldn't be able to buy anything, because I simply don't know. All these interesting and good platforms seem to die in the future if there is not enough support by the customers. - Most user I know buy x86 chips because they simply "work". (They buy AMD if they don't like intel; It's a step in the wrong direction, I think. The decision is not AMD or intel; the decision is x86-arm-powerpc-alpha-sparc.)
Maybe someone is interested in discussing that.
256-bit chip on the horizon? (Score:2)
Ha, made you look. ;) Seriously, since 64bitishness is mostly vapor anyway, I've been daydreaming for years now about what a 256-bitter would be capable of. That would be some serious throughput!
Re:Oh Swell... (Score:1)
Check out
http://www.faceintel.com/
to read about how badly Intel treats its employees and you'll see some of the moral issues I'm talking about. After I read this, I decided that not one more cent of my money was going to be put toward buying a processor made by Intel
64bit vs. 32bit to end-users (Score:1)
The joke is that the newbie said: "Processors available today are 32bit, right? And next CPUs will be 64bit? But that means two times larger software!!!"
:)
Evolution. Was: Bad for AMD (Score:1)
It will run Sun Linux of course.
And there we'll be a host of terminals connected to it.
And admin will slap your little hands on your every move.
Welcome back to the future.
(Arrgh. I miss personal computers)
Re:Back In The Good Old Days . . . (Score:1)
"The number of suckers born each minute doubles every 18 months."
Re:64-bit CISC or RISC (Score:2)
That's precisely what the AMD press release [amd.com] says they're going to do:
There's also this random quote in there, also indicating that they don't plan to introduce some Exciting New 64-bit RISC Architecture:
(Yeah, I just about dropped my teeth when I saw a quote from Cox in there....)
Re:Is Instruction Word Size important? (Score:2)
You might get away with fewer bits if you have a small (e.g. x86-style) register file and no fancyness. But otherwise... it's gonna hurt.
It could back-fire (Score:2)
Consider: AMD has, in the past, made its money by doing what Intel does, but cheaper and better. While it did mean that AMD was always in Intel's shadow to some extent, it was a good market to be in. Being number two in the PC industry is a good place to be if you have significant market share, and AMD was doing well on that. It was also good for consumers to have a choice in their PC purchases.
Now AMD switches to an incompatible architecture. It may beat Intel's line in every way, but stuff written for Intel will not work on AMD. They may lock themselves out of a large market. DEC's Alpha CPU, for example, is a great design, but it sells a fraction of the units the K6 line does. We may also be back to having a single Intel-compatible OEM -- namely, Intel.
It will be interesting to see how this turns out, that is for sure.
Just my 1/4 of a byte.
Re:Thorium? (Score:1)
(Horrorium, Hornyum... I'm going to bed, it's way too late here)
No no no no no. (Score:1)
Alpha on Linux/FreeBSD/Tru64.
Merced on Linux/Win64.
Sparc3, just because a list is too short with two.
Dunno. Especially when you consider the Alpha and Athlon are in a kinda symbiotic relationship wrt sharing EV6.
Anyway, all this next generation stuff is a bit up in the air. Just use the T-word.
Dave
I find it brilliant. (Score:2)
All you need to do is keep the existing predecoder instructions add the ones for 64 bit and increase the pipelines and viola! You have a 64 bit chip based on a proven (or soon to be) design. They will probably add a unit in/near the predecoder to combine 32 bit segments for the 64 bit core.
Beyond that, its a great idea anyway. If done right, they will have a single chip that will compete with both intel's 64 bit and 32 bit (you don't think they are going to abandon destop users do you ?) offerings for many years to come. While intel works on two fronts AMD can focus on one. You didn't think they built the K7 architecture to only last for the next 1-2 years. Much of it will be around probably 4-5 years from now.
(BTW. I have seen no proof that the G4 is faster than the K7. They claim that it is ~3 times faster that the PIII in 7 of intels own tests. Look at the tests. They seem to be testing very specific aspects of the chips functionality. Wait for the real benchmarks to come out.)
Re:I find it a bit disappointing actually (Score:1)
I actually like that idea, but then again I don't run a high end server. So double the number of 32 bit instructions sounds really nice for me.
Sledgehammer is just the code name (Score:1)
Re:I find it a bit disappointing actually (Score:1)
When the Icrapium comes out it will be bit before software is available for all the customers needs. When the SledgeHammer comes out it will be ready to work. No waiting for your favorite software to be ported over to the new architecture, you just go. Huge bonus!
When the Icrapiums come out alot of would be upgraders are going to stick to there pentiums. Who wants a great machine that you can't do the shit you need to do on it?
AMD biggest problem right now is to get the chip released much closer to Intel's release. Or else by that time all the needed software may be available for the Icrapium.
-Al-
Re:Possibly a bit stupid (Score:1)
The way the chip is set up, you will be able to write current 32 bit code to work on it. You will pull a lot of developers in on that. Plus you have the great aspect of a slow migration path. Buy the 64 bit AMD chip keep your existing code. Use the 64 bit code as it becomes available. You don't have to start from scratch.
Re:All Well and Good but... (Score:1)
Re:I find it a bit disappointing actually (Score:1)
AMD should be able to get away with only adding 64-bit instructions for the common x86 operations. There's something like 15,000 different x86 instructions, of which maybe a couple hundred are used extensively (if that). Take this subset, make it orthogonal (and do the same for the 32-bit versions), and you'd be getting a decent chip. Do the rest in software.
--
Bring SledgeHammer Back!!! (Score:1)
-Huang Bao Lin (Trust Me!)
Re:no specs... (Score:2)
And I bet it's a 64-bit version of the "CISC-86" external instruction set that Athlon and K6 and K5 and Pentium {, Pro, II, III} and 486 and 386 use, given what they said in their press release [amd.com]:
Yes, I guess one could, if one really wanted to, read that as saying "extend" in the sense of "add a different instruction set that only a little bit like x86", but I see no reason to believe that's likely to be interpretation AMD had in mind.
Damn Right! (Score:1)
Re:How can you say it is better? (Score:1)
64bit PPC (Score:2)
Re:I find it a bit disappointing actually (Score:1)
Time flies like an arrow;
Example of this: The MCA bus from IBM (Score:1)
SP
Re:All Well and Good but... (Score:1)
Quote from the "Alpha Microprosessor Hardware Reference Manual":
Term ---------- Words - Bytes - Bits -- Other
Byte ---------- 1/2 --- 1 ----- 8 -----------
Word ---------- 1 ----- 2 ----- 16 ----------
Dword --------- 2 ----- 4 ----- 32 ---- Longword
Quadword ------ 4 ----- 8 ----- 64 ---- 2 Dwords
To me this means choices. You don't have to use those 8 bytes for a Quadword if you don't need it, but if you do, its there. Feel free to prove me wrong!
rbf, who is typing on a Alpha running Linux 2.2.12.
LONG LIVE ALPHA!
check their slides.... (Score:1)
http://www.amd.com/news/prodpr/99105.html
http://www.amd.com/products/cpg/mpf/speech/slides
According to them they are going to retrofit Athlon with 64-bit capability at the cost of 5% more silicon. I like their proposals, especially their 3-operand FP instructions (rather than the stack-operand FP).
I think their approach is quite decent. They should be able to come out with one by next year, running on the same EV6 motherboard. Some suggestions I would give them include:
1) explicit register renaming or more registers
2) more condition codes ala POWERPC
3) more predication support (conditional execution) especially on load and stores
4) support for speculative load and check
How much more silicon will that cost ya? another 5%?
Hasdi
Re:Concentrate on the Athlon first? (Score:4)
They're gonna need -something- to replace Alpha... (Score:1)
SoupIsGood Food
VM's and new CPU architectures (Score:3)
But I see a lot of people here saying that AMD's "compromise" will succeed cause it won't force developers to port everything all at once. It'll save a lot of work, so it'll succeed over Merced. Some also bemoan that this means a lesser quality chip will win. A drastic change in architecture is too risky, they say.
But, Java is also portable to anything new that comes along, so an advantage of the VM architecture is there isn't as much reason to fear drastic innovation in the underlying hardware. This is major, IMO. My code will work anywhere, once someone ports the VM to it. A single port, and everyone's code is brought to the new hardware. This is why many people argue that the greater flexibility of the VM architecture is worth the relatively minor performance hit and even the larger memory hit.
Re:Back In The Good Old Days . . . (Score:1)
To me, it's a bit like having to handle the metric system and the American system of measurement. It's useless and only clutters everything up.
---
icq:2057699
seumas.com
Look at Apple... (Score:1)
Whatever the merits of closed versus open systems, a closed system like the Mac does allow Apple to push new technologies more aggressively.
Re:Winners in War (complete cliche) (Score:1)
Re:And it's a PROVEN strategy (Score:1)
The iMac was a big risk, which just happened to be a real money-maker. The question is whether you could classify it as a big mutation since apple has been making all-in-one PC's since the beginning of time (ok, maybe the SECOND day..hehe).
--
Re:Possibly a bit stupid (Score:1)
Exactly - that's what I said "a bit premature".
Granted, they have the slow migration path, but Intel is going to be in direct competition with them, which means that it'll be hard for them to convince developers to use their platform.
Personally, I hope they do well; it's about time Intel [x86.org] had some serious competition.
--
Re:But what else can they do? (Score:1)
Re:Which processor to use. (Score:1)
no, they're not
IBM's PowerPC Open Platform hasn't launched yet and the website is rather small at the moment, but it looks interesting. Is it possible to escape from these old x86 times?
yes, buy an alpha or a mac. the sawtooth mobo's are much better, anyway, and they'll be shipping very soon (much sooner than anyone will have an open PPC board shipping or even in production).
Sledgehammer ads (Score:1)
How twisted would that be? The new Sledgehammer has that same ad except it says "AMD" instead of "Apple" and they debue the new processor in a box that is painted so it looks like one of the old Mac Classics...
I will agree with one of the other poster's about Peter Gabriel's song potentially being in one of the ads...even though I really don't care for the song.
Ok, back to work...
-Vel
Re:And Microsoft lags behind... (Score:1)
Huhh? Maybe you mean way to little RAM. I know win95 has a memory footprint of 19 megs, I think NT has somewhere between 35-45 megs of memory footprint. I think this is what you mean, but it's hard to tell.
Re: (Score:1)
The Sledge (Score:1)
Re:AMD alliances : Alpha ? Transmeta ? (Score:1)
rbf, who is happily using a Alpha running Linux 2.2.12.
LONG LIVE ALPHA!
Re:Back In The Good Old Days . . . (Score:3)
Re:It could back-fire (Score:2)
Good call! (Attn: AMD / agencies!) (Score:2)
That show was vastly underrated; I haven't thought of it in many years. There could be a great funny ad series based on it
Re:I find it a bit disappointing actually (Score:1)
This was the original philosophy of RISC - expose what would have been microcode to the compiler and let it go to town.
Really the only differences between x86 and current "RISC" machines are
Really none of these is inherently bad.
Variable-length instructions can improve I-cache performance. IBM has been using them for years in the 360 and beyond. x86 seems to have gone too far by allowing from 1-15 byte instructions, but a few different sizes isn't so bad.
offset+base+index*scale address can in fact be used by a compiler. Think of accessing a field from an array of structs. Once instruction can do what takes four or five on a RISC machine. Now that one instruction may have a (slightly) higher latency than any one of the four or five RISC instructions, but when you start considering fetch time, the win isn't clear.
Block copy instructions can be very nice for a compiler. Take a look at what gcc does on a MIPS. It inserts a call to memcpy! None of that nonsense is necessary on the x86.
--
Re:I find it a bit disappointing actually (Score:1)
IIRC some of the later VAXen did this (micro-VAX, maybe?) and has been pointed out, Apple did this in the transition to PowerPC. Intel might do this in the future to allow flexibility in marketing.
HP is doing this for Merced to execute PA-RISC binaries, and Dynamo may be what they're using to do it.
--
Apple did this successfully... (Score:2)
AMD's problem is they'll either have to convince Microsoft to support their new instruction set and implement backwards compatibility, or they'll have to write all of that themselves. Anyone know if this can be done in a way that's OS-independent, or will the backwards-compatibility features need to be OS-specific?
Re:I find it a bit disappointing actually (Score:2)
Look at computers these days, their entire architecture is a series of hardware "patches" on an archaic architecture. I mean, just try and count how many different bus-protocols run on your machine (PCI, AGP, ISA, IDE,...). How much memory is on every device and how efficiently is this used when the device isn't using it completely? It seems that each time we are looking for a way to enhance the speed of our machine, - in stead of redesigning - we take whatever we already have and add stuff (Yes, another extra level of cache)... This may be the best way for some upgrade but the Pc industry is what 15 years old?
When will some people finally sit down at a table and say: "What is a computer? What does it have to do? What is the most efficient way to achieve this?"
How can you say it is better? (Score:2)
Try reading my post before responding (Score:2)
Did you try reading my post at all?
I was not talking about data word size -- I am well aware of the benifits of 64-bit native arithmetic.
I was not talking about address word size -- I am well aware of the limitations of a 32-bit address space.
I was talking about instruction word size. That is, the size of the word each individual operation is stored in.
Good Strategic Move (Score:2)
If take-up on the IA-64 instruction set on Windows is slow, and I strongly suspect it will be because of lack of (a certain) OS support and lack of software usage, this definitely gives AMD an opening for a new (or recycled) instruction set on a processor that will run 32 bit software faster than Merced. Maybe they can even pull it off.
Interesting info/analysis at The Register (Score:2)
Interesting times up ahead for CPUs... Sun's UltraSparc-III should be selling by December, and looks pretty damn speedy. More and faster Alpha's coming. Merced is just a test/development platform btw, and won't be that great anyway - the IA-64 design itself has some designed-in limitations, and the Merced design is already a bit of a hack. (anyone want details?) btw, I was reading up some interesting info about Sun's MAJC chip, which is aimed at embedded designs with high-speed data processing, is in a couple of major ways it's actually quite like the IA-64 design, except it has a bunch of other extra spiffy things to make it faster. (want info...?)
Good strategy (Score:4)
The only problem is if there is an alternative, and AMD appears to be poised to offer just such an alternative.
If they can deliver on the performance end, and I think they can, they will offer a much more attractive solution to users and developers. Users won't have to upgrade apps and OS to get better performance, and it sounds like developers of high end apps might have to make only minor changes to adapt their software to use the 64 bit aspects of the chip.
AMD has essentially decided to continue in the path that Intel has followed for the last 15 years. Intel has decided to veer off that path in favor of a new architecture. AMD has decided that there might still be a few years of profitability in it, and I think that they are right.
-josh
Those sayings really can't be true, though... (Score:2)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
Reuse existing 64bit architechture? (Score:2)
Re:And Microsoft lags behind... (Score:2)
flamebait??? (Score:3)
To heck with both of them! I'm saving up for a Transmeta!
Re:Nobody gets fired for buying IBM (Score:2)
So yer C will work just like normal C, eh? You don't have to know about predication, VLIW, load speculation or so forth anymore than you have to obsess about how many bits are used by a branch predictor's history today.
On the other hand, if you, for some godawful reason, need to use 32-bit instructions on a Merced, then yes -- from what we know, you'll take a hit. But otherwise it's the compiler's problem.
Re:All Well and Good but... (Score:2)
For one thing, those 21264 instructions are actually just 32-bits long IIRC ('tho they manipulate 64-bit data).
For another, it's got very limited predication support (conditional moves, again IIRC), in constrast to IA-64/EPIC.
It's also more fun if you've got a (large) register file that can be treated as arbitrarily large 'coz overflow gets mapped to memory -- if you don't mind the cycles, 'natch.
You cannot summarize the 'goodness' of an architecture or processor with just the # of bits it manipulates at a time, or the MHz of the processor.
SledgeHammer - Good idea? Bad idea? (Score:2)
As to everyone skipping out on AMD to head for the Merced chip, I doubt it. Come on, we're all pulling for a new processor that brings us out of the bulky instruction set of 1978 (& probably earlier) 8086s and so forth. We'd love to see Merced be the "chip of the future" and everything else I'm sure Intel is boasting it as. However, we've got to face the music. If someone gives us an opportunity to avoid a drastic change in the x86 instruction set, we'll take it. It sounds like SledgeHammer should kick Merced's butt on running 32 bit code, and we're just gonna have that stuff running around. It doesn't sound like it will be too hard to port stuff to the new AMD chip while Intel's chip may take some work.
I think what it comes down to is AMD opens a new market. People who don't want to spend tons on new ports, but want their code to execute at speeds not limited by 32 bits and 100MHz busses and so forth. (233MHz Athlons soon? -- that rocks!) This then gives AMD an opportunity to produce another chip (Bulldozer perhaps?) that may support Merced, or may not. Depending on how Merced catches on.
I say kudos to AMD. They've got to make a move to pass Intel somehow and it can't come from following in their shadow. They've got to get this show on the road and make a presumptive move. I think they picked a great choice. Not getting stuck in the middle of the road, but not totally commiting to something completely different.
geisel
At least if it doesn't work no one can put it on the Periodic Table of Intel Chip Flops.
Re:I find it a bit disappointing actually (Score:3)
It's not so much the backwards compatability as the fact that the ISA was not designed properly in the first place. Actually, the x86 is pretty close to being a really good compiler target. The offset+base+index*scale addressing can be put to good use. The problem is the non-orthogonality of the instruction set (rep movs takes a byte count only in ECX, etc.).
The 386 was somewhat unfortunate because it seems to have come along "too early." My hope is that AMD will do one of two things:
Dynamic compilation (or "JIT" or whatever) has come a long way in recent years. I hope AMD takes note of it. By moving the more ugly parts of x86 into software, AMD can hopefully design a more efficient core for whatever 64-bit ISA they dream up. If it's built on x86, then AMD should put the 32-bit and 64-bit parts in hardware (adding the appropriate opcodes and formats to get a truly orthogonal ISA) and do everything else in software.
It will be interesting to see what happens.
--
heh. (Score:2)