Executable size affected by module count?

kris foo at bar.com
Thu Jan 25 13:05:17 PST 2007


Sean Kelly wrote:
> 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


Mine too



More information about the Digitalmars-d mailing list