Forum: Compiler & IDEs SDCC: pic-Ports brauchen Hilfe


von Philipp Klaus K. (pkk)


Lesenswert?

Das SDCC 4.1.0 Release kommt näher. Auch diesmal gab es seit dem vorigen 
wieder deutliche Fortschritte. Sorgen machen aber zur Zeit insbesondere 
die pic-Ports. Es besteht die Gefahr, dass die pic14- und pic16-Ports in 
zukünftigen Releases nicht mehr enthalten sein könnten.

Schon seit langem gibt es für diese beiden keinen Maintainer. Die 
gputils, die von SDCC für die pic-Ports genutzt werden, haben keinen 
Maintainer. Auch die Build-Infrastruktur der pic-Ports ist teils etwas 
holprig. Gelegentlich gibt es Patches von Nutzern, aber erstens sind 
diese selten und zweitens ist es natürlich Aufwand, zu beurteilen, wie 
gut diese sind, erst recht für SDcc-Entwickler, die nicht mit PIC 
vertraut sind.

Es wäre sehr hilfreich, wenn wenigstens die Regression tests für pic mit 
weniger Fehlern durchliefen.

2019 gab es zuletzt eine größere Verbesserung am pic14-Port (aus Patches 
eines Nutzers). Seither laufen die Regression tests durch (danach ist 
zwar bei mir dei Konsole unbenutzbar, aber immerhin kann man per make 
--no-print-directory test-pic14 &> log brauchbare Ausgabe in log 
erhalten).
Aus meiner Sicht empfiehlt sich für pic14:

* Das Problem mit der nach Ausführen der regression tests unbenutzbaren 
Konsole finden und beheben
* Bugs, die zum Fehlschlagen von regression tests führen, beheben.
* Unterstützung für long long und unsigned long long für pic14 
implementieren (so dass auch tests, die diese Datentypen verwenden 
kompilieren).
* Einzelne Tests, die auf pic14 nicht ausgeführt werden können (z.B. 
wegen zu kleinem Speicher) für pic14 deaktivieren.
* Das Problem mit der build-Infrastruktur (anscheinend wird manchmal zur 
Buildzeit automake ausgeführt, was fehlschlägt, wenn die Version des 
lokalen automake nicht zu der passt, mit der eine andere Datei erstellt 
wurde) beheben.

Durch die pic14-Verbesserungen 2019 ist pic16 nun hinter pic14 
zurückgefallen. Für pic16 wäre der erste SChritt, die regression-Tests 
soweit zum Laufen zu bringen, dass man sinnvolle Ausgabe erhält (zur 
Zeit bei jedem Test "                                    (f:  0, t:   0, 
c:  0, b:      0, T:        0)" - eigentlich sollte links der Name des 
tests stehen, und die beiden Nullen links sollten angeben, wieviele 
Fehlschläge es bei wie vielen Assertions gab, also etwas so: "abs 
(f:  0, t:   6, c:  1, b:   1151, T:     3288)"). Danach dürften 
ähnliche Schritte wie bei pic14 anstehen.

Ich habe den Eindruck, dass es hier im Forum einige PIC-Nutzer gibt. 
Eventuell finden sich darunter ja welche, die ein paar Patches zu SDCC 
oder gputils beitragen könnten.
Für den Einstieg könnte ich zwar durchaus Fragen zu SDCC beantworten, 
kenne mich aber nicht mit PIC aus.

: Bearbeitet durch User
von Franko P. (sgssn)


Lesenswert?

Hallo
was spricht gegen die Nutzung des freien MPLAB und XC8?

Gruß
gerhard

von Philipp Klaus K. (pkk)


Lesenswert?

Franko P. schrieb:
> Hallo
> was spricht gegen die Nutzung des freien MPLAB und XC8?
>
> Gruß
> gerhard

Meines Wissens sind diese zwar kostenlos, aber nicht frei. Auch wird von 
XC8 wohl nur C90 und C99 unterstützt, während bei SDCC auch neuere 
C-Standards wie C11 verfügbar sind.

Bitte 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
Noch kein Account? Hier anmelden.