
Firm: a C library with graph-based IR suitable for compilers - vmorgulis
http://pp.ipd.kit.edu/firm/Index
======
mpixorg
Another interesting comparison between clang/llvm and cparser/firm has to do
with their respective preprocessors and underlying AST structures. cparser's
entity_t and related structures are clean, clear, and very easy to work with.
That, together with the fact that cparser is written in C, allows you to
effortlessly walk the AST while having access to its entire informationwithout
the help of an iterator, and without having to call any specialized functions.
Having worked with both (lib)clang and (lib)cparser, I consider cparser the
better and easier library for source analysis, as well source-to-source
transformation tools. Other areas where cparser's AST could be nicely
exploited: a source editor that provides, in addition to syntax highlighting,
information about linkage and effective optimization, and a source generation
tool based on the user's own code gallery.

------
lindig
The following code crashes the compiler but is accepted by GCC.

    
    
        static float b5[0][0] = {};
        int main(void)
        {
            return 0;
        }
    

I have filed a bug report.

~~~
PeCaN
0-length arrays are a GNU C extension[1].

In ISO C99, they're only permitted as the last member of a struct with another
member, and are written with an empty pair of brackets[] and no 0.

1\. [https://gcc.gnu.org/onlinedocs/gcc/Zero-
Length.html](https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html)

~~~
lindig
The compiler is described on its home page as "accompanying GCC-compatible C
frontend." So what does this mean with respect to GCC features? In any case, I
don't think the compiler should crash but report a syntax error.

~~~
Rotluchs
It's sufficiently compatible to handle e.g. glibc, which is quite a feat,
because it uses many and somewhat obscure gcc extensions.

------
lindig
I'd be curious about the following aspects: since we have enough good C
compilers we rather need code generators for languages that do things
differently than C. In particular, how difficult is it to generate code for
the following things:

1\. Exceptions. There are several ways to implement exceptions: stack walking
or stack cutting.

2\. Calling conventions. A language might want to use internally a different
calling convention than the one dictated by the ABI.

3\. Garbage collection. This requires interaction with the runtime system
which must know which values are pointers into the heap.

4\. Tail call optimization.

There are probably other modern language features that require support from
the code generator. Could you comment on how the design of the code generator
(in rough sketches) account for these?

~~~
qznc
Due to the development of the X10 frontend, Firm gained more support for
object oriented features (stack allocation, devirtualization) and exceptions
are next.

Firm is well suited for anything natively compiled (Rust, Go, etc). Support
for precise garbage collection would be nice. Nobody is working on this atm.

~~~
sitkack
Having a second Rust compiler would be awesome and a true validation of the
language.

------
ericfrederich
Differences between this and LLVM? I feel it should at least be mentioned on
their page.

~~~
dyspept0r
There's also this mail in the freebsd list archives on the subject. Not sure
how current it is, but it gives more names of algorithms and people in case
one wants to dig deeper. [https://lists.freebsd.org/pipermail/freebsd-
hackers/2008-Nov...](https://lists.freebsd.org/pipermail/freebsd-
hackers/2008-November/026848.html)

~~~
Rotluchs
The main points of this (i.e my) post on the mailing list still apply.
Nowadays everything is even more nice. (:

