[fpc-devel] don't you think it'stime toupdatedelphimodecompatibility? - IDispatch, implements

[Peter Vreman]

At 12:55 29-5-2005, you wrote:
>Daniël Mantione wrote:
>>Op Sat, 29 May 2004, schreef Matthias Hryniszak:
>>
>>>In addition comparing the sources of VCL and FCL they
>>>don't differ that much and the source isn't that much bigger so by this kind
>>>of differences the problem must lie with compiler/linker.
>>
>>It *is* the source. The compiler is perfectly capapable of removing unused
>>code ust as well as the Delphi compiler. So, if you're pointing at the
>>compiler I assume you either have smartlinking disabled or that there is
>>debug information in the executable.
>>However, not much time has been spent to make sysutils, classes etc.
>>smaller. This effort has been done on the system unit in the past, which
>>can explain the difference.
>>But then again, while I don't use the FCL very much, if have not yet seen
>>examples of unacceptable sizes yet.
>
>
>There are too many variables here to conclude decisively what is causing 
>it to be much bigger.
>
>Some things that will affect executable size include:
>
>1) Over zealous use of inlining (I dont see a command option to control 
>how much inlining is done)

There is almost none in the rtl.

>2) Pascal variables not making efficient use of registers. This causes 
>more load/store instructions to be generated than is needed (also produces 
>less optimal code!)

Use -Or. But don't think that it always generates less code. Sometimes the 
code is bigger on i386 because you get extra load/store operations for 
registers esi,edi,ebx that need to be preserved between function calls.


>3) Delphi includes a fair amount of assembler in its rtl.
>
>
>You should also compare FPC smartlinking with the equivalent in the Gnu 
>linker (dead code elimantion?) to see if there really is a difference.

The only way to get better smartlinking is to build an integrated linker in 
the compiler. That way we can control everything.


Peter