Re: Linker ... still useful ?

guerin@IRO.UMontreal.CA writes:
>Especially useful when combining Assembler + High Lev Lang.
>But more and more HLL provide a way to put Asm code directly
>in the source code.


The only programming language to include such a feature in the *standard*
that I know of is Ada 83 (Ada 9X will retain this).


>Is there really an advantage to mix two HLL?


YES! What's more, there is no technical reason why it needs to be hard.
The Burroughs B6700 compilers (Algol, Fortran, COBOL, PL/I, and Tasmania
Pascal) and their linker (called the Binder) and the MCP co-operated to
make it very easy for a program to be made up of any mix of these
languages, and linking was type-safe. I used this system in early 60s.


>Even worst, many HLL don't provide the ability to be
>mixed because of the cryptic way they export their function name.


Please give details. On this UNIX system, I can mix C, C++, Fortran, and
Pascal straight out of the box. There are Lisp systems I can use that
will let me link code written in those languages and call them easily. I
used to work at Quintus: Quintus Prolog gave you a very simple foreign
function interface so that Prolog could call C, Fortran, and Pascal on all
the UNIX ports, C on IBM MVS & CMS, and Lisp on Xerox D-machines. More
recent versions of Quintus Prolog let C call Prolog as well.


The linker (ELF) and debugger (DWARF) interfaces for System V Release 4
were designed to make it easy to link C, C++, Pascal, Fortran, Ada 83,
Modula-2, and a couple of others I forget. VAX/VMS has of course been
there since about 1978.


Put it this way, do you really want to have to rewrite that Oracle
interface in Pascal because some xxxxx decided not to let you mix Pascal
and C code?


>This being because linkers are no more able to handle all the
>functionalities HLL want to.


I don't understand this. Linkers are tools for combining partially
compiled sources, whether they are written in several languages or one.
It is the *compilers'* responsibility to cope with whatever
"functionalities" it offers. The *only* thing you talk about is name
mangling, and it is worth pointing out that the only reason name mangling
ever came into existence is because Cfront *didn't* use the linker to
finish the job, it insisted on restricting itself to things that could be
expressed in C (with calls to support code).


>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 not the fault of the linkers. It is true of EVERY programming
language, by the way. I have used two C compilers, *from the same
vendor*, on the same hardware, where one of them converted "x" to "_x" and
the other didn't. There is nothing in the nature of a linker that forces
C++ compilers to use different name mangling schemes, and the AT&T name
mangling scheme is clearly described in their manual. As it happens, I
have C++ compilers from two different vendors on the UNIX system I am
using, and at one time had access to a third, and they all used the SAME
scheme. Don't blame the linker.


>For languages like C++, it seems that linkers are no more than just tools.


That's all they ever were.


>[It has always surprised me that what linkers do today is not much more, and
>in many cases less, than what they did 25 years ago. Perhaps the demands
>of C++ will make people think about what linkers can or should do. -John]


Does anyone have a really good tutorial introduction to ELF? The System
V Release 4 linker seems to be reporting type clashes in my C code, and
about time too.
--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
--

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