Multi language programming

Dave Lloyd <dave@occl-cam.demon.co.uk>
Mon, 13 Nov 1995 18:22:59 GMT

          From comp.compilers

Related articles
Multi language programming guerin@IRO.UMontreal.CA (1995-11-03)
Re: Multi language programming martelli@cadlab.it (1995-11-12)
Multi language programming dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-13)
Re: Multi language programming guerin@IRO.UMontreal.CA (1995-11-17)
Re: Multi language programming shankar@engr.sgi.com (1995-11-20)
Re: Multi language programming Robert.Corbett@Eng.Sun.COM (1995-11-21)
Re: Multi language programming dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-27)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Dave Lloyd <dave@occl-cam.demon.co.uk>
Keywords: linker
Organization: Compilers Central
References: 95-11-044
Date: Mon, 13 Nov 1995 18:22:59 GMT

> [Sad to report that I've known lots of cases where different compilers for
> the same language on the same machine use different calling sequences and
> name mangles. Even C compilers usually mangle a little, e.g. adding _ before
> the name. -John]


This isn't sad. This really is expected. And desirable. Most
languages (even C, but particularly Ada, Algol68, Fortran90) leave a
great deal of flexibility in representation to the implementor. This
goes beyond simple system dependencies like word-size or alignment
that you may expect to be constant on a platform. There was a
discussion a short while back on the representation of arrays which
highlighted many of the reasons for implementor preferences not being
portable.


Unfortunately the prevalence of C and, worse, the prevalence of the
Unix notion that all C compilers are interchangeable means that C
(used to be Pascal a while back) usually ends up as the lowest common
denominator for what the system API defines (VMS being an honourable
exception). Since most languages also have runtime system
dependencies (try calling most C routines without having started via
main and watch the sparks), it makes sense to distinguish between
calls within the language and those without (this is one use of the
term "external") and have the compiler, conceptually at least,
generate thunks for calls to the external routines which conform to a
standard convention: There have been many attempts to define
mixed-language (and hence mixed-compiler) calling standards over the
years but the industry seems amazingly reluctant to pick up on them
(TDF or ANDF being the closest to success that I know of and even
that has annoying assumptions). This is a shame and wastes a lot of
effort and ultimately results in unrobust composite systems that are
quietly waiting for a push in the wrong place.


As for mangling, that I'm afraid is merely a sad reflection of the
fact that we are still stuck with sixties' linkers designed solely
for FORTRAN IV (C still has to get beyond independent external
compilation units in a global namespace and C compilers rather than
Fortran compilers now hold back progress). However it does provide
some basic protection against fools fiddling with things beyond their
ken. Once the linker errors come up you know you're playing with fire
and tend to be suitably wary.


Regards,
----------------------------------------------------------------------
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
--


Post a followup to this message

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