Related articles |
---|
Using C as a back end predictor@my-deja.com (Pred.) (2000-10-19) |
Re: Using C as a back end jim.granville@designtools.co.nz (Jim Granville) (2000-10-22) |
Re: Using C as a back end peteg@cse.unsw.edu.au (Peter Gammie) (2000-10-22) |
Re: Using C as a back end frido@q-software-solutions.com (Friedrich Dominicus) (2000-10-22) |
Re: Using C as a back end joachim_d@gmx.de (Joachim Durchholz) (2000-10-22) |
Re: Using C as a back end jacob@jacob.remcomp.fr (jacob navia) (2000-10-22) |
Re: Using C as a back end nr@labrador.eecs.harvard.edu (2000-10-22) |
Re: Using C as a back end sjmeyer@www.tdl.com (2000-10-23) |
Re: Using C as a back end lazzaro@cs.berkeley.edu (2000-10-23) |
Re: Using C as a back end predictor@my-deja.com (Pred.) (2000-10-23) |
[25 later articles] |
From: | Friedrich Dominicus <frido@q-software-solutions.com> |
Newsgroups: | comp.compilers |
Date: | 22 Oct 2000 01:19:41 -0400 |
Organization: | Q Software Solutions GmbH |
References: | 00-10-148 |
Keywords: | C, translator |
"Pred." <predictor@my-deja.com> writes:
> I have designed a language for which I'm hoping to create a compiler.
> Since I want a portable solution I was thinking about using a
> retargable C or C++ compiler in the back end along with appropriate
> assembler / linkers. Is this a good solution?
It is often done and, seems to be a reasonable solution.
> I see the following pros and cons:
>
> PROS:
> 1. I don't have to learn about / write code generators for the various
> targets
But the Backend has to run an all those. The problem is that you get
just up to a certain point, beyond that you have to use extensions on
either side.
> 2. "Tried'n'true" back end
surely. C have used so often in that area that the even can cope with
generated code ;-)
> 3. Shorter time-to-market
That's a open point. Assume you are targeting just one platform and
you know this platform quite well, you might be able to do a better
job than others while the support more platforms. But usually I would
say yes. (But the code-generation is just one part, and it's not the
biggest one)
>
> CONS:
> 1. Slower compilation (scan + parse occurs twice)
Unfortunatly yes.
> 2. No control over new versions of the back end
That is a real disadvantage. If you follow Eiffel history, you'll see
what problem occur.
>
> Have there been any work on good ways to transform one language into C
> source?
As I mentioned above. A lot languages get compiled to C, and most of
them are open sources so you can look into it.
>
> Any comments?
You may consider searching for one Compiler developer, which works
closly together with you and who is in control of the planned Backend.
That what we are doing. We had a simular problem, and we solved it
that way. The main advantage I can see in it that the Backend provider
knows his compiler in and out. And because of that he can surely help
working on eliminating the C intermediate step. So you got more
advantages, you can concentrate on C in the beginning, and the C
Backend provider can care about eliminating the C step and this can
gradualy done, because he controls his or her compiler.
> [Lots of compilers use C as a back end, including the original Eiffel and
> C++ compilers. -John]
The only "native" Eiffel compiler is Visual Eiffel from Object Tools
all other are using C as Backend. But in the mean time they even
provide facilities for interfacing to C++
Regards
Friedrich Dominicus
Return to the
comp.compilers page.
Search the
comp.compilers archives again.