SDCC 4.4.0 release candidate 1 available

[PkK]

Dear fellow ColecoVision developers. I haven't posted here in a long time, and haven't found time to develop anything specifically for the ColecoVision (or the Sega 8-bit systems) in a long time. But I have still been working on the Small Device C Compiler (SDCC), which many of us use to write games for the ColecoVision, either directly or as part of a downstream project.


The first release candidate (RC1) for SDCC 4.4.0 is available in our
SourceForge File release system:
https://sourceforge.net/projects/sdcc/files/

In addition to the source package, binaries are available for amd64 Windows, amd64 macOS, and amd64 GNU/Linux.

If you have time, please verify it and report your positive or negative
results.

In addition to various bug fixes, notable features added since the
4.3.0 release are:

* Optimizations for rotations.
* struct / union parameters for hc08, s08 and mos6502.
* Many bug fixes for -ms08 --stack-auto.
* struct / union return support for hc08 and s08 (caller side only).
* Generalized constant propagation.
* New command line option --syntax-only to only parse the input.
* Added C99 header inttypes.h
* Added library functions imaxabs, imaxdiv, llabs, strtoimax, strtoll, strtoull, strtoumax, wcsncmp, wcstoimax, wcstol, wcstoll, wcstoul, wcstoull, wcstoumax
* New r800 port to better support the ASCII Corp R800 and Zilog Z280.
* Changed the default calling convention for r2k, r2ka, r3ka, tlcs90, ez80-z80 from version 0 to 1 (this is an ABI break, and will require changes to user-written asm functions or their declarations).
* Improved optimizations for code speed for stm8, pdk, z80 (and related).
* New mos65c02 port to better support the WDC 65C02.

A full list of changes can be found in the ChangeLog:
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.4.0-rc1/sdcc/ChangeLog

Philipp
(SDCC 4.4.0 release manager)

 

P.S.: there is currently a survey at https://terminplaner4.dfn.de/EQgiMIYKQafCQLtr where you can state which SDCC ports you use or intend to use.

Edited December 22, 2023 by PkK

[AnalogKid]

Hi Philipp.  I've been developing games with SDCC for a few years now and there is really only one thing on my wish-list and I'd like to put it out there as it could be a great benefit for coders mostly for performance but also for resulting code size.  I don't know how feasible such an optimization would be, but, it would be nice if the compiler could take advantage of a programmer ordering their structure members and pertinent code in such a way that that the compiler could avoid adding assembler for calculating offsets for every member reference when the code is using pointers.  Basically what I'm saying is it would be nice if we wrote code the right way then the assembly could just INC HL and save 31 clock cycles per member access which doesn't sound like a lot but it adds up quickly if you have a large number of sufficiently complex screen elements.  I know it would only be applicable for simple statements as you can't hang on to HL otherwise, but, it's worth considering.  For my own games I take SDCC's output and do this optimization by hand via inline assembly, but other coders would certainly benefit.  BTW, just have to say, you guys already have a lot of really clever optimizations for the Z80 in there, nicely done.