[comp.lang.c++] C++ on the sequent

brian@uw-june.UUCP (Brian Bershad) (08/06/87)

I am trying to port c++ v1.2 to the sequent.

Standard c++ with standard c works just fine (this is an
NS32K machine with 10 processors).

The problem is that Sequent has decided to "extend" 
C by adding two new storage specifiers:

	shared
	private

which indicate to the C compiler whether globals
should be declared private to each process,
or shared among all processes.

examples:
	extern shared int foo;
	static private char bar[100];


These are very useful constructs in a parallel environment.

There are 2 problems.  

	1. The easy one.
		The storage specifier keyword "private"  is
		in conflict with an existing C++ keyword.

		I can work around this by using shared_t and
		private_t in my C++ code and then just having
		cfront omit the _t on emission, or just
		sedding cfront's output on its way to ccom (not
		great, but hey, it's a multiprocessor!).


	2. The hard one.
		How to (painlessly) get the new keywords through cfront.
		Semantic checks are unnecessary.  ccom will do them for
		me, and as it is, cfront doesn't always agree with
		ccom anyway.
		

If possible, I would like to avoid diddling too much with the internals
of cfront.


Has anyone already done this for the sequent?  or for some other
"extended" compiler?



-- 
brian@june.cs.washington.edu                Brian Bershad
{ihnp4,decvax,ucbvax}!uw-beaver!brian       Dept. of Computer Science, FR-35
                                            Seattle, WA 98195

rich@oxtrap.UUCP (08/15/87)

In article <2943@uw-june.UUCP> brian@uw-june.UUCP (Brian Bershad) writes:
>I am trying to port c++ v1.2 to the sequent. ...
>
>The problem is that Sequent has decided to "extend" 
>C by adding two new storage specifiers:
>
>	shared
>	private
>
>which indicate to the C compiler whether globals
>should be declared private to each process,
>or shared among all processes.

(DYNIX has 3 segments, code, data, shared-data)

My answer is don't bother.  Sequent has provided us with a number of
techniques for using shared memory, one of which is the "shared"
keyword.  I find the shared data segment distastful for several
reasons.  First, It only gives you shared memory if your processes
derive from a common ancestor through forks only, that is, it is lost
on exec.  Second is a religious viewpoint; if it isn't ansii, it isn't
C.  (Third, it breaks undump, unexec, etc.!)

You really have at least 2 alternatives that I can see.  Use either
mmap with unlinked files, (new processes can't rendevous after the
unlinking), or the SysV shmem stuff.  Mmap is virtually portable,
(entendre intended), while shared and private aren't even C.

rich.
{cbosgd!hal, pyramid!fmsrl7}!oxtrap!rich (oxtrap is a b8000)
"Lies keep people happy" - I94 west of Detroit