Occam compiler using gcc

[Ruth Ivimey-Cook <ruth@xxxxxxxxxx>]

Folks,

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.

So:
- 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.

Regards,

Ruth