Re: mixed c and occam compiler

rog@vitanuova.com (Roger Peppé)
17 Feb 2001 01:30:03 -0500

          From comp.compilers

Related articles
mixed c and occam compiler amw298@ecs.soton.ac.uk (Andrew Woolley) (2001-02-12)
Re: mixed c and occam compiler vbdis@aol.com (2001-02-15)
Re: mixed c and occam compiler rog@vitanuova.com (2001-02-17)
| List of all articles for this month |

From: rog@vitanuova.com (Roger Peppé)
Newsgroups: comp.compilers
Date: 17 Feb 2001 01:30:03 -0500
Organization: Compilers Central
References: 01-02-051 01-02-073
Keywords: practice, C
Posted-Date: 17 Feb 2001 01:30:03 EST

Andrew Woolley <amw298@ecs.soton.ac.uk> schreibt:
> For part of my third year Uni project I have to allow for a mixture of
> c and occam source.


One of your principal difficulties will be the fact that occam has a
lexically nested procedure scope, whereas C does not.


In occam you can say something like (dredging from my extremely rusty
occam syntax):


        PROC x()
                INT a:
                PROC y()
                        a := 99
                PROC z(INT c)
                        SEQ
                                a := 88
                                y()
                                a := a + c
                SEQ
                        y()
                        z()


This sort of thing means that nested functions need some sort of
dynamic pointer chain back up the lexically nested scopes, as variables
outside the innermost scope are not available as fixed offsets from the
current stack frame.


As I recall, the Inmos occam compiler does pass such a pointer around.
this means that although calling C from occam would be doable, and
indeed calling occam from C wouldn't be hard (just pretend you're at
the outermost scope), intermingling C and occam in such a way that the
occam can call C and the C can then call the occam again would be
substantially harder.


    cheers,
        rog.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.