Intel start verkoop 64 bit-ontwikkelsoftware

Intel heeft de verkoop gestart van zijn programmeertools voor het ontwikkelen van 64bit-software, aldus C|Net. Maandag zal de nieuwe compiler voorgesteld worden waarmee code voor zowel Intel- als AMD-chips gecreëerd kan worden. De compiler zal ondersteund worden door zowel Linux als Windows en onder andere gebruikt worden door IBM en Oracle, die hun databasesoftware met deze compiler bouwen. Ook Red Flag Linux en MySQL maken gebruik van Intels software voor het compileren voor 64bit-platformen.

De C- en C++-compiler kost 399 dollar, voor een Fortran-versie betaalt men een bedrag tussen de 499 en de 1399 dollar. Hoewel Sun zich de laatste tijd sterk inspant om 64bit-ondersteuning te leveren met zijn Solaris-OS zal dit besturingssysteem volgens Intel niet ondersteund worden omdat de vraag hiernaar niet groot genoeg zou zijn.

Reacties (29)

[opagrover]

[met het risico op offtopic]
Moet je eigenlijk nog aanpassingen doen aan jouw code als je een applicatie die ontwikkeld is voor 32-bit, naar 64-bit wil omzetten? Of hoef je alleen maar alles door de nieuwe 64-bit compiler te halen, en je hebt een 64-bit programma?

[JeroenB]

Je moet opletten voor subtiele fouten. In sommige programmeertalen is bijv. het datatype "integer" gedefinieerd als 16-, 32- of 64-bits, maar andere omgevingen kunnen de grootte van een datatype laten afhangen van bijv. de maximale registergrootte van de onderliggende architectuur. Als je zo'n omgeving gebruikt en je leunt erop dat een integer 32-bits is, dan kun je bugs introduceren in je code door het te compileren voor een platform met een andere breedte.

[Verwijderd]

een nieuwe compiler is alles wat je nodig hebt in principe. als je een dergelijke vraag stelt ga ik er tenminste van uit dat je geen asm code gebruikt om je zaakjes te optimizen, dus jij hoeft je hier niet echt druk om te maken, maar inderdaad, zoals JeroenB al zegt, let even op hoe je compiler omgaat met integer en floating point datatypen.

[dancingdoorman]

Waarschijnlijk gaat het goed want de meeste ranzige hacks zijn er meestal met de switch van 16 naar 32 wel uitgehaalt.
Beruchte voorbeelden daarvan waaren de problemen met LPARAM en fantatisch slimme hacks om het most signifacant bit van een pointer als flag te gebruiken.
Het bovenste stuk geheugen was bij 16 bit toch voor driver gereserveerd, maar in 32 bit was dat natuurlijk veranderd.

[sn0x0r]

Hmz, nu het over compilers gaat, vraag ik me af hoe dat nou eigenlijk zit met compilers van Borland. Zal bijv. de compiler zelf ook 64-bit geoptimaliseerd zijn, en kan ik met een nieuwe versie dan binnenkort ook 64-bit apps schrijven? Want mijn huidige Delphi 7 kan volgens mij alleen Win32 apps maken.

En zou het ook nog uitmaken of het compilen op een 32-bit proc. is gebeurt of moet dit perse op een 64-bit proc gebeuren. (wat mij niet lijkt, want dit kan in het programma zelf verwerkt worden) En het liefste zou ik natuurlijk een combinatie hebben. In mijn programma ondersteuning voor 32-bit,maar ook voor 64 bit.

[JeroenB]

Een compiler levert gewoon een of meerdere bestand(en) als output, dus je kunt best een compiler maken die andere output heeft als het platform waar hij op draait. Sterker nog, ik compileer dagelijks ARM binaries op x86 De breedte van de doelprocessor staat daar eveneens los van.

[dancingdoorman]

Wel zo prettig dat cross-compilen want je x86 in je desktop is waarschijnlijk behoorlijk sneler als een ARM proc in een palmtop.

[BoomSmurf]

Jammer maar helaas! Zoals het er nu voorstaat gaat Borland geen native 64-bit compiler uitbrengen. Voor 64-bit zul je de .NET versies van de Borland compilers moeten gebruiken

[Verwijderd]

Wel is het zo dat je met CBuilder X de Intel 64 bits compiter als backend kan gebuiken.
Delphi is natuurlijk een ander verhaal. Zonder aparte 64 bits Pascal compiler zul je echt .Net moeten gebruiken. Voor windows is dit niet zo'n probleem en Delphi programma's werken eigenlijk ook alleen maar op windows (ben nog maar hééél weinig kylix programma's tegen gekomen)

[Niles]

Het is al lang bekend dat Intel een 64bit Xeon heeft uitgebracht, dus ook Intel heeft ondertussen al een 64bitter. Het enige voordeel van 64bit is dat je er meer geheugen mee kunt adresseren. 128bits of hoger betekend alleen maar dat je nog meer geheugen kunt adresseren wat totaal niet nodig is. In feite kan 32bits tot 4gig aan geheugen adresseren, wat eigenlijk zogoed als niemand heeft. Met 64bit kun je nu (dacht ik (ergens gelezen dat windows longhorn het ondersteund) tot 16 Terrabyte aan geheugen adresseren, wat volkomen nutteloos is, en voorlopig ook nog LANG niet nodig. Vandaar niet hoger dan 64bits

Edit: dit was bedoelt op WSaeNoTSoCK's reactie
Edit2: voordat elke mierenneuker begint: er zijn natuurlijk nog wel enkele andere kleine voordelen met 64bits ten opzichte van 32bits behalve alleen meer geheugen adressering.

[Verwijderd]

Toch even mierenneuken.

Het is via wat trucjes wel mogelijk meer dan 4gig te gebruiken met 32 bits zeon processoren

[Jeroen V]

Das niet helemaal waar. Met een 64 bits processor kan je direct 64 bits getallen bewerken, met een 32 bits processor zal je dat in meerdere stappen moeten doen wat een behoorlijk stuk trager is.

En denk nou niet dat 32 bits getallen groot genoeg zijn, er zijn genoeg toepassingen te bedenken waarbij dat niet zo is. (en die kunnen op een behoorlijke snelheidsverbetering rekenen als de compilers en de processoren dat direct kunnen)

[Bulls]

betekend dit dat intel ook 64 bits procesors gaan maken? waarom niet gelijk 128/256/512 of 1024

[JSK]

Maandag zal de nieuwe compiler voorgesteld worden waarmee code voor zowel Intel- als AMD-chips gecreëerd kan worden

Erg opmerkelijk dat Intel komt met een compiler die ook AMD chips ondersteund. Zal wel te maken hebben met het feit dat hun EMT64 instructies bijna identiek zijn met de AMD x86_64 extensies. Toch kan ik me niet voorstellen dat ze veel tijd hebben gestoken in het optimaliseren van code voor AMD chips, dat zou wel erg tegenstrijdig zijn.

[player-x]

denk niet dat progameurs van de intel compiler gebruik gaan maaken als amd niet word ondersteund

hier heb je een mooi programa doet dit en dit en dit heel snel cool he
(OOooo btw werkt niet op amd)

[n4m3l355]

amd en intels instructies komen op 7 stuks precies overeen die 7 verschillen blijkbaar lichtjes en intel heeft nog een 8ste unieke instructie. het zou mij niet verbazen als MS hier een grote vinger in de soep had toen deze beslissing gemaakt werd en dat daardoor de instructies zo overeen komen

[the_stickie]

ik dnek niet dat MS daar echt iets mee te maken heeft.
Ik denk dat het eerder ligt aan wat men noemt "marktrisico"; als intel een volledig andere instructieset op de markt zet nà AMD, is de kans bestaande dat die niet meer aanslaat (er zijn immers al AMD 64 processors verkocht).
Dat zu betekenen dat alle investeringen in dei instructieset voor niets (of voor heel weinig) geweest zijn.
Daar komt bij dat Intel gewoon het recht had ze te kopiëren... zo beperken ze dus hun marktrisico én hun R&D. Dat lijkt me dus een logische keuze

[veltnet]

De bovenstaande tekst geeft aan de auteur het principe van Open-Source niet begrijpt.

Citaat van http://www.gnu.org/philosophy/free-sw.html :

``Free software'' is a matter of liberty, not price. To understand the concept, you should think of ``free'' as in ``free speech,'' not as in ``free beer.''

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.


De bakker en de boer kunnen zonder probleem hun brood en melk aan de consument verkopen. Zolang ze het recept (sourcecode) erbij leveren kunnen ze geld verdienen zonder de GNU filosofie onrecht aan te doen.

[Verwijderd]

De bakker en de boer kunnen zonder probleem hun brood en melk aan de consument verkopen. Zolang ze het recept (sourcecode) erbij leveren kunnen ze geld verdienen zonder de GNU filosofie onrecht aan te doen.

Op zich waar voor open source in het algemeen maar dit gaan niet op voor GPL software en dus de GNU filosofie.
Bij GPL (GNU public License) mag de bakker geen brood verkopen (programma) aangezien hij om het brood te maken het recept (sourcecode) heeft gebruikt. Volgens de GPL zou hij het brood weg moeten geven. Hij mag wel geld vragen voor het plastic zakje waar het inzit maar dus niet voor het brood zelf! Dit geld dus ook voor linux distributies. Je betaald voor de CD, verpakking en de paar commerciele programma's maar (in theorie) niet voor Linux zelf.

Een belangrijke vrijheid wordt dus bij de GPL weggenomen. De vrijheid van de programmeur (of de bakker) om te doen en te laten met zijn product wat hij wil. Andere Open Source licenses geven de ontwikkelaar dat recht dus wel. Dit verschil lijkt klein maar is natuurlijk vrij groot. Bij de GPL heeft de klant van de bakker het recht alles wat de bakker maakt zomaar mee te nemen. Bij de Apache license heeft de bakker het recht om geld te vragen voor zijn werk en zijn aanpassingen aan het recept geheim te houden. Dus programma's die onder dat soort licenties verspreid worden hebben meer vrijheden dan GPL programma's

*The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). DUS MET OF ZONDER SOURCECODE.
* De mogelijkheid om een inkomen te generen uit jou werkzaamheden

De keuze is wiens vrijheid belangrijker is: De vrijheid van de gebruiker die OSS toch vaak als "free beer" ziet, of de vrijheid van de programmeur die kan bepalen of hij zijn werk weg wil geven voor het grotere goed of zijn kennis ten gelde wil maken zodat hij meer kan programmeren en nog betere programma's kan maken.

De verschillende OSS licenties laten beide keuzes toe.

[T-MOB]

Als de bakker brood zou verkopen onder de GPL hoeft hij helemaal niets gratis weg te geven. Hij geeft gewoon (tegen drukkerskosten uiteraard ) het recept aan zijn klanten. Waar andere OS licenties degene die het recept meeneemt alle vrijheid geven om ermee te doen en laten wat ie wel legt de GPL 1 beperking op:

Namelijk dat als jij ook brood wil verkopen dat op basis van dit recept of een afgeleide daarvan, dat je de dan verplicht bent om ook het recept erbij te leveren. Met dezelfde verplichting voor derden die dit recept weer gebruiken...

[erkje]

Ja, dan staat er bij de boer in de tuin en bij de bakker in de etalage: Donate via PayPall
Om toch wat te verdienen.

---

Veel kleine(re) open source projecten worden in de vrije tijd ontwikkeld. Dat kun je van de boer en de bakker niet zeggen. Of ze moeten 's avonds naast hun werk nog bijspijkeren als hobby

[Verwijderd]

Wie werkt er nu gratis.... Dan ben je toch gek? In de echte wereld werk je toch ook niet gratis?

Daar is maar een antwoord op: welcome to the real world. In de echte wereld wordt er een heleboel gratis gedaan waar anderen weer aan verdienen. Neem bijvoorbeeld sport. Vrijwel al het verenigingswerk is op vrijwillige basis. De service-verleners (horeca, onderhoud) en hardware leveranciers (vastgoed, sportmaterialen) verdienen hier goed aan.

[Fridge-RaideR]

@JSK

uit de source van dit bericht, trek je eige conclusies maar

The compilers create code for either Intel or AMD chips, said James Reinders, director of marketing for Intel software development products. "Our customers are interested in producing code that runs well on their customers' machines. Some percentage of that is going to be non-Intel," he said. "Our code works at least as well as any other compiler for AMD's processors."

edit:

wat ik denk bedoelen ze eigenlijk, hij zal nie brak zijn en kan concureren, maar denk maar nie dat we hem geoptimaliseerd hebben

[Verwijderd]

hehe volgens mij ga ik weinig aan 64bit hebben met die Atmel ATmega Embedded IC's programmeren

[Kaw]

[ubernerd]Cool! Kan ik mijn schaakprogramma compilen met 64-bit ondersteuning! Het gebruik van bitboards wordt dan een stuk sneller... }:O[/ubernerd]

Off vergis ik me nu in het doel van de compiler?

[Verwijderd]

Voor het gebruik van 64 bits programma's heb je natuurlijk wel de bijbehorende cpu en OS nodig.
Daarnaast is het maar de vraag of een schaakprogramma hier echt sneller van wordt.

Maar op zich klopt het wel. 64-bits programma's kunnen sneller zijn mits alle vereiste onderdelen beschikbaar zijn.

[bbr]

Hoe zit het met Metrowerks Codewarrior?

[Verwijderd]

Volgens mij was het al mogelijk om in een Cygwin omgeving in windows een GGC te laten draaien die geoptimaliseerde bins produceert . Natuurlijk was het eerste dattie deed een bootstrap om cygwin en gcc 64bit te krijgen ^^