Related articles |
---|
mixed c and occam compiler amw298@ecs.soton.ac.uk (Andrew Woolley) (2001-02-12) |
Re: mixed c and occam compiler vbdis@aol.com (2001-02-15) |
Re: mixed c and occam compiler rog@vitanuova.com (2001-02-17) |
From: | vbdis@aol.com (VBDis) |
Newsgroups: | comp.compilers |
Date: | 15 Feb 2001 00:39:56 -0500 |
Organization: | AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com |
References: | 01-02-051 |
Keywords: | C, practice |
Posted-Date: | 15 Feb 2001 00:39:56 EST |
Andrew Woolley <amw298@ecs.soton.ac.uk> schreibt:
>For part of my third year Uni project I have to allow for a mixture of
>c and occam source.
The most severe problems can arise, when the runtime libraries of both
compilers are incompatible. Many languages have their own methods for e.g. I/O
and memory management, which
a) must be initialized at program start
b) can conflict with each other
The risk of such conflicts is low, when all compilers are provided by
the same company, so that they most probably use the same runtime
system.
In the worst case you have to rewrite the system libraries of both
compilers, into a commonly usable library. That new library then
includes the glue, to receive all resource related system calls,
created by every compiler, and to handle the requests in a common
procedure.
In practice it should be sufficient to use one runtime system as
provided by one of the compilers, and to add a library of stubs, which
translate the system calls of the other compiler(s) into calls to the
used runtime system.
When the system subroutines have the same name, but different
operation, the problem is harder to solve. Then you must rename the
conflicting symbols to something unique, for every different routine,
and you also provide the code for the renamed symbols.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.