Executable size affected by module count?

Sean Kelly sean at f4.ca
Thu Jan 25 11:52:33 PST 2007


Frits van Bommel wrote:
> Sean Kelly wrote:
>> Frits van Bommel wrote:
>>> Sean Kelly wrote:
>>>> Thomas Kuehne wrote:
>>>>> Every non-trivial module contains (numbers are for Linux)
>>>>> _D5module7__arrayZ
>>>>> 23 bytes code, 19 bytes stringtab, 18 bytes symtab
>>>>>
>>>>> _D5module8__assertFiZv
>>>>> 24 bytes code, 23 bytes stringtab, 18 bytes symtab
>>>>
>>>> These are the outstanding problem for exposing templates from 
>>>> library code.  And I don't understand why they are generated, since 
>>>> it seems like the code will be identical for each instance 
>>>> generated.  Couldn't they just have a static definition in the runtime?
>>>
>>> In their current form they're not identical for each module, for the 
>>> simple reason that the code (after linking) has the reference to the 
>>> module name string hardcoded.
>>> For two extra instructions per call that could be avoided, though at 
>>> that point you might as well just call _d_assert/_d_arraybounds 
>>> directly instead of using an intermediary function...
>>
>> Exactly my point.  Why not define _d_assert and _d_arraybounds somewhere 
> 
> Please look at phobos/std/asserterror.d and phobos/std/array.d[1]. I 
> didn't just pick those names out of a hat ;).

It's been too long since I've messed with this portion of Phobos.  I 
knew they rang a bell! :-p

> What the generated functions do is basically:
> asm {
>     push EAX;           // caller puts line number there
>     push name_ptr;
>     push name_length;
>     call _d_assert;     // or _d_array_bounds
> }
> Like I said, this can easily be inlined. Replacing "mov EAX, linenr" 
> with three pushes and using a different address is all it takes...
> 
> In fact, it would seem calls to _d_assert_msg are already done like this 
> (for asserts with the optional char[] second argument).

Makes perfect sense.  Well... doing this would eliminate one of the last 
quantifiable issues with placing templates in a library, so it has my vote.


Sean



More information about the Digitalmars-d mailing list