Re: What makes a compiler, was Is Assembler

"cr88192" <cr88192@hotmail.com>
Thu, 19 Feb 2009 06:54:58 +1000

          From comp.compilers

Related articles
[2 earlier articles]
Re: Is Assembler Language essential in compiler construction? tony@my.net (Tony) (2009-02-14)
Re: What makes a compiler, was Is Assembler lkrupp@pssw.com (Louis Krupp) (2009-02-14)
Re: What makes a compiler, was Is Assembler haberg_20080406@math.su.se (Hans Aberg) (2009-02-15)
Re: What makes a compiler, was Is Assembler cr88192@hotmail.com (cr88192) (2009-02-16)
Re: What makes a compiler, was Is Assembler tony@my.net (Tony) (2009-02-15)
Re: What makes a compiler, was Is Assembler tony@my.net (Tony) (2009-02-15)
Re: What makes a compiler, was Is Assembler cr88192@hotmail.com (cr88192) (2009-02-19)
Re: What makes a compiler, was Is Assembler walter@bytecraft.com (Walter Banks) (2009-02-19)
Re: What makes a compiler, was Is Assembler cr88192@hotmail.com (cr88192) (2009-02-21)
| List of all articles for this month |

From: "cr88192" <cr88192@hotmail.com>
Newsgroups: comp.compilers
Date: Thu, 19 Feb 2009 06:54:58 +1000
Organization: albasani.net
References: 09-02-021 09-02-035 09-02-054 09-02-069 09-02-080
Keywords: design
Posted-Date: 18 Feb 2009 17:13:18 EST

"Tony" <tony@my.net> wrote in message news:09-02-080@comp.compilers...
> "Louis Krupp" <lkrupp@pssw.com> wrote in message
>> Tony 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 wouldn't say that. I can't speak to modern Unisys MCP-Series
>> software, but most Burroughs compilers used a single pass that read
>> source code and emitted machine code. There was no intermediate
>> representation.
>
> I'd call that translation then if indeed it didn't internally produce some
> IR. It sounds like programming the machine at a macro level is all.
> [No, see note at end. -John]


a compiler usually does a little more than a macro processor, but in a
general sense they are related.


a way I can regard the process is that the whole thing "winds up" when
processing the input, much like a mechanical clock, and "unwinds" when
producing output.


so, one can twist the key a bunch, and use a few other adjustment knobs, ...
and then the thing starts ticking and the output is produced (in the form of
the hands moving, alarms going off at the right time, ...). yet a clock is
only a single pass, and there is little obvious and direct relation between
the movement of ones' hands and the output of the clock.


this is not the same as, say, a manually-operated coffee grinder or butter
churn, where the actions of the user are directly reflected in the device's
internal movements (crank the handle, grind the coffee, reciprocate the
shaft and churn the butter, ...).




>> An intermediate representation might enable translation from more source
>> languages to a wider range of target architectures and with better
>> optimization, but from the definitions I've seen, a compiler is a
>> program that translates source code to machine code. The implementation
>> details are interesting but are not part of the definition.
>
> I'll have to disagree with you. Where have you seen the definition of
> 'compiler' as "a program that translates source code to machine code"?
> Surely today, that is invalid even if it ever was valid.
>
> Tony
> [The Burroughs compilers are real Algol compilers. If you're not worried
> about optimization, it's quite possible to generate adquate code on the
> fly from each grammar rule. See Irons classic 1961 paper on Syntax
> Directed Translation. -John]


I had once thought of this and considered it might even be possible to
compile a C-subset this way. it had seemed like a way to make a very
fast and lightweight compiler, as it could avoid much of the overhead
of managing internal structures and going through some number of
stages.


however, I don't think full C could be compiled this way (or, at least
not C99), and I am not even sure some things could be compiled propery
(for example: the source has function arguments in left-to-right
order, but many calling conventions require right-to-left ordering,
...).


but, yes, a C subset where some "variations" are allowed, it could work...


AFAIK, many GLSL compilers are single-pass as well?...
[The K&R C compiler processed one expression at a time. A function call is an
expression, so getting the order of the arguments correct was no problem. Due to
the need to fit each pass into 24K bytes, the first pass generated control flow code,
the second did expressions, and optional third did a peephole pass over the assembler
source, and then there was the 1 1/2 pass assembler. -John]





Post a followup to this message

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