Demnächst wird SDCC 3.8.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 3.8.0 erscheint. Besonders schwerwiegende oder einfach zu behebende Bugs könnten dann noch rechtzeitig vor 3.8.0 behoben werden. Neben Quellcode und Dokumentation gibt es bei diesem Release auch Binärdateien (wie zuletzt bei 3.6.0). Letztere sind für GNU/Linux auf amd64, Windows auf amd64, macOS auf amd64, Windows auf x86 (allerdings wurden die Windows-installer noch nicht getestet, da mein einziger Windows-Rechner gerade kein Netzteil hat). In SDCC 3.8.0 wurden gegenüber 3.7.0 viele Bugs behoben und einige neue Features implementiert. Das ChangeLog findet sich unter https://sourceforge.net/p/sdcc/code/HEAD/tree/tags.... Die bedeutendsten neuen Features sind: * Additional general utility function: bsearch() * Support for rematerialization in the stm8 backend reduces register pressure and stack usage * Merged upstream GNU binutils 2.30 * All Python code is now fully compatible with both Python 2.7 and Python 3.6, so Python 3 can be used instead of Python 2. * Regression testing for diagnostics. * Improved handling of local bool variables in the mcs51 backend substantially reduces code size. * Large memory model for stm8 for 24-bit codespace allows using more than 32KB of Flash for code. * New optimizations for calls to some standard library function (printf(), puts(), strcpy()). * The type of true and false from stdbool.h change from int to bool. * New C2X mode (--std-c2x, --std-sdcc2x, #pragma std_c2x) adds support for one-argument static_assert variant. * Intermingling of declarations and statements (ISO C99). * Support headers for AX8052 devices. * Adopted GCC 8.2 regression tests (execute part of the GCC C torture tests). Philipp Klaus Krause SDCC 3.8.0 Release Manager
Gast
#5559901
Ich bin mit den neueren Versionen nicht mehr so auf dem Laufenden. Ist der PIC-Support immernoch "experimental"?
Vancouver schrieb: > Ich bin mit den neueren Versionen nicht mehr so auf dem Laufenden. Ist > der PIC-Support immernoch "experimental"? Ja. Philipp
SDCC 3.8.0 ist nun fertig (es gab seit dem RC1 keine wesentlichen Änderungen mehr - keiner der in RC1 gefundenen Bugs war schwerwiegend genug, das Release zu verschieben). Philipp
Weswegen ist dieses Projekt eigentlich nicht auf Github? Bzw. was spricht für Sourceforge?
Holger K. schrieb: > Weswegen ist dieses Projekt eigentlich nicht auf Github? > Bzw. was spricht für Sourceforge? sdcc nutzt eben ein SVN repo
Philipp Klaus K. schrieb: > Vancouver schrieb: >> Ich bin mit den neueren Versionen nicht mehr so auf dem Laufenden. Ist >> der PIC-Support immernoch "experimental"? > > Ja. > > Philipp kann es sein, dass derjenige, der für PIC beim SDCC zuständig war nicht mehr "an Bord" ist ?
Holger K. schrieb: > Weswegen ist dieses Projekt eigentlich nicht auf Github? > Bzw. was spricht für Sourceforge? GitHub ist neuer als SDCC und SourceForge. Und später gab es nie einen hinreichenden Grund, zu wechseln. Ein Wechsel brächte ja auch Aufwand: Die Entwickler müssten sich umgewöhnen (bezüglich der Tracker, Website, git vs svn, etc). Philipp
Ralph S. schrieb: > Philipp Klaus K. schrieb: >> Vancouver schrieb: >>> Ich bin mit den neueren Versionen nicht mehr so auf dem Laufenden. Ist >>> der PIC-Support immernoch "experimental"? >> >> Ja. >> >> Philipp > > kann es sein, dass derjenige, der für PIC beim SDCC zuständig war nicht > mehr "an Bord" ist ? Es gibt zur Zeit unter den aktiven SDCC-Entwicklern niemand, der sich um PIC kümmert. Borut ist tot, die anderen, die 'mal an pic14 oder pic16 arbeiteten haben wohl keine Zeit. Bei den backends für PIC ist seit Jahren kaum etwas passiert. Das gleiche Problem besteht auch bei den gputils. Philipp
Philipp Klaus K. schrieb: > Borut ist tot, ... ohne Worte.
Ralph S. schrieb: > Philipp Klaus K. schrieb: >> Borut ist tot, > > ... ohne Worte. Borut war seit 2002 dabei. Er war lange Zeit einer der aktivsten Entwickler. Er kannte sich in vielen Bereichen von SDCC (und der Infrastruktur drumherum, wie der Compile Farm, etc) bestens aus. Und er arbeitete auch an den gputils. Viele der anderen Entwickler kennen sich zwar inzwischen auch in teilen von SDCC gut aus, aber jemand mit so breitem Wissen wie Borut fehlt. Borut ist schon vor Jahren gestorben; bisher hat SDCC sich nicht völlig von dem Verlust erholt. Philipp P.S.: https://sourceforge.net/p/sdcc/discussion/1864/thread/a7cdb71e/?limit=25