Patch for sC++ to GNU C++.

Patch for sC++ to GNU C++.

[Jan Madsen]

Hello,

I have previously worked with Mike Stump concerning the insertion of
this patch (first time 3 years ago). In August I contanted Jason
(jason@cygnus.com) but I have never got any answer, Mike Stump has
therefore suggested me to contact you in order to get this patch into
egcs.

The patch allows the GNU C++ compiler to accept a small concurrent
extension called sC++ (home page: http://ltiwww.epfl.ch/sCxx ). The sC++
extension adds 6 new keywords to the C++ language, they are however only
reserved if the source file to be compiled have one of the extensions
'.scxx' or '.scc' (or the flag '-fsyncc++' is used). Otherwise this
extension does not change the behaviour of the C++ compiler frontend.
Below you find a suggestion for a changelog entry for this change.


Wed Aug 19 14:25:00 1998 Jan Madsen <Jan.Madsen@epfl.ch>

        Insertion of the sC++ language extension.
        * Makefile.in: Added rules for sc*.c files.

        * decl2.c: Added flag 'syncc++' to list of flags, and variable
         'flag_synccxx'.

        * gxx.gperf: Added reserved words for sC++, regeneration of
hash.h
          required.

        * lang-options.h: Added flag '-fsyncc++'.

        * lang-specs.h: Added part for sC++ extensions ('.scxx' and
'.scc') and
          specs part for these extensions.

        *lex.c (init_lex): Unset sC++ specific keywords if extension not
used.

        *parse.y: Inserted actions and rules for the sC++ extension
(embedded
         in an 'if (flag_synccxx)').

        *sc-accep.c, sc-activ.c, sc-body.c, sc-const.c, sc-defau.c,
sc-destr.c,
         sc-foral.c, sc-meth.c, sc-misc.c, sc-names.h, sc-selec.c,
sc-selec.h,
         sc-setre.c, sc-stack.c, sc-wait.c, sc-when.c, sc.c, sc.h: New
files. 


You may obtain the complete patch (60-100kb) at the address (or I can
send it to you upon request): 

          http://ltiwww.epfl.ch/~madsen/gnu.html

I have put up two different versions of the patch: one with and one
without the kernel realising the concurrency in sC++. Each patch
decompress into a directory called sc-diff. We have already assigned the
copyright for the patch and the kernel to FSF.


Regards,

Jan Madsen

PS. Please let me know if I can do anything in order to facilitate the
    integration of this patch.

------------------------------------------------------------------------
Computer Networking Laboratory        - Laboratoire de Teleinformatique
Computer Science Department           - Departement d'Informatique
Swiss Federal Institute of Technology - Ecole Polytechnique Federale
1015 Lausanne, Switzerland

email: Jan.Madsen@epfl.ch

Tel. 021 / 693 47 97
Fax. 021 / 693 66 00

http://ltiwww.epfl.ch/~madsen
------------------------------------------------------------------------

Re: Patch for sC++ to GNU C++.

[Joe Buck]

> I have previously worked with Mike Stump concerning the insertion of
> this patch (first time 3 years ago). In August I contanted Jason
> (jason@cygnus.com) but I have never got any answer, Mike Stump has
> therefore suggested me to contact you in order to get this patch into
> egcs.

In essence you have a new language, sC++.  As I've down quite a bit of
research work on synchronous languages (Esterel and friends), I'm quite
interested.

However, sC++ differs from C++ more than Objective-C differs from C.
The C++ team is working very hard to finish matching the ISO spec,
and I don't blame them if they are not enthusiastic about making big
changes to the C++ front end to incorporate your extensions.

For these reasons, I think that it should be incorporated as a new
language front end, rather than as patches to the C++ front end.  The
reason is to avoid destabilizing the C++ front end, and make
it easy for users to choose or not choose sC++ (download or don't
download the overlay).

The idea is that there would be a new directory gcc/sc which would
be a peer of gcc/cp.  It would contain all of the new sc-xxx.c files.
Initially, the parser would need to be duplicated and modified, which
I don't much like.

I think that Objective-C is a good model for you to follow.  You will
notice, if you look at gcc/c-parse.in, that the bison inputs for C
and for Objective-C are generated from the same file, using a simple
sed-based approach.  If Jason agrees, you could make a similar file
for C++/sC++.  If he's not enthusiastic about this, as a temporary
measure you could duplicate and change the parser; the problem then
becomes that bugs would need to be fixed in two places.  Nevertheless
it would be easier to get your changes made available without interfering
with other developers.

> The patch allows the GNU C++ compiler to accept a small concurrent
> extension called sC++ (home page: http://ltiwww.epfl.ch/sCxx ). The sC++
> extension adds 6 new keywords to the C++ language, they are however only
> reserved if the source file to be compiled have one of the extensions
> '.scxx' or '.scc' (or the flag '-fsyncc++' is used).

I suggest dropping -fsyncc++ and just using the extension.

Re: Patch for sC++ to GNU C++.

[Mark Mitchell]

I am very nervous about extensions to languages, especially C++.
That's not because I doubt the skill of the implementors of these
extensions, or the design of the extensions themselves, or even the
utility of the extensions; it's because every extension puts a large
burden on those of us working on the "core" language.

In particular, we have to learn about these extensions an bear them in
mind whenever we make changes.  As an example, take the g++
`signature' extension.  I must keep signatures in mind whenever I make
changes, and I have sometimes broken signatures without breaking
anything else simply because I forgot to bear in mind various quirks
of signatures and their implementation.

FWIW, I recommend that we stay away from any and all non-trivial
extensions to C++ until we complete work on the features core
language.  We've still got work to do with namespaces, `export', other
template features, using declarations, etc.

Lest any devil's advocates out there complain that I propose to add
`__restrict__' to C++, note that I consider `__restrict__' a "trivial"
extension to C++ since it will be handled by first simplifying the C++
front-end to deal with type qualifiers, and then by adding `restrict'
to the set of type qualifiers.  So, in fact, the code will become
simpler, not more complex, and the total overhead for `restrict' will
be approximately 10 lines of code in the C++ front-end.

Obviously, these opinions (both the triviality of `restrict' and the
aversion to C++ extensions) are my own, and represent nothing about
the will of the EGCS steering committee, or that of the C++
front-end maintainer.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: Patch for sC++ to GNU C++.

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Joe> The idea is that there would be a new directory gcc/sc which
    Joe> would be a peer of gcc/cp.  It would contain all of the new
    Joe> sc-xxx.c files.  Initially, the parser would need to be
    Joe> duplicated and modified, which I don't much like.

Me neither.  In fact, I'm thinking about how to (partially) reunify
the C and C++ front-ends.  Please, let's not duplicate any more code.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: Patch for sC++ to GNU C++.

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:

    Joe> Please cd to gcc/objc and look around.  Do you see
    Joe> duplication?  No, you only see six source files.  The only
    Joe> duplication is in objc-parse.y: it and c-parse.y are both
    Joe> obtained from c-parse.in.

I agree with you.  Thank you for making me pay attention long enough
to see what was really going on.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: Patch for sC++ to GNU C++.

[Joe Buck]

>     Joe> As I mentioned, the alternative is to do something like
>     Joe> c-parse.in (the technique used to share the C and Objective-C
>     Joe> parsers).
> 
> You're probably noticing that I'm being contrary.  :-) Here's my
> problem:
> 
>   o If we add a new front-end and duplicate all the files, we've
>     duplicated all the files.  This necessitates changes in two
>     places.  We have *way* too much of this as it is.

Please cd to gcc/objc and look around.  Do you see duplication?  No, you
only see six source files.  The only duplication is in objc-parse.y: it
and c-parse.y are both obtained from c-parse.in.

Just the same, I have to agree with you when you say:

> That leads me to conclude that the right thing to do at the moment is
> to have the people interested in the extension maintain their patches,
> separately from g++.

I think so too, for now (though it appears that Jan's extensions are far
less disruptive than signatures).  But I think that the patches could be
restructured to make them easier to integrate later on: something like an
sc directory plus a smaller patch to the C++ part.  I think that the way
Objective-C is done is a good model.  This might turn Jan's patch into a
much smaller patch plus an add-on directory.

Re: Patch for sC++ to GNU C++.

[Joe Buck]

> 
> >>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:
> 
>     Joe> The idea is that there would be a new directory gcc/sc which
>     Joe> would be a peer of gcc/cp.  It would contain all of the new
>     Joe> sc-xxx.c files.  Initially, the parser would need to be
>     Joe> duplicated and modified, which I don't much like.
> 
> Me neither.  In fact, I'm thinking about how to (partially) reunify
> the C and C++ front-ends.  Please, let's not duplicate any more code.

As I mentioned, the alternative is to do something like c-parse.in
(the technique used to share the C and Objective-C parsers).

Re: Patch for sC++ to GNU C++.

[Chip Salzenberg]

According to Mark Mitchell:
> In fact, I'm thinking about how to (partially) reunify
> the C and C++ front-ends.

Yes!

> Please, let's not duplicate any more code.

Right. The creation of G++ by duplicating C front end sources was its
primary design flaw.

Salzenberg's First Rule of Programming: "Thou Shalt Not Repeat Thyself."
-- 
Chip Salzenberg               - a.k.a. -              <chip@perlsupport.com>
 "... under cover of afternoon in the biggest car in the county?!" //MST3K

Re: Patch for sC++ to GNU C++.

[Joe Buck]

> 
> >>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:
> 
>     Joe> Please cd to gcc/objc and look around.  Do you see
>     Joe> duplication?  No, you only see six source files.  The only
>     Joe> duplication is in objc-parse.y: it and c-parse.y are both
>     Joe> obtained from c-parse.in.

Mark writes:

> I agree with you.  Thank you for making me pay attention long enough
> to see what was really going on.

Convergence may be possible. :-)

So, Jan, I guess what I am asking is for you to restructure your patch so
that it looks like the way objc is built on top of C.  If I understand
things correctly, only the bison input needs changing, right, so it is
analogous to Objective-C?

(I can't promise, of course, that your changes would then be accepted,
that's up to Jason and Jeff -- but it would make it more likely, I think).

Re: Patch for sC++ to GNU C++.

[Jan Madsen]

Joe Buck wrote:
> 
> >
> > >>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:
> >
> >     Joe> The idea is that there would be a new directory gcc/sc which
> >     Joe> would be a peer of gcc/cp.  It would contain all of the new
> >     Joe> sc-xxx.c files.  Initially, the parser would need to be
> >     Joe> duplicated and modified, which I don't much like.
> >
> > Me neither.  In fact, I'm thinking about how to (partially) reunify
> > the C and C++ front-ends.  Please, let's not duplicate any more code.
> 
> As I mentioned, the alternative is to do something like c-parse.in
> (the technique used to share the C and Objective-C parsers).

Perhaps I wasn't that clear in my first mail but the flag '-fsyncc++' is
only there to avoid the duplication of code (I haven't studied the
Objective-C way though). The flag '-fsyncc++' is an internal flag (by
default disabled) which enables the extension. All the modifications for
the sC++ extension is guarded by this flag. There will therefore only be
problems for people who uses the sC++ extension, the C++ language itself
(only the compiler) is not concerned by the change.

Furthermore, the extension is only dependent on the parse.y (and the
lexer files) for generating calls to the kernel. Any other problem
should, I think, be limited to lexical problems such as when a function
changes its name.

Regards,

Jan Madsen

------------------------------------------------------------------------
Computer Networking Laboratory        - Laboratoire de Teleinformatique
Computer Science Department           - Departement d'Informatique
Swiss Federal Institute of Technology - Ecole Polytechnique Federale
1015 Lausanne, Switzerland

email: Jan.Madsen@epfl.ch

Tel. 021 / 693 47 97
Fax. 021 / 693 66 00

http://ltiwww.epfl.ch/~madsen
------------------------------------------------------------------------

Re: Patch for sC++ to GNU C++.

[Jason Merrill]

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

 > In particular, we have to learn about these extensions an bear them in
 > mind whenever we make changes.  As an example, take the g++
 > `signature' extension.  I must keep signatures in mind whenever I make
 > changes, and I have sometimes broken signatures without breaking
 > anything else simply because I forgot to bear in mind various quirks
 > of signatures and their implementation.

Me too.  I've been considering removing signatures for that reason, and
that is why I've been hesitant to accept sC++.

 > Obviously, these opinions (both the triviality of `restrict' and the
 > aversion to C++ extensions) are my own, and represent nothing about
 > the will of the EGCS steering committee, or that of the C++
 > front-end maintainer.

But, as it happens, I share them.

Jason

Re: Patch for sC++ to GNU C++.

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:

    >>  >>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:
    >> 
    Joe> The idea is that there would be a new directory gcc/sc which
    Joe> would be a peer of gcc/cp.  It would contain all of the new
    Joe> sc-xxx.c files.  Initially, the parser would need to be
    Joe> duplicated and modified, which I don't much like.
    >>  Me neither.  In fact, I'm thinking about how to (partially)
    >> reunify the C and C++ front-ends.  Please, let's not duplicate
    >> any more code.

    Joe> As I mentioned, the alternative is to do something like
    Joe> c-parse.in (the technique used to share the C and Objective-C
    Joe> parsers).

You're probably noticing that I'm being contrary.  :-) Here's my
problem:

  o If we add a new front-end and duplicate all the files, we've
    duplicated all the files.  This necessitates changes in two
    places.  We have *way* too much of this as it is.

  o If we don't duplicate all the files, we then have to take the
    extensions into account when dealing with changes to the C++
    front-end.  Automatically generating variants of the files is
    essentially the same as this situation.  When we modify, say,
    type-checking, we must worry about breaking the other variant
    of the language.

That leads me to conclude that the right thing to do at the moment is
to have the people interested in the extension maintain their patches,
separately from g++.  I suspect that in about 6 months to a year we
will have done lot of the work remaining on the C++ front-end required
to reach feature-completeness, and that interfaces will have
stabilized considerably.  (For example, it's still quite likely that I
will rewrite the parser itself in the relatively near future.  I have
a client interested in this work, but it's not yet a high priority for
them.  I'd also be willing to do this work for someone else, if they
asked me.)

Once things have stabilized, we should consider the extension on its
merits.  Adding any extension always creates maintenance difficulties,
no matter how good the extension may be.  We have to weigh the utility
of the extension against these difficulties.  But, I don't think now
is the time to even begin that debate.

Jan, I understand that you have probably done an excellent job, and
that you feel the impact on the compiler is slight.  However, even
reasonably well-contained extensions can cause real maintenance
problems.  Please note that my arguments apply equally to *any*
extension; there is no implied criticism of yours relative to any
other.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: Patch for sC++ to GNU C++.

[Jan Madsen]

Joe Buck wrote:
> 
> >
> > >>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:
> >
> >     Joe> Please cd to gcc/objc and look around.  Do you see
> >     Joe> duplication?  No, you only see six source files.  The only
> >     Joe> duplication is in objc-parse.y: it and c-parse.y are both
> >     Joe> obtained from c-parse.in.
> 
> Mark writes:
> 
> > I agree with you.  Thank you for making me pay attention long enough
> > to see what was really going on.
> 
> Convergence may be possible. :-)
> 
> So, Jan, I guess what I am asking is for you to restructure your patch so
> that it looks like the way objc is built on top of C.  If I understand
> things correctly, only the bison input needs changing, right, so it is
> analogous to Objective-C?
> 
> (I can't promise, of course, that your changes would then be accepted,
> that's up to Jason and Jeff -- but it would make it more likely, I think).

I will put my extension into a separate directory. However, I would very
much like to hear the opinion of Jason or Jeff concerning this work and
to know which version of GCC a patch should be made against.

The work, I will do, will then resume to this:

Creating a cp/parse.in file common for both C++ ans sC++ like the
C/Objective-C parser file. This file will probably only contain one or
two special rules for C++ (if any), the rest of the special rules will
be for sC++.

The sC++ will also need to modify the gxx.gperf file, however this can
be done simply by copying the cp/gxx.gperf file (when configuring the
compiler) and appending the special sC++ keywords to the copied file. 

Creating an 'sc' sub-directory to 'cp' and place my files in there.
Creating a Makefile and configure file in this directory.

There is, however, a couple of things I do not know how to do. If you
could explain to me how it is done and/or point me to the places where a
similar thing is done it will ease my task very much. First, can you
point me to the place where the 'sed' command manipulates the c-parse.in
file. Second, I have modified the file cp/lang-specs.h to accept the
extensions '.scc' and '.scxx', where does this change go (into the gcc
main program? how?)? It is simply the source file extensions that needs
description, otherwise I can use the same code as in the cp/lang-specs.h
(using, for example, the compiler name cc1scpp instead of cc1plus). 
I will probably also need to ask some questions concerning the configure
and makefiles later (when I creates these files). I will, however, first
try to figure out these myself.

Regards,

Jan Madsen

PS. We have an article describing the possibilities of this extension in
the
    September 1998 issue of IEEE Computer (written by Claude
Petitpierre, EPFL).
    If you are interested I am prepared to come to the USA and help
integrating
    the sC++ extension.

------------------------------------------------------------------------
Computer Networking Laboratory        - Laboratoire de Teleinformatique
Computer Science Department           - Departement d'Informatique
Swiss Federal Institute of Technology - Ecole Polytechnique Federale
1015 Lausanne, Switzerland

email: Jan.Madsen@epfl.ch

Tel. 021 / 693 47 97
Fax. 021 / 693 66 00

http://ltiwww.epfl.ch/~madsen
------------------------------------------------------------------------

Re: Patch for sC++ to GNU C++.

[Jeffrey A Law]

  In message < 36304126.205C2B72@epfl.ch >you write:
  > I will put my extension into a separate directory. However, I would very
  > much like to hear the opinion of Jason or Jeff concerning this work and
  > to know which version of GCC a patch should be made against.
Well, front-ends are probably my weakest area in the compiler itself, and it
only gets worse for languages like C++ which I don't know or understand :-)

From a high level I'd have the same concerns that other folks have expressed.
Primarily that we don't want to duplicate a lot of code.  The other concern
is we don't want to bludgeon the C++ front end too much and make life too
difficult on the folks working on our C++ compiler.

In the end, Jason and the other folks working on the C++ front end will have
to decide which side of the fence to fall on.

Note that you'll need to deal with the copyright assignment issues before any
of this work can be integrated.

  > There is, however, a couple of things I do not know how to do. If you
  > could explain to me how it is done and/or point me to the places where a
  > similar thing is done it will ease my task very much. First, can you
  > point me to the place where the 'sed' command manipulates the c-parse.in
  > file.
I'd look in objc/Makefile.in and objc/Make-lang.in

  >  Second, I have modified the file cp/lang-specs.h to accept the
  > extensions '.scc' and '.scxx', where does this change go (into the gcc
  > main program? how?)?
gcc.c?  Maybe?  I'm not good with the spec stuff either (can you tell my
background is optimizers and backends :-)

jeff

Re: Patch for sC++ to GNU C++.

[Ken Raeburn]

Here are some comments I had for Jason when he asked my opinion of the
patches in August.  (I've spent a bit of time working on a Concurrent
C front end, and when MRS was still at Cygnus, pestering him about
thread-safety issues.)  We haven't discussed it since.

Most of my comments are about the generic extension issues, a few
about sC++ specifically.  Some of the issues have already been brought
up in this discussion.  I didn't take as much time as I could've to
investigate the details of the sC++ implementation, and didn't talk to
Jan about it at all, so some of my concerns may be unfounded.

Ken

 To: Jason Merrill <jason@cygnus.com>
 Subject: Re: [Jan Madsen <Jan.Madsen@epfl.ch>] Patch for the sC++ extension.
 From: Ken Raeburn <raeburn@cygnus.com>
 Date: 24 Aug 1998 16:28:45 -0400

 > Thoughts?

 Several...

 First: It'd be great to have some sort of extension for multithreaded
 programs available.  Yes, the Posix library spec is okay, but (1) it's
 only one thread API of several we have to deal with, and (2) it deals
 with low-level issues, and stuff like message-passing has to be built
 on top of it all the time, locking has to be explicitly done, etc.
 Having a language extension puts the API issues under the covers, and
 (generally) lets you specify in one places that all accesses to an
 object should be done with locks, and often lets you say "pass this
 message with these six values, and get a value back".

 I'd rather see something available for C as well, and if I get really
 psyched about it I'll work on Concurrent C/C++ again (looks like my
 previous work is lost to a disk crash and bad backup tapes, but hey,
 parts of it really needed a rewrite anyways).  In fact, some (not all)
 of the sC++ extensions look remarkably like Concurrent C/C++
 extensions, with slightly different syntax, and without support for C.
 (Of course, both the sC++ and Concurrent C extensions also bear some
 resemblance to Ada constructs.)

 Second: I think at some point we should address the general issue of
 extensions to C and C++.  Maybe there isn't anything "general" that we
 can do, but I think we should investigate, and as far as I know no one
 has.  There are several issues to look into, I'm sure; only a few come
 to me off the top of my head.

 * Grammar: The "@" additions to the C++ grammar might conflict with an
   Objective C++ front end.  Some of the new keywords will definitely
   conflict with Concurrent C++.  The grammar gets new hooks all over
   the place for this extension, I think even more so than for
   Concurrent C++.  The new rules in the grammar are active even if the
   extensions are not enabled.

 * How to hook in: Should we add command-line options to enable
   extensions, as they've done, or create new programs like cc1obj that
   have the extensions, and leave them out of the "ordinary" back end?
   Does it matter if we're consistent?

 * Intrusiveness: Should we put "if objc" and "if (flag_synccxx)" hooks
   in all over the place, specific to each extension, or can we find a
   way to add generic hooks in all these places (including the grammar
   and lexer themselves?) that an extension "package" (or more than
   one) can make use of?

 * Combining multiple extensions: Can we produce some mechanism by
   which an "Objective sC++" compiler would just sort of fall out
   naturally?  Grammar and keyword conflicts would have to be handled
   somehow, so possibly the answer is no.  Maybe the answer is to add
   all the hooks and grammar extensions and resolve conflicts up front,
   then selectively enable those additions at run time.

 This could get into a big can of worms, and the easy way out is to
 just deal with it for each such language extension that comes along.
 That works, but has little chance of making it easier to write new
 language extensions.  Maybe that's not important; I don't expect all
 that many to come along, but some do.  For example, database
 extensions, other concurrent-execution models.

 Third: This appears to do synchronous, cooperative multithreading,
 rather than async posix-style (and gthr.h-style) multithreading.  This
 makes it of relatively limited use, in my opinion, but I'm sure it has
 its place.  You have to use their thread mechanism, and their new
 header file in every source file, at least if you use their
 extensions.  (The compiler could be hacked to always read the
 structures and function declarations from the header file without
 explicitly including it from the source file, or hard-code the info
 within the compiler.)  The header file is a little sloppy about
 namespace invasion, and includes some system header files.

 They're assuming that sigsetjmp/siglongjmp are adequate for switching
 threads.  I'm not sure that's all that safe.

 It looks like the library support is only ported to Alpha, Sparc, and
 SGI systems, in the tar file I fetched.  Actually, there's a Linux one
 as well, but the fact that it's a separate distribution doesn't look
 good.  Maybe that's what the "generic" configuration part refers to,
 but how generic can it be if Alpha, Sparc, and SGI each need their own
 replacement definitions?

 Fourth: Minor stuff...  Changing some of the names/spellings to
 English might make it easier on many of the users.  They use the name
 "sC++" in some places and "SyncC++" (the older name of the project, I
 think) in others, and that probably should be made consistent.  Also,
 I've got some minor concerns about just how the hooks into the grammar
 are written (e.g., are they changing the semantics more than they
 should), but I'm sure you'd review that more carefully than I have.
 And I doubt they've checked for proper interaction with templates.

Re: Patch for sC++ to GNU C++.

[Jan Madsen]

Hello,

Thank you for your continued interest. Actually we understand your
situation: more work and ideas than resources sounds familiar.

Can we try a new contact in a few months? We think that our approach is
an important step forward (see also A. Eilien's mail to info@cygnus.com
from Nov. 10, 1998). We now put our effort to port the language and
libraries to Windows 95 as well as supporting tools (we have a first
version of a model checker), and thus look forward to be integrated into
the EGCS package.


Regards,

Jan Madsen


PS. To contact us please use the e-mail address: scxx@di.epfl.ch
    (This is a generic e-mail address for questions about sC++).

PS. Below you find my comments to the sC++/Concurrent C/C++ "objections"
    made by Ken Raeburn.

------------------------------------------------------------------------
Computer Networking Laboratory        - Laboratoire de Teleinformatique
Computer Science Department           - Departement d'Informatique
Swiss Federal Institute of Technology - Ecole Polytechnique Federale
1015 Lausanne, Switzerland

email: Jan.Madsen@epfl.ch

Tel. 021 / 693 47 97
Fax. 021 / 693 66 00

http://ltiwww.epfl.ch/~madsen
------------------------------------------------------------------------

> Subject:  Re: Patch for sC++ to GNU C++.
> Date:     25 Oct 1998 20:03:51 -0500
> From:     Ken Raeburn <raeburn@cygnus.com>
> To:       Jan Madsen <Jan.Madsen@epfl.ch>, egcs@cygnus.com
> References:   1
>
>
>
>
> Here are some comments I had for Jason when he asked my opinion of the
> patches in August.  (I've spent a bit of time working on a Concurrent
> C front end, and when MRS was still at Cygnus, pestering him about
> thread-safety issues.)  We haven't discussed it since.

> Most of my comments are about the generic extension issues, a few
> about sC++ specifically.  Some of the issues have already been brought
> up in this discussion.  I didn't take as much time as I could've to
> investigate the details of the sC++ implementation, and didn't talk to
> Jan about it at all, so some of my concerns may be unfounded.
>
> Ken
>
> To: Jason Merrill <jason@cygnus.com>
> Subject: Re: [Jan Madsen <Jan.Madsen@epfl.ch>] Patch for the sC++ extension.
> From: Ken Raeburn <raeburn@cygnus.com>
> Date: 24 Aug 1998 16:28:45 -0400
>
> > Thoughts?
>
> Several...
>
> First: It'd be great to have some sort of extension for multithreaded
> programs available.  Yes, the Posix library spec is okay, but (1) it's
> only one thread API of several we have to deal with, and (2) it deals
> with low-level issues, and stuff like message-passing has to be built
> on top of it all the time, locking has to be explicitly done, etc.
> Having a language extension puts the API issues under the covers, and
> (generally) lets you specify in one places that all accesses to an
> object should be done with locks, and often lets you say "pass this
> message with these six values, and get a value back".
>
> I'd rather see something available for C as well, and if I get really
> psyched about it I'll work on Concurrent C/C++ again (looks like my
> previous work is lost to a disk crash and bad backup tapes, but hey,
> parts of it really needed a rewrite anyways).  In fact, some (not all)
> of the sC++ extensions look remarkably like Concurrent C/C++
> extensions, with slightly different syntax, and without support for C.
> (Of course, both the sC++ and Concurrent C extensions also bear some
> resemblance to Ada constructs.)

sC++ forms a coherent environment that harmonizes object oriented
programming and process modelling. It is bolstered by a heavy
theoretical background.

sC++ programs can be analysed for deadlocks by random walk validation,
state space reachability analysis, and model checking, for which tools
are already available. Comparing with Promela/SPIN, sC++ is
simultaneously the specification and implementation language. These
features should be preserved when harmonizing the concurrent extension
to other languages.

>
> Second: I think at some point we should address the general issue of
> extensions to C and C++.  Maybe there isn't anything "general" that we
> can do, but I think we should investigate, and as far as I know no one
> has.  There are several issues to look into, I'm sure; only a few come
> to me off the top of my head.
>
> * Grammar: The "@" additions to the C++ grammar might conflict with an
>   Objective C++ front end.  Some of the new keywords will definitely
>   conflict with Concurrent C++.  The grammar gets new hooks all over
>   the place for this extension, I think even more so than for
>   Concurrent C++.  The new rules in the grammar are active even if the
>   extensions are not enabled.

The new hooks are used to gather the names and visibility of the
different member functions belonging to an active class. This can also
be done by decoding the tree structure for a class, but I think the tree
structure is much more likely to change than the parser itself (the
bison rules) and thus it will be much more difficult to maintain.

A number of other hooks are used to test if a member function call calls
a function belonging to an active class. In this case some extra code is
generated by simulating the corresponding parser (bison) actions and
returning the modified tree structure.

> * How to hook in: Should we add command-line options to enable
>   extensions, as they've done, or create new programs like cc1obj that
>   have the extensions, and leave them out of the "ordinary" back end?
>   Does it matter if we're consistent?
>
> * Intrusiveness: Should we put "if objc" and "if (flag_synccxx)" hooks
>   in all over the place, specific to each extension, or can we find a
>   way to add generic hooks in all these places (including the grammar
>   and lexer themselves?) that an extension "package" (or more than
>   one) can make use of?

We let you decide, the sC++ extension can be made to conform to any of
these two ways.

> * Combining multiple extensions: Can we produce some mechanism by
>   which an "Objective sC++" compiler would just sort of fall out
>   naturally?  Grammar and keyword conflicts would have to be handled
>   somehow, so possibly the answer is no.  Maybe the answer is to add
>   all the hooks and grammar extensions and resolve conflicts up front,
>   then selectively enable those additions at run time.
>
> This could get into a big can of worms, and the easy way out is to
> just deal with it for each such language extension that comes along.
> That works, but has little chance of making it easier to write new
> language extensions.  Maybe that's not important; I don't expect all
> that many to come along, but some do.  For example, database
> extensions, other concurrent-execution models.
>
> Third: This appears to do synchronous, cooperative multithreading,
> rather than async posix-style (and gthr.h-style) multithreading.  This
> makes it of relatively limited use, in my opinion, but I'm sure it has
> its place.  You have to use their thread mechanism, and their new
> header file in every source file, at least if you use their
> extensions.  (The compiler could be hacked to always read the
> structures and function declarations from the header file without
> explicitly including it from the source file, or hard-code the info
> within the compiler.)  The header file is a little sloppy about
> namespace invasion, and includes some system header files.

Asynchronous communication makes modelling of a program difficult.
Moreover creating an active object simulating a channel (in a library)
is very easy in sC++, and its subsequent use in the program is as simple
as the use of, for example, the 'strlen()' function.

Concerning the scxx.h header (our new header file), we would also be
very happy if we have had the time to make it disappear (e.g. in the
compiler as you propose). The introduction of a separate namespace for
the kernel header can be done, however, the current header dates from
the GNU C++ version 2.7.0 where namespaces were not a part of GCC.

The inclusion of the system header files are required in order to rename
the "select" and "accept" functions defined in the UNIX operating
system. It is necessary to treat this problem in any concurrent
extension using any of these two keywords.

> They're assuming that sigsetjmp/siglongjmp are adequate for switching
> threads.  I'm not sure that's all that safe.

At some lowlevel point any thread package will be required to use the
sigsetjmp/siglongjmp (or equivalent) system calls to switch threads.

>
> It looks like the library support is only ported to Alpha, Sparc, and
> SGI systems, in the tar file I fetched.  Actually, there's a Linux one
> as well, but the fact that it's a separate distribution doesn't look
> good.  Maybe that's what the "generic" configuration part refers to,
> but how generic can it be if Alpha, Sparc, and SGI each need their own
> replacement definitions?

We provide our system only for these four OS'es because they are the
only systems we have been able to test the sC++ extension on. The sC++
extension to the compiler is, however, completely independent of the OS
on which the compiler is run. Only the sC++ kernel may need some
adaption and this can be made with the same configuration scheme as
other GNU packages.

>
> Fourth: Minor stuff...  Changing some of the names/spellings to
> English might make it easier on many of the users.  They use the name
> "sC++" in some places and "SyncC++" (the older name of the project, I
> think) in others, and that probably should be made consistent.  Also,
> I've got some minor concerns about just how the hooks into the grammar
> are written (e.g., are they changing the semantics more than they
> should), but I'm sure you'd review that more carefully than I have.
> And I doubt they've checked for proper interaction with templates.
>

Sorry for the spelling, if we can go forward, we will do our best to
improve it. SyncC++ was the old name and should be replaced by sC++
wherever it appears.

Templates have not yet been handled by lack of time. We also need to
know where we are heading before investing time in these features.

Re: Patch for sC++ to GNU C++.

[Mike Stump]

> From: Joe Buck <jbuck@Synopsys.COM>
> To: Jan.Madsen@epfl.ch (Jan Madsen)
> Date: Wed, 21 Oct 98 12:38:50 PDT
> Cc: egcs@cygnus.com, jason@cygnus.com


> The idea is that there would be a new directory gcc/sc which would
> be a peer of gcc/cp.  It would contain all of the new sc-xxx.c files.
> Initially, the parser would need to be duplicated and modified, which
> I don't much like.

Uhm, it's the whole compiler, not any subpart of the compiler.  I
don't like copying on that large a scale.

Maybe folks can talk about good ways to think about frontends and code
them so we can get more sharing of semantics between frontends.  This
I think is overdue.