Re: Compiler vs. Translator

dido@imperium.ph
24 May 2004 00:21:25 -0400

          From comp.compilers

Related articles
Compiler vs. Translator postmaster@paul.washington.dc.us (Paul Robinson) (2004-05-16)
Re: Compiler vs. Translator dido@imperium.ph (2004-05-24)
Re: Compiler vs. Translator gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-05-24)
Re: Compiler vs. Translator richard@imagecraft.com (Richard F. Man) (2004-05-24)
Re: Compiler vs. Translator Martin.Ward@durham.ac.uk (Martin Ward) (2004-05-30)
Re: Compiler vs. Translator gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-05-30)
Re: Compiler vs. Translator hannah@schlund.de (2004-06-06)
Re: Compiler vs. Translator jburgy@hotmail.com (2004-06-15)
| List of all articles for this month |

From: dido@imperium.ph
Newsgroups: comp.compilers
Date: 24 May 2004 00:21:25 -0400
Organization: Compilers Central
References: 04-05-051
Keywords: translator
Posted-Date: 24 May 2004 00:21:25 EDT
Content-Disposition: inline

On Sun, May 16, 2004 at 11:39:20PM -0400, Paul Robinson wrote:
> I wanted to start by mentioning something I hadn't thought about until
> the issue "dropped in my lap" so to speak and that's when it showed up
> on my radar screen, and became an issue I had to deal with. I had not
> considered the difference between a translator and a compiler.


There is no real difference between writing a compiler or a language
translator, actually. If you think about it, they're really the same
animal. What you'd call a compiler is actually a translator from your
high-level language into assembly language or straight machine code.
The differences between most high-level languages are about as great
as the differences they have with assembly language, I'm finding.


> What brought this on was that I happened to bid on a programming job
> on rentacoder.com to write a program (in Visual Basic, of course)
> which would translate programs written in FORTRAN into Visual Basic.
> Well, since I've written programs for years using both languages I
> decided to tackle this particular assignment.


OMG... Sounds like a real ugly mess. There exists a FORTRAN to C
translator, and what I can tell you is that it isn't pretty. The
compiler itself is (according to Dave Wheeler's sloccount) 26,640
source lines of code, and the accompanying runtime library is 9,609
SLOC's, giving a total of some 36,249 source lines of code, not a
minor project by any stretch. I suggest you give it a look at it
here:


http://www.netlib.org/f2c


Could give you some ideas on how to continue with your project.


> 1. A translator presumes the code is correctly formatted and would
> compile if passed to a compiler. Compilers syntactically scan code to
> find syntax errors and in some cases correct them.


Not necessarily. In most cases, a compiler for the source language is
not available, and it would be difficult for the translator to make such
assumptions. I don't think it would be acceptable for the translator to
generate incorrect code under any circumstances.


> 2. A translator produces only output for another compiler, a compiler
> (usually) generates object files and/or executables. (Some actual
> compilers generate source for another language or assembly.)


And if the compiler generates source for another language, how does that
make it different from a translator?


> 3. A translator makes certain assumptions about the code being
> presented to it, that it is a complete or reasonably complete piece of
> code. A compiler will check and (usually) complain if you hand it a
> fragment of a program.
>


Which is exactly the same...


Unless the source and target languages are very, very similar (in which
case a translator probably wouldn't really be worth writing most of the
time), a translator is essentially the same as a compiler. The more
distant the languages are, the easier it might become to just retarget
an existing compiler for the source language instead. Run-time issues
also tend to complicate matters as well, and the more run-time
facilities the target language provides that the source language
doesn't, the bigger the run-time library has to be. But then again
FORTRAN has less in the way of run-time facilities than VB does, except
for the fact that it does complex arithmetic natively, so this may be
less of an issue in your case.


> I wrote programs in FORTRAN for over five years and I've learned more
> about the language in the last two weeks - and probably more than I ever
> wanted to know - than I learned in the entire time I spent writing
> dozens of applications using the language. So I will say this: if you
> think you're weak in a particular programming language, consider writing
> a compiler or translator for it and you will realize things you had
> never imagined.
>


True, very true. I'm at the moment writing a compiler for the Limbo
programming language and it seems I've learned almost as much of how
the language works as anyone at Vita Nuova or Bell Labs/Lucent seems to
know. And I haven't actually written a single serious application in
Limbo yet... However, this presupposes you know the theory behind
writing compilers, so it's a pretty high-end route to learning a
language.


Post a followup to this message

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