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

[Jan Madsen <Jan dot Madsen at epfl dot ch>]

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.