This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CIL back-end

Ori Bernstein wrote:
On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <> said:


I'm working for an R&D organization of STMicroelectronics. Within our team we have decided to write a gcc back-end that produces CIL binaries (compliant with ECMA specification, see
Our main motivation is the ability to produce highly-optimized CIL binaries out of plain C code (and C++ in the future), and possibly to add some optimizations to improve, if needed, the quality of the generated code.

It seems that there's a Summer of Code student working on the exact same item:

Perhaps you could collaborate with him, or (as I believe the Summer of Code
rules might require) build off his work after it gets submitted. I'd suggest
you contact the Mono project about it.

Thanks for the info.
A few days ago, the student posted a help request to gcc-help mailing list (, which shows he's at an early stage of the work.
I think in my team we're at a more advanced stage, since we have ideas about how to do things and we start having some prototype code.
I hope a collaboration is possible; I will certainly contact him and the mentor of the SoC project about it. If there are restrictions imposed by SoC rules, it's up to them to let me know.

By the way, from the previous messages, I understand that the inclusion of a CIL back-end into gcc cannot be taken as granted until the issue is discussed and an approval is obtained.
In the meantime, I hope this doesn't prevent requesting a development branch. Without that, it would be much more difficult to build a collaborative, open and world-wide visible development environment.

Not working on the development of the CIL back-end, or even letting it stalled, is not a choice for my team and myself.
What is a choice is to share its development and the related infrastructure in the most open way... I think it's the best choice, for all parties; I really hope it's a viable one!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]