RE: gcc 4.0 front-end infrastructure for C dialects - plans?

["Gary Funck" <gary at intrepid dot com>]

Giovanni, thanks for your reply.  Answers follow.

> -----Original Message-----
> From: Giovanni Bajo [mailto:giovannibajo@libero.it]
> Sent: Friday, December 17, 2004 5:26 PM
> To: Gary Funck
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc 4.0 front-end infrastructure for C dialects - plans?
>
>
> Gary Funck <gary@intrepid.com> wrote:
>
> > The recent discussion titled "gcc integration" has me wondering if our
> > project (implementing an experimental dialect of C used primarily in
> > a distributed shared memory context) should be moving to
> > GCC 4.0 rather the our current focus (gcc 3.4)?
>
> You did not give us the most basic piece of information: are you
> planning to
> contribute this to GCC or not?
>

There is general interest in doing this.  However, I don't think that
in its present state that the mods. would be found acceptable for
inclusion in the gcc development tree.  The required changes are
more far-ranging than Objective C, for example.  Where we might
view Objective C as generalizing calls into message passing, UPC generalizes
pointers so that they can span a global address space.  For example,
in UPC a shared array is declared as follows:

shared int A[100*THREADS];

This declaration says that there are 100 elements local to each UPC thread
(a UPC thread is closer to a Unix process than what we normally think of as
a thread), and all threads can access elements of A, even if they are
local to some other thread.  A pointer to shared object has three parts:
(thread, phase, virtual address) and in a straightforward implementation,
the thread id maps to a process (which may be on a local node, or
remote node), phase allows packing local data into blocks, and the
virtual address locates the data in the thread (the virtual address
need not be a true machine address, but can be viewed as a handle for
locating the actual data inside the thread). In GCC/UPC, a shared
address is typically twice the size of a normal pointer value. Thus,
anywhere normal C deals with pointers, the UPC compiler must be
prepared to handle a pointer to shared object. There are synchronization
statements, a set of specialized library calls, and a few other facets
of the language, but the main impact is the extension of pointers
to allow for pointers to global objects intermingled with conventional
pointers.  The impact of the UPC extensions is probably roughly equal to
the bounded pointer implementation, and then some.


> > 1) Will the current yacc-based parser remain for C dialects in 4.0?
>
> 4.0 is a fixed codebase, we are just fixing bugs at this point.
> So the answer
> is yes, *BUT* there is already a recursive descendent parser for
> C ready for
> 4.1 (the last posted version is here:
> http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02409.html). Instead
> of worrying
> about keeping things in sync with this, why don't you just try?

Thanks, I follow the GCC list sporadically, and missed Joseph's note/patch.
As far as trying, I'll certainly take a look at the possibility of
making the required changes into the newly contributed C parser.

> You are in a
> good position with respect to time: you can work on the 4.1
> parser even before
> the 4.0 is out.
>

Sounds good.

> > 2) Are the 4.0 source files such as c-decl.c, c-typeck.c, and expr.c
> >    sufficiently stable at this point to support changes required by
> >    a C dialect, without more than the usual amount of heartburn?
> >    (the bump from 3.3 to 3.4 was actually quite extensive, but
> >    manageable and understandable).
>
> Between the c-* files and expr.c, there is now the big and
> extensive tree-ssa
> infrastructure with dozen and dozen of new optimization passes.
> You did not
> mention what kind of patches to expr.c you did and why they were
> needed (bugs?
> new features?),

They're needed to implement the semantics of UPC.

>  so I cannot help there. c-decl.c and c-typeck.c
> should have not
> changed too much IIRC, the biggest bump was between 3.3 and 3.4 when Zack
> rewrote the whole declaration machinery.
>

I noticed. <g> At this point, most of UPC's required 3.4 mods. are complete,
so
perhaps we're in a good situation to consider porting the changes into 4.1.

> If you are not going to contribute UPC to GCC *and* it is a short-lived
> project, you can probably stay with 3.4. The 3.4 branch will be probably
> discontinued by the end of 2005 (depends on how good 4.0 turns
> out to be), and
> after that you are left alone with what you have. If you are willing to
> contribute UPC to GCC, the best move is to always keep it in sync with CVS
> HEAD, so that when you are eventually ready to submit it, at
> least it meets our
> most basic criteria (remember: GCC is not going to accept any new
> feature in
> release branches).

I think it would be best if UPC can track the GCC development tree
to the degree possible.

An open request: if anyone here has an interest in reviewing the changes
we've made so far to implement UPC as a C dialect inside of GCC,
and to suggest better ways to make those changes so they
they fit more cleanly into GCC, I'd certainly welcome the chance to
exchange design/implementation ideas with you.

thanks, - Gary
http://intrepid.com/upc