From: | "Tony" <tony@my.net> |
Newsgroups: | comp.compilers |
Date: | Sun, 15 Feb 2009 21:23:32 -0600 |
Organization: | at&t http://my.att.net/ |
References: | 09-02-021 09-02-035 09-02-054 09-02-075 |
Keywords: | design |
Posted-Date: | 16 Feb 2009 04:30:43 EST |
"cr88192" <cr88192@hotmail.com> wrote in message
> "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.
A parse tree or AST can be the IR. The IR doesn't have to be something in
between the AST and code generation.
Tony
Return to the
comp.compilers page.
Search the
comp.compilers archives again.