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

Comments

GCC can't do VLIW

[Anonymous Coward]

Face it, with VLIW the onus for performance is on the compiler. And C is not the easiest language for VLIW compilers. VLIW compilers work best when global analysis can be performed. But global ananlysis is very difficult amid the untamed world of C pointers (aliasing problems).

AMD's 64 bit processor is a better match for the current state of compiler technology, particularly Open Source compiler technology.

Intel's superior offering?????

[Idaho]

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???

As usually slashdot line noise is high

[arivanov]

By the time I read AMD pdf slashdot was already full of various "meaningfull opinions". Whatever, as usual, people never change.

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 them ;-)