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