Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Nov 2008 23:48:53 +0100
From:      Christoph Mallon <christoph.mallon@gmx.de>
To:        Max Laier <max@love2party.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: New C compiler and analyzer lang/cparser in ports
Message-ID:  <492F23D5.3000009@gmx.de>
In-Reply-To: <200811272257.01287.max@love2party.net>
References:  <492F0591.7050807@gmx.de> <200811272257.01287.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier schrieb:
> On Thursday 27 November 2008 21:39:45 Christoph Mallon wrote:
>> A few days ago libFIRM[1] and cparser were added to the ports tree. If
>> you want to see, what other compilers besides GCC have to offer, this
>> might be of interest for you. libFIRM is a modern optimizing
>> intermediate representation (IR) library. cparser is a C compiler
>> providing many useful warnings and uses libFIRM for optimization and
>> code generation.
> 
> Nice stuff!  I remember from a practical work with libFIRM that it is quite 
> pleasant to work with (though there is a bit of a learning curve).

Yes, some design desicions of FIRM seem odd at first - like the use of 
data dependencies instead of data flow, but once you "get it" it's quite 
easy. Also you constantly have to maintain SSA form. Sometimes I seems 
to be a hassle, but usually it prevents you from doing stupid things and 
when you think about how to do the same thing in non-SSA, you realise 
how much more hassle that would be. (-:

> How are the chances of this code staying under GPL2?  I suppose there is no 
> chance to get it dual-licensed under BSDL as well?

I do not want to speculate about this. libFIRM is an university project 
and I have no idea how hard something like relicensing would be.

> In addition, how much work is it to build missing backends?  It seems like 
> there is no amd64 or sparc support at the moment?

AMD64 should not be too hard. It is (naturally) very similar to IA32, so 
basically some extensions to the instruction selection and the ABI 
transformation should suffice. Other backends need some more work, but a 
simple instruction selector can be done quite fast. Of course, 
efficiently using all features of the target machine is considerably 
more work. If the target is sufficiently "RISCy", all the later phases 
like spilling and register allocation can directly be used. There are 
architecures, which are very fancy and need much custom code, but none 
of the usual architectures like ARM and MIPS fall into this category. 
There are unfinished backends for other architecures, but the major 
obstacle to support more backends is the lack of manpower. If you know 
somebody, who wants to work as Hiwi or who is interested in a study or 
diploma thesis, send him to us. (-:

Regards
	Christoph



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?492F23D5.3000009>