All of this propositions are actual for SDCC 3.2.0 #8008 (Jul 6 2012).

1. Smart linking. It's very useable feature for restricted RAM size.
And it is very requested by ZX Spectrum Russian Community on zx.pk.ru forum.

Now SDCC adds to output file ALL functions from ALL included sources
(see function Best40Test_DoNotUsed in file Best40Test.c)

and from ALL specified libraries (all functions from Libs/z80/Best40.lib
are added to result file Best40Test.bin, though really used only 4).

The same I can say about unused constants and variables.

Maybe there is a key of compiler or sdcclib to turn on smart linker?

void Best40_PAINT (SHORTINT x, SHORTINT y)
{
__asm
          ...
          CALL    POINT$
__endasm;
}//PAINT
 
BOOLEAN Best40_POINT (SHORTINT x, SHORTINT y)
{
__asm
#ifdef __SDCC
          LD      IX,#0xFFFE
          ADD     IX,SP
#else
          POP     AF           // восст. стек для правильного выхода по RET
#endif
          LD      E,4(IX)      // координата X
          LD      D,5(IX)      // координата Y
          CALL    POINT$       // вызов POINT
          LD      L,A          // результат: 0 (FALSE) или не 0 (TRUE)
          RET
POINT$:   // если точка выключена, то ZF=1 (Z), иначе ZF=0 (NZ)
          ...
__endasm;
}//POINT

On 08.09.2012 00:34, Oleg N. Cher wrote:

>> Dear Philipp,
>>
>> Now it is not a bug report. I remember my promise to share ideas to
>> further improve of SDCC that gained experience in the process of
>> using SDCC.
>>
>> SDCC - the best C compiler for Z80 of the World - to make it better.
>> Yes, I love your work! It's great.
>>
>> I do not expect a quick response from you today or tomorrow. I like
>> the steps you have taken to improve the code generation. So take this
>> as the long term additional development notices.
>>
>> I've started this notices on my forum (posts for you is in English):
>>
>> viewtopic.php?f=10&t=32

I'll start with this one, since it is the shoter list:

1) The "smart" linking: The current linker behaviour is this: Link all
.rel files specified. The take from the libraries all the modules needed
to resolve dependencies. Example:

To the linker you specify rel files A and B and libraries X and Y.
Inside library X there are modules X1 and X2, inside Y there are modules
Y1 and Y2.
Assume that A contains function f, B contains function g (which calls
h), X1 contains h (which calls i), and Y2 contains i.

In that case A, B, X1 and Y2 will be linked into the result.

2) Passing parameters in registers is indeed something that could
improve code in some cases, and I intend to take a closer look at it
some time, but I don't know when.

3) Optimizing constants: Have a look at RFE #1483474. There's also a bit
of discussion on when memory is needed (i.e. normal const, which could
be used in another source file vs. static const, which means the const
is only visible in the local source file). So this is on the to-do list
(but so are many other things).

4) Assigning aggregates and unions: Leland has been working on this at
some time during summer, but then ran out of time. I hope he picks up
the work later this year.

5) I agree and have just created RFE #3565707, so this will not be
forgotten.

6) In terms of register allcoation, some restirctions were dropped. This
results in a) better code than ever before when using a high
--max-allocs-per-node value b) somewhat worse code and slower
compilation when using a small --max-allocs-per-node value (such as the
default). So it essentially provides the option of even better
optimization for those who are willing to increase compile times a bit,
but results in worse behaviour in other cases. Also note that the
tree-decomposition heuristic we use is not perfect, so the planned
implementation of a better heuristic should help with compilation speed
and code size a bit. See also bug report #3418072.

Philipp