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