Jump to content

SDCC 4.2.0 to be released in February


Recommended Posts

An SDCC 4.2.0 release is expected in February. For those of you that want to use 4.2.0, now is a last chance to check if there are any issues affecting you that could still be fixed before the release.


Major changes since 4.1.0:


* C23 memset_explicit
* Support for --oldralloc has been removed from the z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends.
* gbz80 port now uses more efficient block-initalization of global variables (users of custom a crt0 need to adapt theirs).
* Full support for __z88dk_callee for the z80, z180, gbz80, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka, stm8 backends.
* Support for __raisonance, __iar and __cosmic calling conventions for stm8.
* Support for a new __sdcccall(1) calling convention in the stm8 port AS NEW DEFAULT.
* Support for a new __sdcccall(1) calling convention in the gbz80 port AS NEW DEFAULT.
* Support for a new __sdcccall(1) calling convention in the z80, z80n and z180 ports AS NEW DEFAULT.
* Support for a new __sdcccall(1) calling convention in the r2k, r2ka, r3k, tlcs90 and ez80_z80 ports.
* Removed support for --profile for gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends.
* The z80n port Z80N Core minimum version has been raised from 1.0 to 2.0.
* Improved rematerialization support in the stm8, gbz80, z80, z180, tlcs90, z80n, ez80_z80, r2k, r2ka, r3ka backends.
* The gbz80 port was renamed to sm83.
* New in-development mos6502 port.


(SDCC 4.2.0 release manager)


Edited by PkK
  • Like 1
Link to comment
Share on other sites

Greetings ! __sdcccall(1) allows a huge improvement in performance. I'm testing v4.1.14 and the compiler gives faster and shorter code

Nevertheless I'm a bit surprised that BC is not used as parameter if the functions need to pass 3 parameters (only A/HL and DE are used) .

Moreover the ASM generated still has margins to improve. The peephole optimizer probably needs some extra rule.

Have you considered this project ?


It optimizes the ASM generated by SDCC (and others) applying multiple strategies





Link to comment
Share on other sites

The new calling convention was found by

1) Adding flexibility to SDCC so it can handle nearly any register for arguments in any order.

2) Doing lots of experiments to see what works best (for SDCC).

3) Choosing what worked best as new convention.


Note the "(for SDCC)" in 2). It turned out that current SDCC can't handle a large number of register arguments well. When more arguments are put in registers, on average, SDCC spends too much effort shuffling data around in registers, and is hindered by a lack of free registers. One aspect it that the arguments are considered one at a time, so also the number of arguments, not just the total amount of registers matters. Example: if the ABI has one int argument in hl, the other int in de, but for code generation the opposite would be better, an assembler programmer would just use ex de, hl. But SDCC currently can't do that well (on the other hand, if it is a single long argument, SDCC will use ex de, hl if codegen prefers the upper and lower half swapped).

So the new ABI is something that works very well for SDCC; for assembler programmers it surely is a step forward too, but assembler programmers could use more register arguments well than SDCC can.

IMO this new calling convention should be good enough for the next 10 years or so.




P.S.: A few details: https://arxiv.org/abs/2112.01397


P.P.S.: I haven't looked at MDL recently. When I did a while ago using it on some code generated by SDCC, I found more MDL bugs than potential for improvement in SDCC. But the bugs are fixed now, and I assume MDl has progressed further, so the situation is likely different today.

Edited by PkK
Link to comment
Share on other sites

  • 2 weeks later...
On 2/14/2022 at 4:32 PM, artrag said:

Thanks for the explanation! My wish is that the compiler will become more and more able in using alternate registers and exchange instructions, in the meanwhile I eager to put my hands on the v4.2

Great work! 



I can't speak for all SDCC developers, but me and two other developers intend to focus on improving standard-compliance this summer (and thus for 4.3.0).

Link to comment
Share on other sites

Release Candidate 1 for 4.2.0 has been prepared. Source, documentation and binary packages for amd64 GNU/Linux, 32 and 64 bit Windows and amd64 macOS are available in corresponding folders at the usual  place:



Edited by PkK
Spell "doc" fully as "documentation"
  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

I rebuilt a cvlib-based project with 4.2.0, after rebuilding the libraries of course, compared the asm output to 4.1.0 and saw the obvious improvements, and then tried to run the rom... nothing.  In Gearleco the VDP viewer shows that the name table, pattern table, and sprite table are full of garbage and the program is stuck on a HALT waiting for an interrupt.   ?   Existing asm libraries need to be updated or else the library header files will need to be updated with __sdcccall(0) for things to keep working.


Update: I modified the header files, adding __sdcccall(0) to functions with parameters and/or return values, and that fixed everything.  Aside from the function call optimization, 4.2.0 does appear to generate slightly better assembly code.

Edited by AnalogKid
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...