Hallo liebes Froum, ich meine hier gelesen zu haben, dass es mit dem MSPGCC nicht möglich ist uint64_t zu verwenden. Meine Frage ist nun, ob sich da inzwischen was neues ergeben hat? Falls es eine neuere Version geben sollte, die mit 64Bit-Variablen klarkommt ... gibt es einen Weg diese aktuellere Compilerversion in das Code Composer Studio zu integrieren? Gruß Teetrinker
Hat denn der Compiler kein Manual [1], aus dem man solche Informationen herausziehen könnte? Gruß Skriptkiddy [1] http://mspgcc.sourceforge.net/manual/ (würde da mal bei "data types" nachschauen)
Der CCE kann keine 64 Bit Variablen, der GCC schon und IAR meines Wissens auch.
Teetrinker schrieb: > ich meine hier gelesen zu haben, dass es mit dem MSPGCC nicht möglich > ist uint64_t zu verwenden. Sogar der AVR-GCC (8Bit-CPU)) kann es, also sollte der MSP (16Bit-CPU) es doch erst recht können. Allerdings ist es auf dem AVR extrem aufwendig programmiert und damit sogar größer und langsamer als float. Peter
Peter Dannegger schrieb: > Sogar der AVR-GCC (8Bit-CPU)) kann es, also sollte der MSP (16Bit-CPU) > es doch erst recht können. Der maschinenspezifische Teil von GCC definiert die Grösse der Datentypen und dessen Entwickler trifft die Entscheidung, ob er sich die Mühe mit 64-bit Typen macht oder nicht. Denn von allein gibts die nicht, die Codeerzeugung für die betreffenden Operationen muss dort manuell eingebaut werden. > Allerdings ist es auf dem AVR extrem aufwendig programmiert und damit > sogar größer und langsamer als float. Der inline erzeugte Code ist deshalb ineffizent, weil der Entwickler sich bei diesen Operationen weit weniger Mühe gegeben hat als bei den viel wichtigeren 8/16-Bit Operationen. D.h. der Compiler beschränkt sich hauptsächlich auf generische Operationen für beliebige Operanden, berücksichtigt besondere Fälle wie Shifts mit Konstanten eher wenig.
A. K. schrieb: > Der inline erzeugte Code ist deshalb ineffizent, weil der Entwickler > sich bei diesen Operationen weit weniger Mühe gegeben hat als bei den > viel wichtigeren 8/16-Bit Operationen. Soweit ich das verstanden habe, ist das noch komplizierter: Der AVR-GCC kennt nur max 4 Register je Operand und daher kann man 64Bit (= 8 Register) nicht in Assembler implementieren. Daher wurde 64Bit komplett in C geschrieben mit indirekter Adressierung (8 Byte-Array) und das kostet extrem. Ansonsten wäre 64Bit ein Klacks, selbst wenn man es nicht optimiert. Einfach 8 * hinschreiben "ADC Rn, Rm" kann man nicht weiter optimieren. Peter
Peter Dannegger schrieb: > Sogar der AVR-GCC (8Bit-CPU)) kann es, also sollte der MSP (16Bit-CPU) > es doch erst recht können. Klar kann der mspgcc das schon immer. Lediglich der TI Compiler im CCE kann keine 64 Bit Variablen.
Peter Dannegger schrieb: > Soweit ich das verstanden habe, ist das noch komplizierter: Yep, stimmt. Bei ARM&Co sind die Operatoren für DI Typen im MD-File, bei AVR nicht. Offenbar greift da ein generischer Codegenerator. Sieht zugegebenermassen grässlich aus.
A. K. schrieb: > Peter Dannegger schrieb: > >> Sogar der AVR-GCC (8Bit-CPU)) kann es, also sollte der MSP (16Bit-CPU) >> es doch erst recht können. > > Der maschinenspezifische Teil von GCC definiert die Grösse der > Datentypen und dessen Entwickler trifft die Entscheidung, ob er sich die > Mühe mit 64-bit Typen macht oder nicht. Denn von allein gibts die nicht, > die Codeerzeugung für die betreffenden Operationen muss dort manuell > eingebaut werden. Nein, alles was man machen muss, ist word_mode (8 Bit für avr) und kleinere zu unterstützen. Alles, was darüber hinausgeht, ist bereis "offen" in GCC codiert. Will man besseren Code, muss man das Backend aufpolieren -- in avr-gcc ist das gemacht für float, short und long. Aber das ist reiner Luxus; notwendig für einen funktionierenden Compiler ist es nicht. >> Allerdings ist es auf dem AVR extrem aufwendig programmiert und damit >> sogar größer und langsamer als float. > > Der inline erzeugte Code ist deshalb ineffizent, weil der Entwickler > sich bei diesen Operationen weit weniger Mühe gegeben hat als bei den > viel wichtigeren 8/16-Bit Operationen. D.h. der Compiler beschränkt sich > hauptsächlich auf generische Operationen für beliebige Operanden, > berücksichtigt besondere Fälle wie Shifts mit Konstanten eher wenig. Aufwändig wird es, weil im AVR-Teil nichts gemacht ist. Eine Addition wird also in 8-Bit Stückchen zerbröselt mit soft-codiertem Carry. Nicht die Einzel-Additionen sind aufwändig, sondern das Carry-Geraffel. Peter Dannegger schrieb: > A. K. schrieb: >> Der inline erzeugte Code ist deshalb ineffizent, weil der Entwickler >> sich bei diesen Operationen weit weniger Mühe gegeben hat als bei den >> viel wichtigeren 8/16-Bit Operationen. > > [...] > > Ansonsten wäre 64Bit ein Klacks, selbst wenn man es nicht optimiert. > Einfach 8 * hinschreiben "ADC Rn, Rm" kann man nicht weiter optimieren. Das Problem ist nicht die Arithmetik. Das Problem ist a=b, also einen 64-Bit-Wert von a nach b zu bringen. Das ginge sogar in avr-gcc ohne die binutils zu erweitern. Allerdings ist das so aufwändig, daß es bisher niemand gemacht hat, und die AVR-Maintainer eine Unterstützung nicht machen möchten bzw. nicht für sinnvoll halten. Seh ich übrigens auch so. Ich kann mir auch nicht annähernd vorstellen, daß sich jemand freiwillig diesen Wolf macht. Oder ihr geht hier mit dem Klingelbeitel rum, um Geld für die 1-2 Mannmonate zu sammeln, die ein erfahrener GCC-Entwickler mit entsprechender Expertise so kostet... ;-)
Hallo, vielen Dank für die vielen und interressanten Beiträge! Es gibt also bisher drei Möglichkeiten, wenn man als CCE-User mit 64Bit Variablen arbeiten möchte: 1)Umsteigen auf IAR 2)Umsteigen auf Eclipse + MSPGCC 3)Man(n) frickelt sich das selber hin ... Im Fall des Kollegen, wegen dem ich hier frage, geht es um eine oder zwei Multiplikationen, deren Ergebnis dann 64Bit groß wird ... vielleicht ist Lösung 3 die praktikabelste für uns? Liebe Grüße Teetrinker
Teetrinker schrieb: > 2)Umsteigen auf Eclipse + MSPGCC Wenn -- wie du oben schreibst -- der msp-gcc keine 64-Bit Variablen unterstützt, dann bringt's auch nix, das Ding unter Eclipse anzusprechen. Auch ist nicht klar, was mit "MSPGCC kommt nicht klar mit..." gemeint ist. * Macht er falschen Code? * Gibt es einen Fehler? * Ist der falsche Standard gewählt? uint64_t ist C99. * Fehlt einfach nur ein
1 | #include <stdint.h> |
?
Johann L. schrieb: > Wenn -- wie du oben schreibst -- der msp-gcc keine 64-Bit Variablen > unterstützt, dann bringt's auch nix, das Ding unter Eclipse > anzusprechen. Wir hatten ja schon ausfürlich dargelegt, dass der mspgcc selbstverständlich uint64_t kann. ich hab da auch schon eine Menge mit programmiert, das klappt. Allerdings ist der Umstieg besonders für nicht so hart gesottene eine Qual, denn der GDB Debugger ist kaum brauchbar, und kann im Vergleich zu allen anderen MP430 Debuggern so gut wie gar nichts. Da hilft auch Eclipse wenig. Nicht mal so primitive Sachen wie "Step Over" oder "Restart" sind implementiert. Da kann man vielleicht eher bei CEE bleiben, und versuchen, so große Multiplikationen zu vermeiden. Oder halt richtig Kohle für Crossworks oder IAR ausgeben....
Oder fehlerfreie Programme schreiben. wegduck > Michelangelo reportedly said that he could see a statue in a > block of marble, and that his goal as a sculptor was to carve > away everything which wasn't part of the statue. > Some programmers appear to similarly believe that programming > means starting with a block of code, and carving away everything > which isn't part of the program. This is also known as > programming by debugging. It's a bad idea. Don't do it.
Moin, >Johann L. schrieb: > Auch ist nicht klar, was mit "MSPGCC kommt nicht klar mit..." gemeint > ist. Stimmt :) In der stdint.h die bei CCE mitkommt steht, dass es keine 64Bit Unterstützung gibt .... 32Bit funktioniert ... > * Macht er falschen Code? > * Gibt es einen Fehler? Trotz #include <stdint.h> kommt der Compilerfehler: uint64_t unknown usw. bei longlong ebenso. > * Ist der falsche Standard gewählt? uint64_t ist C99. Kann sein, ein guter Ansatzpunkt zum suchen, hab noch keine Ahnung, wo man das einstellen kann ... >> Michelangelo reportedly said that he could see a statue in a >> block of marble, and that his goal as a sculptor was to carve >> away everything which wasn't part of the statue. >> Some programmers appear to similarly believe that programming >> means starting with a block of code, and carving away everything >> which isn't part of the program. This is also known as >> programming by debugging. It's a bad idea. Don't do it. Dear Mr.Michelangelo, Have you any pieces of marbre, handling 64Bit datatypes like uint64_t or longlong in the language C for the MSP430GCC-Compiler included in the software from Texas Instruments? Yours Strg+V. Guttenberg
Christian R. schrieb: > Oder halt richtig Kohle für Crossworks oder IAR ausgeben.... Naja, Crossworks ist für private Nutzung schon ein paar Größenordnungen günstiger als IAR, knapp 110 EUR ist was anderes als ein paar tausend: http://sites.fastspring.com/rowley/product/crossworksformsp430 (Davon abgesehen bietet Crossworks die reizvolle Möglichkeit, auch unter anderen Betriebssystemen als Windows nutzbar zu sein)
Teetrinker schrieb: > the MSP430GCC-Compiler included in the > software from Texas Instruments? Du hast offenbar was grundlegendes nicht verstanden. Der mspgcc ist nicht der Compiler, der in CCE integriert ist. Der CCE Compiler ist ein eigener von TI, der hat mit dem GCC rein gar nichts zu tun. Auch kann man den nicht in den CCE direkt integrieren. Also in das Eclipse da schon, aber dann hast du auch nicht mehr davon, als wenn du den in ein Standard-Eclipse integrierst. Den TI-Debugger und die Projekt-Wizzards kannst du nicht für den mspgcc nutzen.
Hallo, danke für die vielen und guten Infos !!! Mal schauen wie es jetzt weitergeht ... Gruß Teetrinker
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.