SDCC 4.1.0 was released

بواسطة Bengalack

Champion (414)

صورة Bengalack

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 Smile Works fine with Fusion-C too, once you rebuild the lib with an updated version of ericb59's build-script.

Some official text:

Quote:

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

Login أوregister لوضع تعليقاتك

بواسطة aoineko

Master (165)

صورة aoineko

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.

بواسطة Bengalack

Champion (414)

صورة Bengalack

22-03-2021, 22:47

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

بواسطة geijoenr

Champion (275)

صورة geijoenr

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.

بواسطة aoineko

Master (165)

صورة aoineko

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

بواسطة geijoenr

Champion (275)

صورة geijoenr

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.

بواسطة salutte

Master (137)

صورة salutte

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.

بواسطة Bengalack

Champion (414)

صورة Bengalack

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?

بواسطة salutte

Master (137)

صورة salutte

24-03-2021, 11:37

Bengalack wrote:

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?

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.

بواسطة Bengalack

Champion (414)

صورة Bengalack

13-04-2021, 19:46

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