lerici@super.ORG (Peter W. Brewer) (12/02/89)
I am still interesting in hearing more. I would like
to find out if anyone has ported the 2.0 translator
to the Convex with long long, long long int support
yet before I do it. I would also like to find out if
anyone has gcc1.36.1/2 and g++1.36.1/2 running on their
convexen and about how they installed it.. Thanx in
advance for any responses.. what follows is what I
have up to this point...
Date: Mon, 27 Nov 89 15:10:41 CST
From: dew@bedlam.cray.com (David Whitney)
Message-Id: <8911272110.AA05052@midnight.cray.com>
To: lerici@super.org
Subject: C++ on Crays under UNICOS
Cc: dsp@sobrero.cray.com, luzmoor@craywr.cray.com
Status: RO
Peter,
I have ported AT&T's C++ processor version 2.0 to UNICOS 5.0. So have
several other people, so I hope you haven't been buried with responses.
I can not send you a copy of their product unless you have a license
from them. Generally, I have been restricting myself to providing an
extensive porting guide that would simplify the installation of the
product on your system.
Please let me know how I can help you.
-David Whitney
-CRI, Mendota, heights
Date: Tue, 28 Nov 89 09:34:21 CST
From: dew@bedlam.cray.com (David Whitney)
Message-Id: <8911281534.AA05611@midnight.cray.com>
To: lerici@super.org
Subject: C++ on Crays under UNICOS
Cc: luzmoor@craywr.cray.com
Status: RO
Peter,
I am appending a copy of the porting guide to this message. I am not
certain that sending the diff -r patches would be helpful, since I don't
know how close your version of the cfront source is to mine. The guide
includes the changes that will be necessary, as well as other information
that will be needed. Please read it over and let me know what unanswered
questions you still have.
- David Whitney
- CRI, Mendota Heights
(revision 4)
This is a condensed description of a process that was followed to
port AT&T's c++ version 2.0 processor to the Cray architecture. The
operating system used was UNICOS 5.0 and the C compilers required are
Portable C 5.0 or Standard C 1.0.4, or higher levels.
It is presented here in the hopes that it will be useful to others faced
with the same task. Since this is a continuing process, and should
become simpler as various problems are resolved, please check carefully
to be certain that each of these steps is still necessary.
This approach is to use a host to bootstrap to the Cray. You can
use any machine that already has a running C++ preprocessor.
In general the 2.0 documentation is very good about this process, but
here are several things to watch out for when doing a port to the Cray:
1) Load the files onto the Cray and the host. Don't use a path name
that has a '+' sign in it, since the Cray loaders won't accept it.
2) Build the proto-type header files on the Cray.
There is one trick involved:
'stdcat' doesn't work and will cause the make process to hang.
So comment out the following lines in incl-master/build
102 stdcat -s stddef.h
103 if test $? -ne 0
104 then
108 fi
Keep all the lines between 'then' and 'fi'.
In incl-master/makefile, set SYMBOLICLINK=0 and be sure that OS
is properly set ('svr2' seems to work well).
Run 'make' in incl-master to build the headers.
Ship them to the host by coping the incl-master directory.
In the top level directory on the host, run 'make incl'.
3) Set up 'szal' and 'src/size.h' on the host machine.
Guess at what the output from 'szal.c' should have
been, since it doesn't run on the Cray as is.
The following values work well:
bit 8 64
word 8 8
char 1 1
short 8 8
int 8 8 2147483647
long 8 8
float 8 8
double 8 8
bptr 8 8
wptr 8 8
struct 8 8
struct2 1 1
Note that the maximun size of size of an 'int' has been
restricted to (2**31 - 1). This is done avoid a fatal
error message you may encounter. The problem is
inherent when porting to a machine with a larger
word size. After moving to the Cray, alter
this value to (2**46 - 1) so that the compiler
can generate faster code for multiply and
divide sequences than it could if (2**64 - 1)
were used. Of course, if you are using a Cray to do
the bootstrap, you can use (2**46 - 1) immediately.
It is then necessary to add a definition for
these values to 'src/size.h'. You may encounter a
limitation on your host related to the number of
nested 'elseif' blocks. The 'c' compiler may not warn
you, so look at the resulting '..c' files to be sure
that the correct sizes are being used, after you build them.
The size definitions should be included in an '#elseif'
block that begins:
#else
#ifdef CRAY
.
.
.
#endif
or something similar.
4) YOU WILL NEED A SPECIAL VERSION OF 'cfront' ON THE HOST, if you are
using a host machine that doesn't have a 64 bit word size. The
necessary change that is needed is in 'src/expr2.c'. Since
this same module must again be changed for the Cray, timing
is a little confusing.
Change src.expr2.c line 653 and 654 from:
if (4<SZ_LONG) error('i',"expr::eva;() assumes sizeof(long)<=4, please re-write it");
i &= cast_mask[tp2->tsizeof()-1};
to the following for the version of 'cfront' that you are using
on the host machine (if it doesn't have a 64 bit word size):
if (4>=SZ_LONG) {
i &= cast_mask[tp2->tsizeof()-1};
}
although the grapevine says that the "official" fix (your
version may already have it) is:
i &= ~(((~(unsigned long)0)<<(8*tp2->sizeof()-8))<<8);
5) Set up the control variables in the top level make file on the host.
Set the 'CC = ' variable to point to the existing C++ processor.
Set 'FILLDEF=-DCRAY'
Set the 'SZAL= ' variable to point to the szal output file.
6) In the CC script for the existing preprocessor on the host,
set the 'I= ' variable to point to the declarations that have been
copied to from the target machine and moved by 'make incl'.
Preceed this definition of 'I= ' with 'export I'.
7) Change 'src/expr2.c' line 653 and 654 from:
if (4<SZ_LONG) error('i',"expr::eva;() assumes sizeof(long)<=4, please re-write it");
i &= cast_mask[tp2->tsizeof()-1};
to:
i &= ~(((~(unsigned long)0)<<(8*tp2->sizeof()-8))<<8);
8) Then change 'src/main.c', line 523 from
chop(name);
to:
if (31<(strl+defl)) chop(name);
because the routine 'chop' blindly assumes that the string
in 'name' will always be at least 32 characters long. It isn't.
9) Then change 'src/expand.c' around line 735, where it does the
computation of 'ns', so that the declaration of 'ns' and the 'for'
loop that computes the proper value, preceeds the declarations
for 'Pin' and 'Pexpr'. Then add the following test which
will avoid expanding a call if there are no arguments to the call.
if (ns == 0) {
if (warning_opt) error('w',"cannot inline%n in thisE",fn);
if (fn->n_addr_taken++=0) fn->dcl_print(0);
return 0;
}
This is necessary to avoid an attempt to allocate a zero length
array which will occure if 'ns' is zero in the line:
il->i_args = new ia[il->islots = ns];
10) Produce the '*..c' files.
This involves running 'make fillscratch' from the translators
root directory on the host machine and then moving the scratch
directory back to the target machine. This is also a good time
to move the files that were changed in 'src' (expand.c, expr2.c,
main.c, and size.h).
It is wise to look at one of the '..c' files created in scratch/src.
In size..c is 'BI_IN_WORD' set equal to 64? Is LARGEST_INT set to
point at a reasonable character string? Are the 'sizeof' comments
for each structure a multiple of 8?
You are now finished on the host machine, but don't throw things
away until you're running on the Cray.
11) In tools/demangler/makefile, it is necessary to remove '+' signs from
file names on the Cray-1 line (YMP. XMP, etc). This occures in the
generation of c++filt. The changes are:
mv c++filt.o zonk.o
$(CC) $CFLAGS) -o zonk zonk.o mangle.a
mv zonk c++filt
12) Then change scratch/makefile to add the
"-g" option to the invocation of 'nm', since
the Cray version works a little differrent.
These differrences should disappear with UNICOS 6.0.
13) On the target machine, set up the control variables in the top level
makefile. The variables that need to be set are:
SYS=SYSV
OS=svr2
MACH=CRAY
INSTALL_BIN= ...
INSTALL_LIB= ...
INSTALL_INC= ...
CC=$INSTALL_BIN/CC
CCFLAGS=
FILLDEF=-DCRAY
SZAL= ...
and comment out the following lines in the 'clean' directive in
order to save yourself a lot of grief if you need to re-start:
rm -f scratch/src/*.o
rm -fr lib/mk/*.o lib/mk/libC.a
Or perhaps it is easier to get rid of the call to 'clean' that
occures as part of the 'scratch' process.
On the Cray-2 it is necessary to delete '-O' from the set of options
passed to the CC script. This should be done by deleting it from
'CCFLAGS= ...' . It is not clear what this option is meant do to, but
it just gets passed to the loader where it means something quite
unique to the Cray-2 - and it doesn't work.
14) On the target machine, set up the control variables in the CC script.
The variables that need to be set are:
CCROOTDIR= ...
CCLIBDIR= ...
I= ...
ccC='scc'
cppC='scc -E'
It is possible to use the Standard C compiler as a pre-processor
and the Portable C compiler as a post-processor.
There is a problem with the Portable pre-processor,
in that it produces "#line number file-name" images
without enclosing the file-name in quotes. The
C++ preprocessor dies when it sees one of these,
and it is necessary to suppress the generation of
these images (-P option) or to use the the Standard
C compiler in preprocessor mode (-E option). Since
there are some library modules which will not
compile with the Portable C pre-processor ('manip.c'
and 'oldformat.c') this is not a bad combination. If you do
not have the Standard C compiler available, it is possible
to turn off optimization and use the Portable C compiler to
compiler these modules.
There is a problem with previous levels of the Standard C
compiler that makes it painful to use as the post-processor.
Levels before 1.0.4 would object to the order that 'cfront'
produces declarations. This restriction has been removed with
the release of 1.0.4, however there are several optimization
problems that are yet to be resolved, so it is necessary to
turn off optimization when using it. This can be accomplished
by adding the '-h noopt' option to invocations of the compiler.
It is desirable to do this, since the resulting CC command will
compile C++ programs faster if Standard C is used, without
optimization, than it will if the Portable C compiler is used,
even with full optimization. It is expected that the next
release of Standard C will resolve these optimization problems.
It may also be desirable to alter the TMPDIR location, since
UNICOS is often configured with a small /usr/tmp directory and
a much larger /tmp director. This could differ between sites,
and it is best to check on your specific configuration.
Also replace the following line:
$NM $NMFLAGS $OO | \
with:
/usr/ucb/strings -8 $OO | \
egrep '__st[id]__' | \
sort -u | \
This changes is necessary to get static constructors called
at the start of program execution.
Note: you may encounter a system problem here and may need to
put all the above changes on a single line with the following
line that calls 'munch'. The 'new line' character causes one of
the intermediate pipe files to be lost on some systems.
On thc Cray-2 it is necessary to alter CC to invoke the loader
differently. The problem is that the loaders on the Cray-2
interprets the '-L' and '-l' options differently.
Replace the commamds on lines 379 and 398 that begin:
$ccC $P $LLIBPATH ...
with direct calls to segldr. at line 379, the new line is:
segldr -D MLEVEL=ERROR $Z -l$CCLIBDIR/libC.a >$TEMPDIR/__err 2>&1
and line 398 with:
segldr ${CTDT}.o $Z -l$CCLIBDIR/libC.a
15) In 'scratch/makefile', if you are using the Portable 'C' compiler,
'lex..c', will exceeds some internal limitation. Turn off optimization
or use the Standard C compiler.
On the Cray-2 problems will also be encountered in 'expand..c'
and 'simpl2..c'.
16) From the top level directory on the target machine, run
'make scratch' to build the bootstrap version of c++.
Then turn your attention to building a 'munch' version.
17) The next problem that needs to be addressed is in 'lib/stream'.
'filebuf.c' and 'sbuf.dbp.c' will encounter a problem (in cfront,
I think) related to typedefs expanded on a declaration line
for a variable that has no name. The problem comes up inside
Cray's definition of the exchange packet, so you can delete the
declaration of 'xp_t' (it is not referenced). It can be deleted
from the preprocessor output for these modules, before 'cfront'
gets to look at it, or from 'incl/sys/types.h' - either approach
seems to work.
If you chose to leave the header files alone, you will need to
expand the include files and alter the source.
Use: scc -E -I topleveldirectory/incl filebuf.c > t.filebuf.c
to produce the file to edit. Then generate the object module
with: CC -c t.filebuf.c
and move the output to: 'lib/mk/filebuf.o'.
Similarly for 'sbuf.dbp.c'.
18) The prefered method for building libraries on UNICOS is to use
bld(1). In 'lib/mk/makefile' it is desirable to changed the
use of 'ar ...' to 'bld ...'. This doesn't seem necessary on
the XMP or YMP systems but is important on CRAY-2 systems, and
may become necessary on other systems in the future.
19) The same C compiler limit encountered using the Portable C
compiler for 'scratch/src/lex..c' will also be encountered with
'src/lex.c' when the 'munch' version is generated. If you are not
using the Standard C compiler level 1.0.4, It will be
necessary to turn off optimization for the Portable C compiler
or to use the Standard C compiler after some of the
declarations are re-arranged.
The straight forward way to do this is to tell 'CC' to produce 'c'
output, go in and change this output, and then process it with
the 'c' compiler of choice. The way to acquire 'c' output is:
CC -Fc file.c > t.file.c
Which will produce a new file 't.file.c' with all includes
expanded and all 'C++' syntax converted to 'c' syntax. A '.o'
file can then be produced with:
scc -o t.file.o
Which can then be moved to 'file.o' so that the make files can
continue unchanged.
On the cray-2, this same limit will be encountered for the modules
'expand.c' and 'simpl2.c'
Place the object modules for these files in 'src'.
20) Then generate a munch version of the processor on the Cray
by running 'make CC=... munch' from the top level directory.
21) Then change all demo/*.C file names to demo/*.c so that
they will be acceptable to the Cray C compilers. Perhaps a change
to CC would be warranted for this problem. Hope that all the
demos run.
22) Use the resulting processors to make another 'munch' version
of themselves, and save these.
23) You may wish to perform another test by using the final result
of the above process to generate another version of 'c++'. If
you chose to do this it should compare (except for time stamps)
with the version used to generate it.
Date: Tue, 28 Nov 89 14:56:59 CST
From: convex!metzger@uxc.cso.uiuc.edu (Robert Metzger)
Message-Id: <8911282056.AA29614@mozart>
To: lerici@super.org
Subject: in response to your message below
Cc: mozart!grogers
Status: RO
>------- Forwarded Message
>
>Date: Mon, 27 Nov 89 11:23:41 EST
>From: Peter W. Brewer <uiucuxc!super.org!lerici>
>Subject: C++ translator on convexen
>To: uiucuxc!convex.com!tchrist
>Fcc: +tchrist
>
>I plan on repeating my port of the 1.1 translator to convexen with 2.0
>supporting long long etc. Is this redundant? Has it been done? If so
>I would like to get your version.
>
> Thanx in advance,
> Peter Brewer
> Supercomputing Research Center sn 23 convex c-1
>
>------- End of Forwarded Message
CONVEX has ported AT&T C++ V2.0. We plan on making a product out of it.
Features:
AT&T V2.0 (plus bug fixes to AT&T's code, long long int, etc, etc)
split-screen symbolic debugger that groks C++ (not csd!)
miscellaneous utilities for program development and documentation
libraries of PD C++ code ported to CONVEX
plus some other stuff we're still working on
The output of AT&T's translator is not generally vectorizable or
parallelizable. The C compiler is run with -O1 optimization.
Pre-requisites:
CONVEX C V4.0 (previously known as Vector C)
CONVEX OS V8.0
Availability and Price:
I get my hands slapped when I talk to customers about such things.
Call Larry Grossman in CONVEX Marketing 214-497-4383 for specifics.
We are looking for field test sites for CONVEX C++.
Such sites must have the following characteristics:
a) already has C++ code ready to be translated
b) willing to give use some sort of schedule as to what is going
to be compiled when and by whom
c) willing to give us feedback on what does and doesn't work,
what should be added, etc
Date: Wed, 29 Nov 89 10:31:30 EST
From: Peter W. Brewer <lerici@super.org>
Message-Id: <8911291531.AA23249@super.super.org>
To: stan@cs.uiuc.edu
Subject: cray port
Cc: dew@bedlam.cray.com, lerici@super.org
Status: RO
We have obtained Dave's notes.. they were good but they should have
been 8 pages instead of 4 :-) As we have done this with a Cray 2 I
suppose our notes should be written up as well. I will also add
a convex port with long long .. long long int support to the compendium
as there are so many convex front ends to crays. We do not agree with
Dave as far as his suggestions for the libraries port and would like to
discuss further if anyone is interested. I will post a compendium of
my responses to the unicos mailing and to the c++ news group.
We are interested in obtaining docs and , if available, software in
machine readable form on choices! Also, do you know if anyone has
ported RTL for GNU c to the Crays?
For Dave: version 1.0.3 of scc will not compile the translator generated
c code. We are attempting to obtain 1.0.4. I hope this doesn't mean it
isn't going to work on our "lame duck" architecture the Cray2 :-(.
Peter Brewer
lerici@super.org
Date: Wed, 29 Nov 89 11:13:10 CST
From: dew@bedlam.cray.com (David Whitney)
Message-Id: <8911291713.AA07266@midnight.cray.com>
To: lerici@super.org
Subject: Re: cray port
Cc: luzmoor@craywr.cray.com
Status: RO
Peter,
It wasn't clear to me if you received all of the porting guide. There are
23 items, and I will attach another copy to this message.
The only problem I know of with scc 1.0.3 is that it doesn't like the
order that cfront puts out declarations in. This can be gotton around
if you are willing to generate a C code file from cfront and re-arrange the
declarations before using the compiler. Since this is a general pain if
more than two or three modules are involved, I suggest you stick with
PCC until you can use version 1.0.4. Even then, take note that you MUST
turn off optimization. If you have encontered any other problems, I
would appreciate a more detailed account so that I can get them fixed
as soon as possible.
Let me re-assure you that we have avery intention of continuing to develop
new products for the Cray-2 and will continue supporting existing products.
I have not even heard anyone suggest that we restrict new products to any
particular machines. This is especially true for Key software products
such as CFT77, Standard C and Unicos.
-David Whitney
-CRI, Mendota Heights
(revision 4)
This is a condensed description of a process that was followed to
port AT&T's c++ version 2.0 processor to the Cray architecture. The
operating system used was UNICOS 5.0 and the C compilers required are
Portable C 5.0 or Standard C 1.0.4, or higher levels.
It is presented here in the hopes that it will be useful to others faced
with the same task. Since this is a continuing process, and should
become simpler as various problems are resolved, please check carefully
to be certain that each of these steps is still necessary.
This approach is to use a host to bootstrap to the Cray. You can
use any machine that already has a running C++ preprocessor.
In general the 2.0 documentation is very good about this process, but
here are several things to watch out for when doing a port to the Cray:
1) Load the files onto the Cray and the host. Don't use a path name
that has a '+' sign in it, since the Cray loaders won't accept it.
2) Build the proto-type header files on the Cray.
There is one trick involved:
'stdcat' doesn't work and will cause the make process to hang.
So comment out the following lines in incl-master/build
102 stdcat -s stddef.h
103 if test $? -ne 0
104 then
108 fi
Keep all the lines between 'then' and 'fi'.
In incl-master/makefile, set SYMBOLICLINK=0 and be sure that OS
is properly set ('svr2' seems to work well).
Run 'make' in incl-master to build the headers.
Ship them to the host by coping the incl-master directory.
In the top level directory on the host, run 'make incl'.
3) Set up 'szal' and 'src/size.h' on the host machine.
Guess at what the output from 'szal.c' should have
been, since it doesn't run on the Cray as is.
The following values work well:
bit 8 64
word 8 8
char 1 1
short 8 8
int 8 8 2147483647
long 8 8
float 8 8
double 8 8
bptr 8 8
wptr 8 8
struct 8 8
struct2 1 1
Note that the maximun size of size of an 'int' has been
restricted to (2**31 - 1). This is done avoid a fatal
error message you may encounter. The problem is
inherent when porting to a machine with a larger
word size. After moving to the Cray, alter
this value to (2**46 - 1) so that the compiler
can generate faster code for multiply and
divide sequences than it could if (2**64 - 1)
were used. Of course, if you are using a Cray to do
the bootstrap, you can use (2**46 - 1) immediately.
It is then necessary to add a definition for
these values to 'src/size.h'. You may encounter a
limitation on your host related to the number of
nested 'elseif' blocks. The 'c' compiler may not warn
you, so look at the resulting '..c' files to be sure
that the correct sizes are being used, after you build them.
The size definitions should be included in an '#elseif'
block that begins:
#else
#ifdef CRAY
.
.
.
#endif
or something similar.
4) YOU WILL NEED A SPECIAL VERSION OF 'cfront' ON THE HOST, if you are
using a host machine that doesn't have a 64 bit word size. The
necessary change that is needed is in 'src/expr2.c'. Since
this same module must again be changed for the Cray, timing
is a little confusing.
Change src.expr2.c line 653 and 654 from:
if (4<SZ_LONG) error('i',"expr::eva;() assumes sizeof(long)<=4, please re-write it");
i &= cast_mask[tp2->tsizeof()-1};
to the following for the version of 'cfront' that you are using
on the host machine (if it doesn't have a 64 bit word size):
if (4>=SZ_LONG) {
i &= cast_mask[tp2->tsizeof()-1};
}
although the grapevine says that the "official" fix (your
version may already have it) is:
i &= ~(((~(unsigned long)0)<<(8*tp2->sizeof()-8))<<8);
5) Set up the control variables in the top level make file on the host.
Set the 'CC = ' variable to point to the existing C++ processor.
Set 'FILLDEF=-DCRAY'
Set the 'SZAL= ' variable to point to the szal output file.
6) In the CC script for the existing preprocessor on the host,
set the 'I= ' variable to point to the declarations that have been
copied to from the target machine and moved by 'make incl'.
Preceed this definition of 'I= ' with 'export I'.
7) Change 'src/expr2.c' line 653 and 654 from:
if (4<SZ_LONG) error('i',"expr::eva;() assumes sizeof(long)<=4, please re-write it");
i &= cast_mask[tp2->tsizeof()-1};
to:
i &= ~(((~(unsigned long)0)<<(8*tp2->sizeof()-8))<<8);
8) Then change 'src/main.c', line 523 from
chop(name);
to:
if (31<(strl+defl)) chop(name);
because the routine 'chop' blindly assumes that the string
in 'name' will always be at least 32 characters long. It isn't.
9) Then change 'src/expand.c' around line 735, where it does the
computation of 'ns', so that the declaration of 'ns' and the 'for'
loop that computes the proper value, preceeds the declarations
for 'Pin' and 'Pexpr'. Then add the following test which
will avoid expanding a call if there are no arguments to the call.
if (ns == 0) {
if (warning_opt) error('w',"cannot inline%n in thisE",fn);
if (fn->n_addr_taken++=0) fn->dcl_print(0);
return 0;
}
This is necessary to avoid an attempt to allocate a zero length
array which will occure if 'ns' is zero in the line:
il->i_args = new ia[il->islots = ns];
10) Produce the '*..c' files.
This involves running 'make fillscratch' from the translators
root directory on the host machine and then moving the scratch
directory back to the target machine. This is also a good time
to move the files that were changed in 'src' (expand.c, expr2.c,
main.c, and size.h).
It is wise to look at one of the '..c' files created in scratch/src.
In size..c is 'BI_IN_WORD' set equal to 64? Is LARGEST_INT set to
point at a reasonable character string? Are the 'sizeof' comments
for each structure a multiple of 8?
You are now finished on the host machine, but don't throw things
away until you're running on the Cray.
11) In tools/demangler/makefile, it is necessary to remove '+' signs from
file names on the Cray-1 line (YMP. XMP, etc). This occures in the
generation of c++filt. The changes are:
mv c++filt.o zonk.o
$(CC) $CFLAGS) -o zonk zonk.o mangle.a
mv zonk c++filt
12) Then change scratch/makefile to add the
"-g" option to the invocation of 'nm', since
the Cray version works a little differrent.
These differrences should disappear with UNICOS 6.0.
13) On the target machine, set up the control variables in the top level
makefile. The variables that need to be set are:
SYS=SYSV
OS=svr2
MACH=CRAY
INSTALL_BIN= ...
INSTALL_LIB= ...
INSTALL_INC= ...
CC=$INSTALL_BIN/CC
CCFLAGS=
FILLDEF=-DCRAY
SZAL= ...
and comment out the following lines in the 'clean' directive in
order to save yourself a lot of grief if you need to re-start:
rm -f scratch/src/*.o
rm -fr lib/mk/*.o lib/mk/libC.a
Or perhaps it is easier to get rid of the call to 'clean' that
occures as part of the 'scratch' process.
On the Cray-2 it is necessary to delete '-O' from the set of options
passed to the CC script. This should be done by deleting it from
'CCFLAGS= ...' . It is not clear what this option is meant do to, but
it just gets passed to the loader where it means something quite
unique to the Cray-2 - and it doesn't work.
14) On the target machine, set up the control variables in the CC script.
The variables that need to be set are:
CCROOTDIR= ...
CCLIBDIR= ...
I= ...
ccC='scc'
cppC='scc -E'
It is possible to use the Standard C compiler as a pre-processor
and the Portable C compiler as a post-processor.
There is a problem with the Portable pre-processor,
in that it produces "#line number file-name" images
without enclosing the file-name in quotes. The
C++ preprocessor dies when it sees one of these,
and it is necessary to suppress the generation of
these images (-P option) or to use the the Standard
C compiler in preprocessor mode (-E option). Since
there are some library modules which will not
compile with the Portable C pre-processor ('manip.c'
and 'oldformat.c') this is not a bad combination. If you do
not have the Standard C compiler available, it is possible
to turn off optimization and use the Portable C compiler to
compiler these modules.
There is a problem with previous levels of the Standard C
compiler that makes it painful to use as the post-processor.
Levels before 1.0.4 would object to the order that 'cfront'
produces declarations. This restriction has been removed with
the release of 1.0.4, however there are several optimization
problems that are yet to be resolved, so it is necessary to
turn off optimization when using it. This can be accomplished
by adding the '-h noopt' option to invocations of the compiler.
It is desirable to do this, since the resulting CC command will
compile C++ programs faster if Standard C is used, without
optimization, than it will if the Portable C compiler is used,
even with full optimization. It is expected that the next
release of Standard C will resolve these optimization problems.
It may also be desirable to alter the TMPDIR location, since
UNICOS is often configured with a small /usr/tmp directory and
a much larger /tmp director. This could differ between sites,
and it is best to check on your specific configuration.
Also replace the following line:
$NM $NMFLAGS $OO | \
with:
/usr/ucb/strings -8 $OO | \
egrep '__st[id]__' | \
sort -u | \
This changes is necessary to get static constructors called
at the start of program execution.
Note: you may encounter a system problem here and may need to
put all the above changes on a single line with the following
line that calls 'munch'. The 'new line' character causes one of
the intermediate pipe files to be lost on some systems.
On thc Cray-2 it is necessary to alter CC to invoke the loader
differently. The problem is that the loaders on the Cray-2
interprets the '-L' and '-l' options differently.
Replace the commamds on lines 379 and 398 that begin:
$ccC $P $LLIBPATH ...
with direct calls to segldr. at line 379, the new line is:
segldr -D MLEVEL=ERROR $Z -l$CCLIBDIR/libC.a >$TEMPDIR/__err 2>&1
and line 398 with:
segldr ${CTDT}.o $Z -l$CCLIBDIR/libC.a
15) In 'scratch/makefile', if you are using the Portable 'C' compiler,
'lex..c', will exceeds some internal limitation. Turn off optimization
or use the Standard C compiler.
On the Cray-2 problems will also be encountered in 'expand..c'
and 'simpl2..c'.
16) From the top level directory on the target machine, run
'make scratch' to build the bootstrap version of c++.
Then turn your attention to building a 'munch' version.
17) The next problem that needs to be addressed is in 'lib/stream'.
'filebuf.c' and 'sbuf.dbp.c' will encounter a problem (in cfront,
I think) related to typedefs expanded on a declaration line
for a variable that has no name. The problem comes up inside
Cray's definition of the exchange packet, so you can delete the
declaration of 'xp_t' (it is not referenced). It can be deleted
from the preprocessor output for these modules, before 'cfront'
gets to look at it, or from 'incl/sys/types.h' - either approach
seems to work.
If you chose to leave the header files alone, you will need to
expand the include files and alter the source.
Use: scc -E -I topleveldirectory/incl filebuf.c > t.filebuf.c
to produce the file to edit. Then generate the object module
with: CC -c t.filebuf.c
and move the output to: 'lib/mk/filebuf.o'.
Similarly for 'sbuf.dbp.c'.
18) The prefered method for building libraries on UNICOS is to use
bld(1). In 'lib/mk/makefile' it is desirable to changed the
use of 'ar ...' to 'bld ...'. This doesn't seem necessary on
the XMP or YMP systems but is important on CRAY-2 systems, and
may become necessary on other systems in the future.
19) The same C compiler limit encountered using the Portable C
compiler for 'scratch/src/lex..c' will also be encountered with
'src/lex.c' when the 'munch' version is generated. If you are not
using the Standard C compiler level 1.0.4, It will be
necessary to turn off optimization for the Portable C compiler
or to use the Standard C compiler after some of the
declarations are re-arranged.
The straight forward way to do this is to tell 'CC' to produce 'c'
output, go in and change this output, and then process it with
the 'c' compiler of choice. The way to acquire 'c' output is:
CC -Fc file.c > t.file.c
Which will produce a new file 't.file.c' with all includes
expanded and all 'C++' syntax converted to 'c' syntax. A '.o'
file can then be produced with:
scc -o t.file.o
Which can then be moved to 'file.o' so that the make files can
continue unchanged.
On the cray-2, this same limit will be encountered for the modules
'expand.c' and 'simpl2.c'
Place the object modules for these files in 'src'.
20) Then generate a munch version of the processor on the Cray
by running 'make CC=... munch' from the top level directory.
21) Then change all demo/*.C file names to demo/*.c so that
they will be acceptable to the Cray C compilers. Perhaps a change
to CC would be warranted for this problem. Hope that all the
demos run.
22) Use the resulting processors to make another 'munch' version
of themselves, and save these.
23) You may wish to perform another test by using the final result
of the above process to generate another version of 'c++'. If
you chose to do this it should compare (except for time stamps)
with the version used to generate it.
Date: Wed, 29 Nov 89 11:03:44 CST
From: convex!metzger@uxc.cso.uiuc.edu (Robert Metzger)
Message-Id: <8911291703.AA20184@mozart>
To: lerici@super.org
Subject: C++ field test
Status: RO
If you don't start your porting before the first of the year,
we may be able to save you the effort.
The start date for the field test of C++ is dependent on the start date
of the field test of CONVEX C V4.0 and CONVEX OS V8.0, which is why
I can't give you more precise information.
Give us a call before you start work (or shell out $ for the source!)
Peter Brewer
Supercomputing Research Center
lerici@super.org