Redundant data/code by linking objects.

[denc4]

I've got some seperate "code libraries" I wrote myself, which
I link to an object file. And later on link it into my final
program. i.e. I've got a file with file routines, one for string routines, etc.

When I link a program which does not use ALL, but SOME
routines in one or more of my object files, MASM (6.11) seems to include the whole object file!

result: a larger than needed .COM file.

I wrote a simple test file with only the following contents:

assume cs:cseg, ds:cseg, es:cseg, ss:cseg

  cseg segment para public

  org 100h
  main proc near
    mov ah,2
    mov dl,1
    int 21h
    int 20h
  main endp

cseg ends
end main

..and linked it with an arbitrary object file. Even though
the test file does not use ANY routines of the object, MASM
included the whole frickin' file. result: a .COM file of
about 1k (!).

Any idea how to change this linker behaviour?

 

[TessaBonting]

You can't make the linker do things it is not build for.

- rewrite the obj in smaler parts
- rebuild the link file with those.

The linker is not able to know if some part of your
code is using near data, code etc if within a object file
So you must tell him that bij splitting up the code
yourself

succes, Tessa

 

[denc4]

I used to program in Turbo Pascal, this compiler DID remove
unused functions and procedures from units when building the
main program. This must be a high level language feature
then..

Stupid it does not support this though, it saves disk space
and reduces load times.

How hard can it be for a compiler? just don't include any
functions that are not "call"ed in the main program file.

O well, there must be some underlying factor that I'm
missing here..

 

[lionelhill]

It's actually quite a complicated job, assessing whether a procedure could be called or not. Think about a call dx instruction... if you've got one of them (anywhere), then the compiler and linker cannot be sure what near procedures are called, because it doesn't know the runtime value of dx. Worse still are people (like me) who do absolute far jumps by pushing the address and doing retf; do that with an address that passes through registers and the compiler hasn't a hope of guessing to where the jump will occur.

Pascal can do it because pascal forces a bit more discipline on the programmer about how they call their functions and procedures. If nothing else, you can't call a procedure without refering to it by name (thereby letting the compiler know it's used) because you don't know its address.

 

[TessaBonting]

You forget that these pascal function have themselfs also
a portion of redundant code.
But you couldn't see the real differance.

If you use timefunctions, all the code for timefunctions
is loaded and not just the gettime().

So only if you split all your code up in very tiny objects
you will have the overhead in all languges.

Tessa

 

[lionelhill]

probably depends on version of pascal etc., and is probably different for different units.

For user-written units in Turbo pascal 5.0 and 6.0, the only ones I've checked, all user procedures and functions that are not referenced explicitly are omitted from the final compilation; it works on an individual function/procedure basis.

If you declare a unit in the interface section of some other unit, then the initialization code of that unit is run anyway, together with any procedures/functions refered to in the initialization code (i.e. the stuff between begin and end. without a procedure name).

 

[denc4]

OK, ofcourse it cannot determine where a "call bx" or
"call [bx]" will end up. I was talking about a call with
a symbolic name after it:

call proc1
call RebootPC
etc..

Or better yet, do not include procs that are not extern'd or
externdef'd. That would be an option. But still, if I could
have thought of it, Microsoft certainly would have. So even
that solution probably would have yielded some problems..

I will remove any procs that I do not use for a project,
before I link the lot, like Tessa said.

There is obviously no other choice, unfortunately.