Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3041 > unrolled thread

Re: Are there "compiler generators"?

Back to article view | Back to comp.compilers

Contents

  Re: Are there "compiler generators"? Roger L Costello <costello@mitre.org> - 2022-06-01 11:23 +0000
    Re: Are there "compiler generators"? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2022-06-01 18:05 +0000
    Re: Are there "compiler generators"? gah4 <gah4@u.washington.edu> - 2022-06-01 14:02 -0700
    Re: Are there "compiler generators"? "minf...@arcor.de" <minforth@arcor.de> - 2022-06-07 07:22 -0700
      Re: Are there "compiler generators"? Thomas Koenig <tkoenig@netcologne.de> - 2022-06-07 18:34 +0000

#3041 — Re: Are there "compiler generators"?

Page 161 of the book "Introducing Compiling Techniques" by J.P. Bennett says:
---------------------
Code generator generators

Just as there are parser generators, so there are code generator
generators. In general they all use the same idea, to match patterns
of instructions generated by the front end to patterns of instructions
available to the target machine.

IBURG

Iburg generates a fast tree parser. It takes a grammar describing the
patterns to be matched, with actions that generate the target code.
The grammar is augmented by the 'cost' of the code generated, and is
in general ambiguous. The Iburg generated parser finds the lowest cost
parse of a given sentence. Typically the cost will be the execution
time of the code, but for a compiler concerned with compact code
generation, it could be code size.

The idea of using a grammar to describe target code, and finding the
lowest cost parse, in order to generate the best code predates Iburg.
An early system due to Susan Graham used YACC productions to achieve
the same end.

---------------------

Wow!

So a compiler can be generated declaratively by using a set of
declarative generator tools, e.g., Flex for lexical analysis, Bison
for syntax/semantic analysis, and Iburg for code generation.

Has anyone used this combination of tools to create a whole compiler?

/Roger
[I expect that someone has used lex, yacc, and iburg in the same
compiler sometime in the past 30 years. But that doesn't mean that
they combine into a compiler generator any more than a saw, a hammer,
and a paintbrush combine into a house generator. They're tools, each
does what it does. -John]

[toc] | [next] | [standalone]

#3042

Roger L Costello <costello@mitre.org> writes:
>So a compiler can be generated declaratively by using a set of
>declarative generator tools, e.g., Flex for lexical analysis, Bison
>for syntax/semantic analysis, and Iburg for code generation.
>
>Has anyone used this combination of tools to create a whole compiler?

The students taking my compiler course build such compilers: one
compiler per student, implementing a different small programming
language every year.  They also use Ox (an attribute grammar evaluator
generator) for getting more structure into the in-between part.
Instead of iburg, they can also use burg, which has the same
interface.

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

[toc] | [prev] | [next] | [standalone]

#3043

On Wednesday, June 1, 2022 at 10:24:49 AM UTC-7, Roger L Costello wrote:

(snip)

> So a compiler can be generated declaratively by using a set of
> declarative generator tools, e.g., Flex for lexical analysis, Bison
> for syntax/semantic analysis, and Iburg for code generation.

(snip, our moderator mentioned)
> [I expect that someone has used lex, yacc, and iburg in the same
> compiler sometime in the past 30 years. But that doesn't mean that
> they combine into a compiler generator any more than a saw, a hammer,
> and a paintbrush combine into a house generator. They're tools, each
> does what it does. -John]

There are now 3D printed houses, such as using computer controlled
concrete pouring devices.  One could accept a computerized design
for a house, and then generate it in concrete.  (I think you still need
to do the interior finishing the old way.)

One could write a system around flex, bison, and iburg, that would
accept as input a description of the language, and the output
machine instructions, that would call flex, bison, and iburg as
needed.  The description could be a slightly higher level,
or as flex/bison input with minimal wrapper.
(Maybe not so much optimization, as that tends to be more
specialized.  It could be useful as a first compiler for
a new machine.)

Many imperative languages are similar enough in structure
that it might almost work. It might be especially interesting
for those wanting to make small changes to existing
languages.

Well, I would choose a higher level language than the usual C
for output of lexer and parser.  A language with just the operations
needed for a target compiler.

One could, then, use the code generator not only for the output
from the generated compiler, but for the compiler itself.
(Assume it is for a new machine, with no compilers yet.)

[toc] | [prev] | [next] | [standalone]

#3055

Roger L Costello schrieb am Mittwoch, 1. Juni 2022 um 19:24:49 UTC+2:
> So a compiler can be generated declaratively by using a set of
> declarative generator tools, e.g., Flex for lexical analysis, Bison
> for syntax/semantic analysis, and Iburg for code generation.
>
> Has anyone used this combination of tools to create a whole compiler?

This is a hot AI research field. 'Deep compilers' touch topics like
least cost parsing and optimization of other compilation steps.
But AFAIU there is no such holistic thing like automatic complete
compiler construction a la
Compiler = f (grammar, software-infrastructure, target-hardware)

Some state of the art overview:
https://github.com/zwang4/awesome-machine-learning-in-compilers

OTOH code generators based on graphical input are already "old hats".

[toc] | [prev] | [next] | [standalone]

#3057

minf...@arcor.de <minforth@arcor.de> schrieb:

> But AFAIU there is no such holistic thing like automatic complete
> compiler construction a la
> Compiler = f (grammar, software-infrastructure, target-hardware)

This function misses "semantics" as an argument, probably the
biggest hurdle.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web