[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
- 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.