sdcc 3.9.0 does not terminate compiling dc

[kenyapcomau]

Cloned today, 2019/05/29.

Build platform openSUSE 15.0 x86_64, gcc 7. sdcc 3.9.0 building for z80pack. Stuck compiling dc.

Also interrupting the build killed fcc but left sdcc running so SIGINT needs to be caught and propagated to sdcc.

[nick-lifx]

I have had persistent problems with this sort of thing.

I think it is because SDCC's register allocation algorithm is basically polynomial and tends to blow up when given a complex register allocation problem to solve.

I don't agree with spending excessive amounts of time optimizing in general, it would make sense when building release versions of software but usually is a bad thing.

As far as I know this cannot be turned off in SDCC. I've also fixed at least one bug in the generated code of sdcc, and that sort of thing costs you many hours to find and isolate.

My recommendation is not to use SDCC. If you do, you will frequently have to deal with problems of this type.

I'm working on a FUZIX port using the Amsterdam Compiler Kit's Z80 compiler, although admittedly it is said in the documentation that the ACK 8080 is faster than Z80. This comment may be out of date, so I will just have to see what happens when I try it.

I've temporarily switched to 6502 though, so the ACK Z80 port is not going to be done for a while. Any other idea in the meantime? Somebody suggested that z88dk might be worth a look.

[feilipu]

The z88dk has both sdcc and sccz80 compilers, through a front end zcc, and a number of other tools.

The code generated by sdcc is usually much smaller (more efficient) than sccz80. It can be controlled from very fast (and less optimised) to really slow and approaching optimal register allocations. Develop with fast settings. Release with slow settings. It is that simple.

• --max-allocs-per-node 5000 for development.
• --max-allocs-per-node 1000000 for release.

sccz80 is the house compiler. It is very fast, and is developed by z88dk developer @suborb, so we're in control of outcomes and patching.

sdcc is developed separately, and z88dk does patching to produce a zsdcc version, though these days it is quite close. The z88dk is trying to get to v3.9.0 as a standard for our v2.0 release. But we've not done the detailed testing required. There's more consensus and development effort momentum (people) with sdcc, so it is probably the best overall z80, z80-zxn, z180 compiler project to work with, imho.

[EtchedPixels]

If you take a look at the .travis.yml file or the make files you will see that you can do the build with FUZIX_CCOPTS=-Owhatever

dc does currently eat a lot of RAM with sdcc 3.9.0 (although it's better with the new graph code I think). I tend not to notice as I run with a fair amount of RAM and CPU cores.

I will take a look at the signal propogating. That sounds like a bug

[EtchedPixels]

I did look at sccz80 when I first started Fuzix but it couldn't do multidimensional arrays and wrote awful code as well as having a pile of other misbehaviours it seemed to have inherited from smallc.