[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Occam compiler using gcc


It's good to see people talking on this list again :-)

I am writing to ask your views on a project that I am considering putting a lot more effort into, having now done the initial investigation required.

I thought a while ago that it would make sense if we could bind together the ex-Inmos occam compiler that the KRoC project has been using with the GNU project's gcc compiler. Having looked at the sources for both, and how gcc copes with new languages, and spoken to a friend who happens to be a chief engineer on the Java fontend for gcc, I think this is quite possible -- even relatively easy.

I would expect the gcc backend to make mincemeat of occam code, as there will be many opportunities for optimization. Obviously, the standard debug tools will "just work", because we won't be playing with the object format creation, although expression evaluation might be a problem to start with. Compared to KRoC, I would not expect super-fast context switch times, merely reasonable ones, because the compiler will be generating ordinary code. It is in this area that future research work might yield interesting results, but at present this is beyond my ability.

- If we had such a compiler, and it worked well, do you think that is a Good Thing?
- Would any of you care to help make this a reality?

The Technical Details

I am throwing away the existing occam back-end, but retaining the tree manipulation that happens before code-conversion, so hopefully retaining all the good alias and usage checking. There are two possibilities to linking the compilers together, either to convert the occam compiler to use gcc tree nodes or create a tree-to-tree conversion layer. The easier and safer method is the latter, conversion layer, method and that is what I am intending at present.

Regarding concurrency, it might be possible to change the gcc back-end to optimize task switching and task creation, but it is far from obvious how to do that. Instead, I think the best way forward is to factor out the task primitives so that the compiler becomes relatively independent of the method used to manage tasks. My friend indicated that a package called Green Threads might be good as a lightweight target, and the obvious Posix threads model provides a relatively platform independent task package.

I have done some of the work, and have a set of occam compiler files that are at the right level and contain only expected undefined symbols; the work of creating the conversion layer that will link to these symbols is the major part of this project.