avr-gcc version 4.1.0 bringt ja bei Zuweisungen wie z.B. int x =
0b01010101; unter Linux einen Fehler: "error: invalid suffix "b10010" on integer constant". Dies liegt wohl daran, dass der C-Standard nix von dem "0b" Suffix sagt und daher unter Linux auch nicht unterstütz wird. Mit WinAVR klappt das ja. Hatte auch mal einen Link zu einem Compiler-Patch, welchen ich jetzt aber nicht mehr finde.
Jetzt die Frage an die avr-gcc Benutzer mit Linux: Was macht ihr? Compiler patchen, alles hexadezimal "0x" umschreiben, oder bitweise verodern: "= 1
Ich habe mir in grauer Vorzeit mal ein int a2i(char*) geschrieben, das zumindest den Benutzern _meiner_ Programme die Freiheit gibt,
0bxxx zu benutzen. Wenn die ANSI oder die gcc-Truppe irgendwann mal aufwacht, werde ich das begrüßen. Bits sind nun mal ein wichtiger grundlegender Datentyp und wenn die nicht vernünftig unterstützt werden, erregt das Unwillen.
Wenn Du das ernsthaft unters Volk bringst, kannst Du gleich ein FAQ dazu schreiben, warum B01010101 nicht funktioniert. Der erste DAU wird sich noch am gleichen Tag beschweren.
Die gcc-Leute sind - ganz entgegen der Implikation deiner Äußerung - nicht nur am pennen. Im Gegenteil: das sind sehr hilfsbereite, nette Leute, die ein großartiges Stück Software geschaffen haben.
Äußerungen wie die obige würden mich, wenn ich an so einen Projekt freiwillig (!) und unentgeltlich (!) teilnehmen würde, echt ankotzen.
Du hast den Source. Mach einen Patch. Schick ihn rein. Diskutier's auf der Mailingliste.
Na dann mach ich mal den DAU: Wieso gehts nicht? Ich seh den Fehler nicht, weswegen
#define B01010101 0x55
nicht "funktionieren" soll. FYI: Bei mir kompiliert's einwandfrei - wie zu erwarten war. YMMV.
Gruß, Johannes
--
durch dei Verdunstung kült das sogar ziemlich gut
das ist wie schweiß. Hünde müssen da hecheln so wie Lüfter.
Markus Gronotte in de.sci.electronics
Das betrifft nicht nur den gcc, das hat mich auch schon beim portable C compiler auf der PDP11/40e unter Unix V6 gestört. (V6 ist übrigens kein Nachfolger von Unix system5).
Ich habe das Problem seinerzeit für mich gelöst, da hat der gcc noch nicht existiert( ok, nicht für C-programme selbst, aber für deren In/output, soweit ich dafür zuständig bin.)
Wenn sich jetzt nach 25 Jahren andere Leute immer noch über das gleiche Problem aufregen, dann ist das einfach nur Ignorieren-Wollen von Seiten ANSI und von mir aus der gcc-Gemeinde. Das Problem ist leicht zu sehen und leichter zu beseitigen als die Zuständigkeiten auszuloten.
Das ist so, wie wenn ein paar VHDL-Feinschmecker entscheiden, daß Block-Comments BÄÄÄÄH sind. Man besorgt sich halt einen Editor-Makro der in 1000 Zeilen vorne ein -- einfügen kann und ******* auf die Feinschmecker.
Wenn mein nicht unentgeltliches(!) Pro-Naviagtionssystem verkündet, daß der Öschelbronner Weg 23 links ist, dann finde ich trotzdem nach Hause und werde _keinen_ Verbesserungsvorschlag an BMW schicken. Ich habe keine Lust mehr, den Missionar zu spielen. Von mir aus, wenn's um Phasenrauschen oder Demodulatoren geht, aber nicht bei Grundlagentools auf Ameisen-Kniehöhe.
Was interessiert mich eine Speziallösung für den AVR? Ich benutze ihn nicht und werde ihn nicht benutzen.
(whoever:)
Genau. Wie ein 32 Bit Microblaze oder PPC405 in meinem Virtex-4. Als ob man eine Lösung brauchen könnte, die die nächste Generation nicht überlebt. Doppelt und dreifach eben.
und Du hast das Wort "ankotzen" ins Spiel gebracht?
Wenn ich mich richtig erinnere, ist ein entsprechender Patch in den FreeBSD-Quellen zum avr-gcc eingeflossen. Eventuell mal auf der avr-gcc Mailingliste fragen?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.