Programmieren für 64 Bit



  • Wie erstellt man eigentlich 64 Bit (c++)Programme bzw welche Compiler können das schon?
    Wird wohl auf jeden Programmierer in näherer Zukunft zukommen, aber trotzdem kenne ich keinen der sich damit schon ernsthaft beschäftigt hat.

    Und wie sieht das mit Java/.net aus, läuft mit einer 64 bit runtime da jedes Programm automatisch auf 64 Bit?



  • Als C++ Programmierer wird man das praktisch nicht bemerken bzw. selten damit in Berührung kommen. Was ist denn hauptsächlich 64bit? Genau, der Adressraum. D.h. die Pointer werden von 32bit auf 64bit größer.

    Eigentlich muß man nur einen Schalter im Compiler umlegen. Im VC++ Compiler ist dies zumindest so, und er produziert halt beim Kompilieren entsprechenden Code.

    Achja, was noch größer wird, werden die primitiven Datentypen, wie int oder long. Aber das ist auch von Compiler zu Compiler unterschiedlich. Beim VC++ ist einfach nur ein __int64 dazu gekommen. Alles andere bleibt (sowei ich weiß) gleich.

    Bemerken wird man also praktisch nichts. Und das ist auch gut so, da dies der Sinn von Hilevel-Sprachen sein sollte. Klar, in C++ kann ich auch etwas Lolevel coden, ist aber wohl eher bei Embeddedprogrammierung oder Treibern der Fall.



  • C++: Viele Compiler machen longs und size_t doppelt so lang, sizeof(pointer) ändert sich auch, das Alignment infolgedessen ebenfalls, damit auch wieder sizeof(any class). Wie Artchi bereits erwähnt hat, ist sehr entscheidend, wie lowlevel man programmiert. Aber Änderung der Größe von long kann und ein paar andere Dinge können fast jeden betreffen. Ich kenne auch nur wenige C++ Programmierer, die konsequent size_t benutzen, wo es angebracht ist, statt int oder unsigned int.

    Ich will auch gar nicht den Teufel an die Wand malen, aber man muss sich solcher Dinge schon bewusst sein. Jeder Compiler-Hersteller dokumentiert i.d.R. ordentlich, was sich ändert, wenn man für 64 Bit Plattformen compiliert.

    Und wie sieht das mit Java/.net aus, läuft mit einer 64 bit runtime da jedes Programm automatisch auf 64 Bit?

    Bei Java auf jeden Fall. Reines Java ist so high-level und erlaubt so wenig low-level Aktivitäten, dass du von Änderungen beispielsweise des Alignments nichts mitbekommst. Auch haben die Standardtypen bei Java feste Größen, so dass der Wertebereich gleich bleibt. Bei .Net hängt es von der verwendeten Programmiersprache ab. Wenn man C# oder VB verwendet und damit recht high-level bleibt, gilt das selbe wie für Java. Neu compilieren musst du dort allerdings immer, da der MS-Compiler den IL code in eine gewöhnliche PE exe packt, die nicht portabel ist (obwohl sie so heißt 😉 ).



  • Hier umfangreiche Informationen direkt von MS:
    http://msdn.microsoft.com/visualc/using/building/64bit/default.aspx



  • Optimizer schrieb:

    C++: Viele Compiler machen longs und size_t doppelt so lang,

    Ich dachte immer das size_t auf allen Systemen, Sprachen und Compilern immer gleich groß ist? 😕 Oder hab ich da jetzt was falsch verstanden?



  • Chris++ schrieb:

    Optimizer schrieb:

    C++: Viele Compiler machen longs und size_t doppelt so lang,

    Ich dachte immer das size_t auf allen Systemen, Sprachen und Compilern immer gleich groß ist? 😕 Oder hab ich da jetzt was falsch verstanden?

    Ja, du hast was falsch verstanden. Das muss überhaupt nicht gleich sein.



  • Nö, size_t repräsentiert die größte mögliche Größe auf einem Compiler. In C++ Standard gibt es keine Vorgaben, wie groß Typen sein sollen. Es gibt nur die Vorgabe:

    bool <= char <= int <= long <= size_t

    So in etwa... 🙄



  • Artchi schrieb:

    Nö, size_t repräsentiert die größte mögliche Größe auf einem Compiler. In C++ Standard gibt es keine Vorgaben, wie groß Typen sein sollen. Es gibt nur die Vorgabe:

    bool <= char <= int <= long <= size_t

    So in etwa... 🙄

    Achso...



  • Artchi schrieb:

    Nö, size_t repräsentiert die größte mögliche Größe auf einem Compiler. In C++ Standard gibt es keine Vorgaben, wie groß Typen sein sollen. Es gibt nur die Vorgabe:

    bool <= char <= int <= long <= size_t

    So in etwa... 🙄

    Ich würde eher sagen, dass es

    char <= bool <= ...

    ist.



  • Und char ist als 1byte Variable definiert.



  • mich würde ma interresieren wieso bei bool nicht auch 1 byte reicht. char braucht das für 256 buchstaben und klar, bool braucht 0 und alles was größer und kleiner ist, aber wäre es nicht auch mit weniger speicher zu bewerkstelligen?



  • Und bei MS compilern bleint int und long immer gleich gross, egal ob für x86 oder x64/IA64 compiliert wird.

    Und .NET 2.0 programme laufen unverändert auf x86/x64/IA64. Weder der Programmierer noch der Anwender bekommt davon was mit. Du musst auch hier keine zwei (bzw. drei) EXEn erstellen (was Du bei C++ machen musst).

    Du solltest aber beachten, das MS bei x64/IA64 nicht mehr alles so unterstützt wie bei x86 (z.B: keine Treiber mehr für Access-Datenbanken).
    Siehe:
    http://blog.kalmbachnet.de/?postid=61

    PS: Gehört eigentlich in Compiler-Forum...



  • TravisG schrieb:

    mich würde ma interresieren wieso bei bool nicht auch 1 byte reicht. char braucht das für 256 buchstaben und klar, bool braucht 0 und alles was größer und kleiner ist, aber wäre es nicht auch mit weniger speicher zu bewerkstelligen?

    also bei mir ist ein bool auch genau 1 Byte gross. es gilt ja char <= bool (kleiner GLEICH). Das liegt ganz einfach daran dass man eben festgelegt hat, dass char die Einheitsgroesse ist.

    Wenn du aber gemeint hast, warum ein bool nicht nur 1 Bit reicht: stimmt schon, theoretisch wuerd das reichen. Aber keine moderne CPU wuerd das unterstuetzen. Wenn ein bool nur 1 Bit gross waer, muesst die CPU immer gleich ein ganzes Byte aus dem Speicher laden um darauf zuzugreifen. Die kann gar nicht anders.
    Stell dir das nur mal vor, wenn eine CPU auf jedes einzelne Bit im Speicher einzeln zugreifen koennte. Dann muessten Speicheradressen gleich um ein Vielfaches laenger sein, und dass wuerd die CPU wieder ausbremsen.



  • Gast1089 schrieb:

    Und char ist als 1byte Variable definiert.

    naja, es gibt so komische prozessoren von texas instruments, da sind chars 32 bit breit weil alle maschinenbefehle mit 32 bit operanden hantieren. ..aber der begriff 'byte' bedeutet ja nicht zwangsläufig 8 bits (hab ich hier im forum gelernt 👍 )



  • Blue-Tiger schrieb:

    TravisG schrieb:

    mich würde ma interresieren wieso bei bool nicht auch 1 byte reicht. char braucht das für 256 buchstaben und klar, bool braucht 0 und alles was größer und kleiner ist, aber wäre es nicht auch mit weniger speicher zu bewerkstelligen?

    also bei mir ist ein bool auch genau 1 Byte gross. es gilt ja char <= bool (kleiner GLEICH). Das liegt ganz einfach daran dass man eben festgelegt hat, dass char die Einheitsgroesse ist.

    Wenn du aber gemeint hast, warum ein bool nicht nur 1 Bit reicht: stimmt schon, theoretisch wuerd das reichen. Aber keine moderne CPU wuerd das unterstuetzen. Wenn ein bool nur 1 Bit gross waer, muesst die CPU immer gleich ein ganzes Byte aus dem Speicher laden um darauf zuzugreifen. Die kann gar nicht anders.
    Stell dir das nur mal vor, wenn eine CPU auf jedes einzelne Bit im Speicher einzeln zugreifen koennte. Dann muessten Speicheradressen gleich um ein Vielfaches laenger sein, und dass wuerd die CPU wieder ausbremsen.

    nein ich meine ein byte. ich dachte bool wär größer als ein byte. naja hat sich erledigt



  • Die einzigen Vorteile die man dadurch hat ist doch schneller mit ints die über die 32 Bit Grenze hinaus gehen rechnen zu können(wenn es denn mal sowas im Anwendungsbereich gibt) und genauere Fließkommazahlen zu haben oder?
    Ich frage mich grad wie die ihre "bis zu 30% schneller" Spiele rechtfertigen hier:
    http://amd64downloads.filecloud.com/dreadnought.asp

    Ich sehe nicht so richtig, warum bestehender Code schneller wird, nur weil die Fließkommazahlen genauer werden(die haben vorher ja auch ausgereicht) oder man mit größeren Zahlen rechnen kann.
    Programmiert man sowas sonst mit selbstgebastelten genaueren Fließkommazahlen oder wie?

    Hab auch mal gelesen, dass das dem mmx/3dnow Kram ganz gut bekommen soll, liegt das daran oder eher ein reiner Marketinggag?



  • TravisG schrieb:

    ich dachte bool wär größer als ein byte. naja hat sich erledigt

    Ist es teilweise auch. Ich kenne Compiler für normale 32-Bit Intel-CPUs, die 32Bit große bools erstellen.



  • Bei 32 bit Integern und einer 64 bit CPU könnte man gleichzeitig auf 2 Integer operieren.
    Wenn man zB eine Addition hat von 4 Werten würde eine 32bit CPU 2 Taktzyklen benötigen:
    1. a + b = x
    2. c + d = y
    Aber eine 64bit nur ein Zyklus.
    1. ac + bd = xy

    naja so in etwa, kenn mich mit maschinennaher Programmierung nicht aus.



  • dreaddy schrieb:

    Ich frage mich grad wie die ihre "bis zu 30% schneller" Spiele rechtfertigen

    ich kenn mich da nicht aus, kann mir aber vorstellen, dass ne 64bit cpu mit nem 8 byte double besser umgehn kann, als ne 32bit cpu..

    und nein, ich glaube kaum, dass man bei spielen selbstgebastelte zahlenklassen verwendet. allerdings passen eben "in einem durchgang mehr bits in die cpu".

    ist eigentlich interresant, ich glaub, das probier ich mal mit meinem amd64 aus..



  • Ist doch recht einfach zu verstehen, wie das kommt. Für 64 Bit Werte sind diese Prozessoren sowieso schneller. Für 32 Bit Werte steht die doppelte Anzahl an Registern zur Verfügung. 😃


Anmelden zum Antworten