Related articles |
---|
Sharing code and data in multi-language environments hulaas@lcodec1.epfl.ch (1993-05-24) |
Re: Sharing code and data in multi-language environments tmb@arolla.idiap.ch (1993-05-24) |
Re: Sharing code and data in multi-language environments prener@watson.ibm.com (1993-05-25) |
Re: Sharing code and data in multi-language environments henry@zoo.toronto.edu (1993-05-27) |
Newsgroups: | comp.compilers |
From: | prener@watson.ibm.com (Dan Prener) |
Keywords: | linker, design |
Organization: | IBM T.J. Watson Research Center, Hawthorne, New York |
References: | 93-05-113 |
Date: | Tue, 25 May 1993 08:24:52 GMT |
hulaas@lcodec1.epfl.ch writes:
> It seems to me that one of the weakest points in a compiler system would
> be syntactic and semantic control in presence of multi-language modules.
> ... Therefore, possible research fields could be:
> - Linkers cooperating with compilers to enforce that kind of checking;
> - Utilities translating interfaces from one language to another;
> - Formalisms describing data, types, routine profiles, calling mechanisms,
> parameter passing and so on independently from any particular language;
> What do you think ? Have you ever heard of any work on this field ?
The pl.8 compiler research project at IBM did some work on this. Part of
the work involved linkers checking types of external objects, both data
and procedures, from separate compilations. The compiler included in its
output a hash of a canonicalized version of the declaration of external
objects. The linker checked that the hashes matched.
This approach is used by the linker under AIX, on the RS/6000. Of course,
the compiler production of such type-checking information is optional,
since much old code would break if consistency were enforced. But, if the
type information is presented to the linker, it will do the checking.
Another part of your quest was also dealt with in the pl.8 project. The
pl.8 compiler compiled several languages (our own pl.8, C, and Pascal).
However, the front ends for these languages were far from disjoint. They
shared much code, and also used an internal dictionary format that was
capable of representing the union of the languages. Furthermore, the
compiler had the ability to pre-digest declarations into its internal
dictionary format. This was primarily done for compile-time efficiency.
However, it gave the ability for a pre-digested set of declarations from
one language to be used when compiling another.
For both function and robustness, I would say that the technique of
non-disjoint front ends was quite good. On the other hand, from the
points of view of speed of development (in particular, the ability to have
different teams producing the various front ends at the same time), and of
modularity, it could be a little cumbersome.
--
Dan Prener (prener@watson.ibm.com)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.