SDCC 4.2.0 to be released in February

[PkK]

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.

 

Philipp
(SDCC 4.2.0 release manager)

 

Edited February 10, 2022 by PkK

[artrag]

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 ?

https://github.com/santiontanon/mdlz80optimizer

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

 

 

 

 

[PkK]

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.

 

Philipp

 

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 February 12, 2022 by PkK

[artrag]

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! 

 

 

[PkK]

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).

[PkK]

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:

 

http://sourceforge.net/projects/sdcc/files/

Edited February 22, 2022 by PkK
Spell "doc" fully as "documentation"

[artrag]

Going to test! Thanks!!

PS

MDL is working very well on SDCC. It cuts away hundreds of z80 cycles and bytes even at the lowest depth of search.

If you have 5 minutes of spare time, you should definitely have a look on what it does on the ASM files generated by SDCC.

 

[PkK]

SDCC 4.2.0 has bee released today.

[AnalogKid]

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 March 17, 2022 by AnalogKid