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
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.
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
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!
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.
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
>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.
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
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
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.
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.
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.
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?
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.
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 EinsteigerLPC1xxx für Umsteiger
Hier ein Beispiel für eine kostenlose IDE:
STM32 CooCox Installation
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
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
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?
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
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
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.
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