Ich suche einen "etwas anderen" C-Compiler Meine Controller programmiere ich seit einigen Jahrzehnten nur in Asm. Ich hatte mehrmals meine Programmierung mit C angefangen, aber aus diversen Gründen wieder verworfen. Meine Anwendungen sind oft zeitkritisch, ich ersetze Hardware gerne durch Software wann immer das geht. Jetzt suche ich einen C-Compiler, der etwas anders arbeitet als zB AVR-GCC. Normale C-Compiler behandeln -logisch- vozugsweise die Sprache C und nur als ungeliebten Zusatz Asm. Ich hätte das aber gern umgekehrt. Ideal wäre eine Software mit 2-Fenster-Technik, links C und rechts Asm. Als Ergebnis ein Asm-Code, den ich dann mit dem Assembler endgültig übersetze. So eins habe ich schon mal kurz getestet, für den 8051, ich weiß aber nicht mehr was das war. Ist schon etwa 30 Jahre her und vermutlich untergegangen. Inzwischen arbeite ich vorzugsweise mit ATMEGAs. Gibt es so ein Compiler? Vielen Dank im Voraus. Gruß Peter
:
Gesperrt durch Moderator
Peter Hofbauer schrieb: > Gibt es so ein Compiler? nein, denke ich nicht. Macht auch überhaupt keinen Sinn. Schreib das Programm einfach ein C und die paar stellen wo du wirklich mit der Geschwindigkeit von C Probleme bekommt (was seeehr selten sein sollte) schreibst du einfach ein ASM.
Man kann GCC grundsätzlich Assembler ausspucken lassen. Aber (afaik) halt auch immer nur beim Bauen.
Wenn Du es chronisch Eilig hast: Warum nicht Assembler und C mischen. Der GNU-Compiler hat damit keine Probleme. Auf diese Weise kannst Du die Funktionalität von C mit ein paar Quickes aus der Assemblerkiste mischen. Ist vor allem sinnvoll, wenn Du der Fließkommaarithmetik nicht aus dem Wege gehen kannst.
Peter II schrieb: > Macht auch überhaupt keinen Sinn. Doch, macht es. Viele mögliche Asm-Optimierungen kollidieren mit den Anforderungen der normalen C-Laufzeitumgebung. Ich ahne, was dem TO vorschwebt: die Möglichkeit, zumindest einige Register (ggf. soviel wie irgend möglich) dem Zugriff des C-Compilers komplett zu entziehen. Darauf wird's wohl im Wesentlichen hinauslaufen. Ganz klar: der C-Code würde umso ineffizienter, je weniger Register er benutzen kann. Das stört aber niemanden, weil man C ja sowieso nur für den unwichtigen Kram einsetzt, bei dem Geschwindigkeit keine oder nur eine untergeordnete Rolle spielt.
kopfkratz Also suchst Du eine IDE die Deinen C-Code zeitgleich in ASM umsetzt und anzeigt ? Ließe sich mit GCC realisieren wenn es NICHT in Echtzeit passieren soll. Gut könnte man auch dauernd laufen lassen macht aber wenig Sinn. Die eigentliche Frage ist was willst Du erreichen ? Das Du siehst wie der C Compiler die Anweisungen in ASM umsetzt und den dann ggf. optimieren ? Inline ASM geht auch sehr gut wie schon erwähnt. Oder Du bleibst halt bei reinem Assembler ;-)
Außerdem ist es ja auch so, dass der Compiler viele Optimierungen noch gar nicht einsetzen kann, bevor er nicht den größeren Kontext analsysieren kann. Daher würdest Du riesige ASM-Sprünge sehen, weil Du hier und dort nur eine Zeile änderst und er auf die Idee kommt, dass er jetzt hier inlinen kann, dort irgendwas lustiges mit Zeiger-Aliasen machen kann, hier eine Schleife unfolden sollte etc... Ansonsten können die gängigen IDEs aber veränderte Dateien automatisch neu laden... wenn Du also beim Bauen Asm ausgeben lässt, und die entsprechene Assembly-Datei im Splitscreen offen ist, wird er sie wohl updaten... Ist das nicht nah dran? :)
Peter Hofbauer schrieb: > Ideal wäre eine Software mit 2-Fenster-Technik, links C und rechts Asm. Wieso das denn, ich habe IDEs, da sind im linken Fenster die Source Files (Module) aufgeführt (.c, .h, .asm usw.) und rechts wird editiert - sowohl C als auch Assembler, das ist doch alles gleichberechtigt. Der Editor weiss natürlich was C und was ASM ist und färbt das alles schon entsprechend ein. Ich denke, das ist auch der normale Weg. Auch Resourcenfiles und ähnliches wird da mitverwaltet. Wenn man das nötige KnowHow hat, kann man nicht nur Assembler-Funktionen von C aus aufrufen oder ISRs in Assembler schreiben, sondern ebenso C-Funktionen aus einem Assembler-Programm aufrufen, z.B. um eine Fliesskommaberechnung durchzuführen. Für Profis ist eigentlich eine mehrsprachige Entwicklung eine bare Selbstverständlichkeit, ich finde daher die Diskussion C oder ASM geradezu albern und nur was für geistig beschränkte. Für mich lautet die Antwort auf die Frage C oder ASM schlicht Ja. Manchmal auch noch Pascal dazu. Gruss Reinhard
Danke für die schnellen Antworten! Leider existiert so ein Compiler wohl nicht, schade! Ich wollte mir nur Schreibarbeit sparen und im logischen Ablauf einen übersichtligeren Kode haben. Bei meinen Anwendungen sind übrigens keineswegs zeitkritische Programmteile "seeehr selten", sondern leider die Regel. Die parallele Programmierung mit C und Asm in 2 Fenstern meines Editors habe ich versuchsweise mal getestet. Der von GCC erzeugte Asm-Code ist dazu ungeeignet. Besser gesagt eine Katastrophe! Das scheint am Versuch des Compilers zu liegen, den Code zu optimieren. Und dann den Asm-Teil selber verbessern? Das könnte in die Hose gehen. Ich hatte mir von einem "Asm-orientierten" C-Compiler einen besseren Asm-Code versprochen. Für den 8051 hatte ich so einen mal Testweise. Dessen Asm-Code war brauchbar. Übrigens benötige ich die Lib von C nicht. Ich habe alles was ich benötige in Asm, auch Fließkommaarithmetik. Stammt noch aus meiner 8051-Zeit. Das war nicht so kompliziert wie es scheint. Man muß es nur machen, soviel Fleiß muß sein! Werde mich jetzt doch mal mit "nur C" beschäftigen. Gruß Peter
Peter Hofbauer schrieb: > Bei meinen Anwendungen sind übrigens keineswegs zeitkritische > Programmteile "seeehr selten", sondern leider die Regel. Wieso dann nicht einen µC nehmen, der gleich mehr unter der Haube hat? Heutzutage gibt es viele Hersteller mit Cortex-Mx Kern, bis zu 180MHz. Außerdem kann der C-Compiler einen viel effizienteren Code erzeugen, da der µC bereits mit 32 Bit rechnet. Somit sind Programmteile in Assembler eher die Ausnahme und man hat genügend Reserve für Erweiterungen. Die Bekanntesten können hier nachgelesen werden: - STM32 - LPC1xxx - ARM
:
Bearbeitet durch User
Markus Müller schrieb: > Wieso dann nicht einen µC nehmen, der gleich mehr unter der Haube hat? War ja klar dass du wieder hier auftauchst.. Antwort: Weil er mit ATmega programmiert. Und weil der ATmega sauschnell ist. Und wenn mir die Programmiersprache die Performance verhunzt, ändere ich nicht den Prozessor sondern die Sprache. Und weil zwischen STM und AVR ein himmelweiter Unterschied ist. Und weil für Hobbybastler der STM monatelange Einarbeitung erfordert. Und weil der 100mal komplizierter ist. Und wer hier was gegenteiliges behauptet, der lügt! So!
Peter Hofbauer schrieb: > Meine Anwendungen sind oft zeitkritisch, hast du mal ein Beispiel "aus der Praxis" ?
markusDerBastler schrieb: > Und wenn mir die Programmiersprache die Performance verhunzt, ändere ich > nicht den Prozessor sondern die Sprache. Na dann viel Spass - als ob C so schlecht wäre und es so viele besser gibt. > Und weil zwischen STM und AVR ein himmelweiter Unterschied ist. > Und weil der 100mal komplizierter ist. Ja genau, die Peripherie in einem LPC1xxx und STM32 ist viel moderner mit der sich dank DMA und viel mehr eigener Intelligenz ein noch effizienteren Code erzeugen lässt. Damit werden zeitkritische Anwendungen viel leichter umgesetzt - und man spart sogar Zeit, die man bei einem AVR hinein stecken muss um zusätzlich was in Assembler zusammen zu basteln. Außerdem war meine Frage an Peter Hofbauer gerichtet.
:
Bearbeitet durch User
Peter Hofbauer schrieb: > Leider existiert so ein Compiler wohl nicht, schade! Hast du mal überlegt, wie das gehen soll? Ein bissel C-Code hinwerfen, dann im entstandenen ASM-Code rumhacken. Anschließend wieder im C-Code ändern, wobei der Compiler natürlich "wissen" soll, was du dir bei deinen Änderungen im ASM-Code "gedacht" hast, dies "intelligent einflechten", und womöglich am Ende gar "selbst lernend" deine "ASM-Code-Verbesserungen" in künftigen Programmen berücksichtigen. - Klar wär das toll. Aber mal realistisch betrachtet würde das allenfalls ohne "intelligent einflechten" und "selbst lernend" einigermaßen funktionieren, und nur mit einem C-Compiler ohne die geringste Optimierung. Dein ASM-Code würde durch C-Code-Änderungen wohl trotz dem immer wieder ungewollt Schaden nehmen. Mag sein, dass es so etwas mit den genannten Beschränkungen vor 30 Jahren mal gegeben hat. > Ich wollte mir nur Schreibarbeit sparen und im logischen Ablauf einen > übersichtligeren Kode haben. Klar, wollen kann man vieles. Aber du wirst wohl keine IDE finden, die deinen ASM-Code "versteht", und als logischen Ablauf in C-Code umsetzt. Du kannst aber in ASM modular programmieren, Macros verwenden und wiederverwendbaren ASM-Code erstellen. Das spart auch Schreibarbeit. Bibliotheken sind ebenso mit ASM möglich, genau so gemischt-sprachige Programmierung, wie schon beschrieben. ;-) Edit: Tippfehler
:
Bearbeitet durch User
Peter Hofbauer schrieb:
> Meine Anwendungen sind oft zeitkritisch,
hast du mal ein Beispiel "aus der Praxis" ?
>Dessen Asm-Code war brauchbar.
Augenblick mal - der Compiler machte aus optimierten C-Code lesbaren
ASM-Code.
Heutzutage wollen die meisten Programmierer einen Compiler, der aus
Quick&Dirty C-Code trotzdem schnellen und kleinen ASM-Code erzeugt.
Für dich und Steve Wozniak mag das ein Nachteil sein. Für die große
Masse, die überhaupt nicht weiß, wie man Programmcode optimiert, ist es
eher ein Vorteil.
Peter Hofbauer schrieb: > Ich hatte mir von einem "Asm-orientierten" C-Compiler einen besseren > Asm-Code versprochen. Für den 8051 hatte ich so einen mal Testweise. > Dessen Asm-Code war brauchbar. Also mit dem Freeware SDCC für 8051 komme ich inzwischen gut klar, sowohl mit Inlining als auch mit externen separaten reinen Assemblerfiles, die aus C gerufen werden. Der 8051 braucht hin und wieder einen Assemblerfetzen, z.B. wenn man den Timer 0, der im 16-bit-Mode kein Autoreload hat, manuell nach laden muß, und dafür Takte zählen muß. Die beiden Bytes werden ja nacheinander wieder in den Timer geschrieben, und da darf kein Übertrag genau an dieser Stelle statt finden. Wenn man das richtig macht und auch kann, ist das aber gar kein Thema. Ich war aber auch schon genötigt, eine größere zeitkritische Funktion in Assembler zu schreiben und zu optimieren, weil C das absolut nicht packte. Z.B. mal FIFOs für den UART. In ASM bekam ich die Baudrate auf 115.200, bei C noch nicht mal auf die Hälfte. Meine Priorität im Hobby liegt ja darin, das zu optimieren, was ich besitze, und nicht ständig neu kaufen, doppelt so groß und doppelt so schnell. Als Profi in der industriellen Entwicklung kann man das gerne machen. Als Oberfläche und Editor verwende ich Geany, da hat man aber auch alle Fenster von Dateien offen, die man möchte. Ich schmökere ja auch mal gerne im ASM-Code herum, den der C-Compiler macht. Ein Fenster läßt sich auch noch teilen, aber nee, das geht meiner Meinung nach zur vernünftigen Ansicht nicht. Vielleicht mit größerem Monitor oder zwei Monitoren.
Glaubt ihr immer noch an das Märchen, daß ihr mit Assembler schnelleren Code zusammengefriemelt bekommt, als ein C-Compiler? Träumt weiter.
Wilhelm F. schrieb: > Ich war aber auch schon genötigt, eine größere zeitkritische Funktion in > Assembler zu schreiben und zu optimieren, weil C das absolut nicht > packte. Z.B. mal FIFOs für den UART. In ASM bekam ich die Baudrate auf > 115.200, bei C noch nicht mal auf die Hälfte. eventuell kannst du aber C nicht so gut wie ASM. Man kann C auch so schreiben das der Optimierer es einfach hat. Und mit dem ASM wissen welches du hast sollte man eigentlich sehr guten C-Code schreiben können. Mir würde auch ein Beispiel interessieren.
Peter II schrieb: > Mir würde auch ein Beispiel interessieren. Eines nannte ich schon, wofür man ASM braucht: Die Nachladung von Timer 0 im Timer-Interrupt selbst.
Wilhelm F. schrieb: > Eines nannte ich schon, wofür man ASM braucht: Die Nachladung von Timer > 0 im Timer-Interrupt selbst. warum sollte das in C nicht genauso gehen? Es wird zwar standardmäßig SREG auf dem Stack gesichert aber das kann bei bedarf abschalten. Und die Zuweisung geht auch in C.
Der GCC hat eine recht komplexe Syntax um inline-ASM mit C zu verbinden, d.h. Variableninhalte auszutauschen etc. Wie gut das bei AVR funktioniert weiß ich nicht; bei ARM und x86 funktioniert es. Aber das braucht man natürlich nur wenn man etwas in C oder C++ gar nicht abbilden kann; in 99.9% der Fälle muss man es nur richtig schreiben...
Peter II schrieb: > warum sollte das in C nicht genauso gehen? Weil C nicht korrekt auf den Taktzyklus genau eine 16-bit-Konstante auf den aktuellen unbekannten Timerwert aufaddieren kann, ohne daß es zu Fehlern kommt.
Eine kurze Zwischenfrage. Hat einer aus der ARM Fraktion mal nachgeschaut, ob bei der "Standard Peripheral Library" solche Sachen in Assembler codiert werden?
Wilhelm F. schrieb: >> Mir würde auch ein Beispiel interessieren. > > Eines nannte ich schon, wofür man ASM braucht: Die Nachladung von Timer > 0 im Timer-Interrupt selbst. und dafür soll ein Hersteller den Aufwand treiben eine neue, komplexe IDE zu entwickeln? Vielleicht könnte man ein Eclipse Plug-In bauen das den kompilierten C-Code einfacher in Projekte einbaut, aber für ein paar Zeilen Inline Asm lohnt sich auch das nicht. Ansonsten finde die Vorstellung gruselig so einen Misch-Masch zu warten. Packe das mal nach ein paar Jahren wieder an und versuche den bis in die Haarspitzen optimierten Maschinencode noch zu verstehen.
Kein Name schrieb: > Hat einer aus der ARM Fraktion mal > nachgeschaut, ob bei der "Standard Peripheral Library" solche Sachen in > Assembler codiert werden? Die Standard Peripheral Library gehört speziell zu ST, nicht allgemein zu ARM. Und da ARM 32bit ist, sind solche Frickeleien für bis zu 32bit-Counter natürlich unnötig. Und falls man 64bit Counter hat (hätte) wüsste ich nicht wieso man Assembler benötigen würde; höchstens müsste man außendrum Interrupts abschalten. Aber allein mit 32bit-Countern kann man ja schon bis zum St. Nimmerleins Tag zählen...
Die CMSIS macht Spezial ASM Befehle einfach in C nutzbar. Wie z.B. Shiften, oder Byte/Word Swap. Dafür gibt es extra ASM Befehle, der jedoch in der Standard C Definition so nicht enthalten ist. Ansonsten ist die LIB ASM Frei.
Hay Jojo, mag ja sein, dass Peter so etwas auch in Jahrzenten noch versteht. Der springende Punkt: für die paar Programmier, die so etwas noch können, entwickelt kein BWLer eine passende IDE.
Jojo S. schrieb: > Wilhelm F. schrieb: >>> Mir würde auch ein Beispiel interessieren. >> >> Eines nannte ich schon, wofür man ASM braucht: Die Nachladung von Timer >> 0 im Timer-Interrupt selbst. > > und dafür soll ein Hersteller den Aufwand treiben eine neue, komplexe > IDE zu entwickeln? Das war doch jetzt gar nicht die Frage. > Ansonsten finde die Vorstellung gruselig so einen Misch-Masch zu warten. > Packe das mal nach ein paar Jahren wieder an und versuche den bis in die > Haarspitzen optimierten Maschinencode noch zu verstehen. Kein Problem, da ich den Code immer sehr ausführlich direkt am Ort dokumentiere. Ob man sich jetzt für jede Funktion ein separates ASM-File macht, oder alles in ein ASM-File knallt, ist auch jedem selbst überlassen. Jedenfalls komme ich sehr gut zurecht.
Markus Müller schrieb: > Wie z.B. > Shiften, oder Byte/Word Swap. Dafür gibt es extra ASM Befehle, der > jedoch in der Standard C Definition so nicht enthalten ist. Braucht man aber natürlich nicht, denn optimierende Compiler wie GCC generieren die entsprechenden Befehle automatisch...
Dr. Sommer schrieb: > Markus Müller schrieb: >> Wie z.B. >> Shiften, oder Byte/Word Swap. Dafür gibt es extra ASM Befehle, der >> jedoch in der Standard C Definition so nicht enthalten ist. > Braucht man aber natürlich nicht, denn optimierende Compiler wie GCC > generieren die entsprechenden Befehle automatisch... Mit SWAP und ROL tun sich die meisten Compiler schwer, da sich diese Operationen in C nur sehr mühselig beschreiben lassen. Das ist aber selten ein Problem.
Tim schrieb: > Mit SWAP und ROL tun sich die meisten Compiler schwer, da sich diese > Operationen in C nur sehr mühselig beschreiben lassen. Ja in C siehts etwas hässlich aus. Aber ich meine mich daran zu erinnern dass der GCC das hinbekommt.
Dr. Sommer schrieb: > Tim schrieb: >> Mit SWAP und ROL tun sich die meisten Compiler schwer, da sich diese >> Operationen in C nur sehr mühselig beschreiben lassen. > Ja in C siehts etwas hässlich aus. Aber ich meine mich daran zu erinnern > dass der GCC das hinbekommt. Noch nicht mal Assemblerprogrammierer bekommen es immer richtig hin, vielleicht ist der Kopf noch bei der letzten Party am Wochenende. In einem Code für den 8051 fand ich da schon mal vier mal ein Byte mit RL A links rotiert, anstatt ein mal ANL A, #0F0h und danach SWAP A. Oder XRL A, #0FFh, anstatt CPL A. Beides waren bei mir mal Knackpunkte in einer Speed-Optimierung. Den Assembler sollte man schon gut können, wenn man darin auch optimiert.
Wilhelm F. schrieb: > In einem Code für den 8051 fand ich da schon mal vier mal ein Byte mit > RL A links rotiert, anstatt ein mal ANL A, #0F0h und danach SWAP A. Oder > XRL A, #0FFh, anstatt CPL A. Beides waren bei mir mal Knackpunkte in > einer Speed-Optimierung. Den Assembler sollte man schon gut können, wenn > man darin auch optimiert. So etwas bekommt ein guter C-Compiler aber dafür hin.
Wilhelm F. schrieb: >> und dafür soll ein Hersteller den Aufwand treiben eine neue, komplexe >> IDE zu entwickeln? > > Das war doch jetzt gar nicht die Frage. Doch, der TO sucht so etwas wenn ich das richtig verstanden habe. Dein Beispiel zeigt das man auch Asm in einer C Umgebung brauchen kann, aber so ein paar Zeilen lassen sich besser mit Inline abfrühstücken. Was wäre jetzt ein Bespiel für eine aufwändigere Funktion die man lieber in Asm bauen wollte? Ich wüsste ad hoc keines, die C Compiler sind doch mittlerweile so gut das man sich Mühe geben muss ineffizienten Maschinencode zu produzieren. Vielleicht kann man etwas optimieren wenn man spezielle Befehle einsetzt die der Compiler nicht mag, soetwas wie SIMD vielleicht. Aber die hat der alte ATMega ja nicht, also noch ein K.O. für so eine Anwendung. Auch wenn man sich so eine wilde Mathe Lib wie die DSP Lib für die Cortexe ansieht findet man nur C + Inline Macros für die speziellen Befehle. Bevor ich da Stunden an Arbeit dem Performancegott opfere würde ich auch eher über den Tellerrand gucken und die passende Hardware suchen. Eine schnelle FFT z.B. kriegt man auf einem ATMega hin, aber dann fehlt dem der Speicher und beim Cortex z.B. habe ich auch gleich DMA für den AD-Wandler.
>Glaubt ihr immer noch an das Märchen, daß ihr mit Assembler schnelleren >Code zusammengefriemelt bekommt, als ein C-Compiler? 88a8: e3510000 cmp r1, #0 88ac: 13a01000 movne r1, #0 88b0: 03a01001 moveq r1, #1 88b4: 15821000 strne r1, [r2] 88b8: 05821000 streq r1, [r2] 88bc: 159f203c ldrne r2, [pc, #60] 88c0: 059f203c ldreq r2, [pc, #60] 88c4: 13a01801 movne r1, #65536 ; 0x10000 88c8: 03a01801 moveq r1, #65536 ; 0x10000 Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja Inline Assembler ist schlecht, weil der Compiler Probleme mit der Optimierung bekommt.
heinz schrieb: > Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja und wie sieht der C code dafür aus?
heinz schrieb: > Wenn ich seh was gcc (-O2) so macht - ist die Antwort Ja Welche Version? > Inline Assembler ist schlecht, weil der Compiler Probleme mit der > Optimierung bekommt. Dafür gibt es die entsprechenden Constraints, geht, ist aber etwas fummelig
4.7.4
if (t){
t=0;
GPSET0 = 1<<16;
}
else{
t=1;
GPCLR0 = 1<<16;
}
Ist nur ein Ausschnitt. Sorry nicht -O2 sondern -O3
Peter Hofbauer schrieb: > Ich wollte mir nur Schreibarbeit sparen und im logischen Ablauf einen > übersichtligeren Kode haben. ähh...warum benutzt du dann ASM? ;-)
Also hier mal die Timernachladung 16 bit im Timerinterrupt des 8051:
1 | _t0_reload:: |
2 | mov r0, dpl ; Variable 1 |
3 | mov dptr, #_t0_reload_PARM_2 ; Adresse Variable 2 |
4 | movx a, @dptr |
5 | mov r1, a ; Variable 2 |
6 | |
7 | ; Das war die Parameterübergabe des Compilers, die ich hier |
8 | ; in die Register R0 und R1 verfrachtete. |
9 | |
10 | clr EAL |
11 | clr TR0 |
12 | mov a, r0 |
13 | add a, TL0 |
14 | mov TL0, a |
15 | mov a, r1 |
16 | addc a, TH0 |
17 | mov TH0, a |
18 | setb TR0 |
19 | setb EAL |
20 | ret |
Was will ein C-Compiler denn hier optimieren können? Und vor allem: Bekommt der das genau exakt so hin? Der Timer wird hier für die Nachladung exakt genau 7 Maschinenzyklen lang gestoppt, die exakte Berechnung durch geführt, mit den sieben stehen gebliebenen Zyklen wieder aufaddiert, (ist in einer Konstantendefinition in Main.h) und dann wieder gestartet.
Ja -alles volatile. Wobei das t eigentlich nur static sein müsste. Habe ich gleich ausprobiert und ändert nix
Peter Hofbauer schrieb: > Meine Anwendungen sind oft zeitkritisch, ich ersetze Hardware gerne > durch Software wann immer das geht. Widerspricht sich das nicht? Hardware ist fast immer schneller als Software. Peter Hofbauer schrieb: > Ideal wäre eine Software mit 2-Fenster-Technik, links C und rechts Asm. Mmhh, kann das nicht die TI Entwicklungsumgebung (Code Composer) für ihre DSP-Familie? Wobei der imho nur den Assembler anzeigt und man den nur über den C-Code beeinflussen kann. Das es so etwas für AVR gibt wäre mir neu... und was generisches wirst du kaum finden.
Wilhelm F. schrieb: > Was will ein C-Compiler denn hier optimieren können? Und vor allem: > Bekommt der das genau exakt so hin? Die Frage ist eher: - Wie groß ist der Anteil des kritischen Codes an Deinem Projekt? - Reicht es nicht, eine Funktion als Assemblersource in das Projekt einzubunden? Bloß weil der C-Compiler in 3% des Codes nicht das macht, was man will, heisst es nicht dass man für die übrigen 97% etwas anderes braucht.
:
Bearbeitet durch User
Tim schrieb: > - Wie groß ist der Anteil des kritischen Codes an Deinem Projekt? > - Reicht es nicht, eine Funktion als Assemblersource in das Projekt > einzubunden? 1 Prozent des gesamten Codes. Und das stört nun wirklich gar nicht weiter. Meine Frage, wie man das hier Beitrag "Re: Ich suche einen "etwas anderen" C-Compiler" in C macht, ist noch nicht beantwortet.
Wilhelm F. schrieb: > Meine Frage, wie man das hier > > Beitrag "Re: Ich suche einen "etwas anderen" C-Compiler" > > in C macht, ist noch nicht beantwortet. Vielleicht geht es, vielleicht auch nicht. C hat überhaupt nicht den Anspruch, 100% deterministischen Zugriff auf das "Bare Metal" zu ermöglichen. Dazu kommt noch, dass der 8051 uralt ist und nicht auf Hochsprachen optimiert wurde. Auf dem 6502 fällt es noch viel leichter, eine vermeintliche Untauglichkeit von C nachzuweisen.
:
Bearbeitet durch User
garnicht..entweder machst du markierst du einen c-funktion als naked und schreibst dort inline-asm oder du schiebst die Funktion in eine .S-file... übrigends, auf halbwegs neuen architekturen mit pipeline kannst du sowas wie instruktionen/takte zählen vergessen...je nachdem was da im hintergrund abgeht, wird die code-exekution verzögert... ähnliches kann dir bei DMA übertragungen im hintergrund passieren... compiler sind heutzutage 1. schlau und 2. ziemlich flexibel... die übersetzung von funktionen und variablen können mit diversen flags manipuliert werden... ich habe vor kurzem einen taskswitcher komplett in c++ geschrieben... bis auf ein paar intrinsics die man eben bei der architektur braucht gibts auch keinen asm-code... bevor der stack usw steht muss man halt variablen als register definieren.. geht super und man kann mit einer gewöhnlichen for-schleife den sram initialisieren... also auch das startup-file ist c++... lang lebe die const static member-function ;) 73
Danke für die rege Beteiligung! Einige wollten mal ein Beispiel über zeitkritische Anwendungen. Ok, jetzt mal ein paar Beispiele aus meiner Praxis. Ich fange mal mit den ersten Versuch eines Umstiegs auf C an. Kleinste Deatils verschweige ich hier mal, das wird sonst zu lang. 1. Fall Die Anforderung (eine Maschine mit Meßeinrichtungen): permanete Berechnungen während ein Motor davonrast. Um mir die Arbeit zu erleichtern hatte ich mir einen C-Compiler gekauft. Übrigens für über 2000DM. Dann habe ich an einen Testaufbau die Zeiten mit den Skop gemessen. Das war es dann. Den Compiler habe ich nie wieder verwendet. Die Zeiten der Rechenroutinen waren alle viel zu lang. Dann habe ich einen Satz Rechenroutinen in Asm entwickelt. Auch Fließkommaarithmetik. Damit gings. 2. Fall Für die Entwicklung von Steuerungen für umfangreiche Maschinen habe ich für den 8051 so etwas ähnliches wie eine Programmiersprache entwickelt. Alle (!) Abläufe wurden in Tabellen eingetragen. Mehrere gleichzeitige Abläufe bekamen eine eigene Tabelle. Darüber trohnte eine Mastertabelle, in der standen alle beteiligten Tabellen. Der Controller mußte alle Tabellen fortlaufend abarbeiten. Das war selbst in Asm grenzwertig was die Durchlaufzeit angeht. In C wäre das -zumindest für einen 8051- kaum möglich. 3.Fall Ein etwas neuerer Fall: ein Farb-LCD-Modul mit ATMEGA128 wurde mit fertigen C-Programmstücken gliefert. Darum habe ich das ganze mit GCC angefangen. Es zeigte sich eine verzögerte Reaktion auf Tastendrücke weil das Programm zu lange in der C-Routine fürs LCD drin bleibt. Darauf habe ich alles in Asm umgeschrieben. Allerdings lag das auch an der ungünstigen Konstruktion des mitgelieferten Kodes. Inzwischen habe ich mal die Codelänge des heute fertigen Projektes mit den C-Teil verglichen. Der C-Teil ist 50 (in Worten: fünzig) mal so lang. 4.Fall Eine Messplatine sollte 8 (!) verschieden serielle Schnittstellen mit zum Teil irren Baudraten bekommen. Der Prozessor (ein 8051-Ableger von Philips, Typ habe ich vergessen) hatte aber nur 2 integriert. Das geht nur zu Fuß in Asm. 5.Fall Ein Controller (ATMEGA2561) für einen HF-Spektrunanalyzer. Die Darstellung muste auf einer Oszi-Bildröhre erfolgen. Deren Ablenkung muß halt Zeitlinear erfolgen sonst wird das sichtbar. Außerdem mußten die Messungen in exakt zeitlichen Abläufen erfolgen. 6.Fall Eine Meßplatine mit USB. Für den Controller (CY7C...) hatte ich einen C-Compiler, der mir eigentlich gut gefallen hatte. Trotzdem habe ich alles, auch wegen der USB-Schei*e, vorsichtshalber in Asm geschrieben. Das hat sich später ausgezahlt. Die Entwicklung erfolgte noch mit Win2k. Unter XP war noch alles OK. Dann kam Win7. Die Programme auf dem PC stiegen nach unterschiedlichen Zeiten manchmal -nicht immer- aus. Diese PC-Programme wurden übrigens in Indien geschrieben. Dann schafften es die Soft-Ings in Indien und etwa 3 Ings in D auch nach 2 Jahren nicht, den Fehler zu finden. Das habe ich in einer Woche erledigt. Weil alles in Asm war. Das ist noch ein wichtger Punkt: die Fehlersuche. Ich hätte noch mehr, aber es wird langweilig. Ich habe absolut nichts gegen C! Deshalb suche ich ja nach einen für mich richtigen Weg. Natürlich kann man auch in C schnelle Programme schreiben. Es ist aber schwer möglich, die Zeiten in einer C-Routine zu berechnen. Geht nur mit messen. Was mich wundert: die C-Schreiber hier im Forum reagieren auf Asm irgentwie wütend. Worum? Ich werde mich jetzt mal überwinden und mir GCC reinziehen, allen Abneigungen zum Trotz. Beim folgenden Projekt, eine Steuerung für eine Senk-Erodiermaschine. Gruß Peter
heinz schrieb: > 4.7.4 > > if (t){ > t=0; > GPSET0 = 1<<16; > } > else{ > t=1; > GPCLR0 = 1<<16; > } > > Ist nur ein Ausschnitt. Sorry nicht -O2 sondern -O3 Da fehlen aber noch 2 "str" im ASM-Code. Der generierte Code müsste maximal Zeit-Effizient sein, eventuell nicht maximal Platz-Effizient. Die Frage ist aber, geht es in ASM überhaupt kompakter? Da bin ich mir grad nicht so sicher! PS: Es gibt schon GCC Version 4.8.2 ...
Peter Hofbauer schrieb: So etwas nennt man im Englischen "anecdotal evidence". Deine Beispiele haben gemeinsam: - Keine konkreten Fakten. Woran hat es gehakt? War es nur eine Kleinigkeit im kritischen Pfad, oder lag es wirklich an der gesamten Softwarearchitektur? - Sie setzen alle auf 8051 und AVR, für C nur bedingt geeignete Architekturen. - Du erwähnst häufig, dass Du auch Algorithmen verändert hast. Einen Unterschied in der Ausführungszeit um einen Faktor 50 lässt sich anders auch nicht erklären. Verstehe ich Beispiel 6 richtig: Du hast etwas in Assembler geschrieben und andere haben anschließend einen Fehler nicht finden können, bis Du den Assemblercode selbst korrigiert hast?
> if (t){ > t=0; > GPSET0 = 1<<16; > } > else{ > t=1; > GPCLR0 = 1<<16; > } Versuche mal (sofern deine Programmlogik mit den Nebenwirkungen leben kann; "uint8_t" natürlich anpassen):
1 | uint8_t tt = t; |
2 | if (tt){ |
3 | tt=0; |
4 | GPSET0 = 1<<16; |
5 | }
|
6 | else { |
7 | tt=1; |
8 | GPCLR0 = 1<<16; |
9 | }
|
10 | t = tt; |
Tim schrieb: > Dazu kommt noch, dass der 8051 uralt ist und nicht auf > Hochsprachen optimiert wurde. Auf dem 6502 fällt es noch viel leichter, > eine vermeintliche Untauglichkeit von C nachzuweisen. Ja das ist völlig klar. Der 8051 entstand noch lange vor C. Der Vorgänger 8048 lebte in Assembler, ich glaube da gibt es bis heute keinen C-Compiler für.
Peter Hofbauer schrieb: > Natürlich kann man auch in C schnelle Programme schreiben. Es ist aber > schwer möglich, die Zeiten in einer C-Routine zu berechnen. Geht nur mit > messen. Das geht auf den neuen Microcontroller auch mit Assembler nicht mehr: -Flash Waitstates -DMA -Instruction cache (z.B. im STM32F4)
Wilhelm F. schrieb: > Tim schrieb: > >> Dazu kommt noch, dass der 8051 uralt ist und nicht auf >> Hochsprachen optimiert wurde. Auf dem 6502 fällt es noch viel leichter, >> eine vermeintliche Untauglichkeit von C nachzuweisen. > > Ja das ist völlig klar. Der 8051 entstand noch lange vor C. C kam 1972 raus... C++ 1983. Die 8051er 1980, selbst der 8048 kam erst nach C auf den Markt.
Peter Hofbauer schrieb: > Ein etwas neuerer Fall: ein Farb-LCD-Modul mit ATMEGA128 wurde mit > fertigen C-Programmstücken gliefert. Darum habe ich das ganze mit GCC > angefangen. Es zeigte sich eine verzögerte Reaktion auf Tastendrücke > weil das Programm zu lange in der C-Routine fürs LCD drin bleibt. Darauf > habe ich alles in Asm umgeschrieben. Allerdings lag das auch an der > ungünstigen Konstruktion des mitgelieferten Kodes. Inzwischen habe ich > mal die Codelänge des heute fertigen Projektes mit den C-Teil > verglichen. Der C-Teil ist 50 (in Worten: fünzig) mal so lang. sorry das glaub dir niemand. Bei den meisten Display Ansteuerungen sind sogar Wartezeiten im code damit das Display hinterher kommt. Auch willst du behaupten das die Zeilenanzahl von C 50mal so groß ist wie der ASM code? Und das bestimmt bei gleicher Funktionalität. Das ist auch schwer zu glauben.
Arc Net schrieb: > Wilhelm F. schrieb: >> Tim schrieb: >> >>> Dazu kommt noch, dass der 8051 uralt ist und nicht auf >>> Hochsprachen optimiert wurde. Auf dem 6502 fällt es noch viel leichter, >>> eine vermeintliche Untauglichkeit von C nachzuweisen. >> >> Ja das ist völlig klar. Der 8051 entstand noch lange vor C. > > C kam 1972 raus... C++ 1983. > Die 8051er 1980, selbst der 8048 kam erst nach C auf den Markt. Das Argument zieht nicht. Damals war man froh, dass man überhaupt einen Microprozessor auf einem Chip hinbekam. An Hochsprachen war dabei nicht zu denken. Anders beim 68000 und x86.
Arc Net schrieb: > C kam 1972 raus... C++ 1983. > Die 8051er 1980, selbst der 8048 kam erst nach C auf den Markt. Sorry, aber ein Unternehmen konnte ja einen C-Compiler für 3000 DM kaufen, nicht ein Hobbybastler.
Wilhelm F. schrieb: >> C kam 1972 raus... C++ 1983. >> Die 8051er 1980, selbst der 8048 kam erst nach C auf den Markt. > > Sorry, aber ein Unternehmen konnte ja einen C-Compiler für 3000 DM > kaufen, nicht ein Hobbybastler. ?? 1982 konnte man für 3000 DM noch nicht einmal einen Computer kaufen, der einen C-Compiler ausführen konnte.
Hallo Tim, wie ich erwähnt habe, sind Details weggelassen. Das wird zu lang. Vielleicht ist auch einiges nicht genau geschrieben worden. Mit 50 mal ist die Codelänge (der Hex-Code) gemeint, nicht die Geschwindigkeit. Ich habe die Algorithmen nicht verändert, meinst Du damit die Rechenroutinen? Die habe ich komplett in Asm geschrieben und nicht aus den C-Übersetzung generiert. Da würde ich auch nicht durchfinden. Beispiel 6: Das war ein Beispiel für die Vorteile von Asm bei einer tiefgehenden Fehlersuche. Die erwähnten Kollegen hatten den Soucecode meiner Firmware und alle Infos. Ich war zu dem Zeitpunkt nicht mehr in der Firma. Die haben mich privat kontaktiert. Der Assemblercode hatte keinen Fehler, ich mußte den Prozessor in die USB-Sache reingehen und austricksen. Das geht nur in Asm! Die Ursache lag übrigens bei Microsoft, die hatten ohne Grund und ohne Infos den Ablauf an jenen Stellen geändert, der nicht im USB-Protokoll zwingend definiert ist. Natürlich kann man fast alle Aufgaben auch in C ausführen. Dazu muß man aber trotzdem Asm können. Mit C programmieren indem man den Compiler in Richtung "schneller" steuert und dabei Asm im Kopf? Und ein Wechsel auf einen anderen Prozessor kommt wegen der erforderlichen Anschaffungen (Emulator) nicht in Frage. Gruß Peter
Peter Hofbauer schrieb: > Und ein Wechsel auf einen anderen Prozessor kommt wegen der > erforderlichen Anschaffungen (Emulator) nicht in Frage. Das sehe ich auch so. Bei einem Wechsel auf ein anderes System (STM32), hat allein der Emulator 20 Euro gekostet.
Hallo, also eine richtigen(!) Emulator bekommt man nicht für 20 Euro. Wenn ja, habe ich Interesse. Mein Emu für den ATMEGA hat über 300 Euro gekostet. Gruß Peter
Peter Hofbauer schrieb: > Hallo, > also eine richtigen(!) Emulator bekommt man nicht für 20 Euro. Wenn ja, > habe ich Interesse. Mein Emu für den ATMEGA hat über 300 Euro gekostet. > Gruß Peter was ist ein richtiger Emulator? Was ist falsch an dem von Atmel oder dem AVRemu?
Tim schrieb: > ?? 1982 konnte man für 3000 DM noch nicht einmal einen Computer kaufen, > der einen C-Compiler ausführen konnte. Na siehste. Soviel zu unseren Alleswissern hier.
Peter Hofbauer schrieb: > Die Ursache lag übrigens bei Microsoft, die hatten ohne > Grund und ohne Infos den Ablauf an jenen Stellen geändert, der nicht im > USB-Protokoll zwingend definiert ist. Das heißt, die URSACHE lag in deiner Firmware, die falsche Annahmen über den USB-Standard machte und nur zufällig auf der MS-Implementation funktionierte.
Hallo PeterII welche Emus genau meinst Du? Meiner (für >300) ist von ATMEL. Gruß Peter
Peter Hofbauer schrieb: > Hallo PeterII > welche Emus genau meinst Du? Meiner (für >300) ist von ATMEL. > Gruß Peter Für moderne MCUs nutzt man keinen Emulator mehr. Die haben alle Debugfunktionen eingebaut (z.B. SWD für ARM). Die dafür notwendig Hostadapter gibt es ab 20 EUR nachgeworfen.
Bei den Cortex-Mx ist das mit auf dem Chip drauf. Dazu gibt es den ST-Link mit dem kann man mit 2 Pins den STM32 laden und debuggen. Wenn man es professioneller haben will, dann kauft man sich einen J-LINK. Der ist schneller. Als Firma kostet der incl. Trace Feature schon etwas mehr - braucht nur so gut wie niemand. Für den "Hausgebrauch" reichen somit 20 EUR - so viel kostet das STM32F4DISCOVERY Borad, bei dem ein ST-LINK schon gleich mit drauf ist. ATMEGA ist schon ziemlich alt und heute gibt es viel moderneres, z.B. PIC18, PIC24, PIC32, STM32, LPC1xxx, MSP430 - alles moderne Chips. Und wenn man einen STM32 einfach nur bespielen will, so stöpselt man den per USB an den PC und mittels internem Bootloader kann der bespielt werden - kostet nix. Hier ein Artikel zum lesen: STM32 für Einsteiger LPC1xxx für Umsteiger Hier ein Beispiel für eine kostenlose IDE: STM32 CooCox Installation
:
Bearbeitet durch User
Hallo USB USB schrieb: > Peter Hofbauer schrieb: >> Die Ursache lag übrigens bei Microsoft, die hatten ohne >> Grund und ohne Infos den Ablauf an jenen Stellen geändert, der nicht im >> USB-Protokoll zwingend definiert ist. > > Das heißt, die URSACHE lag in deiner Firmware, die falsche Annahmen über > den USB-Standard machte und nur zufällig auf der MS-Implementation > funktionierte. Eben nicht, im USB-Standard sind freiheiten, z.B. nur die Bandbreite ist einzuhalten. Die "falschen Annahmen" hatte der Controller-Hesteller (Cypress). Der Controller benötigte intern im USB-Teil zwischen 2 Control-Transfers etwas mehr Zeit. Microsoft hatte diese Zeit um 92% verkürzt. Das konnte ich austricksen weil der Controller den normalen Arbeitsspeicher auch intern verwendet. Ich hoffe diesen Vorgang geklärt zu haben. Es ist nicht OK, meine Angaben ohne Wissen zu bezweifeln. Gruß Peter
>Der generierte Code müsste maximal Zeit-Effizient sein,
88b4: 15821000 strne r1, [r2]
88b8: 05821000 streq r1, [r2]
.
.
88c4: 13a01801 movne r1, #65536 ; 0x10000
88c8: 03a01801 moveq r1, #65536 ; 0x10000
str r1, [r2]
mov r1, #65536
2 Takte weniger und kleiner ;)
Tim schrieb: > Peter Hofbauer schrieb: >> Hallo PeterII >> welche Emus genau meinst Du? Meiner (für >300) ist von ATMEL. >> Gruß Peter > > Für moderne MCUs nutzt man keinen Emulator mehr. Die haben alle > Debugfunktionen eingebaut (z.B. SWD für ARM). Die dafür notwendig > Hostadapter gibt es ab 20 EUR nachgeworfen. OK, das ist jetzt geklärt. Ich werde aber trotzdem nicht wechseln, später vieleicht. Gruß Peter
Peter Hofbauer schrieb: > Ideal wäre eine Software mit 2-Fenster-Technik, links C und rechts Asm. > Als Ergebnis ein Asm-Code, den ich dann mit dem Assembler endgültig > übersetze. So eins habe ich schon mal kurz getestet, für den 8051, ich > weiß aber nicht mehr was das war. Ist schon etwa 30 Jahre her und > vermutlich untergegangen. Eigentlich ist das doch nichts anderes als ein moderner debugger? http://www.coocox.org/images/CoDebugger_screen_shot19.gif
heinz schrieb: > 2 Takte weniger und kleiner ;) Und wo lädst du die Adresse von GPSET0 bzw. GPCLR0? r2 enthält ja hier noch die von "t"... Aber vermutlich könnte man es tatsächlich so machen:
1 | 88a8: e3510000 cmp r1, #0 |
2 | 88ac: 13a01000 movne r1, #0 |
3 | 88b0: 03a01001 moveq r1, #1 |
4 | 88b4: 15821000 strne r1, [r2] |
5 | 88b8: 05821000 streq r1, [r2] |
6 | 88bc: 159f203c ldrne r2, [pc, #60] |
7 | 88c0: 059f203c ldreq r2, [pc, #60] |
8 | 88c4: 13a01801 mov r1, #65536 ; 0x10000 |
9 | str r1, [r2] |
Das würde 2 Instruktionen, aber keinen Takt sparen... Der Compiler mag vermutlich nicht die eigentliche store-Instruktion verschieben weil volatile.
Peter Hofbauer schrieb: > Der Controller benötigte intern im USB-Teil zwischen 2 > Control-Transfers etwas mehr Zeit. Microsoft hatte diese Zeit um 92% > verkürzt. Das konnte ich austricksen weil der Controller den normalen > Arbeitsspeicher auch intern verwendet. Und was hat das jetzt mit der Verwendung von C oder ASM zu tun? Nichts,reine Timingfrage der Hardware.
Helmut Lenzen schrieb: > Peter Hofbauer schrieb: >> Der Controller benötigte intern im USB-Teil zwischen 2 >> Control-Transfers etwas mehr Zeit. Microsoft hatte diese Zeit um 92% >> verkürzt. Das konnte ich austricksen weil der Controller den normalen >> Arbeitsspeicher auch intern verwendet. > > Und was hat das jetzt mit der Verwendung von C oder ASM zu tun? > Nichts,reine Timingfrage der Hardware. Stimmt, aber bei der Fehlersuche war Asm von Nutzen. Wenn das Programm in C geschrieben wäre, hätte ich wohl meine Probleme bei der Fehlersuche gehabt. Nur darauf wollte ich hinaus. Halt, da fällt mir noch was ein. Wegen USB durfte ich keinen Timer-Int verwenden. Auch wenn in der Interruptroutine kein einziger Befehl (außer reti) steht, tritt der USB-Fehler wieder auf. Aber ein Timer war unbedingt nötig weil in der Meßkarte Zeiten im 1ms-Raster nötig war. Das habe ich ohne Interrupt lösen müssen. Indem alle Routinen in der Hauptschleife in genauen Zeiten fertig werden müssen. So etwas geht in C überhaupt nicht! Eine andere Hardware war nicht möglich, auch keine Änderung, die Karten waren schon einige Zeit in Gebrauch ohne Probleme unter XP. Aber nochmals: ich habe nichts gegen C, ich zweifle nicht an den Aussagen der C-Schreiber hier. Meine Anwendungen sind halt sehr HW-orientiert. Gruß Peter
@Peter: Dein Problem ist IMHO , das Du "gewöhnt" bist, aus einer Hardware X das maximal mögliche heraus zu kitzeln und dabei zwangsläufig über Fälle stolperst, die nur mit Assembler lösbar sind. Da Du ungefähr weisst, was Du in Assembler mit einem z.B. 8051 hin bekommst, gehst Du Projekte damit an und stellst die auch fertig, so weit so gut. C soll Assembler nicht ersetzen, sondern soll das programmieren komfortabler gestalten (wie jede andere Programmiersprache auch). Obwohl die Compiler heute recht gut sind, kostet das zwangsläufig Performance, da die Optimizer nun nicht wirklich jeden Fall berücksichtigen können. Ergo: Du kaufst immer eigentlich zu kleine Schuhe weil Du einen großen Schuhanzieher hast. C ist eine Systemprogrammiersprache für Unix und hatte schon immer die Möglichkeit für zeitkritische Sachen Assembler einzubinden. Auch das Setup der Maschine an und für sich (crt0.s, crtend.s) gehört zu den Fällen, an denen standardmäßig Assemblerprogramme eingesetzt werden. Allerdings bestand das Ziel darin, auch mittels Hacks (nicht passende Variablenbreiten etc) direkt auf der Hardware herumzumuddeln, der Programmierer wird sich dabei schon was gedacht haben. (das ist die Stelle auf die die Pascalfreaks immer anspringen, keine Typprüfung, na sowas aber auch..) Am wohlsten fühlen sich C-Compiler auf Maschinen mit Registerfiles und vielen möglichen Zeigerregistern. Auf solchen Maschinen ist C auch entwickelt worden (PDPs von DEC). Auch wenn diese Maschinen aus heutiger Sicht keine Wurschtpelle mehr vom Teller ziehen sind sie doch deutlich komfortabler auch in Assembler zu programmieren als ein 8 Bit Mikroprozessor wie der AVR. Von Gurkendesigns wie dem 8048 oder 8051 oder eigentlich allen Intel Prozessoren möchte ich da gar nicht reden (ok, ich kenne I860, 960 usw. nicht). -- Du schreibst Du brauchst die ganzen Bibliotheken nicht...falsch. Eine Bibliothek ist eine Sammlung von Objektfiles. Was da drin ist, entscheidet der, der diese Bibliotheken gebaut hat. Was zum Teufel hindert Dich daran, Dir selbst passende Bibliotheken für die von Dir benötigten Funktionen zusammenzustellen, deren Quelle von Dir geschriebene Assemblerfiles sind? Diese Bilbiotheken werden vom Compiler an und für sich nicht mehr angefaßt, nur der Lader bindet als letztes Deine Dateien an das C-Programm. Das scheint mir hier der Punkt zu sein, den Du nicht verstanden hast. Niemand wird Dich vor den Kopf stoßen, wenn Du z.B. aktiv an der Weiterentwicklung des Codegenerators von AVR-GCC mitarbeiten willst, Fachleute sind da händeringend gesucht. Ich habe auch mit Software zu tun die andere Leute geschrieben haben. Da war auch so Einer dabei, der keine Standardbibliotheken brauchte. Das Ergebnis dessen ist eine Art Pfennigfuchser-Stringverarbeitung die sich über mehr als hundert Programmzeilen zieht um eine formatierte Ausgabe von Zahlen über eine serielle Schnittstelle zu verwirklichen. Ok, der Typ hat sicher Rechenzeit und jede Menge Platz gespart, nur ist der Flash des Atmega16 knappe 20% voll und die mit 16Mhz getaktete CPU verbringt mehr als 99% ihrer Zeit damit auf einen Tastendruck eines Bedieners zu warten um dann eine einzelne Zeile mit 9600 Baud auszugeben. Ob er wohl Geld von Atmel für die Nichtverwendung des ROMs und Maschinenzyklen zurück bekommen hat? Ich denke nicht...dafür ist der Code aber echt beschissen zu warten.. Ich würde auf den Trichter nicht kommen und lieber das (große) printf aus der Standardbibliothek verwenden, weißt Du auch warum? Ich kriege meine vertane Lebenszeit nicht zurück. Gruß, Holm
Hallo Holm, im Prinzip gebe ich Dir Recht! Ich wollte nicht auf Libs verzichten, sondern zusätzlich meine Eigenen verwenden, was ja unter C geht. Meine eignen Rechenroutinen sind etwas gestutzt und deutlich schneller. Mir fehlt nur ein C-Compiler für den ATMEGA, der "Asm-Orientiert" arbeitet. Ich habe verstanden, das es so einen nicht gibt. Meine Frage ist also beantwortet. Allen Beteiligten meinen herzlichen Dank! Gruß Peter
markusDerBastler schrieb: > Markus Müller schrieb: >> Wieso dann nicht einen µC nehmen, der gleich mehr unter der Haube hat? > > War ja klar dass du wieder hier auftauchst.. > > Antwort: Weil er mit ATmega programmiert. > Und weil der ATmega sauschnell ist. > Und wenn mir die Programmiersprache die Performance verhunzt, ändere ich > nicht den Prozessor sondern die Sprache. > Und weil zwischen STM und AVR ein himmelweiter Unterschied ist. > Und weil für Hobbybastler der STM monatelange Einarbeitung erfordert. > Und weil der 100mal komplizierter ist. > Und wer hier was gegenteiliges behauptet, der lügt! > > So! Bis zum letzten Satz dachte ich du meinst das ernst :) So, Spass beiseite: C-Compiler sind heute mächtige Werkzeuge. Allerdings sind sie das nur wenn man ihnen nicht in die Suppe spuckt. Assembler mag in absoluten Randbedingungen und je nach Fähigkeit des Compilers Sonderoptimierungen erlauben die sinnvoll sind. Im Grossen und Ganzen wäre eine ständiges Eingreifen in das generierte Assembly aber Gift. Gerade beim 8051 wundert mich das, weil Compiler mangels Stack die automatischen Variablen mit Call-Tree-Analyse zusammenfasst und Register bzw Datennutzung global optimiert. Das ist ein wenig wie wenn man bei der Bohrmaschine mitkurbeln will.
Nachtrag: Wenn es um eine optimierte CRT geht, was ich beim GCC verstehen kann, macht es mehr Sinn sich hier eine eigene Version zu erstellen. Den meisten Linkern ist es egal woher sie die Implementierung einer Funktion einbinden.
Wilhelm F. schrieb: > Tim schrieb: > >> ?? 1982 konnte man für 3000 DM noch nicht einmal einen Computer kaufen, >> der einen C-Compiler ausführen konnte. > > Na siehste. Soviel zu unseren Alleswissern hier. Mittlerweile etwas OT, aber so viel Geschichte muss sein... Micral N ab Januar 1973 für damals umgerechnet 1300 USD In der ersten c't wurde ein PL/S-Compiler für 8080 und CP/M für 820 DM angeboten... Motorola hat damals (Oktober 1983) einen 68000-basierten Einplatinenrechner für 495 USD verkauft http://www.classiccmp.org/cini/pdf/Motorola/mecb.pdf C-Compiler für CP/M-80 gab's ab $49.95 (basierend auf dem Small-C-Compiler von 1980, Mindestanforderungen: 8080er, 48 kiB RAM und Floppy, einen Cobol-Compiler gab's im Sonderangebot für $29.95...) https://archive.org/stream/byte-magazine-1983-08/1983_08_BYTE_08-08_The_C_Language#page/n127/mode/2up
:
Bearbeitet durch User
Peter Hofbauer schrieb: > Ich werde mich jetzt mal überwinden und mir GCC reinziehen, allen > Abneigungen zum Trotz. Das solltest Du tun. Dann wirst Du schnell merken, daß man Assembler wirklich kaum noch braucht. Ich habe diverse Steuerungen in C mit 8051 oder AVR programmiert, aber die CPU-Geschwindigkeit war nie ein Problem. Oftmals laufen die AVRs mit der Werkseinstellung 8MHz / 8 = 1MHz. Mein I2C-Sniffer schafft nur 230400 Baud bei 14.7456MHz Takt. Liegt aber daran, daß der ATtiny85 keine HW-UART hat, ich muß also zu Fuß die Bits basteln. Aber mit HW-UART nichtmal 115200Baud zu schaffen, das glaub ich Dir einfach nicht. Das sind elendig lange 160 Zyklen je Byte, läßt Du den C-Compiler im UART-Interrupt etwa noch Schach spielen?
Arc Net schrieb: > Micral N ab Januar 1973 für damals umgerechnet 1300 USD Und auf dem Ding soll ein C-Compiler ausführbar gewesen sein?
Brüder Grimm schrieb: > Glaubt ihr immer noch an das Märchen, daß ihr mit Assembler schnelleren > Code zusammengefriemelt bekommt, als ein C-Compiler? > > Träumt weiter. Jaaaaa!!! Wenn ich in Assembler einen Code schreibe, in dem es keinen überflüssigen Befehl gibt, dann kann es C natürlich auch nicht besser. Gelegentlich habe ich den von C generierten Code mit Assembler-Code verglichen. In den meisten Fällen war der aus C erzeugte Code nicht gleichlang, sondern länger. Bei meiner letzten absolut zeitkritischen Anwendung habe ich mehrere Schnittstellen (2 x SSI-Slave, 2 x UART mit hoher Datenrate und eine selbst definierte synchrone serielle Schnittstelle) von einem 8-Bit-µC mittels priorisiertem Interrupt gleichzeitig bedient. Ich glaube nicht, dass ich es auch in C hinbekommen hätte.
Jochen Tesch schrieb: > Gelegentlich habe ich den von C generierten Code mit Assembler-Code > verglichen. In den meisten Fällen war der aus C erzeugte Code nicht > gleichlang, sondern länger. Bisher war es IMMER so: Jemand kommt voller Empörung an und zeigt seinen C-Code und den dazugehörigen ASM-Code (vom GCC erzeugt). Dabei präsentiert er einen kürzeren ASM Code und moniert, der Compiler wäre ja blöd. Nach kurzer Analyse stellt er dann fest, oh, sein ASM Code hat diverse Randbedingungen nicht erfasst. Egal, umschreiben, nochmal meckern. Gleiches Spiel, geht nicht in 100% aller Fälle. Das Ende vom Lied: Der GCC hat wohl doch den optimalen ASM Code erzeugt. UND hätte ers selber in ASM gemacht, hätte er sich noch den Code verbuggt und das wahrscheinlich lange ohne es zu merken. Bring doch auch mal ein Beispiel wo der GCC angeblich so schlecht arbeitet und DU besser bist. gruß cyblord
cyblord ---- schrieb: > Bring doch auch mal ein Beispiel wo der GCC angeblich so schlecht > arbeitet und DU besser bist. Die Applikation dazu habe ich genannt.
Das hier? > Bei meiner letzten absolut zeitkritischen Anwendung habe ich mehrere > Schnittstellen (2 x SSI-Slave, 2 x UART mit hoher Datenrate und eine > selbst definierte synchrone serielle Schnittstelle) von einem 8-Bit-µC > mittels priorisiertem Interrupt gleichzeitig bedient. Warum sollte das in C nicht gehen, bzw. schlechter sein als dein ASM? Begründung? > Ich glaube nicht, > dass ich es auch in C hinbekommen hätte. Hört sich weniger nach Unzulänglichkeiten beim Compiler an. Außerdem, selbst WENN es kurze Passage gäbe, wo man ASM unbedingt braucht, spricht trotzdem nichts dagegen, den Rest in C zu machen. ASM wo unbedingt nötig schreibt jeder C-Programmierer ebenfalls gerne. Aber ich sehe nur Geschichten und Vermutungen. code or it didn't happen
:
Bearbeitet durch User
cyblord ---- schrieb: > Warum sollte das in C nicht gehen, bzw. schlechter sein als dein ASM? Die Antwort hast Du Dir doch selbst gegeben. Ein C-Compiler fragt viele Randbedingungen ab, auch die, die nie relevant werden können. Bei einer Applikation, wo es wirklich auf jede (!) Bit-Zeit ankommt, sollten natürlich nur die wirklich relevanten Randbedingungen berücksichtigt werden. Mittels Assembler kann ich das selbst entscheiden und so einen schnelleren Code erzeugen.
Rufus Τ. Firefly schrieb: > Arc Net schrieb: >> Micral N ab Januar 1973 für damals umgerechnet 1300 USD > > Und auf dem Ding soll ein C-Compiler ausführbar gewesen sein? Da ging's mir eher um die bezahlbaren Computer... Aber gut. Auf dem wahrscheinlich nicht, aber auf dessen Nachfolger aus dem Jahr 1975 mit 8080 sollte das möglich gewesen sein Laut http://www.retrotechnology.com/dri/isis.txt soll es in dem Zeitrahmen einen PL/M-Compiler (CP/M 80) gegeben haben, der auf 8080ern lief. Einen C-Compiler der mit 32 kiB RAM auskam, gab's ab 1979 für Z80/8080 http://www.bdsoft.com/resources/bdsc.html ob es noch frühere C-Compiler für diese Systeme gab entzieht sich meiner Kenntnis.
Brüder Grimm schrieb: > Glaubt ihr immer noch an das Märchen, daß ihr mit Assembler > schnelleren > Code zusammengefriemelt bekommt, als ein C-Compiler? > > Träumt weiter. Das ist weder ein Märchen noch ein Traum, sondern gelebte Realität. Schaust du z.B. einfach mal in die Quelltexte des des AVR-GCC. Da findest du sehr viele Beispiele, bei denen schon die von ihrem Produkt überzeugten notorischen C-ler keinen anderen Ausweg wußten, als auf Asm zurückzufallen, um eine zumindest akzeptable Performance zu erreichen... Und glaube ja nicht, daß das bei anderen Architekturen besser wäre. Abseits vom Mainstream (im Wesentlichen x86 und ARM) sind die Nachteile der Compiler noch sehr viel größer, weil sich dort kaum wer die Arbeit macht, solche plattformspezifischen Asm-Optimierungen zu schaffen und in den Compiler zu integrieren. Da wird immer nur das Allernötigste gemacht, damit der Rotz überhaupt an's Laufen kommt und Leute wie du ihren unterirdischen Müll überhaupt produzieren können. Oder du mußt eine Menge Kohle für kommerzielle Compiler bezahlen. Die Kohle gibst du da im Wesentlichen für, tätärä, Asm-optimierte Libs aus, die die Performance auf dem Zielsystem ganz offensichtlich massiv verbessern können...
c-hater schrieb: > Die > Kohle gibst du da im Wesentlichen für, tätärä, Asm-optimierte Libs aus, > die die Performance auf dem Zielsystem ganz offensichtlich massiv > verbessern können... Genau das ist es bei C. Die guten Libs bekommt man mit einem teueren Kauf-Compiler, die Freeware-Dinger wie SDCC haben das nicht drin, muß man selber nach arbeiten, wenn man will. SDCC: Unterstützt z.B. für den 80C517A keine multiple Datapointer, was für z.B. memcpy() ausgezeichnet wäre. Auch nicht die MDU, die sogar für Floating Point optimiert ist, und bis zum Faktor 100 schneller rechnen kann als Standard-8051. Nur ein teuerer z.B. Keil-Compiler macht das, Ready-to-Use. Und nur in der Vollversion, bei denen fehlen glaube ich in der Demoversion die Floating-Point-Libs.
@c-hater: Dann schreib doch weiter Basic. Mann Du gehst mir mit Deinem ständigem wiederkäuenden Gesabbel bei jeder Gelegenheit auf die Eier. Gruß, Holm
Interessanterweise sprechen die gegen C vorgebrachten Argumente doch zugleich für C.
Mich überzeugt der ASM-Hang keineswegs. Neben der Taktrate von 20MHz hat der AVR ja auch einen Taktteiler, den man auf 1 reduzieren könnte. Mit Round-Robbin oder preemptiven Strategien (in C) eine große Zahl von Schnittstellen abfragen, deren Taktrate ein Bruchteil der Prozessorrate ist, halte ich für keine Kunst. Allerdings bin ich mir darüber im Klaren, wenn man lange genug in die ASM-Datei hineinschaut, sie irgendwann auf einen zurückblickt. (Vulgo: wenn man nur die eine Lösung anerkennt, findet man gegen jede passende Argumente. So gibt es keinen Grund, die eklatanten Fehlentscheidungen der existierenden Compiler im Rahmen von quelloffenen Projekten zu beheben, d.h. die Zeit nicht mit tippen hier im Forum sondern offensichtlichem Bug Fixing in gcc o.ä zu verbringen.)
Wilhelm F. schrieb: > SDCC: Unterstützt z.B. für den 80C517A keine multiple Datapointer, was > für z.B. memcpy() ausgezeichnet wäre. Hast Du mal nachgerechnet, was das wirklich ausmacht? Diese Umschalterei kostet nämlich auch Zeit. Ich hatte früher mal ne Kopierroutine mit 2 Pointern ohne Umschaltung benutzt, die ist wirklich schneller. Ein Pointer ist DPTR und der andere ist P2,R0. Außerdem gilt das nur für langsamen XDATA, da kommt es auf einen Zyklus mehr oder weniger eh nicht an. Dieser 80C517 muß früher mal sehr teuer gewesen sein. Ich hab ihn in keinem kommerziellen Produkt finden können. Da waren immer nur normale 80C31 drin bzw. später 89C51. Daher wundert es mich garnicht, daß die SDCC-Leute seine speziellen Bells and Whistles nicht unterstützen. Der 80C517 war wohl ein reiner Lern-MC und daher nur auf Eval-Boards drauf.
Peter Dannegger schrieb: > Dieser 80C517 muß früher mal sehr teuer gewesen sein. War er, in einer alten Elektor von 1993 ist er mit 44.95DM gelistet. der kleinerer 80c535 mit 29.95DM 80C31 war da schon mit 5.48DM zu haben.
markusDerBastler schrieb: > Antwort: Weil er mit ATmega programmiert. Ich kann auch mit einem Hammer Schrauben rausdrehen. Das ist aber kein Argument. > Und weil der ATmega sauschnell ist. Offensichtlich ja nicht. > Und wenn mir die Programmiersprache die Performance verhunzt, ändere ich > nicht den Prozessor sondern die Sprache. Das müsste erst einmal bewiesen werden. Wer sagt, dass er einfach keinen effizienten C-Code auf die Reihe kriegt? > Und weil zwischen STM und AVR ein himmelweiter Unterschied ist. Himmelweit wäre übertrieben. > Und weil für Hobbybastler der STM monatelange Einarbeitung erfordert. Das kann ich nicht bestätigen. Die Peripheral Library kann schon sehr viel und wird in Zukunft noch bedienungsfreundlicher. > Und weil der 100mal komplizierter ist. Nicht wirklich. > Und wer hier was gegenteiliges behauptet, der lügt! Troll. Peter Hofbauer schrieb: > Einige wollten mal ein Beispiel über zeitkritische Anwendungen. > Ok, jetzt mal ein paar Beispiele aus meiner Praxis. Ich fange mal mit > den ersten Versuch eines Umstiegs auf C an. Kleinste Deatils verschweige > ich hier mal, das wird sonst zu lang. Also entweder sind das alles Legacy-Anwendungen (dann sind solche Tricks durchaus nachvollziehbar) oder der Hardwareentwickler hat gepfuscht, weil er auf uralten Kram gesetzt hat, der in keinster Weise der Anwendung angemessen ist. Die Softwarekomplexität sinkt gewaltig, wenn man intelligent die vorhandene Hardware verwendet. 8 serielle Schnittstellen kriegt man heutzutage locker in unter 100 Codezeilen unter. Womit wir beim Punkt wären: Für Uralt-Architekturen entwickelt keiner mehr etwas, es ist viel, viel einfacher, eine moderne Architektur mit bewährten Werkzeugen zu nutzen. Deshalb wird es eine solche Entwicklungsumgebung auch sicher nie geben. Es sei denn die vereinte 8051er-Fangemeinschaft rafft sich zusammen und entwickelt endlich das Tool, das sie alle so dringend benötigen.
Peter Dannegger schrieb: > Wilhelm F. schrieb: >> SDCC: Unterstützt z.B. für den 80C517A keine multiple Datapointer, was >> für z.B. memcpy() ausgezeichnet wäre. > > Hast Du mal nachgerechnet, was das wirklich ausmacht? > Diese Umschalterei kostet nämlich auch Zeit. > Ich hatte früher mal ne Kopierroutine mit 2 Pointern ohne Umschaltung > benutzt, die ist wirklich schneller. Ein Pointer ist DPTR und der andere > ist P2,R0. > Außerdem gilt das nur für langsamen XDATA, da kommt es auf einen Zyklus > mehr oder weniger eh nicht an. Ich machte da mit den 8 Datapointern mal was direkt in ASM, FIFOs für den UART, und das fluppte so richtig. Ob ich die MDU noch mal in Angriff nehme, und Libraries anpasse, weiß ich nicht. Ich könnte es, wenn ich wollte. Helmut Lenzen schrieb: > War er, in einer alten Elektor von 1993 ist er mit 44.95DM gelistet. > der kleinerer 80c535 mit 29.95DM Der letzte 80C517A kostete mich 1999 bei Segor 47 DM. Die 80C515A bei Holz Elektronik 1993 aber auch so viel. Versender wie Reichelt hatten auch meistens nicht diese A-Typen. > 80C31 war da schon mit 5.48DM zu haben. Standard-8031 NMOS beim Schuricht 1992: 5 DM. Das war aber auch OK, weil das das Sprungbrett für mich überhaupt zum Einstieg in µC war.
cyblord schrieb: >Bisher war es IMMER so: Jemand kommt voller Empörung an und zeigt seinen >C-Code und den dazugehörigen ASM-Code (vom GCC erzeugt). >[] darum geht es überhaupt nicht Assembler ist immer kürzer als C allerdings mit 90% Wahrscheinlichkeit eben auch verbugt da hast du recht. Vergleiche mal GCC Code mit dem Code eines komerziellen Compilers dann siehst du gewaltige Unterschiede. Ich habe schon Projekte in SDCC und mit Keil gemacht (gleicher Code bis auf die Compilerspez. Unterschiede) da sind Größendifferenzen von 30% normal. Die Codeefizienz ist bei kommerziellen Produkten deutlich besser. Muss auch so sein sonst würde das ja niemand kaufen. Übrigens war beim Keil zwischen den Uralt DOS Versionen und den neuen µVision Versionen nur marginal was den Code anging. Peter Dannegger schrieb: >Der 80C517 war wohl ein reiner Lern-MC und daher nur auf Eval-Boards >drauf. och ich kenne einige komerziellen Maschinensteuerungen wo die Teile verbaut waren. 100er Preis war Anfang 90 so um die 18DM netto Problem bei Siemens war eher die nicht zu kalkulierende Lieferzeit weshalb die überall rausgeflogen sind und weil Sie bald 15 Jahre der Meinung waren dass Flash in MCUs Teufelszeug ist. Das war meiner Meinung nach auch der Grund warum die C166er nie erfolgreich war. Thomas
> Ich habe schon Projekte in SDCC und >mit Keil gemacht (gleicher Code bis auf die Compilerspez. Unterschiede) >da sind Größendifferenzen von 30% normal. Toller vergleich, ich dachte es geht um GCC? Auf AVR und ARM ist der Unterschied zwischen Keil und GCC nicht groß, wenn er überhaupt da ist.
>Auf AVR und ARM ist der Unterschied zwischen Keil und GCC nicht groß, >wenn er überhaupt da ist. das ist wahr es gibt gar keinen AVR Compiler von Keil Schon beim ARM sieht es ganz anders aus... Arm hat keil nicht umsonst gekauft. Die GCC Editionen von Keil wurden nicht mehr gepflegt. Mir ging es generell auch nicht um GCC oder Keil oder andere sondern einfach um den Unterschied zwischen komerziellen Compilern und Free Compiler. Thomas
> das ist wahr es gibt gar keinen AVR Compiler von Keil > Schon beim ARM sieht es ganz anders aus... > Arm hat keil nicht umsonst gekauft. Die GCC Editionen von Keil wurden > nicht mehr gepflegt. > Mir ging es generell auch nicht um GCC oder Keil oder andere sondern > einfach um den Unterschied zwischen komerziellen Compilern und Free > Compiler. > > Thomas ja, GCC ist ein wirklich guter Compiler, der auch kommerziell gepflegt wird. Und das gilt für AVR, x86 ARM uvm. Die Mär vom kostenlosen Billigcompiler ist wirklich Unsinn.
SDCC ist weder ein besonders gut optimierender C-Compiler, noch sind die von ihm unterstützten Architekturen besonders gut für Hochsprachen geeignet. Das steht sogar in der Dokumentation von dem drin! SDCC als Maßstab für "C ist scheiße" zu benutzen, ist schlicht unfair - besonders, da diese Vergleiche dann oft von Leuten kommen, die jahrelange Erfahrung mit Assembler auf genau dieser Architektur haben. Vernünftige Vergleiche bekommt man nur unter vernünftigen Bedingungen. Aber die wollen die Assembler-Verfechter ja nicht, es könnte ja das falsche Ergebnis rauskommen...
fondue schrieb: > ja, GCC ist ein wirklich guter Compiler, der auch kommerziell gepflegt > wird. Und das gilt für AVR, x86 ARM uvm. Die Mär vom kostenlosen > Billigcompiler ist wirklich Unsinn. Der Unterschied zwischen Löhnware und Freeware liegt mehr in den Libraries als im Compiler. In einem kleinen Programm bei Freeware für ARM hat man schnell mal die halbe Newlib an der Backe und die ist nicht wirklich platzsparend konzipiert. Da kommen dann krasse Grössenunterschiede im resultierenden Programm zustande. Nimmt man als Referenz jedoch statt Newlib beispielsweise die ebenfalls auf GCC basierende kommerzielle Entwicklungsumgebung Rowley Crossworks, dann sieht das schon ziemlich anders aus.
Einen neuen Compiler zu schreiben ist nicht so einfach.Das braucht Jahre und viele Fachkenntnise.
Fachmann schrieb: > Einen neuen Compiler zu schreiben ist nicht so einfach.Das braucht Jahre > und viele Fachkenntnise. Korrekt. Ein Betriebssystem auch nicht, und trotzdem hat jeder Haushalt inzwischen mehr Systeme mit Linux als mit dem kommerziellen Windows. Linux wird mit GCC compiliert.
Es gibt schon einige nicht kommerzielle Compiler, JAL zum Beispiel. Aber offensichtlich ist er noch nicht ausgereift obwohl es ihn seit Jahren wenn nicht Jahrzehnten gibt. Daran kann man sehen, dass es nicht so einfach ist.
Thread beobachten
Seitenaufteilung abschalten