Hallo, was für Argumente sprechen dafür einen Keil oder IAR Compiler zu verwenden, anstatt einem kostenlosen GCC. Im Speziellen würde mich GCC für ARM für Industrieelektronik interessieren. Lors
Lors42 schrieb: > was für Argumente sprechen dafür einen Keil oder IAR Compiler zu > verwenden, anstatt einem kostenlosen GCC. Vermutlich fragst du im GCC-Forum da die falschen Leute. ;-) Hier sind ja die versammelt, die eher nicht einen Keil oder IAR benutzen.
Lors42 schrieb: > was für Argumente sprechen dafür einen Keil oder IAR Compiler zu > verwenden, anstatt einem kostenlosen GCC. ^^^^^^^^^^^ Was nun aber der Keil oder der IAR macht oder kann, was der GCC nicht kann, kann ich nicht sagen. Würde mich aber auch mal interessieren. Ingo
Lors42 schrieb: > was für Argumente sprechen dafür einen Keil oder IAR Compiler zu > verwenden, anstatt einem kostenlosen GCC. Jeder Compiler enthält Fehler. Die Wartung eines Compilers ist eine nicht ganz triviale Arbeit, und die läßt sich der Hersteller des kommerziellen Compilers via Lizenzgebühr bezahlen. Bernhard
Ingo schrieb: > Was nun aber der Keil oder der IAR macht oder kann, was der GCC nicht > kann, kann ich nicht sagen. Würde mich aber auch mal interessieren. Keil erzeugt zumindest effizientern Bincode als GCC. 10-20% weiniger sind je nach den verwendeten Funktionen schon drin. Kann bei größeren Geräte-Stückzahlen, wo jedes Byte weniger Kosteneinsparung bedeuten kann, von Bedeutung sein. In der Industrie führt an Keil kaum ein Weg vorbei.
>Vermutlich fragst du im GCC-Forum da die falschen Leute. ;-) Hier >sind ja die versammelt, die eher nicht einen Keil oder IAR >benutzen. Gibt halt ein GCC Forum und kein KEIL-Forum. ;) Ich selbst arbeite privat mit GCC (STM32F3 von Olimex, Olimex-Jtag, Linux, OpenOCD, CodeSourcery) Hat mich viel Nerven und ein Wochenende gekostet , bis die Toolchain endlich lief. Aber jetzt finde ich es recht passabel, damit zu arbeiten. Ob der Code 20k oder 30k hat, ist mir dabei fast egal. Eher vielleicht, ob es guten Beispielcode oder Libs gibt. Lors
Matthias K. schrieb: > Keil erzeugt zumindest effizientern Bincode als GCC. So pauschal würde ich diese Aussage nicht stehen lassen. Mag vielleicht für einen AVR gelten, schon beim ARM würde ich das anzweifeln.
Jörg Wunsch schrieb: > schon beim ARM würde ich das anzweifeln. Das gilt aus meiner Erfahrung für ARM und 8051er. Mit AVR gibt Keil sich nicht ab. Da fehlt die breite Anwendung in der Industrie. (Ich will nichts gegen AVR sagen, die benutze ich auch gern.) Mein 20 Jahre alter DOS C-Compiler von Keil für die 8051er liefert noch heute Bincode, welcher kürzer und schneller ist als der in der aktuellen Version von SDCC. Lors42 schrieb: > Aber jetzt finde ich es recht passabel, damit zu arbeiten. Ob der Code > 20k oder 30k hat, ist mir dabei fast egal. Das gilt nur im Hobbybereich. Wenn Du Geld durch Serienfertigung in hohen Stückzahlen verdienen willst, kostet jedes Byte RAM oder FLASH zuviel zusätzliches Geld.
Matthias K. schrieb: > Mein 20 Jahre alter > DOS C-Compiler von Keil für die 8051er liefert noch heute Bincode, > welcher kürzer und schneller ist als der in der aktuellen Version von > SDCC. SDCC ist auch kein Vergleich. Nichts gegen das Teil, GCC würde sich mit so einer Krücke wie MCS51 gar nicht abgeben, aber die beiden kann man (auch von der dahinter stehenden manpower) in keiner Weise vergleichen. Ich bin ansonsten Keil-geschädigt. Ich habe mal ein, zwei Tage herumdebuggen müssen (mit einem hundsmiserablen Debugger unter OS/9), weil der Keil-Compiler zu blöd war, Variablen, die in einem geschachtelten Block angelegt worden sind, beim Verlassen des Blocks wieder vom Stack abzuräumen. Einen derart elementaren Fehler vergisst man so schnell nicht.
Lors42 schrieb: > was für Argumente sprechen dafür einen Keil oder IAR Compiler zu > verwenden, anstatt einem kostenlosen GCC. Garantierter Support und entsprechende (möglicherweise auch sinnfreie) Vorgaben der Zertifizierung. Z.B. im Automotive-Bereich darf man keinen Gcc verwenden, wenn man eine bestimmte Zertifizierung für die Software erlangen möchte.
Floh schrieb: > im Automotive-Bereich darf man keinen Gcc verwenden, wenn man eine > bestimmte Zertifizierung für die Software erlangen möchte Das geht schon, Du musst nur selbst den Compiler zertifizieren.
Jörg Wunsch schrieb: > Krücke wie MCS51 Die 8051er sind nach wie vor die Arbeitstiere in der Industrie. Die Nachteile der Architektur konnten sie bis heute nicht vom Markt verdrängen. Im Gegenteil, es kommen ständig neue Typen dazu. 100MMIPS sind drin. Ein Grund ist auch, dass die Projekt-Entscheider, selbst verantwortliche Kaufleute, mit den Begriff 8051 was anfangen können. Da kommt immer das Argument der Ersetzbarkeit durch kompatible Typen im Falle eines Lieferengpasses, was natürlich nur für die kaum noch eingesetzten Ur-Typen gilt.
Profi schrieb: > Das geht schon, Du musst nur selbst den Compiler zertifizieren. Wie soll das gehen? Du findest keinen, der dafür die Verantwortung übernimmt.
Matthias K. schrieb: > Ein Grund ist auch, dass die Projekt-Entscheider, selbst verantwortliche > Kaufleute, mit den Begriff 8051 was anfangen können. Da kommt immer das > Argument der Ersetzbarkeit durch kompatible Typen im Falle eines > Lieferengpasses Das liegt eher daran, dass die Firmen in Toolchains und teueren Debugkram investiert haben. Das ganze unterliegt regelmäßigen Updates und man scheut natürlich investitionen in etwas Neues. Was kostet ein vollwertiger Arbeitsplatz?
Profi schrieb: > Das liegt eher daran, dass die Firmen in Toolchains und teueren > Debugkram investiert haben. Das ganze unterliegt regelmäßigen Updates > und man scheut natürlich investitionen in etwas Neues. Das stimmt auch. Die langjährige Firmen-Erfahrung mit bestimmten µC-Familien ist ein wichtiges Argument. Das weiß Keil und Co. natürlich auch, ebenso die µC-Hersteller. Warum sollte man funktionierende Strukturen gegen andere, gleichwertig funktionierende Strukturen umstellen? Da blieben unter dem Strich nur Zusatzkosten.
Floh schrieb: > Garantierter Support Das ist auch ein Traum...... Wir hatten vor nicht all zu langer Zeit mehrere IAR-Compiler für NEC-V850 gekauft. Die alten Versionen waren aus dem Support, Update Preis ca. Neupreis, da kauft man halt neu. Hat man versucht alte Projhekte zu übersetzen gab es eine "bulescreen". d.h. diese Version war völlig unbrauchbar. Der Saftladen hat dann 6 Monate für den Bugfix gebraucht und auch erst dann nach dem wir unser Geld zurück haben wollten. Für die ARM Projekte habe ich dann gar nichts mehr von IAR gekauft. Wegen Mondpreisen und Lizensierungs (Dongle, Registrierung) Schwachsinn. Ich empfehle für AVR und ARM Rowley Crossworks. Das kostet einen Bruchteil von IAR und Keil. Funzt perfekt (bis jetzt). Hat einen super Support. Die Lizenz kann mehrfach installiert werden. Auf dem Arbeitsplatz, einem Laptop, dem Homeoffice und einem Testsystem. Die Lizenz für die Firma kostet 1200€ für den Privatman 100€ was will man mehr......
Matthias K. schrieb: >> Krücke wie MCS51 > > Die 8051er sind nach wie vor die Arbeitstiere in der Industrie. Ja, aber compilermäßig ist das Ding halt so krückig, dass man wohl wirklich entweder sehr viel Enthusiasmus haben oder ausreichend Geld bekommen muss, um sich das anzutun, dafür einen Compiler zu bauen und zu pflegen. Für die AVRs hat schon kurze Zeit nach der Markteinführung (da waren die Teile bei weitem nicht so bekannt wie heute), Denis Chertykov eine GCC-Portierung angefangen. (Atmel hatte sich damals überhaupt nicht dafür interessiert, die haben da voll und ganz an IAR geklebt.) Dazu sollte man noch wissen, dass GCC in seinem Selbstverständnis ursprünglich nur für 32-bit-CPUs (und später natürlich auch 64) konzipiert war, d. h. eine Portierung für eine 8-/16-bit-CPU war ganz sicher eine Herausforderung. Für den MCS51 ist das bis heute noch nicht passiert, und ich finde es reichlich unwahrscheinlich, dass es je passieren wird.
Matthias K. schrieb: > Wie soll das gehen? Du findest keinen, der dafür die Verantwortung > übernimmt. Trägst nicht die Verantwortung für Deine Handlungen? Genauso wie ich selbst geschriebene Software zertifizieren kann, kann ich Tools zertifizieren. Ich sage nicht, dass es sich für jeden lohnt.
Jörg Wunsch schrieb: > Ich bin ansonsten Keil-geschädigt. Ich habe mal ein, zwei Tage > herumdebuggen müssen (mit einem hundsmiserablen Debugger unter OS/9), Bist du sicher, dass du den gleichen Keil meinst? Der Deutschland- Distributor für OS-9 hieß ebenfalls Keil, nur mit einem Dr. davor. Die Firma existiert m.W. nicht mehr und hat nichts mit der Fa. Keil zu tun, die C-Compiler für 8051-, C16x- und ARM-Controller herstellt und mitt- lerweile zu ARM Inc. gehört (www.keil.com).
Profi schrieb: > Trägst nicht die Verantwortung für Deine Handlungen? vollständig: Trägst Du selbst nicht die Verantwortung für Deine Handlungen?
Yalu X. schrieb: > Bist du sicher, dass du den gleichen Keil meinst? Nö, wohl nicht. Pech für die Münchner Firma Keil, dass ihre Aachener Namensvettern so einen miesen Eindruck hinterlassen haben. ;-) Im Ernst: ich habe mit Keil so und so nicht viel zu tun.
Jörg Wunsch schrieb: > ich habe mit Keil so und so nicht viel zu tun Dann schmeiss einmal einen Blick auf deren homepage. Die heissen heute ARM und die kennst Du bestimmt.
Jörg Wunsch schrieb: > Pech für die Münchner Firma Keil, dass ihre Aachener Namensvettern so > einen miesen Eindruck hinterlassen haben. ;-) Ich glaube, die waren auch nicht in Aachen, sondern irgendwo in Baden-Württemberg ;-) Und die Software selbst kam ja von Microware aus dem Amiland. Aber den besten Eindruck hat damals (das ist jetzt schon etliche Jahre her) auch der 8051-C-Compiler der anderen Fa. Keil (um die es in diesem Thread geht) nicht auf mich gemacht. So hat der Compiler bspw. gemeint, in folgendem Konstrukt
1 | int main(void) { |
2 | ...
|
3 | for(;;) { |
4 | ...
|
5 | for(i=0; i<n; i++) { |
6 | ...
|
7 | }
|
8 | }
|
9 | return 0; |
10 | }
|
(das ja für Mikrocontrolleranwendungen nicht untypisch ist) die äußere Schleife wegoptimieren zu können, so dass nur noch
1 | int main(void) { |
2 | ...
|
3 | for(i=0; i<n; i++) { |
4 | ...
|
5 | }
|
6 | return 0; |
7 | }
|
übrig blieb, was dem Programm natürlich ein schnelles Ende bereitete. Der Workaround:
1 | int always_true = 1; /* muss global sein */ |
2 | |
3 | int main(void) { |
4 | ...
|
5 | while(always_true) { |
6 | ...
|
7 | for(i=0; i<n; i++) { |
8 | ...
|
9 | }
|
10 | }
|
11 | return 0; |
12 | }
|
Das Konkurrenzprodukt kam von der Fa. Tasking (heute Altium). Wenn man aber in Erfahrung bringen wollte, welches der beiden Produkte nun das bessere ist, und dazu Kollegen in anderen Firmen fragte, warum sie den Compiler von Keil (Tasking) benutzen, war die Antwort, dass der Compiler zwar nicht viel tauge, der von Tasking (Keil) noch schlechter sei :) Ich gehe natürlich davon aus, dass inzwischen beide Hersteller ihre Bugs gefixt haben.
Yalu X. schrieb: > Ich gehe natürlich davon aus, dass inzwischen beide Hersteller ihre Bugs > gefixt haben. Bill Gates hat mit DOS angefangen. Und heute ...
Profi schrieb: > Die heissen heute > ARM und die kennst Du bestimmt. Sie sind von ARM gekauft worden, machen aber nach wie vor dasselbe wie zuvor. Da sie das außerdem nur für Betriebssysteme machen, die ich weder habe noch haben möchte, habe ich mit denen nichts zu tun. Yalu X. schrieb: > Ich glaube, die waren auch nicht in Aachen Zumindest war ich gemeinsam mit einem Kollegen dazumals mal in Aachen, um der Firma (Dr. Keil) einen Besuch abzustatten. Ist aber nun auch schon über 20 Jahre her. OS-9 habe ich hernach nie wieder gemacht, denn die seinerzeitigen Systeme wurden dann durch DG-UX abgelöst (welches heute auch keiner mehr kennt ;).
Vielleicht erstmal kurz sortieren: - Es wurde nach den Compilern gefragt, also nicht nach der Enwicklungsumgebung und nicht nach "Debugzeugs". Es sind also die Werkzeuge zur Codeerzeugung zu vergleichen, die da wären: der (C-)Compiler selbst, der Assembler, der Linker und auch die Laufzeitbibliotheken (C-Library, Compilerlibrary analog libgcc) - Wie schon angemerkt: von Keil werden Compiler für MC51 und ARM angeboten, von IAR gibt es Compiler für fast alles was Beinchen hat, GCC gibt es nicht für MC51. Bleiben zum Vergleich die Compiler für Controller mit von ARM entwickelten Kernen. War wohl auch Hintergrund der ursprünglichen Frage. - Keil wurde von ARM gekauft (übernommen?). Der MC51-Compiler ist meines Wissens ein eigentständiges Produkt, im Hintergrund der Keil-IDE für ARM (MDKARM) arbeitet die Toolchain der Firma ARM (RealView-Tools). Vor langer Zeit gab es von Keil noch einen eigenen ARM-Compiler aber der ist inzwischen lange tot. - Man kann auch für GCC Support kaufen. Insbesondere für ARM-targets sei die Firma Codesourcery genannt. Die Leute dort kennen sich wirklich gut aus, man kann sich selbst davon überzeugen: einfach in den Changlogs und Bugtrackern im Umfeld der GNU-Tools (gcc, binutils, newlib (nicht GNU)) nach codesourcery E-Mail-Adressen suchen. ARM hatte Codesourery auch dafür bezahlt, sich um die GNU Tools zu kümmern. Wie das nach der Übernahme von Codesourcery durch Mentor Graphics aussieht, weiss sich nicht. "Subscription" von vorkompilierten GNU-Tools mit Support werden allerdinges weiterhin angeboten. - ARM unterstützt die GNU-Tools inzwischen auch sehr direkt, nicht mehr nur "indirekt" duch Codesourcery. Es gibt vorkompilierte Toolchains, in denen auch Änderungen zurückportiert wurden - sehr ähnlich der Arbeitweise von CS, wobei CS jedoch auch oft Erweiterungen eingebaut hatte, die noch nicht "upstream" weitergereicht wurden, also noch nicht in den Quellen von GNU verfügbar waren (z.B. ehedem der ARMv7/thumb2-Support, inzwischen lange in den offziellen Quellen enthalten). Zitat von launchpad.net für das Unterprojekt gcc-arm-embedded: "[...]ARM is maintaining a GCC toolchain source branch targeted at Embedded ARM Processors[...]". Mehr oder weniger subjektive Einschätzungen nach einigem, was ich mit den verschiedenen Compilern für Controller mit ARM-Kernen gemacht habe. Dabei sehr wenig mit dem IAR-Compiler, wenig mit ARM/Keil-Realview und einiges mit arm-gcc. Dabei auch gelegentlich Code für Realview oder IAR-ICCARM nach GNU portiert, um Teile in eigenen Entwicklungen zu verwenden: Die Compiler für ARM sind in Bezug auf erzeugte Codegröße und "schnellen" Code alle brauchbar. Man findet im Netz ein paar Vergleiche, die aber meist recht alt sind. Ganz lustig war ein Vergleich, den Keil lange vor der Übernahme durch ARM auf deren Webseite verbreitet hatte, in dem die damalige Version des GCC mit dem damals noch verfügbaren Keil ARM-Compiler in Bezug auf Codegröße verglichen wurde. GCC kam schlecht weg, was daran lag, dass der Compiler von Keil mit den optimalen Einstellungen genutzt wurde, der GNU C-Compiler aber mit Standardeinstellungen. Im Netz sollte man auch noch den Gegenvergleich finden, bei dem herauskam, dass die Unterschiede bei Weitem nicht so gross waren. O.K., der alte Keil-ARM Compiler ist Schnee von vorgestern und die GNU-Tools werden auch stetig weiterenwickelt aber man kann festhalten, dass Vergleiche nur so gut sind, die die Kenntnisse der Leute über die Nutzung der jeweiligen Toolchain. Die ARM Compiler von ARM/Keil und IAR bieten ein paar Erweiterungen, die es zum Teil im C-Compiler GNU-Compiler-Collection nicht gibt. Beim Portieren von Code stolpert man gelegentlich darüber. Bleibt man immer bei einer Toolchain, sind diese Merkmale eher Nebensache. Insbesondere die relativ einfache Syntax um bei Realview und ICCARM Variablen an bestimmten Speicheraddressen zu fixieren (@, AT) gibt es m.W. im gcc-arm nicht. Was aber nicht heisst, dass es vom Prinzip her nicht geht. Man muss sich allerdings mit dem Linker, input- und output-sections etwas auskennen und gegebenfalls etwas "Makro-Magic" einbauen, was nicht ganz trivial ist. Ob feste Bindung von Variablen an Speicheraddressen guter Programmierstil ist, sei dahingestellt. Bei IAR werden wohl traditionell, d.h, weil es wahrscheinlich auch bei anderen Architekuren oft gemacht wird, Bitfelder auf Hardwareregister gemappt (u.a. mit der o.g. Erweiterung). Das war bis vor kurzem mit dem gcc nicht möglich (insbes. bei ARMv4). War auch nicht weiter dramatisch, da man mit direkten Bitmanipulationen und evtl. einem Satz Makros die gleiche Funktionalität erreichen konnte - wenn auch nicht ganz so "schick" anzuschauen. War beim Portieren von Code immer einiges an Arbeit. Inzwischen bieter der gcc diese Funktion auch ("volatile bitfields"). Wird wohl so auch von ARM gefordert. Auch hier sei dahingestellt, ob das so guter Programmierstil ist. Habe die Erweiterung selbst auch noch nicht ausprobiert, daher auch keine belastbare Aussage. Größere Unterschiede gibt es in den Laufzeitbibliotheken. Besonders die Codegröße von stdio-Funktionen wie f|sprintf u.ä. sind bei der im Umfeld von arm-gcc oft verwendeten newlib (das ist eine libc) ist im Vergleich zum Realview und IAR recht gross. Das ist auch ein Grund warum Rowley z.B. zwar im Hintergrund von Crossworks den GNU Compiler nutzt, jedoch eine eigene libc entwickelt hat. Verwendet man stdio-Funktionen mit Bedacht und nutzt gegebenfalls eigene Funktionen (Atmel macht das z.B. bei stdio in Beispielen für arm-gcc so), sind die Unterschiede in Bezug auf Codegröße sehr viel geringer. Stöbert man durch die Quellen der newlib, findet man auch einige Änderungen zur Optimierung, die von Leuten mit arm.com-E-Mail Adressen eingebracht wurden. Angeblich arbeite ARM inzwischen aktiver an der Optimierung einer freien libc (ob das die newlib ist, weiss ich nicht) und auch der libgcc - ist aber nur eine mündiche Information und ich finde gerade keinen Beleg im Netz dafür. Inwieweit libc-Funktionen für eigene Entwicklungen wichtig sind, insbesondere wenn noch "Zertifizierungen" durchzuführen sind, hängt vom Anwendungsfall ab. Kann nichts zu schreiben, da ich meine Auftragsarbeiten bisher nur an Auftraggeber weitergeben habe, die sich um alles Weitere gekümmert haben. Es gab jedoch nur sehr selten Rückfragen und dabei nie ersthafte Probleme. Vermeide jedoch im Zweifel auch die libc für kritische Codesequenzen und halte mich bei kommerziellen Arbeiten weitestgehend an die MISRA-Regeln. Würde die Entscheidung zum Compiler selbst nur dann vom Hersteller abhängig machen, wenn eine Art Zertifizierung gefordert wird, die nur vor diesem Hersteller geboten wird. Ob eine Code aber z.B. nach MISRA-Regeln geschrieben ist, kann auch mit externen Tools überprüft werden, dazu braucht man nicht unbedingt den IAR-Compiler und dessen Warnings. Schön bei den Paketen von ARM/Keil und IAR ist die gute Integration des Compilers in deren IDE. Wobei die Codeeditoren von uVision(ARM) und EWARM(IAR) lange nicht so viel bieten wie z.B. der Eclipse Editor. Für diejenigen die es brauchen, düften die Möglichkeiten, die Debugger und evtl. Hardware-Simulatoren bieten eher ausschlaggebend sein. Dabei fand ich die Möglichkeiten, die uVision bietet immer recht beeindruckend (Den "Erstkontakt", um mit einem neuen Controller etwas zu spielen, mache ich immer noch gerne mit der µVision Evaluierungsversion und deren Hardwaresimulator, jedoch mit GNU-Compiler). Auch Entwicklungsumgebungen, die im Hintergrund den GNU C-Compiler nutzen (z.B. Crossworks, Attolic True Studio und die interessanten aber teilweise sehr teuren Attolic Zusatzmodule, RIDE, CoIDE aber auch uVison nach Auswahl), bieten viele Debugmöglichkeiten. Dann gibt es noch Spezialprogramme und -hardware, z.B. von Lauterbach. Dieser Absatz hat aber schon nichts mehr mit der ursprünglichen Frage nach den Compilern zu tun, sondern eher mit dem "Drumherum".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.