This is the mail archive of the
mailing list for the GCC project.
Re: RFC: GIMPLE tuples. Design and implementation proposal
- From: Rob1weld at aol dot com
- To: "Diego Novillo" <dnovillo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 9 Jul 2007 03:30:15 EDT
- Subject: Re: RFC: GIMPLE tuples. Design and implementation proposal
>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
>This page http://deputy.cs.berkeley.edu/ has a link to this document
>which describes a means to obtain three-address code here
>>2007/7/08, Diego Novillo <firstname.lastname@example.org_
>>Any specific reasons why we should? Better memory savings? Faster
>>processing? It's not clear from your message what the advantages would
>>be (ignoring the fact that their implementation language is completely
And ignoring that portions of GCC are not written in "C": examples being the
use of configure scripts to spit out snippets of "C" to (test for compiler
features), use of flex, yacc, the various files generated and then compiled.
GCC is not 'just "C"' - probably be more portable if it were ...
An example of a project using ML for "Intermediate Representation":
- The acronym CAML originally stood for Categorical Abstract Machine
- It has a large standard library that makes it useful for many of the same
applications as Python or Perl, as well as robust modular and
programming constructs that make it applicable for large-scale software
- ML-derived languages are best known for their static type systems and
type-inferring compilers. OCaml unifies functional, imperative, and
object-oriented programming under an ML-like type system.
- OCaml's static type system eliminates a large class of programmer errors
that may cause problems at runtime. However, it also forces the programmer
to conform to the constraints of the type system, which can require careful
thought and close attention. A type-inferring compiler greatly reduces the
need for manual type annotations.
- OCaml is perhaps most distinguished from other languages with origins in
academia by its emphasis on performance. Firstly, its static type system
renders runtime type mismatches impossible, and thus obviates the need for
runtime type and safety checks that burden the performance of dynamically
typed languages, while still guaranteeing runtime safety.
- Also the reason that you made mention of, CIL is written in that language.
The object (and library) files are completely linkable with "C" code.
- organizes Câs imperative features into expressions, instructions and
based on the presence and absence of side-effects and control-flow.
- Every statement can be annotated with successor and predecessor
- CIL provides an integrated program representation that can be used with
that require an AST (e.g. type-based analyses and pretty-printers), as well
routines that require a CFG (e.g., dataflow analyses).
- CIL also supports even lower-level representations (e.g., three-address
- Deputy is implemented using the CIL infrastructure for C program analysis
and transformation, and it uses GCC as a back end.
- Deputy is a C compiler that is capable of preventing common C programming
errors, including out-of-bounds memory accesses as well as many other common
type-safety errors. It is designed to work on real-world code, up to and
including the Linux kernel itself.
- Deputy allows C programmers to provide simple type annotations that
pointer bounds and other important program invariants. Deputy verifies that
your program adheres to these invariants through a combination of
and run-time checking.
- Unlike other tools for checking C code, Deputy provides a flexible
language that allows you to describe many common programming idioms without
changing your data structures. As a result, using Deputy requires less
effort than other tools. In fact, code compiled with Deputy can be linked
directly with code compiled by other C compilers, so you can choose exactly
when and where to use Deputy within your C project.
I think you will find that Deputy is like "C" with a few extra comment lines.
Of course you do not have to have the advantages of using Deputy. You can
read about CIL and implement a few of CIL's ideas in "C" and use those in
Deputy with CIL provides both a higher level and a lower level than the
implementation and would provide a "C" compiler that has more checks as
one that always has a few bugs (upon which all the rest of the toolchain is
Portions of the "C" testsuite that fail are a few years old.
You mention "Better memory savings? Faster processing?". If that is all you
then what language do you think we would be using - hint it is not very
I respect the fact that people at Redhat are competent programmers, I do not
you are dismissive of Berkeley, (or Rice, NYU, TAMU, or any of a number of
ideas to contribute to your project). I was trying to keep my suggestion
to your goal rather than to give you a "do it this way - it is better"
argument and suggest
you follow a different course of action.
Have you tried to compile GCC 4.3 with CIL ? I have. You are not required to
simply have a look at what others are doing and incorporate the best ideas
efforts. Your "tuple paper" seemed to end abruptly and was not fleshed out.