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