Forum: Compiler & IDEs SDCC 4.0.0 release candidate 1


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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
von Abyssaler Resonanzspürer (Gast)


Lesenswert?

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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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

von Christopher J. (christopher_j23)


Lesenswert?


von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?


von W.S. (Gast)


Lesenswert?

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.

von ggg (Gast)


Lesenswert?

Du kannst die exe mit einem Packer öfnnen und damit so vorgehen, wie du 
es für richtig hältst.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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/

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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/

von Larry (Gast)


Lesenswert?

> 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...

von S. R. (svenska)


Lesenswert?

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?

von Larry (Gast)


Lesenswert?

> 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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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!

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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).

von Le X. (lex_91)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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
von S. R. (svenska)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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
von S. R. (svenska)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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
von Bernd K. (prof7bit)


Lesenswert?

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
von Gerd E. (robberknight)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Tom Amann (Gast)


Angehängte Dateien:

Lesenswert?

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

von Tom Amann (Gast)


Lesenswert?

Hatte noch vergessen zu erwähnen, mit 16Bit-Variablen funktioniert es 
richtig.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von TomA (Gast)


Angehängte Dateien:

Lesenswert?

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

von TomA (Gast)


Lesenswert?

Noch vergessen: Geany ist 1.37.1.

von kannAlllesBesser?! (Gast)


Lesenswert?

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?

von TomA (Gast)


Lesenswert?

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

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

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
von Lars R. (larsr)


Lesenswert?

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.

von TomA (Gast)


Lesenswert?

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

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

> 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

von TomA (Gast)


Angehängte Dateien:

Lesenswert?

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

von Lars R. (larsr)


Lesenswert?

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

von Thomas Z. (usbman)


Lesenswert?

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.

von TomA (Gast)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.