>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld writes: >This page http://deputy.cs.berkeley.edu/ has a link to this document http://hal.cs.berkeley.edu/cil/ >which describes a means to obtain three-address code here http://hal.cs.berkeley.edu/cil/ext.html#toc24 .
>>2007/7/08, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >>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 >>different). 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": _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir-rep.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir-rep.html) Ocaml: - The acronym CAML originally stood for Categorical Abstract Machine Language. - 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 object-oriented programming constructs that make it applicable for large-scale software engineering. - 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. CIL: - organizes C’s imperative features into expressions, instructions and statements based on the presence and absence of side-effects and control-flow. - Every statement can be annotated with successor and predecessor information. - CIL provides an integrated program representation that can be used with routines that require an AST (e.g. type-based analyses and pretty-printers), as well as with routines that require a CFG (e.g., dataflow analyses). - CIL also supports even lower-level representations (e.g., three-address code). Deputy: - 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 describe pointer bounds and other important program invariants. Deputy verifies that your program adheres to these invariants through a combination of compile-time and run-time checking. - Unlike other tools for checking C code, Deputy provides a flexible annotation language that allows you to describe many common programming idioms without changing your data structures. As a result, using Deputy requires less programmer 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 simply read about CIL and implement a few of CIL's ideas in "C" and use those in GCC. Deputy with CIL provides both a higher level and a lower level than the current implementation and would provide a "C" compiler that has more checks as opposed to one that always has a few bugs (upon which all the rest of the toolchain is built). Portions of the "C" testsuite that fail are a few years old. You mention "Better memory savings? Faster processing?". If that is all you want then what language do you think we would be using - hint it is not very portable. I respect the fact that people at Redhat are competent programmers, I do not know why you are dismissive of Berkeley, (or Rice, NYU, TAMU, or any of a number of places with ideas to contribute to your project). I was trying to keep my suggestion closely aligned 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 switch, simply have a look at what others are doing and incorporate the best ideas into your efforts. Your "tuple paper" seemed to end abruptly and was not fleshed out. Rob