Re: Linker ... still useful ?

guerin@IRO.UMontreal.CA wrote:
-snip-
>No, what I want to question in fact is linking as a process different from
>compilation, as a real step in the process of building executables.
-snip-
>As a real step, linkers provide "implementation hiding" of used source
>code. Hence a company can furnish precompiled code without the user beeing
>able to figure out how the functionalities are implemented, assuming you
>don't want to reveal your secret trick ... Is this really the case ?? Is
>this really useful ??


It is certainly very useful, most library providers would not want to
provide source. (Many that provide code for interpreted languages such as
lisp where the srouce can be regenerated use encryption so customers cant
see it). Also object code libraries usually are more compact than source,
which means less disk space used. These days more and more of a program
comes from a library written by some one else. Do you write your own
window system these days? Also look at the developments of DLLs.


>As another real step, linker provide the ability to put together
>precompiled code from different source language. Especially useful when
>combining Assembler + High Lev Lang. But more and more HLL provide a way


Less and less provide this in my view. As optimizing compilers get more
sophisticated this becomes very difficult to provide. Also many very high
level languages (if I can call them that - such as application generators)
and even tools such as LEX and YACC compile down to another high level
language (such as C) so can't provide this anyway.


>to put Asm code directly in the source code. Is there really an advantage
>to mix two HLL ? Even worst, many HLL don't provide the ability to be
>mixed because of the cryptic way they export their function name. This
>beeing because linkers are no more able to handle all the functionalities
>HLL want to.


It is often necessary to mix high level languages in large projects. One
reason is libraries are developed in different places, and often purchased
from third parties (eg the operating system library) who may have used
other languages. Old libraries developed in old languages may be reused.
We have had programs that have included pascal, fortran and C code all at
once. How many C programs include LEX or YACC code or call the NAG
library (Fortran) or even talk to the operating system (assembler). It is
also becoming common to use application generators to generate specific
parts of the program such as user interfaces, database interfaces or
parsers. In my view it is going to become more common for large
applications to be built from parts written in different languages, with
specialist languages for specialist parts. See Martin Griss'es ideas on
software factories.


>Take a look at C++, implementation is definitely not as hidden as it could
>be, the language not hiding the private part of object, encouraging
>inlining, and template. Hence sacrificing implementation hiding to speed
>of the executable. Every company has its own way of encrypting function
>name so as to do type checking and overloading. C++ from X is even not
>linkable with C++ from Y.


This is a standardization issue and quality of implementation issue - most
sane operating system vendors provide a common calling and naming standard
for the operating system so that things can be linked because they know it
is needed. If X's third pary compiler does not work with other languages
on system Y then don't buy it. This is a real problem area and is probably
holding up the development of C++ object libraries for sale as not only do
you have to support your library for different machines you also have to
support different compilers as well. What happens if your customer uses
Eifel? Why can't your C++ objects be used with his/her Eifel code? Its a
poor state of affairs indeed.


-snip-
>Is there still a place for linkers as real step toward the making of
>executable ???


Yes. I think we are coming to a time when there will be a major step
forward in linker technology. It is needed for reuslable code. DLLs are
only just the start of it.


Stephen Baynes baynes@mulsoc2.serigate.philips.nl
Philips Semicondutors Ltd
Southampton
United Kingdom
--

Return to the comp.compilers page.
Search the comp.compilers archives again.