Visual Studio 2004 Whidbey mit 64-Bit Support

Compilerseitige Unterstützung für den 64-Bit Befehlssatz IA64 des Intel Itanium gibt es bereits in der aktuellen Version der Microsoft Entwicklungs-Umgebung Visual Studio. In der neuen Version 2004 mit <a href="http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx" TARGET="b">Codenamen "Whidbey"</A> soll nun auch noch der Support für den AMD64 (x86-64) Befehlssatz des AMD Opteron und Athlon 64 hinzukommen.<ul><i>Whidbey will also include the 64-bit C++ compilers that are currently only available in pre-release form within the PSDK. These compilers enable Visual C++ developers to write unmanaged code that target the 64-bit versions of Windows running on both Intel and AMD hardware. Support for targeting 64-bit Windows will be fully integrated into the IDE (figure 8).</i></ul>Ein schönes Schaubild dazu gibt's <a href="http://www.planet3dnow.de/vbulletin/showthread.php3?s=&postid=1392403#post1392403">hier</a>.

Mit der Integration des x86-64 Befehlssatzes betritt auch Microsoft Neuland bei der Compiler-Entwicklung. Niemals zuvor hat eine AMD-Entwicklung Berücksichtigung gefunden bei den Compilerbauern aus Redmond; 3DNow! nicht und Enhanced 3DNow! ebenfalls nicht! Wer diese Befehlssätze nutzen wollte, musste sie entweder in Assembler oder mit Hilfe der AMD CPU-Libraries manuell programmieren. Für viele der Hauptgrund, weshalb sich 3DNow! nicht durchsetzen konnte. Zwar werden auch die Intel Befehlssätze SSE und SSE2 vom MS-Compiler nicht unterstützt, doch gibt es für Visual Studio zumindest die Möglichkeit, den Intel-Compiler einzubinden, der dann Optimierung per Knopfdruck gestattet. Ein Feature, das AMD den Programmierern nicht anbot - bis Whidbey.

Damit dürfte eine schnelle Verbreitung von nativer AMD64-Software nur noch eine Frage der Zeit sein, wobei OpenSource-Anwendungen wie OpenOffice, eMule oder VirtualDub mal wieder im Vorteil sein dürften, da diese Programme im Quellcode vorliegen und jederzeit mit jedem beliebigen C(++) Compiler für alle nur erdenklichen Zielplattformen kompiliert werden können.
THX Alex für den Hinweis

(Quelle: Microsoft)

naja, vielleicht doch 64 Bit nicht übertreiben.

Aber, ein neuer Meilenstein für AMD64.
Auch Softwarehäuser, welche mehrheitlich für IA32 entwickeln, werden wohl demnächst eine x86-64 EXE-Datei zusätzlich erstellen.

Wohl das 'schlimmste':
Intel muß nach dem MS-Start auch Intel-Compiler mit AMD64 nachrüsten um wettbewerbsfähig zu bleiben.

Es fragt sich langsam, was Intel eigentlich von der Anti-x86-64 Haltung eigentlich hat. Der Itanium eignet sich wunderbar, um bisherige RISC-Applicationen auszuführen und könnte hier eine lukrative Nische besetzten.

Für einen XEON mit x86-64 könnte Intel locker mal 50-100 € mehr verlangen und schnell mal 100 Millionen/a zusätzlich an Gewinn erwirtschaften. Auch im Desktopbereich wäre dei Erweiterung pronlemlos unterzubringen.

Die letzten Schätzungen liegen bei 2-3 Millionen Transistoren / CPU Mehraufwand, d.h. +2-3% an Transistoren und ca. 5% an DIE-Fläche für alles = 1 mm2 !

Damit dürfte das Yamhill Projekt offiziell bestätigt sein.

Original geschrieben von Nero24
Damit dürfte eine schnelle Verbreitung von nativer AMD64-Software nur noch eine Frage der Zeit sein, wobei OpenSource-Anwendungen wie OpenOffice, eMule oder VirtualDub mal wieder im Vorteil sein dürften, da diese Programme im Quellcode vorliegen und jederzeit mit jedem beliebigen C(++) Compiler für alle nur erdenklichen Zielplattformen kompiliert werden können.
THX Alex für den Hinweis

Zum Vergrößern anklicken....

Das Zeugs einfach nochmal durch den Compiler zu jagen reicht in den meisten Fällen nicht aus. Im besten Fall passiert gar nichts (ok, vielleicht werden dann die zusätzlichen Register genutzt, was ja schon ein großer Vorteil ist), im schlimmsten Fall knallt es dann bei der Ausführung des Programms. Sehr viele C und C++ Programme machen exzessiven Gebrauch von Zeigern. Na mein lieber Schwan, was glaubt ihr, was sich da alles noch an Bufferoverflows finden läßt.

Original geschrieben von Nero24
Zwar werden auch die Intel Befehlssätze SSE und SSE2 vom MS-Compiler nicht unterstützt

Zum Vergrößern anklicken....

*hüstel* Also ich hab hier Visual Studio 2003 laufen und kann sehr wohl auf SSE und SSE2 optimieren lassen. Es steht bei den Projektoptionen unter C/C++ -> Codeerstellung ganz unten ("erweitertes Anweisungsset aktivieren").

@PuckPoltergeist: Das mit den Zeigern macht normalerweise nix, wenn man bei der Entwicklung berücksichtigt hat, dass die Zeiger auch mal 64 Bit lang sein können. Visual Studio bietet des weiteren seit 2 Versionen die Möglichkeit, nach 64-Bit-Portabilitätsproblemen zu suchen (dabei werden auch die Probleme mit den Zeigern erkannt). Wenn man dieses Feature immer fein nutzt, ist es ein leichtes, das Programm später auf x86-64 zu portieren.

Original geschrieben von TiKu
@PuckPoltergeist: Das mit den Zeigern macht normalerweise nix, wenn man bei der Entwicklung berücksichtigt hat, dass die Zeiger auch mal 64 Bit lang sein können. Visual Studio bietet des weiteren seit 2 Versionen die Möglichkeit, nach 64-Bit-Portabilitätsproblemen zu suchen (dabei werden auch die Probleme mit den Zeigern erkannt). Wenn man dieses Feature immer fein nutzt, ist es ein leichtes, das Programm später auf x86-64 zu portieren.

Zum Vergrößern anklicken....

Kann ich nicht beurteilen, da ich mit VS schon lange nicht mehr "gearbeitet" habe. Ich weiß nicht einmal, ob sich die meisten OS-Projekte so ohne weiteres mit VS übersetzen lassen.
Es kommt auch immer auf die Implementierung des jeweiligen Herstellers an. Wenn ich nicht ganz irre, ist unter Linux auch bei x86_64 int immer noch 32 Bit groß. Bei anderen Plattformen beträgt dies ja dort schon 64 Bit.

Original geschrieben von TiKu
*hüstel* Also ich hab hier Visual Studio 2003 laufen und kann sehr wohl auf SSE und SSE2 optimieren lassen. Es steht bei den Projektoptionen unter C/C++ -> Codeerstellung ganz unten ("erweitertes Anweisungsset aktivieren").

Zum Vergrößern anklicken....

Hoppla, dann ist das wohl an mir vorüber gegangen. Hatte als letztes die Version 7 im Einsatz und da war's noch nicht drin