Compilers - Compiler vs. Translator

Author

Compiler vs. Translator

Paul Robinson

2004-05-17, 12:31 am

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.

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.

I think someone once said that every programmer has three things they
will want to tackle in their life: to write an operating system, to
build their own computer and to write a compiler. Well, I've done the
first two, and now I'm discovering the difference between a translator
and a compiler and I realize just how many things you have to think
about when you're compiling a source program, and how you have much
more leniency when it's "just" a translator. But let me offer my
suggestions on (some of) the differences between the two. Other
people might have more ideas or might have a better statement about
this:

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.
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.)
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.

I wrote programs in FORTRAN for over five years and I've learned more
about the language in the last two w

s - 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.

I have been a programmer for over 24 years. I did not realize the
complexity of the task which I had in front of me (or I might have
either asked for more money or not bid on it) but given what has
happened, I have learned so much about how text processing of source
languages is done that I am amazed at what I have accomplished. I also
have to admit I've never had as much fun doing a program as I have on
this one. Once this is finished (and doing the project has given me so
many more ideas that I know it will be finished) - somewhat faster than
I originally feared when I realized how big a piece I had bit into - I
will be able to proudly look back on what I've done as some of the best
work I've accomplished.

"I did not expect it to be as great as this - or as hard." - Dr. Hugh
Akston in Ayn Rand's "Atlas Shrugged"

--
Paul Robinson "Above all else... We shall go on..."
"...And continue!"

[I wouldn't expect it to be much easier to translate Fortran into VB
than to translate Fortran into assembler or machine code. The
gratuitous but inevitable semantic differences among various
Fortran-like languages practically force you to compile into something
very low level, then pattern match to get the code in the target
language. You might want to look at f2c which is the old f77 compiler
with a new back end to generate C rather than assembler. -John]

dido@imperium.ph

2004-05-24, 1:32 am

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 w

s - 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.

glen herrmannsfeldt

2004-05-24, 1:32 am

Paul Robinson wrote:
(snip)

> 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.

Interesting idea. About 30 years ago I was working on a program to
translate HP BASIC into Fortran. I didn't actually finish it, but the
description of it was useful on the written part of my college
applications.

(snip)

> I'm discovering the difference between a translator
> and a compiler and I realize just how many things you have to think
> about when you're compiling a source program, and how you have much
> more leniency when it's "just" a translator.

(snip)

> 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.

You could do that, but then you could for a compiler, too.
What will your translator do when given incorrect input?

In the early days of C, there was a program called lint,
separate from the compiler, which gave more detailed messages,
and checked things that compilers usually didn't.

There are some translators which are more like preprocessors which
will translate incorrect input to incorrect output. The user must
then figure out the meaning of the messages that result from compiling
the output. (Ratfor and MORTRAN are somewhat that way, both with
Fortran as the target.)

> 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.)

In the case where you are translating a fairly simple language into a
more powerful language, you might be able to use some of the features
on the target language to simplify the translator. Otherwise, it
probably isn't so much different.

> 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.

> I wrote programs in FORTRAN for over five years and I've learned more
> about the language in the last two w

s - 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.

If you read comp.lang.fortran many of those details come up as people
run into them. Many of the problems of compiling Fortran are well
known by now. (If I remember right, it is almost 50 years old.)

> 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.

Just wondering, Fortran 66, 77, 90, 95, or 2003?

-- glen

Richard F. Man

2004-05-24, 1:32 am

As the moderator said, this is a very complex problem. Depending on
the FORTRAN dialect, it may be many many man years of work. I would
suggest that if you can, back out of the bid, unless they are paying
you in the order of many hundreds of thousands or more.

Paul Robinson wrote:

> ....
> 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.
>

--
// richard
http://www.imagecraft.com

Martin Ward

2004-06-03, 7:28 pm

On Monday 24 May 2004 5:21 am, dido@imperium.ph wrote:
> 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.

In theory, yes. In practice there is a huge difference. ("The
difference between theory and practice is that in *theory* there is no
difference between theory and practice, but in *practice* there is").

A translator usually has to generate nice, structured, maintainable
code in the target language which makes use of idioms in the target
language where possible. A compiler can generate any code it likes,
however ugly, which is syntactically valid for the target language.

A compiler has to cope with any valid syntax in the source language,
and generate semantically equivalent code in the target language. A
translator usually has a fixed body of code that it is required to
translate, and may have some leeway over rarely used idioms which are
hard to translate automatically (generating a "FIXME" comment with
manual intevention required to complete the task).

A compiler usually has to do optimisation. A translator can rely on
the compiler for the target language to do optimisation: in fact, it
should *not* do optimisations which affect readability of the code.

A compiler is translating from a higher level language to a lower
level language (or to a low level subset of the target language). A
translator is usually translating from a high level language to
another high level language, or from a low level language to a high
level language. For example, translating from assembler language to C
or COBOL (see http://www.cse.dmu.ac.uk/~mward/martin/papers/ for
example).

--
Martin
Martin.Ward@durham.ac.uk http://www.cse.dmu.ac.uk/~mward/
[I agree that they're different, but contrary to what one might hope,
a translator is certainly no easier to write. -John]

glen herrmannsfeldt

2004-06-03, 7:28 pm

dido@imperium.ph wrote:

(snip regarding Fortran to VB translator)

> 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.

(snip)

> 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.

Well, the ones I know are called preprocessors, instead.

Consider Ratfor and MORTRAN2, both meant to improve Fortran,
and will accept many Fortran statements with little modification.

Also, many errors will go straight through to the Fortran
compiler compiling the output.

It doesn't seem that any such preprocessors (not counting
the C preprocessor) have been very popular, though.

> 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.

I thought it would be the other way around. Though it isn't
so much the number of features, but the specific features
that are needed.

(snip)

-- glen

Hannah Schroeter

2004-06-06, 3:59 pm

Hello!

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>[...]

>It doesn't seem that any such preprocessors (not counting
>the C preprocessor) have been very popular, though.

What about cfront, before good "direct" C++ compilers came up?

>[...]

Kind regards,

Hannah.
[Cfront was a compiler, not a translator. Its output was intended to be fed to
a C compiler, but not to be readable or maintainable by people. -John]

Sponsored Links