🚀 go-pugleaf

In article <309@hubcap.UUCP> grunwald@M.CS.UIUC.EDU writes:
>Tired of developing your iPSC applications on the 310? Want to use EMACS, RCS
>and your other normal tools?
>
>Announcing, 'rcc', the remote C compiler server.

Here in Caltech, we have been running a locally developed environment
that reduces the 310 to merely an advanced device driver and compiler
engine.  We are not only able to compile cube applications from any
hosts connected to our network, we are also able to allocate subcubes,
run host programs, spawn cube programs, etc all without ever having to
touch the 310 directly.  Since the host programs run right on the Unix
machine you are using, without any special arrangements, you can have
your SUN3/160 display the Mandlebrot set generated by your cube; you
write a host program that opens a SUN window and communicates with
other cube processes as if itself is one of the cube processes.  This
environment, called the Cosmic Environment, brings together the cube
and any network connected resources in a transparent way (upto the
level of byte order compatibility).  We have users working, compiling
program, and running jobs from other departments, from across L.A., and
all the way north to the state of Washington.  Long distance computing
is a bit slow however.  This cube/software combo is very popular here
and users sometimes resort to verbal abuse to get a share of the cube.

For some time, Intel has worked to port this environment.  The result
is included in Intel's software distribution as part of the unsupported
protocode package.  We have not talked to them about this for a while
and cooperation has wained on this.  The main reason for the difficulty
in porting Cosmic Environment to the current iPSC is that, due to
historical reasons, our set of utilities and message functions are
different from Intel's and the patch work gets a little messy.  We
shaped our software after what is available to us and how we use the
machine.  For example, since we do not have an extended memory machine
and we do not have vector options, we could not add facilities in our
environment to deal with of them.  Part of what Intel did is try to
modify the Cosmic Environment so that it handles these other options.
Intel gives considerations to those who intend to run these cubes stand
alone and write programs in fortran.  We did not design in the support
for either because our computing resources consist a network of Unix
boxes and programmers who speak C as their second language.

There is no right side on this, but I think there should have been
more cooperation between us and Intel in the begining when the iPSC is
still in development and we were trying to put together a generalized
host environment.  For the next generation cube, Intel gets to start
over and we intend to get a better cooperation with them.  We hope this
environment or a later revision of it (after working it out with all
interested parties), will set a standard that most vendors can agree
on, easing the portability problem.  I can't say on this, but I can
tell you that we have a very good start on this.

Right now, if you have a plain iPSC sitting on a network of 4.2BSD
machines the latest Cosmic Environment is available for you on Unix
tar tape or via ARPANET.  Requests should be sent to:

Dr. Charles L. Seitz
Computer Science 256-80
California Institute of Technology
California, 91125

Or by electronic mail to "chuck@vlsi.caltech.edu".

I do not think I can post the software on the net because it approaches
1 megabyte in source form.  Beside, the big brothers are watching.

+--------------------------------------------------------------------------+
| Wen-King Su  wen-king@vlsi.caltech.edu  Caltech Corp of Cosmic Engineers |
+--------------------------------------------------------------------------+