SDCC 4.1.0 was released

Hero (590)

22-03-2021, 21:00

Maybe people know this, but it certainly went under my radar.

Anyways, I'm very happy with the new version. Several of my (rather serious) issues have been resolved, and the new version seems to work fine in my current project. It generates smaller files than v4.0.0 also, which I need Works fine with Fusion-C too, once you rebuild the lib with an updated version of ericb59's build-script.

Some official text:

引用:

The official release for SDCC 4.1.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 32- and 64-bit Windows, 64-bit macOS, and x86_64 GNU/Linux.

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

New z80n port for the Spectrum Next CPU (a Z80 variant).
Much better register allocation in the gbz80 backend.
Workarounds for Rabbit wait state bugs in the r2k backend
New r2ka port to better support Rabbit 2000A, 2000B, 2000C, 3000.
Default crt0 and --data-loc for Rabbits suitable for typical Rabbit hardware configurations, such as the RCMs.
Many improvements in code generation for z80 and related ports.
Rabbit register definition headers for Rabbit 2000, 2000A, 2000B, 2000C, 3000, 3000A.
C23 digit separators.

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

ログイン/登録して投稿

By aoineko

Champion (477)

22-03-2021, 22:04

If you are using SDCC and want to make it more efficient, I suggest you support this request to improve function parameter passing via registers: https://sourceforge.net/p/sdcc/feature-requests/253/.
Passing parameters through the stack has a disastrous impact on performance with a Z80 processor. There are plenty of cases where you could do without it by using registers. This is the purpose of this feature request which has been in the SDCC todo list for some time but has not yet been prioritized. You can help to change this.

By Bengalack

Hero (590)

22-03-2021, 22:47

Yup! Seems like improvements will come in 4.2.0. Currently I’m using __z88dk_fastcall wherever I can

By geijoenr

Champion (314)

22-03-2021, 23:42

The code generation in sdcc is quite complicated as it is, no wonder this is not yet prioritized. Pushing everything to the stack allows for easier register allocation because the scope is clearly defined. Given the small amount of registers in z80 this looks like a hell of a feature to implement.

By aoineko

Champion (477)

23-03-2021, 00:11

geijoenr wrote:

Given the small amount of registers in z80 this looks like a hell of a feature to implement.

According to the function parameter size, __z88dk_fastcall already use 1, 2 or 4 of the Z80 8-bits registers (L, HL, and HL+DE respectively).
I don't think we need more. The biggest problem of __z88dk_fastcall is the fact we can only use 1 parameter.
We can use 4 registers by passing a 32-bits value to our function, but not to send two 8-bits values. :-/
If we could use __z88dk_fastcall with any combination of values up to 32-bits (4 registers), it would be enough to cover 80-90% of the hundreds of functions of my C lib for example. The performance gain would be very significant!

As a bonus, be able to chose the register mapping (my first 8-bits value go to A, my second got to L for ie.) it would allow to interface easily with assembler libraries (to take advantage of the very numerous Z80 routines over the web or to have simple access to the Bios functions).

By geijoenr

Champion (314)

23-03-2021, 00:12

well, let's see what happens with the feature then.

do you know you can use __naked as well to skip the preambles? maybe that also helps in the meantime.

By salutte

Master (161)

23-03-2021, 10:03

I have been playing with SDCC 4.1.0 and I found that the SDASZ80 included now breaks my linker. The object code now has version XL3 instead of XL2 of the previous versions. Luckily I can compile with SDCC 4.1.0 to assembler, and I can use the SDASZ80 from 4.0.0.

Code generation definitely has improved, and also compilation times.

By Bengalack

Hero (590)

23-03-2021, 20:52

Not sure what xl3/xl2 is, but I just found out that @santiontanon's mdl optimizer does not produce a working application anymore. (no errors at build time, its just that the application does not work correctly). Maybe this is due to a new SDASZ80?

By salutte

Master (161)

24-03-2021, 11:37

Bengalack wrote:

The ".rel" files in 4.0.0 start by "XL2", while the ".rel" files in 4.1.0 start by "XL3". I have not investigated the difference, but it is significant enough to break my linker. I can confirm that the code generation for z80 targets is WAY better. A code that compiled to 1834 bytes on 4.0.0 now compiles to 1421 bytes!!!

On the other hand, I am finding very hard to track Heisenbugs in my newest game on very complex functions. These bugs appear even if I do not apply MLD.

I'll investigate further.

By Bengalack

Hero (590)

13-04-2021, 19:46

Philipp Klaus Krause states in this thread that he's working on it. It's a start at least: