Slashdot Mirror
AMD Releases X86-64 Architecture Programmers Overview
AMD has released a manual in PDF format to allow software developers to migrate their code to its 64-bit Hammer microprocessor platform. The PDF document is here and Sandpile Web site gives excellent explanatory material of the content of the PDF file. Surprisingly, Sun supports the Sledge Hammer. Article can be found here
It's inferior to Intels VLIW approach.
We don't new another patch on x86, we need a new arch. Intel's approach is superior, but it will take longer to perfect. AMD is counting on that delay to gain support for their inferior product.
My.. How the tables have turned.
AMD's 64 bit processor is a better match for the current state of compiler technology, particularly Open Source compiler technology.
This is obviously a power move on the side of AMD. However, people that know about Sledgehammer also know about Intel's new 64-bit architecture. Though this might be of interest to some, the only people who really care are developers, and I'm sure they're going to wait for Intel's superior offering. Now that AMD's made the first move, it puts pressure on Intel to quicken the pace a bit. I think this is the first step to putting more powerful computers out onto the market. The next six months or so are going to see computing have a brand new facelift, what with the court cases with the RIAA, MPAA, this race for the 64-bit chip, and the massive popularity that Linux is gaining. These are exciting times, indeed.
AMDs 64 bit chip wasn't really alien to big system integrators (IBM, Compaq), but with Sun's glowing support, it'll have an enourmeous mindshare. Who knows, maybe Sun could be for Hammer what IBM was for Java: The Confirmation.
Technical merit won't really make a difference here; both Intel and AMD can make a good chip. It's going to come down to who gets to market first, who can buy the press coverage, and who's going to get the required software support.
I have some vague memory of an Intel sponsored 64bit Linux port; If AMD expects to succeed, they should be doing the same.
I can sum the whole post up in two words:
my sig's at the bottom of the page.
Hmz, I call that very narrow minded, or perhaps 'biased' would be the better phrase. As a matter of fact Microsoft (Windows and other programs) sometimes also don't support the processor as efficiently as they could. The Pentium processor has been around for quite some time now (I'm referring to the plain Pentium (I?) btw) yet it took a lot of developers ages before any decent Pentium based software came out. I've debugged quite some software back then just to see in which way Pentium based software really did differ with the rest and I was quite surprised to make this discovery.
Offcourse I don't judge all the software outthere, don't get me wrong, but if Windows in those days also didn't use the processor to its full extent then I have a difficult time believing that they are doing so now (speculation, mind you). But why didn't Intel complain about that, and still seem to complain about Sun?
Face it, X86 is dead... Sun had an excuse to add a 64bit extension to their 32bit CPUs... The sparc arch wasn't hopelessly outdated. There is no such excuse for x86.
AMD's design enhancements are very very very weak. They don't even add a non-stack based FPU (x86's WEAKEST POINT!).
The only good things that AMD's new arch will do is: Make handling big address spaces less of a kludge (still a kludge), and allow x86es to perform DES cracking as fast as Alpha or Usparc (sideways).
Other then that there it's mostly marketing fluff. While 64bits might sound faster then 32bits, it really isn't (Cept for a few apps like DES cracking). It's all dependent on the arch and design and AMD is keeping the same crap arch.
The reason compilers can't handle VLIW very well is because it hasn't been out there enough. The approach is superior, and it will perform like it sooner or later.
By buying into AMD on this we are selling out our future.
You obviously never read Tom's Hardware. Look at this article describing how Tom thinks about Intel's IA64 architecture (Itanium, formerly Merced) in relation to AMDs SledgeHammer technology.
Why do you think it's called SledgeHammer in the first place???
Every expression is true, for a given value of 'true'
Huge amount of computer based work is now done on Wintel instead of mainframes. Remember how much stability problems arised in windows due to the 16-bit compatibility? Ok, so it was not because of the bitness but the insecure memory model. Still, providing backwards compatibility to 32-bit software is going to happen with separate interfaces (what's the length of an 'int'?^). Have some more DLL Hell? I wouldn't mind Microsoft dropping the backward compatibility all together - heck, the world would probably choose to turn compatible with my OS - but somehow I imagine that won't happen
Most of us would probably finally like to trash 16-bit compatibility, wouldn't we? Keep the old processors for old games and recompile what is
worth it. Or just make it software-emulated and stop wasting die space. But there it remains, according to the PDF. It's just a tradition, not useful anymore.
I was considering whether I should upgrade from Celerons to PIII's at home, when it hit me: wait another year or so, and invest into a 64-bit system. Worth it? In schedule? Time will tell. If only Abit released plans of Hammered mobos
I think, therefore thoughts exist. Ego is just an impression.
Intel started that whole game with adding MMX Technology (R) to their chips. It made everyone think that, somehow, they were getting something entirely different with the Pentium chips because MMX was this magical add-on that no one else had.
Suddeny Cyrix (you remember them don't you) chips started coming out with MX technology. AMD, if I remember correctly started licensing MMX for a while and finally came out with 3DNow.
Now every peice of hardware you buy comes with magical tweaks. Hard drives, video cards, and even motherboards -- they all come in brightly colored boxes with completely unrelated pictures on them flouting "Proprietary Brand Useless Features (R)" If you're going to blame someone for being lame, blame Intel. (Of course, I'd also blame Microsoft, who touts useless or standard features as being "innovative")
I don't understand why Intel and AMD don't start to work on non x86 based processors. The pentium IIIs and athlons already have far too much code to keep them backwards compatible. As far as software goes, Microsoft has already abandoned DOS totally, so why keep the processor architecture to run DOS.
I think they should come up with a new design for a good 64 bit processor. Something that is RISC, but not worrying about x86.
Make Microsoft port all their code for a change to the new processor. They've had it easy. Linux can run on countless platforms and would be easily ported.
For the uninformed,
VLIW means Very Long Instruction Word, which means that the processor can execute
several instructions at one time (one Instruction Word can contain multiple instructions).
This is a good idea because this way the processor does not have to worry about
running instructions concurrently. Instead, the compiler has to worry about that,
which makes it really hard to write a compiler that handles this right, while still
optimizing as much as possible.
Since the VLIW technology has not been tested very much in microprocessor designs,
Intel is doing some really hard (maybe even innovate!) work, but that also means
many problems/bugs/performance issues, as with almost every 'new' technology.
VLIW is successfully used in (e.g.) DSP processors, but those have very simple
instruction sets, where the order in which things are processed often does not
really matter, so this is rather simple to implement.
However, in a microprocessor it's much harder, which may be part of the reason why Intel's Itanium is delayed so much (performance problems, and problems running high clock frequencies).
Every expression is true, for a given value of 'true'
Okay, so assuming I buy a 64bit x86 CPU and slap Linux on it, what difference will I see as an end user to my current 32 bit system. Ignoring clock speed differences, will it be massively faster? Will it be more stable? What *real* beneift do I get from choosing a 64 bit processor, instead of a 32 bit one. The fact that it can address shitloads more memory doesn't help much. Who can afford over a Gig on their home system anyway?
If not one of them is surly gonna beat the crap out of the other and we suddenly have monopoly on CPU's again.
I know at least that if they're not compatible i'll go for Intel as a standard.
Does anyone have any info regaring this issue?
Øyvind
I have to admit I am impressed:
- AMD managed to get rid of quite a bit of legacy for the 64 bit mode. Most of the utterly idiotic segmented switching is gone. There is a well defined supervisior mode and user mode. There is a SYSCALL instruction so the mess of "jump to that magic offset to get promoted to OS level" is gone and OSes will have a nice clean API.
- At the same time there is a reasonable amount of backwards compatibility. It is not without a cost but the cost is way less than Itanic. Almost all idiotic x86ism (tm) like the x86 task switching mechanism generate a GPF on the spot. So the OS will have to handle them in software. This means two things: the compatibility is relatively simple and the compatibility will be easier to achieve for emulating 32 bit OSes where ring 0 is called within a well defined API. Porting "the world of bypass backdoors" - NT on this will suck (even after AMD has broken their own rules and made exemptions for it). Porting all Unix OSes available for x86 will be a piece of cake.
- Also unless told to it will do all calculations in 32 bit. So that most of favourite x86 legacy issues will have less impact. Also it has a reasonable number of register. 8 more general purpose 64 bit ones and 8 more 128 bit SIMD ones.
Quite an interesting beast to play with, question being will it have proper linux and BSD support. Also after reading the PDF it becomes clear why is the Sun support for this. This approach is very close to their uSparc/Sparc legacy scenario. And they have swam in that swamp for years (and are still swimming there). It is their CPU. It was born for themBaker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Why PDF? I'll tell you! PDF is the STANDARD format for online technical datasheets. Go to the webside of ANY company that manufactures semiconductor products and try to get datasheets. They're all in PDF.
People won't care about performance nearly as much as they do about compatibility. If all we wanted was a 64 bit architecture that was fast -it's already out there. It's called Alphas. So, this race between AMD and Intel is about which will Windows run on? It's too bad, though, since Linux has already proven that a good OS is capable of working anywhere. I would prefer to have more choices in the hardware world....
First, make it work, then make it right, then make it fast, then, make it bloated!
Intel is behind behind behind in IA-64. MS is releasing their latests compiler soon MSVC 7. No IA-64 support. GCC has no IA-64 support. What about drivers, that need to be written in an assembly that noone knows? Normally, those things take time. With IA-64, it will take 5 times longer than usual due to the insane architecture difference. Intel will need to do much hand holding to prevent alienating x86 developers.
:)
AMD has managed to address some of the major issues without causing major issues. The architecture is a logical next step, not a crazy throw-it-out-the-window change. Many people would love a re-engineering, since it really is time. But 8 more registers, 64-bit support, and a few tidy-ups and we are in business. With technology, simplicity wins most of the time since it is cheaper and easier.
The big question is "Can AMD release this before Intel steals the idea and make their own version?"
VHS won out because "The cartridge was smaller" thus easier. IA-64 is a behemoth, and the timetable doesn't look good.
There are enough OSses on 32-bit CPU's that can handle large files. NT and FreeBSD to name two. It is unbelievable that Linux still hasn't fixed this.
It would be unbelievable if it hadn't been fixed, as almost any reasonable size database would run into the end of the line fairly quickly. If you pay attention to the available patches for the kernels you'd know that quite a while ago there were patches to the kernel to support larger files - I think the name was the Large File Summit or LFS (not to be confused with Log-structured File Systems). Ah - the patches are available here.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
For most tasks, 64 bit computing is not an obvious win.
Sure databases and heavy duty scientific computing benefit from the vastly larger address space, but day to day gaming, office tasks, web surfing, mp3 listening and Natalie Portman porn viewing (I had to say it) won't benefit much at all.
Now architectural improvements and (mainly) higher clock rates will mean serious improvements in peak performance, but I think Apple is on the right track with pervasive SMP, which should deliver higher SUSTAINED performance, so that I can do all of the tsaks above at the same time without worrying about spikes in demand for processing power will freeze my game at some crucial point. Of course, MacOS isnt's the ideal SMP platform, but the hardware is on the right track.
I know this is way-OT and I probably should post as AC but ...
Why the hell does the sandpile site locked to width of 1024 pixels?
Even if my monitor was at 1024x768 it's awful arrogant of them to think that i would maximise my browser just to read it.
I'm getting close to patching junkbuster (http://junkbusters.com) to strip width= from the html!
At least I have the zoom out option in Opera.
You get more and larger registers --- it will be faster because the less time spent moving data in memory to and from registers the faster the app will be. When you want to multiply 2 numbers they have to be pulled from memory and thrown into 2 registers and then operated on, then you get a result in one of those registers and you can do something else to it. Now scale that up to say an mp3 encoder which is doing millions of repetetive math operations and reusing results of previous calculations.... and you hopefully get the picture.
Granted, this isn't as huge of an issue now that we have chips with a meg of cache on board and busses that can do 4 gigabits/sec.... but every little bit helps! even a 1st-level cache hit takes longer than just using what's already in a register.
There are many PDF-viewing (and creation!) programs available --- You can use xdvi or gv to view PDFs as well. No need to use Adobe's crufy Motif-based quivering mount of hacks.
:)
(Last four words stolen from elsewhere
alpha is definetly NOT a VLIW cpu. also, VLIW is nothing new, intel had a VLIW chip out about ten years ago, which never caught on.
btw, there's a reason no one else is making VLIW cpus. it's because it's an inherently flawed idea.
When u say that VLIW has not been tried out yet u r speaking about the situation last yr when VLIW only existed in textbooks( where incidentally it has been for more than a decade). But with the successful launch of Transmeta's Crusoe which does software emulation of the x86 and uses a VLIW processor VLIW is here to stay Incidentally in my opinion if we HAVE to have backward compatibility why not have it in software and not on the die?
**Life is too short to be serious**
Microsoft has already abandoned DOS totally
But the embedded market hasn't. Neither have these guys. And the FreeDOS Project is even creating a GPL'd DOS clone.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
The only thing that really sucks about this is that the byte order is still backwards Intel legacy crap.
But is little-endian (LSB first) really backwards? That's how bytes are sent over a serial port (low bit first). Little-endian is also the standard on the popular 6502 and Z80 CPUs in embedded systems and in the popular Game Boy handheld console (think Handspring Visor without the pen input). x86 asm coders seem to think the way 68000 and friends do it is bass-ackwards.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
I know I'm supposed to be impressed by the bigness of the term "64 bit" and all, but this is striking me as another odd niche piece of hardware that most developers don't have time to exploit. Think MMX, Katmai, 3DNow.
Processor speeds have gotten high enough and software bloated enough that much bigger wins can be obtained from cleaning up existing software than from CPU pissing contests. Corporate fanboys don't want to hear that, though.
I find it hilarious that by the phrasing of your post you assume most companies have either moved to win2k already or are waiting to... There are many of us out here in various industries that would rather shoot ourselves in the head than move to win2k. Talk about insane overhead, non-compliant "standards based" features, and just general pain... maybe win2k would have been ok if they had axed the winNT compatibility so that lanman crap wasn't still hanging around. blah. I'll stick with our various commercial unix platforms for the time being, thank you :)
EOM
jeb.
I've programmed in 6502 assembly on both Apple II and NES, and I've looked at a Game Boy ROM (Game Boy uses a Z80-compatible CPU, and only once have I ever seen a string written backwards. It was "DISK VOLUME BARSBAIT" in the old Apple II DOS 3.3. Try editing some legal NES ROMs with a hex editor.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
For a shameless commercial:
BOPS designs DSPs, and a demo of iVLIW (yet another taste of VLIW). here, and press start demos. Have phun.
disclaimer: I work there.
nosig today
... called Sledge Hammer. I thought it was hilarious. I wish they had it on video.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
If AMD wants to be shipping X86-86 boxes soon (like early next year), they really need a solid, working, 64-bit OS for it. Linux being what it is, it will get ported over no matter what, but *very early* availability of Linux may well be what makes or breaks the X86-64. I sure hope that AMD, or some partner, will soon make public an internal port of GCC and Linux. If they haven't done it, they'd better start one, like now.
One thing the x86 architecture has going for it is the fact that it probably ends up having some of the smallest executables out there. Have any of you ever compared the size of a sparc binary versus an x86 binary. Often times the x86 binary ends up being half the size. And I'm sure that the instruction set for IA-64 will result in similiar sized binaries to that of the sparc and the alpha. Say what you will about CISC instructions, but it does make for a bit smaller memory footprint as far as memory resident code goes...
In my local computer store (PC World for those in the UK) I read the following ad for some laptop.
Sony Vaio XXXXXX laptop
Key Features:
* 10.4" TFT Screen
* XXXMhz P3 CPU
* No Modem
Solved all my problems since it's so hard to get a laptop without a built in modem these days.
Oddly the feature card failed to mention 1394 Firewire, Memory Stick Slot and the low weight!??
Both architectures have their own strong points and weak points...
What could play in favor of AMD now is that software for Itanium at it's launch might be far from mature and it might take a while before it gets any better. There will be not many other options considering that backwards compatibility with x86 for Itanium is, as it should be considering the new architecture, just a big joke. Not quite ideal for servers if you ask me...
This could mean a wide headstart for AMD:
- Backward compatible with a performance boost instead of a performance hit while 64bit software gets polished
- Porting existing software will be easier and easier means pontentially more software available at launch
- Probably much better availabilty of the chips; many websites have claimed that Itanium will only prepare the "road" for it's eventual successor..
- Rumors have also claimed that Intel had no intention to drop the x86 line of chips for a while. That could also play in favor of AMD; they would have potentially the first widly available 64bit x86 chip in the market. Unless Intel adds a 64bit layer of it's own to it's x86 chips.. but then again.. AMD seems to be much more ready than they are on this front and it would be stupid even for Intel to release their potentially incompatible "extensions" after them.. Intel would be one that would be playing catch-up.. unless they can bribe as much software houses as they can..
Now if AMD really manages to do it correctly, and considering their success with the Athlon it might happen.. they've seen bad days but it is getting much better IMHO, they really might become the new leader in, at least, desktop chips. Servers are another story but still it is possible considering again that software for Itanium won't be as much mature so easily. I don't think Microsoft will follow AMD in 64bit though unless their "marriage" with Intel comes to a divorce...
And i'm not upset at all for linux... i'm sure it will be available for it...
Dynamic software translation is such a technology. Yes I know that it completely failed to do anything for the Alpha's NT penetration (remember the FX!32 dual mode chip?) but we'll put
that down to poor marketing (did you ever see one system with it?).
This is how the revolution will be telecast. Apple did it. win/tel will do it too. While I love AMD for giving intel credible competetion, I do have to admit that I think sacrifices to binary compatibility are looking like a worse and worse strategy.
This is the optimal time to introduce a new architecture. When apple changed to PPC, they were switching to a much faster chip, so were able to claim significant speedups vs the old architecture. Win/tel doesn't really have that option (requiring longer lead times to see significant speed iumportovements over the current arch), but we finally have a plateau in speed requirements.
This plateau means that a new architecture can be introduced on obsolesence alone -- the first couple of generations don't need to compete on speed. As more and more applications get ported to native code, consumers will again see speedups.
Of course, the new architecure would offer speedups to their big-money early adopters -- java backends are already architecture independent. Just introduce a native java VM along with the chip.
So if there ever was a time to throw out cruft it is now, before the next wave of innovation starts. Go to a faster architecture now, get back-compat by emulation/translation.
Everyone wins; server users dump money into native JVMs and get speedups soon. Consumers wait and by the time the next wave of power hungry apps comes along, everyone has "gone native".
Notice that this entire argument is based on the assumtion that the plateau will last long enough to give most of the industry a chance to go native. So I ask you; what technologies are out
there waiting to use the power? Natural language speech recognition? Good AI in games? Immersive 3d environments?
AMD will is announing that they will have a live webcast from Linuxworld 2000 on the 15th. Let's hope they announce some news about new optimized compilers for Linux or something at the show.
As a matter of interest: why ?
PS. Crusoe's native IS is VLIW.
Part of the advantage with AMD's offering, is
that porting from the 32bit x86 to their 64bit x86
is MUCH, MUCH easier than porting from x86 to IA64. This means that though Intel had to start
more than a year in advance, AMD needs much less
time to get support than Intel.
Besides, the OSes are the most important, but not
everything. The applications also have to be present. And Intel does not have that much of a head start here.
Also.. AMD's offering can run 32bit x86 applications MUCH faster and better than IA64.
That said. I think Intels architecture looks more
interesting. I've just got the feeling that AMD is right about the industry wanting another x86.
Everyone says they hate x86, and most of us do hate all the legacy, but starting all over with
a HUGE presence of applications for x86 doesn't
seem like that good an idea.
A point against being better at compatibility,
is that Intel is large enough to warrant porting,
and with Sledgehammer being good at running 32bit,
people may not bother to port applications to 64bit x86.
Time will tell..
The compaq C compilers were advertised to get about a 20%-30% speed increase over gcc, and that was about a year ago. All sorts of nifty optimizations were scheduled to be merged into gcc since then.
I've moved to an Athlon because alphas are just too damn expensive, but gcc was not so far behind digital's C compiler.
If you want to talk about fortran, that is a different story. I think that on average the digital fortran compiler would produce code about double the speed of g77.
Anyhow, the tremendous speed increase in the digital compiler was mostly in inefficient code. There is a very interesting (but old now) paper linked to off of alphalinux.org about how to write optimized C code. While unoptimized code would usually run a slower on gcc, the difference prettymuch disappeared when you optimized your C (things like manually unrolling loops, transposing matrices before multiplications, etc.).
So it depends. The digital C compiler would result in unoptimized code running faster on an Alpha, and the data that I have for this was from a long time ago. What the state of compilers is now, I don't know. However, I would be extremely suprised if gcc hasn't gone a long way to catching up.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I got a good chuckle out of the fact that AMD is calling the 64-bit IP RIP. Every time RIP gets touched it signals the end of non x86 processors. 'RISC' processors will be pushed into even narrower markets than they already are. The extra R&D money AMD has because of the volumes of x86 processors will allow them to continue to gain ground on existing RISC processors until companies simply cannot afford to make a general purpose non x86 processor for desktop/workstation/server use that competes with x86. The only place you will find non x86 processors is in embedded systems where the extra decode logic for x86 costs to much power.
BTW: The next step for AMD after this is to build a SMT x86-64.
I didn't see any mention of 3DNow. It's been a while since I've seen talk of it.
I _think_ that 3DNow was completely compatible with MMX, and so the reuse of the floating-point registers is all that was needed (If I could remember the name of a 3DNow op, I'd look in their table).
What I thought was interesting, however, was that Intel's SSE instructions were incorporated. I wonder if this was an admission of failure on the part of 3Dnow (since to my knowledge SSE was superior), or if they're just trying to capture that compatibility (while at the same time, upping it's potential performance by doubling the number of registers).
My favorite addition however was the new addressing scheme. The reduction of segment selector-dependency, plus the addition of IP-relative addressing just rocks; Finally, dynamically relocate able code.
As a hobby, I've followed the growth of x86 hardware since the 808[68], so it's really cool to see it finally catch up to the RISC big-boys in most arenas.
Now if they could only have provided 32 GPR and 32 FP-esk registers instead of the paltry 16 (including SSE).
Another interesting point is that the new "xHammer" design is truly an improvement over legacy design instead of scrapping then emulating (a la Italium). Basically, by using prefix op-codes, they maintain a tremendous amount of compatibility and CPU-reuse. In fact, the CPU should hardly even notice which mode it's in (minus how it deals with the upper 32-bits). Any future advancements in scheduling design, n-way execution, etc, should benefit both "long" and "legacy" modes.
Though I find much distaste for variable-length instructions, this is a beautiful case of human ingenuity solving a problem in an intelligent way (various NASA solutions come to mind).
AMD is sure to best Intel at overall value at this stage (Intel may still have a few 32bit tricks up it's sleeve). My real question, however, is how well AMD will fair against finely tuned 64bit solutions. Now that x86 is infiltrating more and more of the server market, does AMD really stand a chance of competing against raw FPU or multi-processing on say Sparc / Alpha / Power / HP / etc? They seem to be fairing well in the fabrication process micron and MHZ wise. Post-RISC chips still have an edge over x86 in that little translation of op-codes is required, and the over-all die-size can be smaller to perform the same functions. This facilitates less power-consumption and theoretically higher clock-speeds. Also, to my knowledge, many op-codes in these post-RISC chips are well suited for multi-CPU design (Off hand, I remember the Alpha's version of test-and-set).
How much life does x86 really have left in it? Can we just keep adding layers and layers of compatibility modes? And if Intel maintains a predominant market share, are they going to be able to purposefully produce incompatibilities to stifle innovation? We've already seen how they can gum up the works with RAMBUS / DDR-SDRAM and their biased chipsets.
-Michael
-Michael
It supports 2^52 bytes (4 petabytes=4.50E15 bytes) of physical memory, that should be enough for the next several years, but why not plan ahead at have it support the full 2^64 bytes (16 exabytes=1.84E19 bytes)?
Sadly, the other guy didn't get it.
As far as I recall, the Saturn chips don't hold a candle to the Dragonball procs in the TI8x (and the Gameboy. Interesting tidbit, the TI8x has a processor that is 6 MHz while the one in the GB is only 4 MHz, both are speced to run higher)
A deep unwavering belief is a sure sign you're missing something...
GCC has targets for just about all well known processor families (and some lesser known) but AMD is conspicuously absent. They are supported as x86 clones only. We have code generation options for i386, i486, pentium and pentiumpro, but no k6 or k7.
Surely the k7 has unique scheduling and timing characterstics that GCC could benefit from. Apparently nobody has bothered to include these in GCC, and AMD isn't doing it.
Maybe the 64-bit sledgehammer will be enough of an innovation to warrant a new backend target for GCC.
IMHO
AMD have spend many years following Intel. They've made a living, by making Intel compatible architecture.
Even though the apprentice may have now grown up to challenge the master, AMD still feel it's not yet time to go out on a limb.
X86 is old, and it is time for it to die the death it should've died long ago. However, what AMD are offering, as far as I can see, is a chance to go to 64bit architecture sooner, without having to create a whole new processor. Even given the increased support for AMD these days, I don't think many would be prepared to follow them that far.
So, what we've got is a happy medium from AMD, while they and we wait for Intel to define the new standard.
AMD may well be playing catch-up again in a million years time when Itanium actually becomes a reality. But on the other hand, if support for Sledgehammer is good, we might see some new architecture from AMD soon!
Oh, BTW. Itanium == Crap Name. Sledgehammer == Very Cool Name!
"How much truth can advertising buy?" - iNsuRge - AK47
"How much truth can advertising buy?" - iNsuRge - AK47
Why do you think it's called SledgeHammer in the first place???
Because someone, somewhere in AMD got thoroughly stoked on Peter Gabriel songs? Might I even go so far as to say "stoked, big time?"
Alternatively, it may be because the crackers would ordinarily go nuts when they have that much horsepower on tap for DDoS attacks, so AMD are pre-empting them: everyone knows you don't drive crackers nuts with a sledge hammer.
All right, so the pun was stretched. It's morning here, OK? (-:
Got time? Spend some of it coding or testing
Does the name Larry Ellison ring a bell to you ???
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
What I want to know is why don't someone like intel or AMD sponsor something like bochs? Then there would be no need for backwards compatability. Need to run your old apps? Use an emulator. It would probably be much cheaper than designing a chip to run around the x86 architechure.