On processors for D ~ decoupling

[Sean Kelly]

Walter Bright wrote:
> kris wrote:
>> Yes, that's correct. But typeinfo is a rather rudimetary part of the 
>> language support. Wouldn't you agree? If I, for example, declare an 
>> array of 10 bytes (static byte[10]) then I'm bound over to import 
>> std.string ~ simply because TypeInfo_StaticArray wants to use 
>> std.string.toString(int), rather than the C library version of itoa() 
>> or a "low-level support" version instead.
> 
> It has nothing to do with having a static byte[10] declaration. For the 
> program:
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> The only things referenced by the object file are _main, __acrtused_con, 
> and __Dmain. You can verify this by running obj2asm on the output, which 
> gives:
> 
> -------------------------------------
> _TEXT   segment dword use32 public 'CODE'       ;size is 0
> _TEXT   ends
> _DATA   segment para use32 public 'DATA'        ;size is 0
> _DATA   ends
> CONST   segment para use32 public 'CONST'       ;size is 0
> CONST   ends
> _BSS    segment para use32 public 'BSS' ;size is 10
> _BSS    ends
> FLAT    group
> includelib phobos.lib
>         extrn   _main
>         extrn   __acrtused_con
>         extrn   __Dmain
> __Dmain COMDAT flags=x0 attr=x0 align=x0
> 
> _TEXT   segment
>         assume  CS:_TEXT
> _TEXT   ends
> _DATA   segment
> _DATA   ends
> CONST   segment
> CONST   ends
> _BSS    segment
> _BSS    ends
> __Dmain comdat
>         assume  CS:__Dmain
>                 xor     EAX,EAX
>                 ret
> __Dmain ends
>         end
> ----------------------------------

As expected, building this against Ares produces the exact same output.

> Examining the .map file produced shows that only these functions are 
> pulled in from std.string:
> 
> 0002:00002364       _D3std6string7iswhiteFwZi  00404364
> 0002:000023A4       _D3std6string3cmpFAaAaZi   004043A4
> 0002:000023E8       _D3std6string4findFAawZi   004043E8
> 0002:00002450       _D3std6string8toStringFkZAa 00404450
> 0002:000024CC       _D3std6string9inPatternFwAaZi 004044CC
> 0002:00002520       _D3std6string6columnFAaiZk 00404520
> 
> I do not know offhand why a couple of those are pulled in, but I suggest 
> that obj2asm and the generated .map files are invaluable at determining 
> what pulls in what. Sometimes the results are surprising.

Do I have to do anything special to get this data in the .map file? 
Mine contains no function references at all.  Here's the first few lines 
(where it seems the function data should be):

  Start         Length     Name                   Class
  0002:00000000 0000E1B8H  _TEXT                  CODE 32-bit
  0002:0000E1B8 00000162H  ICODE                  ICODE 32-bit
  0003:00000000 00000004H  .CRT$XIA               DATA 32-bit

> It's just not a big deal. Try the following:
> 
> extern (C) int printf(char* f, ...) { return 0; }
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> and compare the difference in exe file sizes, with and without the 
> printf stub.

Compiled against Ares with "-release" specified, the EXE is 82,972 bytes 
without the stub and 82,972 bytes with the stub.  Compiled against 
Phobos, it's 87,068 bytes without the stub and 86,556 with the stub.  So 
you're right, it's not a big difference at all.  And neither is the ~5K 
executable size difference--I think the gap has actually closed over 
time, as I remember it being wider.  The zero byte difference for Ares 
is a bit confusing though.  I'll take a look at the binaries on my way 
home and see if I can suss out the differences.


Sean