Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: An ISIS blurb (and a comment on the name of the system)
Message-ID: <27385@cornell.UUCP>
Date: 1 May 89 16:21:25 GMT
References: <27301@cornell.UUCP> <7839@batcomputer.tn.cornell.edu>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 126

In article <7839@batcomputer.tn.cornell.edu> mitch@tcgould.tn.cornell.edu (Mitch Collinsworth) writes:
>Just curious.  Is anyone planning on recoding the two files written in
>assembler for the DECstation 3100 (MIPS risc processor)?

The short answer is that someone at Cornell is interested in
doing this, but I don't know if he will definitely get it done.
My group has been doing too many ports lately, and is not eager to
undertake more of them, although we are happy to advise... in
return for a copy of the port, of course!  ISIS Distributed Systems
(a company that I founded last year in Ithaca) is willing to do ports
for a fee, which will in general depend on the difficulty of 
the port.  For example, IDS did an Apollo port recently and is
considering doing a DEC VMS port.

Since we get many inquiries about porting ISIS to other machine
arcitectures and other versions of UNIX, I wrote up some notes discussing
the procedure:

ISIS is fairly portable, as systems of this size go.  However,
it makes use of some UNIX features that are not always supported.
Below, we discuss these and how one deals with them.

1. Lightweight tasks.
 
ISIS requires a lightweight task mechanism; it includes an
implementation for use on machines that have no native mechanism.
If you have a native mechanism, you need to port some macros
in the file cl_task.h/pr_task.h.  For example, the Cthreads port
(for use under MACH) basically consists of defines for about 10
task-related operations that ISIS needs to know how to do.  Ports

If your machine has a native task mechanism, you should define
the flag THREADS to be 1 in cl_task.h and pr_task.h.  Otherwise,
leave THREADS undefined.

Ports to machines that lack a native task mechanism are a bit
more painful.  Here, ISIS allocates chunks of stack dynamically
and uses _setjmp/_longjmp to switch between them.  
(These are the versions that don't save/restore signal masks.)

Some versions of _longjmp enforce jumps "up" the stack, and give
errors when ISIS jumps to a dynamically malloc-ed area that isn't
part of the standard stack.  If this happens on your system,
you may be forced to recode them in assembler.  This
is done in cl_setjmp.s/pr_setjmp.s. cl_setjmp.c and pr_setjmp.c
are for machines where _setjmp/_longjmp works and we wanted
to avoid running the assembler on an empty file.

You will also need to set the stack pointer and any other
registers on which code depends while running.  Normally, we
do this in assembler with an embedded "asm" call, but you can
also write an assembler language subroutine to do it, or even
use _setjmp and _longjmp to do it (if you know which entry
in the jump-buf contains the stack-pointer).  Note that
we allow a bit of extra room after the jmp-buf just in case
your version of _setjmp/_longjmp overruns the normal area.

To test your port of the task mechanism, modify cl_task.h and
recompile clib and mlib, then build the program "demos/testtasks.c".
This program runs without needing ISIS up.  It creates a few
tasks and switches between them, saving and restoring register 
values with considerable vigor.  If the values are being trashed,
your version of _setjmp/_longjmp might be at fault, or your
task package, or something else.  Don't try to advance to step 2
until this test runs cleanly.

2. Variable argument lists

These used to be a BIG headache.  We no longer pass structures
by value, which makes porting much easier.   So, you should be able
to completely ignore this whole issue unless your machine doesn't
support the va_arg convention for managing variable length arg lists.
Should that be the case, however, you will need to come up with a
version of varargs or you will be unable to port ISIS.

4. Optimizers, linking, loading, etc.

You will need to create a subdirectory to build ISIS within.  We
suggest that you duplicate the SUN3 directory (symbolic links and
all) and then edit the file MACHINE/makefile (where MACHINE is the
name for your machine).

We advise against using the optimizer for your C compiler until
ISIS seems stable.  Some optimizers have bugs and this is a real
pain to have to deal with in addition to doing the port itself.
Save optimization for the last step.

With GCC you may need to enable special options such as -fno-defer-pop,
because lightweight tasks sometimes violate assumptions that a system
like GCC is making concerning how stacks behave.  This seems very
architecture dependent.

3. Communication features

The next issue concerns getting ISIS to deal with client programs.
When "isis" starts up, it runs "protos", which then expects "isis"
to connect to it.  This connection can be done using unix-domain
connected sockets in stream mode or using tcp connected streams.
The unix streams are usually better performers.  Depending on your
system, enable the following flags in BOTH clib/isis.h and protos/pr.h:

	UNIX_DOM		1 if unix-domain, leave undefined otherwise
        SIMWRITEV               1 if writev() is broken, undefined if not
        SCATTERSEND             1 if ISIS should use scatter writes with
                                  UDP, undefined if not.

If your system doesn't support any of the available options, perhaps
you should contact us before continuing...

ISIS also has code that looks up things like port numbers and machine
names using gethostbyname() and getservbyname().  These can be changed
easily on systems that have other approaches to getting this data.
Contact us if you need help.

4. A minor "meta-comment"

We recommend that you not try to port ISIS V1.1 to a new system, since
V1.2 is much more portable and will be out shortly.

5. Contact us for help...

We will be happy to help if you run into problems (as long as it
doesn't take much of our time).  Contact ken directly: 607-255-9199
or ken@cs.cornell.edu.

Ken Birman