"Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
news:ceslnv$164e$1@digitaldaemon.com
| Since I posted my post, however, Lars has indicated that the linker is
actually
| cleverer than I had thought, and might be able to do that sort of thing at the
| function level. It doesn't appear to do that automatically, but - if I've
| understood the documentation correctly - it can be made to do that with some
| command line parameters. More experimentation is needed. When someone gets
| function-body-elimination working, I hope they post an example.
|
| Jill

In a final exe, how can I know if a function body is there or not? If you tell, I can help with that ;)

-----------------------
Carlos Santander Bernal

In article <cet74t$1ieu$1@digitaldaemon.com>, Carlos Santander B. says...
>
>In a final exe, how can I know if a function body is there or not? If you tell, I can help with that ;)

Well, one easy way would be to include the following function - and /don't/ call it.

#    const byte LOOKUP[1000000];
#    byte f(int n)
#    {
#        return LOOKUP[n];
#    }

If the resulting executable is over a megabyte large then it's a fair bet that that the unused f and LOOKUP have not been eliminated.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
news:cet8g3$1j5u$1@digitaldaemon.com
| Well, one easy way would be to include the following function - and /don't/
call
| it.
|
| #    const byte LOOKUP[1000000];
| #    byte f(int n)
| #    {
| #        return LOOKUP[n];
| #    }
|
| If the resulting executable is over a megabyte large then it's a fair bet that
| that the unused f and LOOKUP have not been eliminated.
|
| Jill

(After adding void main () {} )
72200 bytes. Compiler flags don't change anything.

-----------------------
Carlos Santander Bernal

In article <ceu358$22e1$1@digitaldaemon.com>, Carlos Santander B. says...
>
>"Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
>news:cet8g3$1j5u$1@digitaldaemon.com
>| Well, one easy way would be to include the following function - and /don't/
>call
>| it.
>|
>| #    const byte LOOKUP[1000000];
>| #    byte f(int n)
>| #    {
>| #        return LOOKUP[n];
>| #    }
>|
>| If the resulting executable is over a megabyte large then it's a fair bet that
>| that the unused f and LOOKUP have not been eliminated.
>|
>| Jill
>
>(After adding void main () {} )
>72200 bytes. Compiler flags don't change anything.

Wow. Sounds like you've got it.

You could try changing

#    const byte LOOKUP[1000000];

to

#    const byte LOOKUP[100000] =
#    [
#        /* One hundred thousand bytes of initialized random data */
#    ];

and if /that/ still works, I'd say you've definitely licked the problem! (This is almost exactly what my own lookup functions do, you see. If this can be made to work then we're rolling!

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
news:cevac8$2tsm$1@digitaldaemon.com
| Wow. Sounds like you've got it.
|
| You could try changing
|
| #    const byte LOOKUP[1000000];
|
| to
|
| #    const byte LOOKUP[100000] =
| #    [
| #        /* One hundred thousand bytes of initialized random data */
| #    ];
|
| and if /that/ still works, I'd say you've definitely licked the problem! (This
| is almost exactly what my own lookup functions do, you see. If this can be
made
| to work then we're rolling!
|
| Arcane Jill

Sorry, can't do that: DMD ran out of memory on my computer. Somebody else can try. Compile the file generated by this:

//////////////////////////////
import std.stream;

void main ()
{
    auto MemoryStream ms = new MemoryStream;
    ms.writeLine ( "const byte LOOKUP[1000000] = [" );
    for ( uint i=1; i<50000; ++i )
        ms.writeLine ( "0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9," );
    ms.writeLine ( "0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9];" );
    ms.writeLine ( "byte f(int n) { return LOOKUP[n]; } void main () {}" );
    ms.position = 0;
    auto BufferedFile bf = new BufferedFile ( "test.d", FileMode.Out );
    bf.copyFrom ( ms );
}
//////////////////////////////

The file would be over 2MB.

-----------------------
Carlos Santander Bernal

Carlos Santander B. wrote:

> 
> The file would be over 2MB.

DMD on Linux, compiled (1 GB RAM) and the size is exactly 2.0Mb.

Carlos Santander B. wrote:

> "Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje
> news:cevac8$2tsm$1@digitaldaemon.com
> | Wow. Sounds like you've got it.
> |
> | You could try changing
> |
> | #    const byte LOOKUP[1000000];
> |
> | to
> |
> | #    const byte LOOKUP[100000] =
> | #    [
> | #        /* One hundred thousand bytes of initialized random data */
> | #    ];
> |
> | and if /that/ still works, I'd say you've definitely licked the problem!
> | (This is almost exactly what my own lookup functions do, you see. If
> | this can be
> made
> | to work then we're rolling!
> |
> | Arcane Jill
> 
> Sorry, can't do that: DMD ran out of memory on my computer. Somebody else can try. Compile the file generated by this:
> 
> //////////////////////////////
> import std.stream;
> 
> void main ()
> {
>     auto MemoryStream ms = new MemoryStream;
>     ms.writeLine ( "const byte LOOKUP[1000000] = [" );
>     for ( uint i=1; i<50000; ++i )
>         ms.writeLine ( "0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9," );
>     ms.writeLine ( "0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9];" );
>     ms.writeLine ( "byte f(int n) { return LOOKUP[n]; } void main () {}"
>     ); ms.position = 0;
>     auto BufferedFile bf = new BufferedFile ( "test.d", FileMode.Out );
>     bf.copyFrom ( ms );
> }
> //////////////////////////////
> 
> The file would be over 2MB.
> 

Of course the generated .d file is 2Mb but the executable "test" is 1.1Mb

"Juanjo Álvarez" <juanjuxNO@SPAMyahoo.es> escribió en el mensaje
news:cf1bm6$18t9$1@digitaldaemon.com
| DMD on Linux, compiled (1 GB RAM) and the size is exactly 2.0Mb.

But that'd be for the gcc linker. What about OPTLINK? Can you test it on Windows?

-----------------------
Carlos Santander Bernal

The digitalmars linker understands special directives in modules which denote the borders of what needs to be pulled in for each symbol. These are generated automatically when compiling into a lib, or have to be turned on manually otherwise. Thus it is able to link in separate functions and not only whole modules.

Other linkers may or may not have a similar feature, most seem to. The GNU ld for Windows apparently doesn't, but ld doesn't have much in common between platforms, so elsewhere it probably does.

Where you are right about "indivisibleness" is a class: it pulls in the VTable which references all of its functions, which will then have to be linked in. However Sather (the language which only supports whole-program compilation) also dealed with that, by analyzing what methods can potentially be called. It did a grand lot of analysis of what can be inlined, eliminated, etc. So i think we should be able to escape the bloatware curse this way someday, but we much now make sure that the spec doesn't prevent such analysis.

-eye