Forums

Dear fellow Sega 8-bit developers. I haven't posted here in a long time, and haven't found time to develop anything specifically for the Sega 8-bit systems (or the ColecoVision) 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 Sega 8-bit systems, 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.

Hey @PkK, thanks for all your work on SDCC, it's such a great project; and thanks for the update here!

I'm currently bundling SDCC (in conjunction with DevkitSMS) as one of a few tools into a docker image that I know a few people here are using and it's an interesting problem to stay up to date with different versions.

I might make a canary version with this RC on it and post back here in case anyone wants to try it out.

(Edit: Fixed my numbers were written the wrong way around - sorry about that! When I then transcribed them I wrote them flipped. Have edited this post to reflect the much nicer numbers 4.4.0 is putting out!)

Hey, thanks for all the work that you do. I compiled my little project just to see how it differs, and measured the output assembly.

For example, selecting each whole asm file with Z80 Assembly Meter in VScode gives...

Scene manager:
4.3.0 is 631 cycles
4.4.0 is 643 cycles (lil slower but nothing anyone would notice)

Fire effect:
4.3.0 is 784 cycles,
4.4.0 is 784 cycles (same, though the main loop is already hand-coded asm)

Scrolling scene:
4.3.0 is 2149 cycles,
4.4.0 is 1915 cycles (a little faster!)

Plasma effect:
4.3.0 is 3628 cycles,
4.4.0 is 2873 cycles (much faster -- wrote the numbers down the wrong way first time, sorry! This needs to be 100% pure hand-coded asm if I want it to be in any way performant, but plasma code makes my brain hurt heh)

I fully expect I'm probably just writing sub-optimal C, but may still be of interest as a "real world" example. I'd also hazard a guess that it's protecting memory and registers a bit better.

darkowl wrote

Hey, thanks for all the work that you do. I compiled my little project just to see how it differs, and the output assembly is sometimes a little faster but - at least with what I've written - can be quite a bit slower too.

Which options do you use to compile? In general, SDCC 4.4.0 should have better optimizations for speed for z80 than 4.3.0, so the generated asm should typically be faster (when using --opt-code-speed).

Interesting. Yes, I'm using --opt-code-speed.

Ahh... I see. I wrote down 4.4.0 first and then 4.3.0 second. I'll just edit my post above to correct that; the reverse should be true!

A few small increases, a few small decreases, but for the plasma especially a large decrease in cycles. I did a more thorough read-through of a diff between the two files and while I'm no z80 expert, I could see where the cycles were being saved. Nice!

If you suspect some of your C code to be "non-optimal" for the z80, feel free to post it, so we can have a look.
Also, the use of --max-allocs-per-node tends to have a strong effect on the quality of the code generated by SDCC.

Switching my new projects from 4.3 to 4.4 and what I have to say is that everything works without a single trouble, everything (smslib, psglib, and my own new projects) working without a single error.

Regards.

Just a quick question; looks like 4.4.0 was released, but the Windows 64-bit build seems to be missing?

https://sourceforge.net/projects/sdcc/files/sdcc-win64/4.4.0/ only has up to RC3, but other binaries (including Windows 32-bit) do seem to exist.

Author	Message
PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	SDCC 4.4.0 release candidate 1 available Posted: Fri Dec 22, 2023 7:28 am
	Dear fellow Sega 8-bit developers. I haven't posted here in a long time, and haven't found time to develop anything specifically for the Sega 8-bit systems (or the ColecoVision) 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 Sega 8-bit systems, 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.

willbritton Joined: 06 Mar 2022 Posts: 671 Location: London, UK	Posted: Fri Dec 22, 2023 10:02 am
	Hey @PkK, thanks for all your work on SDCC, it's such a great project; and thanks for the update here! I'm currently bundling SDCC (in conjunction with DevkitSMS) as one of a few tools into a docker image that I know a few people here are using and it's an interesting problem to stay up to date with different versions. I might make a canary version with this RC on it and post back here in case anyone wants to try it out.

darkowl Joined: 12 Dec 2021 Posts: 43 Location: Melbourne, Australia	Posted: Fri Dec 29, 2023 1:17 am Last edited by darkowl on Sat Dec 30, 2023 2:53 am; edited 4 times in total
	(Edit: Fixed my numbers were written the wrong way around - sorry about that! When I then transcribed them I wrote them flipped. Have edited this post to reflect the much nicer numbers 4.4.0 is putting out!) Hey, thanks for all the work that you do. I compiled my little project just to see how it differs, and measured the output assembly. For example, selecting each whole asm file with Z80 Assembly Meter in VScode gives... Scene manager: 4.3.0 is 631 cycles 4.4.0 is 643 cycles (lil slower but nothing anyone would notice) Fire effect: 4.3.0 is 784 cycles, 4.4.0 is 784 cycles (same, though the main loop is already hand-coded asm) Scrolling scene: 4.3.0 is 2149 cycles, 4.4.0 is 1915 cycles (a little faster!) Plasma effect: 4.3.0 is 3628 cycles, 4.4.0 is 2873 cycles (much faster -- wrote the numbers down the wrong way first time, sorry! This needs to be 100% pure hand-coded asm if I want it to be in any way performant, but plasma code makes my brain hurt heh) I fully expect I'm probably just writing sub-optimal C, but may still be of interest as a "real world" example. I'd also hazard a guess that it's protecting memory and registers a bit better.

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Fri Dec 29, 2023 5:24 pm
	darkowl wrote Hey, thanks for all the work that you do. I compiled my little project just to see how it differs, and the output assembly is sometimes a little faster but - at least with what I've written - can be quite a bit slower too. Which options do you use to compile? In general, SDCC 4.4.0 should have better optimizations for speed for z80 than 4.3.0, so the generated asm should typically be faster (when using --opt-code-speed).

darkowl Joined: 12 Dec 2021 Posts: 43 Location: Melbourne, Australia	Posted: Sat Dec 30, 2023 2:40 am
	Interesting. Yes, I'm using --opt-code-speed. Ahh... I see. I wrote down 4.4.0 first and then 4.3.0 second. I'll just edit my post above to correct that; the reverse should be true! A few small increases, a few small decreases, but for the plasma especially a large decrease in cycles. I did a more thorough read-through of a diff between the two files and while I'm no z80 expert, I could see where the cycles were being saved. Nice!

PkK Joined: 07 Aug 2007 Posts: 220 Location: Yach, Germany	Posted: Sat Dec 30, 2023 10:45 am
	If you suspect some of your C code to be "non-optimal" for the z80, feel free to post it, so we can have a look. Also, the use of --max-allocs-per-node tends to have a strong effect on the quality of the code generated by SDCC.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sun Dec 31, 2023 1:52 pm
	Switching my new projects from 4.3 to 4.4 and what I have to say is that everything works without a single trouble, everything (smslib, psglib, and my own new projects) working without a single error. Regards.

darkowl Joined: 12 Dec 2021 Posts: 43 Location: Melbourne, Australia	Posted: Sat Mar 02, 2024 12:43 am
	Just a quick question; looks like 4.4.0 was released, but the Windows 64-bit build seems to be missing? https://sourceforge.net/projects/sdcc/files/sdcc-win64/4.4.0/ only has up to RC3, but other binaries (including Windows 32-bit) do seem to exist.

Forums

View topic - SDCC 4.4.0 release candidate 1 available