Demnächst wird SDCC 4.0.0 erscheinen. Es gibt nun einen Release Candidate 1, am üblichen Ort unter https://sourceforge.net/projects/sdcc/files/. Dies ist die letzte Gelegenheit, noch Bugs in der aktuellen Version zu finden, bevor 4.0.0 erscheint. Besonders schwerwiegende oder einfach zu behebende Bugs könnten dann noch rechtzeitig vor 4.0.0 behoben werden. In SDCC 4.0.0 wurden gegenüber 3.9.0 viele Bugs behoben und einige neue Features implementiert. Das ChangeLog findet sich unter https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLog Die bedeutendsten neuen Features sind: * The pdk15 backend now passes the regression tests (both with and without --stack-auto), and is thus considered stable. * New in-development pdk13 backend for Padauk µC with 13-bit wide program memory. * C2X memccpy(), strdup(), strndup(). * Better tail call optimization. * Many fixes in the pic14 backend. * C2X u8 character constants. * C2X bool, static_assert, alignof, alignas. * C2X attributes on statements. * C2X attribute declarations. * Support for extended ASCII characters in sdas, sdld. * Compiler support for UCNs and non-ASCII utf8 in identifiers. Philipp Klaus Krause SDCC 4.0.0 Release Manager
:
Bearbeitet durch User
Hoffentlich gibt es zum 4.0.0 auch eine einer Version 4.0.0 angemessene Installationsanleitung. - Welche Environmentvariablen müssen gesetzt werden. - Was kommt Wohin ... Das war ja in der Vergangenheit eher immer ein Gerätsel. Und Rätseln tue ich mir nicht an. Da warten dann die kommerziellen Versionen die O.O.B. funktionieren.
Abyssaler Resonanzspürer schrieb: > Hoffentlich gibt es zum 4.0.0 auch eine einer Version 4.0.0 > angemessene Installationsanleitung. > > - Welche Environmentvariablen müssen gesetzt werden. > - Was kommt Wohin > ... > > Das war ja in der Vergangenheit eher immer ein Gerätsel. > Und Rätseln tue ich mir nicht an. Da warten dann die kommerziellen > Versionen die O.O.B. funktionieren. Diesbezüglich sind mir keine Änderungen seit 3.9.0 bekannt. Aber abgesehen von Windows sollte das unproblematisch sein ("make install" installiert, soweit nichts anderes angegeben wird, nach /usr/local/bin, wie es eben üblich ist). Soweit ich weiß, nutzen die meisten SDCC-Entwickler hauptsächlich GNU/Linux; entsprechend werden Bugs und Probleme dort schneller bemerlt. es wäre sicher gut, jemand zu haben, der sich darum kümmert, dass SDCC auf Windows gut läuft und es keine Windowsspezifischen Dokumentationslücken gibt. Wer Patches zur Verbesserung (z.B. der Dokumentation) hat: https://sourceforge.net/p/sdcc/patches/ Philipp
Philipp Klaus K. schrieb: > https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLog Das ist doch das Changelog vom 3.9.0 release candidate, oder nicht? Das vom 4.0.0 RC sollte das hier sein: https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.0.0-rc1/sdcc/ChangeLog
Christopher J. schrieb: > Philipp Klaus K. schrieb: >> > https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLog > > Das ist doch das Changelog vom 3.9.0 release candidate, oder nicht? Das > vom 4.0.0 RC sollte das hier sein: > https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.0.0-rc1/sdcc/ChangeLog Ja. Inzwischen ist 4.0.0 fertig. https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.0.0/sdcc/ChangeLog
Philipp Klaus K. schrieb: > Aber abgesehen von Windows sollte das unproblematisch sein ("make > install" installiert... "sdcc-4.0.0-x64-setup.exe" Sowas kann ich überhaupt nicht leiden. Warum geht das offensichtlich nicht, so ein Programmpaket als eine simple Zip-Datei auszuliefern, die man in irgend ein Verzeichnis seiner eigenen Wahl entpackt und dort schlicht und einfach benutzt? Braucht SDCC es denn, in den Eingeweiden des OS herumzuwühlen, womöglich sogar noch nach Admi-Rechten zu fragen, um sich installieren und benutzen zu lassen? W.S.
Du kannst die exe mit einem Packer öfnnen und damit so vorgehen, wie du es für richtig hältst.
W.S. schrieb: > Philipp Klaus K. schrieb: >> Aber abgesehen von Windows sollte das unproblematisch sein ("make >> install" installiert... > > "sdcc-4.0.0-x64-setup.exe" > > Sowas kann ich überhaupt nicht leiden. > > Warum geht das offensichtlich nicht, so ein Programmpaket als eine > simple Zip-Datei auszuliefern, die man in irgend ein Verzeichnis seiner > eigenen Wahl entpackt und dort schlicht und einfach benutzt? Gehen würde es schon, aber die bei weitem meisten Windowsnutzer wünschen einen Installer. Bei den täglichen Snapshots gibt es auch .zip: Das dem Stand des 4.0.0-Release entsprechende .zip für 64-Bit Windows ist dieses: http://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32/sdcc-snapshot-x86_64-w64-mingw32-20200128-11528.zip/download
Falls jemand eine kurze Einführung zu SDCC, und den Rest der freien Toolchain für Padauk-µC wünscht, und den Vortrag heute auf der FOSDEM verpasst hat: Es gibt eine Aufzeichnung: https://fosdem.org/2020/schedule/event/paduak_toolchain/
W.S. schrieb: > Sowas kann ich überhaupt nicht leiden. Das interessiert jetzt wen? Compiliers dir eben selber wenns dir nicht passt: https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/
> Das interessiert jetzt wen?
Er hat ja nicht unrecht.
Bei manchen Installern aus "indischer" Softwareproduktion wird
fuer jede versch.ssene Datei ein Registryeintrag erzeugt, damit
der Uninstaller aber auch nichts uebersieht.
Die Eintraege werden bei einer Deinstallation natuerlich nicht
entfernt.
Ein so installierter GCC erzeugt so voellig unnoetigen Overhead.
Macht z.B. die gewesene Firma Raisonance, heute Keolabs so.
Das muss einem nicht gefallen. Zumal andere Softwareprojekte
es durchaus schaffen, parallel ein Zip-Archiv anzubieten.
Wenn durch den Installer dann wenigstens die Environmentvariablen
gesetzt wuerden...
Larry schrieb: > Das muss einem nicht gefallen. Zumal andere Softwareprojekte > es durchaus schaffen, parallel ein Zip-Archiv anzubieten. Die ZIP-Datei existiert und wurde verlinkt. Zufrieden?
> Die ZIP-Datei existiert und wurde verlinkt. Zufrieden?
Ja.
Ausserdem war ich nicht der erste der geklagt hat.
Den muesstest du fragen.
Ich habe den Installer auf einer Virtualbox-WXP-Instanz
laufen lassen und mir selber ein (Nano-)Zip erzeugt.
Allerdings von der 32 bittigen Version.
Die wollte ich in den naechsten Tagen mal testen.
Aber trotzdem danke der Nachfrage.
Larry schrieb: > Das muss einem nicht gefallen. Zumal andere Softwareprojekte > es durchaus schaffen, parallel ein Zip-Archiv anzubieten. Der Tonfall machts eben und der Tonfall von W.S. ist eben mal wieder ... daneben. Man kann ja Fragen warums das nicht gibt, aber muss man direkt rummotzen? @Philipp Klaus K: Sachma wie würdest du den Aufwand Einschätzen dem SDCC ein MIPS1 Backend zu verpassen? Bzw ist der SDCC noch klein genug um auf einem RTOS wie FreeRTOS zu laufen? Irgendwie habe ich den größenwahnsinnigen Gedanken, dass auf dem MIPS TTL Rechner unbedingt ein C Compiler rauf muss!
Mw E. schrieb: > > @Philipp Klaus K: > Sachma wie würdest du den Aufwand Einschätzen dem SDCC ein MIPS1 Backend > zu verpassen? Vom Aufwand her wäre es machbar, aber GCC und LLVM dürften für eine solche RISC-Architektur besseren Code generieren. > Bzw ist der SDCC noch klein genug um auf einem RTOS wie FreeRTOS zu > laufen? > Irgendwie habe ich den größenwahnsinnigen Gedanken, dass auf dem MIPS > TTL Rechner unbedingt ein C Compiler rauf muss! SDCC ist der (Small Device) C Compiler, nicht der Small (Device C Compiler). Wenn der Compiler selbst klein sein soll, wäre TinyCC naheliegend (der hat aber bisher auch kein MIPS-Backend).
Philipp Klaus K. schrieb: > Gehen würde es schon, aber die bei weitem meisten Windowsnutzer wünschen > einen Installer. Nicht nur die sondern auch und ganz besonders die Linuxer. Es gibt nichts schlimmeres als einen tar-Klumpen dessen Inhalt ich, am Besten noch an der Paketverwaltung vorbei, irgendwo hinkopieren muss.
Le X. schrieb: > Nicht nur die sondern auch und ganz besonders die Linuxer. > Es gibt nichts schlimmeres als einen tar-Klumpen Nein. > dessen Inhalt ich, am > Besten noch an der Paketverwaltung vorbei, irgendwo hinkopieren muss. Nein.
Le X. schrieb: > Philipp Klaus K. schrieb: >> Gehen würde es schon, aber die bei weitem meisten Windowsnutzer wünschen >> einen Installer. > > Nicht nur die sondern auch und ganz besonders die Linuxer. > Es gibt nichts schlimmeres als einen tar-Klumpen dessen Inhalt ich, am > Besten noch an der Paketverwaltung vorbei, irgendwo hinkopieren muss. Meiner Erfahrung nach wollen GNU/Linux-Nutzer meist: 1) Ein Paket, dass sie über den Paketmanager ihrer Distribution installieren können. Am besten gleich von der Distribution bereitgestellt, wie bei SDCC (https://repology.org/project/sdcc/versions). 2) Einen Tarball und ein öffentlich zugängliches Quellcoderepository, die Quellcode enthalten, den sie auf üblichem Weg bauen, und dann per "make install" installieren können.
Wenn ich einen Tarball mit Binaries bekommen kann (wie Eclipse zum Beispiel) den ich einfach irgendwo in meinem home entpacken und starten kann dann hab ich da kein Problem damit. Das selbe gilt für AppImage. Abgehangenes Zeug oder Standard-Kram installier ich mir aus den Repositories der Distribution. Aber sobald ich irgendwo bleeding edge brauche weil es zum Beispiel die betreffende Software vor 2 Jahren noch gar nicht gab oder wenn ich händeringend auf ein neues Feature warte das jetzt endlich implementiert wurde kann ich mit der abgehangenen Version aus den Repositories nichts anfangen. Dann bleibt nur noch ppa (Ubuntu), Tarball mit Binaries, AppImage oder Snap oder selber kompilieren. Das gibt (mit Ausnahme von ppa, deshalb nehm ich da auch zunehmend Abstand von) auch keine Konflikte mit der Paketverwaltung, insofern ist die Formulierung "an der Paketverwaltung vorbei" nicht zutreffend solange man die Finger von den Ordnern lässt die der Paketverwaltung gehören(!) und stattdessen lokal installierte Software nur an Orten installiert die genau für sowas vorgesehen sind (~/.local, /usr/local, /opt) oder ein Tarball oder AppImage irgendwo ins eigene home, oder ein snap. Da ist dann genau nichts "an der Paketverwaltung vorbei" sondern das ist der normale vorgesehene Weg.
:
Bearbeitet durch User
Bernd K. schrieb: > Dann bleibt nur noch ppa (Ubuntu), Tarball mit Binaries, > AppImage oder Snap oder selber kompilieren. Der übliche Weg ist "selber kompilieren". Die von dir gewünschten Binaries landen dann standardmäßig in /usr/local/ - und ja, das ist "an der Paketverwaltung vorbei". Ob das Probleme auslöst oder nicht, kann die Paketverwaltung nicht wissen und deswegen macht man das üblicherweise nicht. Binaries sind nicht portabel (d.h. SDCC müsste mindestens x86, x86_64, arm64 und armhf/armel ausliefern), zudem ist nicht garantiert, dass sie überhaupt funktionieren. Selbst glibc ist nicht binärkompatibel (deswegen kompiliert NVidia die Grafiktreiber gegen echt antike glibc-Versionen). Statisch linken gegen glibc ist übrigens "highly discouraged" (u.a. weil glibc selbst dlopen() benutzt). Was du also willst ist, dass jemand seine C-Programme für dich gegen eine fremde oder veraltete libc kompiliert, nur damit du dir den Aufwand sparst. Ziemlich verlangend. Von den anderen Abhängigkeiten mal abgesehen.
S. R. schrieb: > /usr/local/ - und ja, das ist "an der Paketverwaltung vorbei Nein, ist es nicht denn die Paketverwaltung hat nichts in /usr/local, deshalb muss man dort auch nicht an ihr "vorbei". Dieser Ort gehört ganz allein dem Eigentümer der lokalen Maschine zur freien Verfügung und nicht der Paketverwaltung. Im Gegenzug lässt man selbst die Finger von /usr denn das wiederum gehört allein dem Paketmanager und sonst niemandem. Und schon kommt sich niemand in die Quere. > Was du also willst ist, dass jemand seine C-Programme für dich gegen > eine fremde oder veraltete libc kompiliert Die meisten schaffen es es zu vermeiden gegen irgendwelche Bleeding Edge Versionen zu linken oder irgendwas zu verwenden das es erst in 2 Jahren bei Otto Normalverbraucher geben wird, dann läuft das Zeug auch überall. Und wenn nicht dann würd ichs bei mir mit meiner 2 Jahre alten libc sowieso auch selber nicht gelinkt bekommen. Und wenn ich alles immer selber kompilieren wollte würde ich Gentoo benutzen. Das hab ich mal ein Jahr lang gemacht, da war ich noch jung und genauso drauf wie Du, dann ist mir das irgendwann zu blöd geworden. Wenn ich mir heute was installiere will ichs meist am selben Tag noch benutzen und nicht erst in 6 Stunden. Wenn der Softwareanbieter Binaries anbietet (in welcher Form auch immer) dann benutze ich die dankbar und gerne! Beispiel: arm-none-eabi-gcc (Tarball), avr-gcc (Tarball), vscode (Snap), Eclipse (Tarball), Pycharm (Tarball), Blender (Snap), Prusa Slicer (AppImage), FreeCAD¹ (AppImage), etc... Nichts davon kommt dem Paketmanager in die Quere weil es nicht an diesem vorbei sondern völlig getrennt(!) davon installiert wurde. Seit ich aufgehört habe dem Paketmanager irgendwelche inoffizielle Quellen unterzujubeln in der irrigen Annahme das wäre der richtige Weg und stattdessen sowas strikt komplett separat(!) an separaten(!) Orten installiere lauft jedes 6-Monatige Ubuntu-Upgrade wie am Schnürchen und ohne Schluckauf durch. __ ¹) allein beim Gedanken daran sowas wie zum Beispiel FreeCAD mit seinen zwölfunddreißig Abhängigkeiten (oder sowas wie Eclipse oder dergleichen) selber kompilieren zu müssen bekomme ich Gänsehaut, allein beim Gedanken daran...
:
Bearbeitet durch User
Bernd K. schrieb: >> /usr/local/ - und ja, das ist "an der Paketverwaltung vorbei > > Nein, ist es nicht denn die Paketverwaltung hat nichts in /usr/local, > deshalb muss man dort auch nicht an ihr "vorbei". Du Witzkeks. "Unabhängig von der Paketverwaltung" ist dasselbe wie "an der Paketverwaltung vorbei". Beispiel: Ich installiere ein paar Binaries in /usr/local/bin, aber die Paketverwaltung installiert das gleiche Paket wegen bestimmter Abhängigkeiten in /usr/bin, dann bekomme ich voll lustige Probleme, weil beide (a) existieren und (b) gleiche Dateien benutzen. Wenn nicht in /etc, dann vielleicht im Homeverzeichnis. Super, sowas. Bernd K. schrieb: > Die meisten schaffen es es zu vermeiden gegen irgendwelche Bleeding Edge > Versionen zu linken oder irgendwas zu verwenden das es erst in 2 Jahren > bei Otto Normalverbraucher geben wird, dann läuft das Zeug auch überall. Heißt: Du verlangst tatsächlich, dass die Binaries bevorzugt gegen ein RedHat 6.2 kompiliert werden. Ich staune. Bernd K. schrieb: > Und wenn ich alles immer selber kompilieren wollte würde ich Gentoo > benutzen. Das hab ich mal ein Jahr lang gemacht, da war ich noch jung > und genauso drauf wie Du, dann ist mir das irgendwann zu blöd geworden. Tut mir Leid, aber im Gegensatz zu Dir ich sehe ich einen klitzekleinen Unterschied zwischen "ich muss alles selbst kompilieren" und "wenn ich Bleeding Edge will, dann baue ich die halt selber". Und insbesondere SDCC zählt jetzt nicht gerade zu den Projekten, wo ich mit drölfundvierzig Webpaketen aus in Javascript, Python und PHP zusammengewürfelten Abhängigkeiten kämpfen muss. Bernd K. schrieb: > Beispiel: arm-none-eabi-gcc (Tarball), avr-gcc (Tarball), [...] $ sudo apt install gcc-arm-none-eabi gcc-avr funktioniert bei mir prächtig (die anderen Programme nutze oder kenne ich nicht). Achso, du wolltest Bleeding Edge fahren. Naja, ich entnehme deinem Rant einfach mal, dass du gerne Windows mit seinen Installern und der DLL-Hölle wiederhättest, aber der Ansatz, einfach pro Anwendung ein eigenes Betriebssystem zu installieren (Snap, AppImage), deine vollumfängliche Zufriedenheit findet - und lasse das Thema ruhen. Die Welt bewegt sich da ohnehin hin.
S. R. schrieb: > aber der Ansatz, > einfach pro Anwendung ein eigenes Betriebssystem zu installieren (Snap, > AppImage) Das Prinzip hat sich auch beim Deployen von Webanwendungen und anderen Cloud-Diensten mit Pauken und Trompeten durchgesetzt (Docker) weils so viel endloses Nervenaufreiben komplett vermeidet. Und zwar das Nervebaufreiben das man immer hat wenn man versucht fremden Code in seinem eigenen System zu integrieren ohne was kaputt zu machen oder tonnenweise dev-Pakete und libs von denen man noch nie was gehört hat zu installieren. Wenn es gelingt Binaries zu machen die überall einfach so laufen ohne mit irgendwas in die Quere zu kommen oder irgendwas besonderes an meinem System zu verlangen dann soll mir das nur recht sein. Und wenn das erfordert daß der Softwareanbieter ein bisschen aufpasst gegen was er linkt und auch auf anderen Maschinen testet als nur seiner eigenen dann soll das gerne so sein.
Bernd K. schrieb: > S. R. schrieb: >> aber der Ansatz, >> einfach pro Anwendung ein eigenes Betriebssystem zu installieren (Snap, >> AppImage) > > Das Prinzip hat sich auch beim Deployen von Webanwendungen und anderen > Cloud-Diensten mit Pauken und Trompeten durchgesetzt (Docker) weils so > viel endloses Nervenaufreiben komplett vermeidet. Nein, es vermeidet das endlose Nervenaufreiben nur dem Entwickler oder Tester, der das Zeug einmalig schnell zusammenfrickeln will. Dem Administrator, der diesen Mist dann über Jahre hinweg stabil und vor allem auf aktuellem Sicherheitspatchlevel halten muss, bereitet es schlaflose Nächte. Da helfen nur Pakete vom Paketmanager der Distribution. Oder für das, was dort nicht vorhanden ist, ein eigenes Repository mit den Quellen und Bauanleitungen (z.B. .spec-Dateien) von allen Abhängigkeiten.
:
Bearbeitet durch User
Gerd E. schrieb: > Nein, es vermeidet das endlose Nervenaufreiben nur dem Entwickler oder > Tester, der das Zeug einmalig schnell zusammenfrickeln will. > > Dem Administrator, der diesen Mist dann über Jahre hinweg stabil Nein, der Entwickler ist gleichzeitig der Administrator seines eigenen Images. Der klickt einmal mit der Maus und sein Image wird mit allen altuellen libs neu gebaut und verteilt. Der Administrator des Hosts sorgt nur dafür daß seine Dockerfarm läuft, das ist sein Job und mehr nicht. Mit dem was in den Images innendrin ist hat der exakt nichts am Hut, da kann er auch nichts machen, da ist jemand anders zuständig und er hat demzufolge auch NULL Nervenaufreiben damit weil an der Stelle für ihn absolut nichts zu tun ist. Jeder hat weniger Stress und Konfliktpunkte. Win-Win. Dementsprechend muß ich mir wenn ich ein Snap installiere auch nicht die Nerven aufreiben um mein System irgendwie passend hinzubiegen denn das Snap bringt alles mit was es braucht. Das Paketsystem ist gut für das Grundsystem, für die Infrastruktur in der nicht mehr viel Bewegung ist. Für alles was darüber hinausgeht, für alles schnellebige ist das vollkommener Wahnsinn und praktisch nicht mehr zu beherrschen, das hat man jetzt mittlerweile gelernt nach zig Jahren gescheiterten Versuchen das irgendwie mit dem Paketsystem hinzubekommen.
:
Bearbeitet durch User
Bernd K. schrieb: > Gerd E. schrieb: >> Nein, es vermeidet das endlose Nervenaufreiben nur dem Entwickler oder >> Tester, der das Zeug einmalig schnell zusammenfrickeln will. >> >> Dem Administrator, der diesen Mist dann über Jahre hinweg stabil > > Nein, der Entwickler ist gleichzeitig der Administrator seines eigenen > Images. Wenn Entwicklung und Betrieb des Images in einer Firma laufen - meinetwegen, da kannst Du die Aufgabengebiete definieren wie Du willst. Aber wenn die Entwicklung außer Haus bei einer anderen Firma ist kannst Du das in sehr vielen Fällen vergessen weil Du Dich auf die was das Thema Sicherheit angeht nicht verlassen kannst. > Der klickt einmal mit der Maus und sein Image wird mit allen > altuellen libs neu gebaut und verteilt. Und woher weiß er daß er mit der Maus klicken muss? Also wie ordnet er die ganzen Security Advisories, die da jeden Tag rauskommen, der Liste seiner Abhängigkeiten (und deren Abhängigkeiten, rekursiv) zu? > Der Administrator des Hosts sorgt nur dafür daß seine Dockerfarm läuft, > das ist sein Job und mehr nicht. Mit dem was in den Images innendrin ist > hat der exakt nichts am Hut, da kann er auch nichts machen, da ist > jemand anders zuständig und er hat demzufolge auch NULL Nervenaufreiben > damit weil an der Stelle für ihn absolut nichts zu tun ist. Der Admin ist normalerweise auch dafür zuständig die Sicherheit des Gesamtsystems sicherzustellen. Da muss er einen Sicherheitspatch machen können, auch wenn der Entwickler grad an einem anderen Projekt dran ist oder sonstwas. > Jeder hat weniger Stress und Konfliktpunkte. Win-Win. Nur wenn man das Thema Sicherheit ausblendet vielleicht.
Gerd E. schrieb: >> Jeder hat weniger Stress und Konfliktpunkte. Win-Win. > > Nur wenn man das Thema Sicherheit ausblendet vielleicht. Nein, ich sehe nicht wo das die Sicherheit nachteilig beeinflussen sollte. Im Gegenteil: Weil Updates stressfreier und mit weniger Nebenwirkungen verbunden sind können sie zügiger geschehen.
Angehängte Dateien:
-
SDCCrst.png
58 KB
Guten Tag Herr Philipp Klaus K. Ich schreibe mir derzeit ein IDE-Plugin für 8051 unter dem Texteditor Geany. Als Compiler benutze ich den SDCC. Mit dem Assembler bin ich durch und wende mich nun dem C-Hochsprache debugging zu. Als Quelle für das debuggen verwende ich die ".rst" und "ihx" Dateien. Dabei ist mir folgendes aufgefallen: Ich schreibe einen C-Befehl "bVar += 3" und dieser wird korrekt in die Assemblerbefehle "mov r7,bVar mov a,#03 add a,r7" übersetzt, aber das zurückschreiben in die Speicherzelle (data 08) erfolgt erst im nächsten Befehl. Wenn ich nun nach ausführen von "bVar += 3" die Variable bVar anzeige befindet sich der alte Wert in dieser. Im Bild ist zu sehen dass sich in R7 und bVar der Wert 0x27 und nur im Akku der neue Wert 0x2A befindet. Am unteren Bildrand ist ein Speicherauszug der ersten 32 Byte des direkt adressierbaren Datenspeichers zu sehen (Adr 000 - 01F). Links einige Register und rechts der Programmcode in C und Assembler. Ich könnte nun die Variable volatile deklarieren, aber dann wird der Programmcode länger. Wenn ich für Debug und Release unterschiedliche Variablen deklariere bekomme ich unterschiedliche Programmlaufzeiten und mit volatilen Variablen ein grösseres Programm. Für den Normalbetrieb ist es unerheblich, ob die Variable im aktuellen oder erst im nächsten Block aktualisiert wird. Beim debuggen stört es aber erheblich. In der Befehlslogik ist es auch nicht korrekt, der Befehl bVar += 3 sollte den Inhalt der Variable und nicht den Inhalt des Akku um 3 erhöhen. Für mich habe ich bereits eine Lösung des Problems gefunden, nehmen sie dies nur als Hinweis worüber man sich noch Gedanken machen kann. Im Ganzen finde ich den SDCC gelungen und bedanke mich für ihren Aufwand und dass sie ihn frei zur Verfügung stellen. Mit freundlichen Grüssen. Tom Amann
Hatte noch vergessen zu erwähnen, mit 16Bit-Variablen funktioniert es richtig.
Oft stellen C-Compiler bei eingeschalteter Optimierung die Reihenfolge von Befehlen um. Sie dürfen das auch, solange das gewünschte Ergebnis erreicht wird. Daher Frage: Debuggst Du Code, der mit eingeschalteter Optimierung übersetzt wurde? Wenn ja, dann schalte die Optmierung aus, übersetze und debugge nochmal.
Angehängte Dateien:
-
SDCCrstW.png
67 KB
Hallo Frank M. Ich habe keine Möglichkeit gefunden beim SDCC die Optimierung abzuschalten. Von den im Handbuch beschriebenen Parametern zum einstellen der Optimierung habe ich die meisten durchprobiert. Da es mit 16Bit-Variablen funktioniert wie es soll, gehe ich von einem Bug bei 8Bit-Variablen aus. Wenn man es weiß ist es kein großes Problem, wird es doch nur beim Hochsprache-Debug wirksam. Im Normalbetrieb ist es funktionell einerlei ob das zurückschreiben als letzter Befehl des aktuellen Block, oder als erster Befehl des Folgeblocks geschieht. Ich umschiffe das jetzt indem ich im Hochsprache Modus nicht die Variablen anzeige, sondern den Assemblercode. So sehe ich sofort, ob das Problem besteht und kann den fehlenden Schritt händisch (später vielleicht automatisch) durchführen. Das Problem ist damit gelöst. Im Bild ist das gleiche Programm mit 16Bit-Variable "bVar" zu sehen, hier ist alles wie es sein soll. Das Betriebssystem ist Linux Ubuntu 18.05.5 und SDCC ist 4.0.0. Mit freundlichen Grüssen. Tom
Tom Amann schrieb: > Ich schreibe mir derzeit ein IDE-Plugin für 8051 unter dem Texteditor > Geany. hi, dein projekt finde ich interessant! sind deine quellen dazu irgendwo online und kannst du mehr darüber berichten?
Hallo kannAlllesBesser?! Um den Tread des Herrn Philipp Klaus K. nicht länger zu kapern habe ich die Frage in: Beitrag "Re: Geany-Plugin: Icon aus Toolbar entfernen?" beantwortet. Mit freundlichen Grüßen Tom
TomA schrieb: > Hallo kannAlllesBesser?! > > Um den Tread des Herrn Philipp Klaus K. nicht länger zu kapern habe ich > die Frage in: Macht euch keine Sorgen um diesen Thread, es wird wohl in den nächsten Tagen einen neuen Thread "SDCC 4.1.0 release candidate 1" geben.
Leider bin ich kein Experte zum mcs51-Port oder zu den Debug-Informationen. Aber dass diese nicht immer ganz exakt sind, ist ein leider Problem, dass auch andere Ports betrifft (siehe z.B. https://sourceforge.net/p/sdcc/bugs/2701/ und https://sourceforge.net/p/sdcc/bugs/3163/). Zur Zeit gibt es nur wenige aktive SDCC-Entwickler, deren Zeit ist knapp, und es gibt bei SDCC viele Baustellen, auf denen Verbesserungen wünschenswert wären. Immerhin ist der mcs51-Port noch in einem deutlich besseren Zustand als pic14- und pic16-Port.
:
Bearbeitet durch User
Philipp Klaus K. schrieb: > Immerhin ist der mcs51-Port noch in einem deutlich besseren Zustand als > pic14- und pic16-Port. Der pic14-Port ist praktisch unbenutzbar. Der ganze Code ist voll mit Bank-Select vollgemüllt. Ich bin mir auch nicht sicher, ob es überhaupt sinnvoll ist, so viele Plattformen zu unterstützen. Immerhin liefert Microchip mit dem XC8 eine wirklich brauchbare Alternative. Beim MCS51-Port sehe ich es genau so: Der Keil-C51 ist wunderbar. Allein dessen Optimierung mit mehreren Durchläufen ist schon den Kaufpreis wert. Schade, dass weder der XC8 für die PIC noch der avr-gcc nur annähernd mithalten können.
Hallo Philipp Klaus K. sie müssen sich nicht entschuldigen, dass sie Software kostenfrei zur Verfügung stellen. Ganz im Gegenteil, ich bin froh mit SDCC arbeiten zu dürfen ohne Lizenzgebühren bezahlen zu müssen - möchte mich an dieser Stelle nochmal dafür bedanken. Für die normalen User liegt ja noch nicht mal ein Bug vor, nur für Hochsprachendebugger tritt er überhaupt in Erscheinung. Irgendwann wird einer der Programmierer Zeit finden sich des Problems anzunehmen. Bis dahin wird es halt umschifft. Mit freundlichen Grüßen. Tom
> Ich bin mir auch nicht sicher, ob es überhaupt sinnvoll ist, so viele > Plattformen zu unterstützen. Immerhin liefert Microchip mit dem XC8 eine > wirklich brauchbare Alternative. > > Beim MCS51-Port sehe ich es genau so: Der Keil-C51 ist wunderbar. Allein > dessen Optimierung mit mehreren Durchläufen ist schon den Kaufpreis > wert. Schade, dass weder der XC8 für die PIC noch der avr-gcc nur > annähernd mithalten können. Weder XC8 noch Keil-C51 sind frei. Aber die zukünftige Unterstützung für PIC is in der Tat fraglich. Bei MCS-51 sieht es nochmal anders aus: SDCC mag zur Zeit nicht so gut optimieren wie Keil-C51, aber SDCC ist immerhin ein C-Compiler (mit halbwegs brauchbarer Unterstützung der C-Standards bis ISO C17 - bei ISO C23 ist gibt es noch viele Lücken). Keil-C51 behauptet nur, ANSI-C von 1989 zu unterstützen, aber selbst da sind noch einige Lücken. Philipp
Angehängte Dateien:
-
PreisKeil.png
18 KB
Hallo Lars R. Du vergleichst hier Äpfel mit Birnen und nicht jeder ist bereit mal schnell 2870€ für eine Entwicklungsumgebung fürs Hobby zu bezahlen. Muss wohl wieder Frühling sein, die Frösche quaken schon wieder. Frösche sind nun nicht gerade dafür bekannt besonders clever zu sein, aber laut quaken dass können sie! Im Anhang ein Auszug mit Preisangabe zum Keil. Gruss Tom
Hallo Tom, TomA schrieb: > fürs Hobby zu bezahlen Mir war nicht klar, dass man sich hier nur mehr äußern darf, wenn man die Entwicklung als Hobby betreibt. Als ich mich vor dreizehn Jahren hier angemeldet habe, war das offenbar noch anders. TomA schrieb: > Im Anhang ein Auszug mit Preisangabe zum Keil. Qualität hat halt ihren Preis. Wie gesagt, wenn die einen Compiler für PIC hätten, wären die Kosten auch nicht das Problem. Für mich ist ein Compiler ein Werkzeug, welches man für die tägliche Arbeit als Entwickler für Firmware braucht. Und am Werkzeug sollte ein Unternehmen nie sparen... Aber mein Gequake ist ja irrelevant wie ich von dir gelernt habe. Darf man fragen, wie lange du schon dein Geld damit verdienst? Viele Grüße, Lars
Philipp Klaus K. schrieb: > Bei MCS-51 sieht es nochmal anders aus: SDCC mag zur Zeit nicht so gut > optimieren wie Keil-C51, aber SDCC ist immerhin ein C-Compiler (mit > halbwegs brauchbarer Unterstützung der C-Standards bis ISO C17 - bei ISO > C23 ist gibt es noch viele Lücken). Keil-C51 behauptet nur, ANSI-C von > 1989 zu unterstützen, aber selbst da sind noch einige Lücken. Der SDCC braucht sich mittlerweile nicht mehr zu verstecken. Ich kann allerdings nur den 51er Port beurteilen und der hat in den letzten Jahren deutlich zugelegt. Der Code ist zwar immer noch größer. Nach meiner Erfahrung ca 20%, das war früher aber deutlich schlechter. Weil mich das auch interessiert hat habe ich ein Projekt von mir mal so geändert dass der Code sich mit minimalen Änderungen in Keil, IAR, und SDCC übersetzen ließ. Tasking hab ich noch nicht probiert, bei IAR hatte ich nur die freie Version, weshalb die Ergebnisse da ev. nicht korrekt sind. Als Rangfolge hat sich da Keil ->IAR ->SDCC ergeben. Was mir beim SDCC positiv aufgefallen ist, sind die wesentlich restriktiveren Warnmeldungen bei Schlamperei im Code wie nich initialisierten Variablen. Ob der Compiler nun C17 kann ist mir ziemlich egal. Die meisten Änderungen musste ich dabei für IAR wegen memcpy und printf machen. Zusätzlich kann IAR keine mem specifier auf auto variablen anwenden.
Hallo Philipp Klaus K. manchmal dauert es etwas bis der Groschen fällt, trotz ihres Winks mit dem Zaunpfahl. Einer der Vorteile des SDCC ist, dass er quelloffen ist. QUELLOFFEN - Das bedeutet ja, das ich bei Problemen selbst in die Quellen sehen und das Problem beseitigen kann. Das fiel mir erst jetzt wie Schuppen von den Augen. Da kann man sehen, wie Betriebsblind man sein kann. Werde mir die Quellen mal ansehen, denn dafür sind sie da. @Lars R. Vielen Dank für die Einladung zum Froschkonzert, leider fehlen mir Zeit und Interesse für das gegenseitige anquaken. @Thomas Z. Der Keil-Compiler ist auch nicht frei von Fehlern. Da ich weder Militär noch Amt bin, sind mir die Normen und Vorschriften auch nicht tragend. Der Compiler muss ein Quellprogramm brauchbar in ein Maschinenprogramm übersetzen. Das kann der SDCC schon ganz gut. Gruß. Tom
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.