Speculaties over x86-64 support in Microsoft compiler

The Inquirer schijnt een aantal bewijzen gevonden te hebben dat Microsoft druk bezig is met het inbouwen van ondersteuning voor waarschijnlijk de x86-64 Hammer in zowel de Visual C++ compiler als Windows.NET. Ze hebben namelijk deze foutmelding van Visual C++ gevonden in MSDN . Uit de foutmelding valt op te maken dat zowel de frontend als de backend compiler de volgende processoren ondersteund: x86, IA64, en AMD64. Waar zou AMD64 voor staan? Het kan bijna niks anders zijn dan de x86-64 architectuur van de Hammer. Een andere pagina op MSDN beschrijft een C++ structure, STACKFRAME, en ook hier staat er een verwijzing naar zowel x86, IA64 en AMD64. Op de MSDN is nog meer bewijs te vinden:

ProcessorArchitecture

Specifies the system's processor architecture. This member can be one of the following values:

PROCESSOR_ARCHITECTURE_UNKNOWN

PROCESSOR_ARCHITECTURE_INTEL

64-bit Windows:

PROCESSOR_ARCHITECTURE_IA64

64-bit Windows:

PROCESSOR_ARCHITECTURE_IA32_ON_WIN64

64-bit Windows:

PROCESSOR_ARCHITECTURE_AMD64

Met dank aan Mateyo voor het opsturen van de link.

Reacties (25)

Ik zie dat er bewijzen zijn gevonden dat het op de VC++ compiler x86-64 zal komen...nu vraag ik me dus af of Microsoft de ondersteuning voor x86-64 ook in de VisualBasic compiler gaan bouwen...ik hoop van wel aangezien ik naast PHP programmeur ook VB als expertise heb...en ik mijn code graag geoptimaliseerd voor x86-64 zou willen zien!

Tevens vraag ik me ook af of als dat je code naar x86-64 compiled of dat je het dan ook op een regulier x86 systeem kan draaien...is hier een soort 'backward' competibily in zoals x86-64 ook 32 bits x86 code verstaat of niet?
Als dit niet zo is dan vraag ik me af hoeveel bedrijven software zullen gaan leveren compiled voor x86-64.
Aangezien het feit dat x86 code wel op x86-64 draaid en niet visa versa...ben ik dan toch bang dat bedrijven het bij standaard x86 programmateur zullen houden en consumenten niet (volledig) van de x86-64 hammer core zullen profiteren...en dat alleen servers met deze core wel profeit zullen hebben van deze chip aangezien de fabrikanten voor software meestal wel verschillende platform versie op de markt brengt en graag wil dat zijn product het onderste uit de kan haalt betreffende het platform!


Dit 'bewijs' bewijst wel dat Microsoft dit gaat inbouwen...aangezien er zowat letterlijk staat dat het proggie crasht als de code een bepaalde processor target!

Visual C++ Concepts: Building a C/C++
Program

Fatal Error C1905
Front end and back end not compatible (must target same processor)

This error occurs when a .obj file is generated by a compiler front end (C1.dll) that targets one processor, such as x86, IA64, or AMD64, but is being read by a back end (C2.dll) that targets a different processor.

Ensure that you are using a matching front end and back end.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccor e/html/vcerrFatalErrorC1905.asp

Tevens vraag ik me ook af of als dat je code naar x86-64 compiled of dat je het dan ook op een regulier x86 systeem kan draaien...is hier een soort 'backward' competibily in zoals x86-64 ook 32 bits x86 code verstaat of niet?
Als dit niet zo is dan vraag ik me af hoeveel bedrijven software zullen gaan leveren compiled voor x86-64.

Uiteraard is het niet backwards compatible (dus AMD64 code draait niet op een Pentium oid), anders zit er ook geen verbetering in. Je zou wel elke executable en elke bibliotheek een i386, een AMD64 en een IA64 stuk mee kunnen geven, maar dat is enkel heel erg omslachtig en kost heel veel ruimte op je HD (al zal dat niet echt bezwaarlijk zijn tegenwoordig). Zulke programma's bevatten echter voor iedereen overbodige code, zodat je altijd performance verliest hebt tov programma's die voor 1 architectuur zijn gecompileerd.
Dat is HET nadeel van Windows. Ze kunnen slechts voor i486 (misschien pentium?) optimaliseren (XP doet het niet meer op een 386 neem ik aan), zodat je veel van je mooie nieuwe instrukties niet gebruikt.
Als je in Linux daar wel gebruik van wilt maken kan je gewoon zelf alles hercompileren

erg veel plaats zal 3 versies ook weer niet innemen, de programma's van nu zijn lang niet zo groot als men denkt, zelfs bij spellen niet - de "game.exe" meestal maar een paar mb groot, alleen de data files zijn xxl. Ook de argument van verminderde performence geldt niet: je levert gewoon alle versies en kopier de goede tijdens de installaties, zoals die verschillende rpm's voor verschillende distributies in linux.

alleen spellen en veeleisende applicaties hebben voordeel van x86-64, in IE, office en co merk je er toch niks van, je werk echt niet opeens 2x sneller (zou wel mooi zijn )

Dat is HET nadeel van Windows. Ze kunnen slechts voor i486 (misschien pentium?) optimaliseren (XP doet het niet meer op een 386 neem ik aan), zodat je veel van je mooie nieuwe instrukties niet gebruikt.
Als je in Linux daar wel gebruik van wilt maken kan je gewoon zelf alles hercompileren

Ik denk niet dat WinXP alleen maar pentium optimized code bevat hoor. Bepaalde time-critical kerneltaken zullen best geoptimaliseert zijn voor jouw huidige processor (en dus bevat het ook overbodige code: support voor andere processoren. Maar dat hoeft natuurlijk niet op je hdd te staan, maar iig wel op de cdrom). Maar je zult dit wel veel meer terug zien in de drivers voor je hardware, vooral voor je videokaart. Ook die zijn cpu specifiek geoptimized (als het een beetje goeie drivers zijn iig )

Ik zie dat er bewijzen zijn gevonden dat het op de VC++ compiler x86-64 zal komen...nu vraag ik me dus af of Microsoft de ondersteuning voor x86-64 ook in de VisualBasic compiler gaan bouwen...ik hoop van wel aangezien ik naast PHP programmeur ook VB als expertise heb...en ik mijn code graag geoptimaliseerd voor x86-64 zou willen zien!

Effe serieus, sinds wanneer gaan VB en een variant van optimaal hand in hand in dezelfde zin?!?!?

Dat hangt voor een heel erg belangrijk deel van de programmeur af..

Een goede VB programmeur kan echt heel wat snelheid in z'n applicaties erbij krijgen.

Maar goed, verder commentaar wordt echt OT

VB 6.0 wordt eerst omgezet in C, daarna gecompileerd een binary. Een geoptimaliseerde C-compiler werkt dus ook voor VB

VB 7.0 wordt eerst omgezet naar MSIL (MicroSoft Intemediate Language). de JIT-compiler van .net wordt blijkbaar geoptimaliseerd voor AMD64, VB 7.0 dus ook.

Ik ben deze meldingen als eens eerder tegengekomen op MSDN. Ik kon alleen nooit meer een link geven naar die betreffende pagina.
Dat MS nu ook AMD64 vermeld is mooi. Dit betekent dat ze AMD (en x86-64) erkennen en er dus ook ondersteuning voor is.

Het lijkt mij niet meer dan logisch dat Microsoft ook iets aan x86-64 Support gaat doen. Alleen het feit dat er in Linux wel ondersteuning gaat komen voor x86-64 moet voor Microsoft al een teken zijn dat ze niet "achter" moeten gaan lopen. Bij Microsoft opperen ze veel performance op om alles compatibel te kunnen houden, en als ze dan x86-64 zouden overslaan zou het betekenen dat ze opeens een streep door compatibiliteit gaan zetten. Dat lijkt me erg onlogisch.

Het is alleen de vraag hoe MS eventuele bugs gaat oplossen.
De linuxwereld is er allang aan gewend om in de beginperiode met alfa versies te werken, zowat dagelijks nieuwe versies te downloaden etcetc.

MS kan dat niet, omdat hun clientele verwacht dat ze gewoon in 1 keer een eindproduct bieden.
Dus zitten ze daar nu met z'n allen amd-64 te debuggen?

Ik ben benieuwd!

[edit]
Beaves, ik bedoel meer dat de linux ontwikkelaars een grote groep gratis test-engineers tot hun beschikking hebben, met een groot palet aan verschillende hardware, dus test-setups.
MS moet dat allemaal zelf doen, intern, met eigen mankracht tegen eigen kosten.
Voor de linux wereld zijn er genoeg fanaten die beta tester willen spelen, maar zoals gezegd staan bedrijven niet te popelen om daarmee tijd te verspillen.
Ik ben bang voor AMD dat ook hier de acceptatie niet zo snel zal zijn als men nu denkt, bedrijven kijken liever de kat uit de boom en kiezen voor de geijkte oplossing (intel in veel gevallen, voor 64-bit misschien andere oplossingen, sun hp oid).
En linux moet wel redelijk werken vanaf het begin, maar er zal een 'steep learning curve' zijn, omdat het open source is, en er gewoon duidelijk bijstaat dat het een alfa versie betreft. Toegegeven, pas als het stabiel (verklaard) is, zullen bedrijven ervoor kunnen gaan, maar voor die tijd zal linux met amd-64 support allang ruim voorhanden zijn op het web, dus in het publieke zicht.

Beaves, ik bedoel meer dat de linux ontwikkelaars een grote groep gratis test-engineers tot hun beschikking hebben, met een groot palet aan verschillende hardware, dus test-setups.
MS moet dat allemaal zelf doen, intern, met eigen mankracht tegen eigen kosten.

Als je niet weet hoe het bij MS toegaat, zeg dan niets. Je blaat over Linux, wat off topic is, en maakt een vergelijking die nergens op slaat. MS heeft een zeer groot testlab met meer hardware configuraties dan menige linux user. Elke nacht draaien automatic builds die de dag daarop 24/7 getest worden door een groot aantal testers, die dan bugs rapporteren die daarna gefixt worden en die fixes duiken daarna weer in een build op etc. Bij Linux is het maar afwachten OF iemand een 32proc Unisys doos overheeft om het te testen. Bij MS staat zo'n ding in het testlab. Waarom? Omdat Unisys zelf dat ding komt brengen. IBM zat ook met 120 engineers te testen aan windows2000 op IBM hardware op de MS campus.

Voor de linux wereld zijn er genoeg fanaten die beta tester willen spelen, maar zoals gezegd staan bedrijven niet te popelen om daarmee tijd te verspillen.

En terecht. de 'fanaten' zijn er wellicht wel, maar 200.000 testers met een amd athlon op 1GHz heb je niet veel aan, als je AMD64bit compiles wil testen of bv de EPIC support van GCC. (Wat Linux ermee te maken heeft met het hele verhaal begrijp ik overigens niet, je zult Open Source wel met Linux verwarren. Vaak gemaakte domme fout)

Ik ben bang voor AMD dat ook hier de acceptatie niet zo snel zal zijn als men nu denkt, bedrijven kijken liever de kat uit de boom en kiezen voor de geijkte oplossing (intel in veel gevallen, voor 64-bit misschien andere oplossingen, sun hp oid).

We praten over een COMPILER, niet over systemen of operating systems!. Een nieuwe proc met een nieuwe instructieset introduceren kost een lange tijd. Als AMD verwacht dat ze binnen 6 maanden een grote hap van de 'big-iron' servers in handen hebben, zijn ze aan het dagdromen. En ja, het gaat over de big-iron bakken: dus bakken met meer dan 4GB mem, met meer dan 2 procs. Die koop je niet elke dag.

En linux moet wel redelijk werken vanaf het begin, maar er zal een 'steep learning curve' zijn, omdat het open source is, en er gewoon duidelijk bijstaat dat het een alfa versie betreft. Toegegeven, pas als het stabiel (verklaard) is, zullen bedrijven ervoor kunnen gaan, maar voor die tijd zal linux met amd-64 support allang ruim voorhanden zijn op het web, dus in het publieke zicht.

Nou en! Ik weet niet of je meekijkt bij de Linux development, maar de verschillende processortakken lopen ALTIJD achter op de x86-32 tak. GCC support die klinkt als een klok zal zeker een tijd op zich laten wachten, x86-32 is al niet al te best (de output is niet dermate goed geoptimized). Support voor bv EPIC is ronduit belabberd (ze optimaliseren niet voor die instructieset).

Het boeit de gemiddelde gebruiker van een 64bit processor geen reet of iets in alpha stadium is of beta. Dat gebruik je nl. niet op zo'n dure bak. Daar gebruik je productiespul op wat 24/7 in de lucht blijft. Immers, daarvoor koop je een 64bit doos met veel memory en veel processoren.

Het is alleen de vraag hoe MS eventuele bugs gaat oplossen.

Gewoon, zoals ze nu ook bugs oplossen, binnen redelijke tijd.

De linuxwereld is er allang aan gewend om in de beginperiode met alfa versies te werken, zowat dagelijks nieuwe versies te downloaden etcetc.

Is dat goed dan? Linux moet ook vanaf het begin redelijk werken wil het echt gaan doorbreken. Bedrijven willen niet eerst alpha's en beta's gaan draaien, die willen meteen gaan werken.

Maar ook al wordt x86-64 nog niet volledig gesupport, de huidige software wordt ook native uitgevoerd, dus zonder enige vorm van tijdverlies. Het is zelfs zo dat de Hammer de huidge software sneller zal gaan uitvoeren dan de huidige x86 CPU's, ook zonder specifieke x86-64 support.

Dus het is geen halszaak, het supporten van x86-64, wat wel het geval is bij IA-64, want die ondersteund de huidge software niet native, en is daardoor langzamer. (Wat minder van belang is in de server wereld, maar wel voor thuisgebruik).

Precies, en daarbij komt nog dat x86-64 lang niet zo moeilijk is te implementeren als IA-64. Want het is dus zo dat de huidige software ook perfect en native door de Hammer wordt ondersteund. Dus ook al zou je geen specifiek support inbouwen, het werkt wel. Maar dan verlies je dus de extra performance die x86-64 bied.

Dus het zou dom zijn om die inverstering die ze hebben moeten doen, niet te doen en zo een potentieel grote markt buiten te sluiten, want ik denk dat x86-64 erg veel gebruikt gaat worden, door zowel de consument als in de diverse servers.

Als je dat dus niet zo ondersteunen, zou dat betekenen dat je performance zou verliezen tegen over de concurenten.

Overigens betekend dit niet dat MS ook support bied voor x86-64, alleen dat de compiler het dus begrijpt. Dat is toch een redelijk verschil.

Niet te vergeten dat Linux momenteel al 64bit
processoren support (zoals bijv. de Alpha).
De x86-64 support in Linux zou momenteel ook
al werken heb ik begrepen.

Yup, Suse heeft al een AMDx86-64 versie af.
Deze werdt ook ge-demo-ed op IDF.
Deve toegepaste technieken zijn voorgeschoteld voor implementatie in de .5 kernel

OK, dan kun je dus voor AMD64 compileren. Straks heeft een zeer kleine minderheid van de pc-gebruikers een pc die ook AMD64-instructies aankan. daar ga je dus niet je programma voor compileren, als dat betekent dat d emeerderheid van de gebruikers dan niets meer met je programma kan.
Dat gaat dus alleen gebeuren voor heel specifieke toepassingen: een op maat gemaakte toepassing voor een grote klant die alleen hammers gebruiket), en wellicht door een paar bedrijfen die het zich kunnen veroorloven om verschillende compilaties te leveren voor hetzelfde platform (windows op intel of AMd is 1 platform).
In de praktijk zal de thuisgebruiker met een hammer dus of zelf moeten programmeren en compileren, hopen op een hammer-java VM of MSIL of moeten hopen dat John Carmack ook hammer-optimalisaties in Quake 4 inbouwt. In alle andere gevallen heeft de hammer-bezitter niets aan de hammer 64-bit instructies.

OK, dan kun je dus voor AMD64 compileren. Straks heeft een zeer kleine minderheid van de pc-gebruikers een pc die ook AMD64-instructies aankan. daar ga je dus niet je programma voor compileren, als dat betekent dat d emeerderheid van de gebruikers dan niets meer met je programma kan.

Je kan wel bepaalde snelheids-kritieke onderdelen in een afzonderlijke DLL steken en deze voor verschillende systemen optimaliseren en compileren. Dan gebruik je gewoon de voor de gebruikte hardware geoptimaliseerde DLL. Zoiets doet Adobe ook al een tijdje voor MMX en multi-processor support...

Er zijn genoeg mensen die software schrijven voor specifiek 1 bepaald platform. En dan dus hun software compileren met de optimalisaties voor hun systeem. Deze software-op-maat wordt niet als product naar vele klanten gestuurd (met elk hun eigen type systeem), maar meestal is er maar 1 klant. In deze gevallen is deze extra optimalisatie in de compiler erg welkom.
Vrij veel compilers kennen deze optie hoor. Ook gcc heeft switches om bijvoorbeeld i386 code te maken of i486 of Pentium optimalisaties. Heel handig als performance nodig is.

Hoe zit het met Intel zijn instructieset? Wordt die eigenlijk compatible met AMD64/x86-64?

idd: Yamhill. Daar is maar weinig van bekend, toch?

Je doelt zeker op Yamhill...

zie http://www.tweakers.net/nieuws/20829?highlight=Yamhill

Geezzz... roep 'Microsoft' en een groepje nitwitts komt weer met 'linux' aanzetten. Dit gaat over de VC++ compiler. Niet over Linux.

Dat MS AMD's 64bit instructies gaat ondersteunen lijkt me niet meer dan logisch. in de VC++ compiler van Visual Studio.NET zit al 64bit support, een extra emitter erbij lijkt me niet zo'n probleem. MS heeft al 64bit support in de compiler voor EPIC.

Komen we meteen op het punt dat maar weinig mensen hier uberhaupt weten hoe een compiler werkt of hoe je dit soort software bouwt. Als je dat niet snapt, zeg dan niets.

Natuurlijk wordt Linux er bij gehaald, dat is je vergelijkings materiaal, wat wil je anders?
verder wordt hier niets negatiefs aan de orde gebracht en zie ik niet in waar je "heftige" reactie vandaan komt

MS heeft al 64bit support in de compiler voor EPIC

64bit support zegt opzich ook nog niets m.b.t AI-64 en x86-64, 64bit support voor wat???

Dit lijkt ook logisch dat MS dit in zijn compiler wil hebben zitten als je ziet dat AMD zijn 64bit volgend jaar al in mainstream wil maken. AMD begint serieus markt te winnen dus lijkt mij dit gewoon een veiligstelling van MS.

kunnen we eindelijk een stappie beter vergelijken. zie maar de volgende berichten. http://www.tweakers.net/nieuws/20848

nu de hammer strax de nieuwe vliw proc van intel/h (ben ff de naam vergete).

appels met appels vergelijken zal heus niet gebeuren. de intel code-generator is zo uitgekauwd dat ie vast betur zal optimaliseren.