From: | "cr88192" <cr88192@hotmail.com> |
Newsgroups: | comp.compilers |
Date: | Mon, 16 Feb 2009 07:27:28 +1000 |
Organization: | albasani.net |
References: | 09-02-021 09-02-035 09-02-054 |
Keywords: | design |
Posted-Date: | 15 Feb 2009 18:36:07 EST |
"Tony" <tony@my.net> wrote
> "Hans Aberg" <haberg_20080406@math.su.se> wrote in message
>> marco.m.petersen@gmail.com wrote:
>>> I mean, if you wrote a program that converts code from BASIC to C++
>>> then calls another compiler to do the compilation process, wouldn't
>>> that be considered as a compiler?
>>
>> Yes, formally a compiler just translates one computer language into
>> another. For example, an assembler translates into the machine code
>> language.
>
> I would say that is simply translation and not compilation because there
> is
> no intermediate representation. The IR (and the creation of it via
> lex/parse/semantic analysis before code generation) is what I think
> distinguishes compilers from interpreters and translators.
>
I will disagree here...
it is not an IR which makes it a compiler, and infact many simpler compilers
for many languages may lack an IR altogether...
rather, I think it is more about the semantic symmetry between the
input and the output. a translator will usually translate between one
form and another, where both forms represent more or less the same
semantics, and can be translated between one and the other with little
or no loss of information (a translator then bases its operation
primarily on the input and output, converting from one form into
another, with the internal machinery of the translator being of
minimal significance).
so, for example, an assembler can convert ASM to machine code, and a
disassembler can (more or less), get it back...
compilers are typically far less symmetric, where what a compiler
produces can typically not be converted back into what it came from,
and usually there is a strong divergence in terms of the semantics
between the input and output (the relation being not so much based on
the relative structure of the input and output, rather it is based on
the internals of the compiler itself...).
but, many tools may fall into a gray area between these extremes.
or such...
Return to the
comp.compilers page.
Search the
comp.compilers archives again.