%\documentstyle{csart}

%\begin{document}

%\newenvironment{linear}{\\ \begin{minipage}[t]{\textwidth}}{\end{minipage}}

\section{\label{vcr}The Virtual Channel Router}

     The Southampton VCR \cite{vcrref1} provides efficient routing
of messages between arbitrary user processes on arbitrary processors,
overcoming the hardware limitation of first generation transputers and
their compilers, which only provided support for communication between
processors with direct physical connections.  VCR
adheres strictly to the occam model of communication,
so the channel retains a central role,
and all communications are strictly synchronised.  An enhanced occam
compiler is available which transparently incorporates calls to VCR
procedures wherever user code contains occam communication primitives.
Also a configurer recognising a subset of occam is available for
placing top-level user processes on processors.  The only apparent
distinction between this configurer and earlier ones is that there are
no hardware-related restrictions on the number or connnectivity of
configuration-level channels; these channels are now through-routed
``virtual channels''.

     For purposes of this article, the most interesting aspect of VCR
is not the enhanced compiler or configurer, which together still only
directly support {\em static} placement of user processes on
processors, with static connections, but the facilities in the VCR
library for {\em dynamic} placement.

     Existing implementations of occam include an unnatural restriction
which only allows code to be placed on particular processor through
directives in the top-level configuration code.  One of the goals of
VCR has been to provide a run-time library for a dialect of the
language in which this restriction was lifted \cite{fulloc}.  In
configuration-level occam the process
\begin{linear}
\begin{verbatim}

    PROCESSOR expression
      process

\end{verbatim}
\end{linear}
which behaves identically to `process', but
is specified to run on the processor defined by `expression', may
appear.  The VCR library \cite{vcrref3}effectively allows this placed process to
appear anywhere in a user process, not just in a static, top-level,
\verb$PLACED PAR$.  In both (early) static configurers and dynamic VCR
the restriction is enforced that `process' should be a call to a
separately-compilable procedure (rather than general in-line code).
For many purposes this is a relatively minor ``implementation limit''.
The important point is that arbitrary parameters, including channel
parameters, can be passed to this procedure invocation.

     If it weren't for the insistence that {\em channel} parameters can
be passed to the procedure invocation, this placement mechanism
would be a fairly mundane remote procedure call (RPC).  The fact that
the calling (parent) process can pass channel parameters to the remote
process makes this mechanism much more expressive.  As the simplest
example, some parent process could execute
\begin{linear}
\begin{verbatim}

    CHAN OF PROT from.slave, to.slave :  PAR
      ... client process
      PROCESSOR remote
	server (to.slave, from.slave)

\end{verbatim}
\end{linear}
where the (implicitly local) ``client
process'' interacts with the remote invocation of {\em server} through
the channels {\em to.slave} and {\em from.slave}.  (Not completely
dissimilar mechanisms are available in some distributed system
programming languages, for example \cite{hermes}).

     This is a small step, logically, from earlier occam
implementations.  The implementation details of the new regime are
significantly more complicated, though.  Spawning a process remotely
presumes the existence of a fairly elaborate kernel running on the
target processor, whereas earlier occam implementations allowed naked
user code to run on all processors.  Since it can't be predicted at
compile time where the user process will place processes, the kernel
needs to be equipped with dynamic memory management capabilities to
find workspace for the spawned processes.  Moreover, some technology is
needed to set up channels such as {\em from.slave} and {\em to.slave}
above.

     The physical incarnation of a virtual channel end is a data
structure (called the Virtual channel Control Block, or VCB, in
VCR) which contains information concerning the whereabouts of the local
and remote processes connected by the channel, and buffer space.  In
the fragment above both ends of a channel have data structures
allocated {\em locally} (because in general it isn't known at
allocation time which would be the ``proper'' processor on which to
allocate the remote end; in fact the definition of occam allows several
RPCs on {\em different} processors to be passed the same channel end at
different times).  Then, when the remote procedure call (RPC) occurs,
one end of the channel must be ``moved'' to the remote processor for
the duration of the RPC.  This involves an exchange of control messages
between the local and remote kernels causing space for the channel to
be allocated remotely, and possible transfer of the contents of the old
channel VCB from the local processor.

     The pure remote procedure call mechanism illustrated above thus
requires dynamic operations including channel-moving for its
implementation.  These aren't explicit in the code above, but the
technology has to be available in the VCR run-time system.  The
motivation of the current work was the desire to spawn much more
general networks than such simplified client-servers {\em efficiently} at
run time.  For this it seems that the underlying technology of VCR
suffices, but that the bits have to be put together in more general
paradigms than pure occam remote procedure calls.

%\end{document}

