SDCC 3.8.0 RC1

[Philipp Klaus K. (pkk)]

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

[Vancouver (Gast)]

Ich bin mit den neueren Versionen nicht mehr so auf dem Laufenden. Ist 
der PIC-Support immernoch "experimental"?

[Philipp Klaus K. (pkk)]

Vancouver schrieb:
> Ich bin mit den neueren Versionen nicht mehr so auf dem Laufenden. Ist
> der PIC-Support immernoch "experimental"?

Ja.

Philipp

[Philipp Klaus K. (pkk)]

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

[Holger K. (holgerkraehe)]

Weswegen ist dieses Projekt eigentlich nicht auf Github?
Bzw. was spricht für Sourceforge?

[Christopher J. (christopher_j23)]

Holger K. schrieb:
> Weswegen ist dieses Projekt eigentlich nicht auf Github?
> Bzw. was spricht für Sourceforge?

sdcc nutzt eben ein SVN repo

[Ralph S. (jjflash)]

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 ?

[Philipp Klaus K. (pkk)]

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

[Philipp Klaus K. (pkk)]

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

[Ralph S. (jjflash)]

Philipp Klaus K. schrieb:
> Borut ist tot,

... ohne Worte.

[Philipp Klaus K. (pkk)]

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