From: pabuhr@plg.waterloo.edu (Peter A. Buhr)
Subject: uC++ First Release
Organization: University of Waterloo
Date: Tue, 7 Apr 1992 21:29:06 GMT

We are pleased to announce, to any interested parties, the availability of
Version 3.2.5 of uC++ (pronounced micro-C++).  uC++ extends the C++
programming language in somewhat the same way that C++ extends the C
programming language.  The extensions introduce new objects that augment
the existing set of control flow facilities and provide for light-weight
concurrency on uniprocessor and parallel execution on multiprocessor
computers running the UNIX operating system.  uC++ is not another thread
package built on top of C++, but a comprehensive set of language extensions
that integrate the notions of coroutine, mutual exclusion and concurrent
execution into the language.


uC++ Version 3.2.5 is a beta release so please understand that some aspects
of the language still need work and that the runtime environment is not yet
complete. Nevertheless, uC++ Version 3.2.5 does work and can be used by
others to examine the ideas presented in uC++.  (Be gentle.) Version 4.0 is
coming and will have more features and be more robust.


Here are some things to watch out for in Version 3.2.5:

1.  The uC++ translator may fail when given very bad syntax errors.  The
error recovery facilities of the translator will be updated in version 4.
Also, the translator is vulnerable to programs that use the same names for
types and routines.  Beware of this vulnerability.  It may show up in very
subtle errors.

2. The "inline" version of the runtime environment is not working in this
release, so that performance is significantly slower than it can be. When
the "inline" version is working, performance is comparable to any light-
weight tasking system.

3. Tasks cannot be declared in the external area because the constructors
for the runtime objects may not have been executed yet.  A version of the
runtime library is being developed that will allow declaring external
tasks.

4.  The only multiprocessor computer supported in this release is the
Sequent Symmetry. Ports to more vendor/machines will appear shortly.

5. This version is not tested with the new GCC 2.0 compiler.  This testing
will be done shortly. Several example programs use the TI COOL preprocessor
to construct generic types (templates).


uC++ requires at least version 3.8 of dmake, which is available by
anonymous ftp from the following location (remember to set your ftp mode to
binary):

	watmsg.uwaterloo.ca (129.97.141.9)   pub/dmake/dmake38.tar.Z

Execute the following command to unpack the source:

	% zcat dmake38.tar.Z | tar -xf -

To build dmake, edit the variables in file ./unix/startup.h.  The variable
MAKESTARTUP must specify the location of the startup.mk file, which
contains all the implicit recipes.  This file is placed at the top level of
the source directory after dmake is built.  If dmake is not being installed
in a public location, set the value of MAKESTARTUP to
dmake-source-path/startup.mk.  After setting the MAKESTARTUP variable,
execute the command make in directory dmake to determine what
configurations are available.  A list of possible configurations will be
printed.  Once dmake is built, add the executable to your command path.

The current version of uC++ can be obtained by anonymous ftp from the
following location (remember to set your ftp mode to binary):

	watmsg.uwaterloo.ca (129.97.141.9)   pub/uSystem/u++-3.2.5.tar.Z

Execute the following command to unpack the source:

	% zcat u++-3.2.5.tar.Z | tar -xf -


To build uC++, edit the variables in file ./Makefile.  The variable ROOT
must specify the current location of the uC++ source (the path to the
directory that contains the source).  The variable BINDIR specifies the
location where the u++ executable and other executables needed for
compilation are placed.  The LIBDIR variable specifies the location for the
u++ runtime libraries.  Both BINDIR and LIBDIR have default values.  After
setting at least the ROOT variable, execute the command dmake in this
directory to determine what configurations are available.  A list of
possible configurations will be printed.

After installation is complete, there will be a number of executables
created in the BINDIR location.  Add this directory to your command path to
access the compilation command u++, or move the u++ executable itself to a
directory in your command path.  Do not move the other executables in
BINDIR, as the u++ executable references these executables and the runtime
library via hard coded path names set at installation time.


A postscript and dvi version of the uC++ reference manual are available in
the same ftp directory as u++-3.2.5.tar.Z, called u++-3.2.5.ps and
u++-3.2.5.dvi respectively.  They contain a copy of the uC++ documentation
that has been formatted for 8.5x11 paper.  This has been made available
because some people have had problems LaTeXing the documentation that comes
with the uC++ distribution.  Normally, it is unnecessary to retrieve these
file as uC++ comes with the latex source for the reference manual.


uC++ runs on the following processors: M68K series, NS32K series, VAX,
MIPS, Intel 386, Sparc, and the following UNIX operating systems:

	- generic BSD 4.3
	- Sun OS 4.x
	- Tahoe BSD 4.3
	- Ultrix 3.x/4.x
	- DYNIX

uC++ requires at least GNU C++ 1.39.1.  uC++ will NOT compile using other
compilers.  (Don't even think about it and don't try GCC 2.0!) To run
multiprocessor on a Sequent GNU C++ must use the Sequent assembler and
loader, which means using collect.


There is a Software-Practice and Experience paper about uC++ Version 2.0 in
the Feb 1992 issue. Note, there have been several changes from version 2 to
3, and there will be more changes from version 3 to 4.

uC++ is being used daily to build highly concurrent access methods for
persistent file structures (databases) here at Waterloo.


What's coming in uC++ Version 4:

	- port to GCC 2.0
	- inline version of kernel
	- multiprocessor ports to SGI, Encore
	- uWait and uSignal as members of uCondition
	- port to IBM 6000
	- task priorities
	- exception handling
	- improve translator, make more robust
	- time out on I/O calls

We hope to have most of this done by the end of the summer.