🚀 go-pugleaf

In the course of implementing the Modula-2 language on 
the Sun workstation under the Unix (TM) operating system,
I have been faced with the problem of how to deal with
the coroutine mechanism (Wirth's PROCESS type).  There are
a couple of aspects of the mechanism as I understand it
which just don't lend themselves to an obvious interpretation
in an environment like this.  Specifically, I am looking
for your input on the meaning of process priorities
( syntax "MODULE" <ident> "[" <ConstExpression> "]" ";" )
and the IOTRANSFER procedure on a system like Unix where
programs outside the kernel cannot access hardware,
prevent interrupts, or change machine interrupt response
priority levels.  The following approaches suggested
themselves to me, but undoubtedly there are many others:

A . Go ahead and generate code for the bare-bones
    machine, force the user to go through the process
    of linking kernel-mode code, and make NEWPROCESS,
    TRANSFER, and IOTRANSFER part of a nonstandard
    Unix kernel.  Although to the uninitiated, this might
    look like just what the doctor ordered, it's much
    easier said than done, and the risks are immense.
    It becomes very difficult to manage the asynchronism
    between new releases of the operating system and any
    updates to the compiler.

B . Take the other extreme and forbid process priorities
    and the IOTRANSFER procedure altogether;  Implement
    NEWPROCESS and TRANSFER only, don't let Unix know
    that the stack pointer of the process is being
    played with, and let the code run entirely in user
    mode.  It is now easy to share an address space 
    between coroutines, because all coroutines in the
    user's Modula-2 program are a single Unix process.
    I get the feeling that this is what Dr. Wirth would
    recommend, as he states (ed. 1 & 2 PIM2) that the
    IOTRANSFER procedure is PDP-11 specific.  It has the
    disadvantage that Modula-2 programs cannot do explicit
    rescheduling of other coroutines based on asynchronous
    external events.

C . Use IOTRANSFER as a mechanism for waking up a
    coroutine on a Unix signal, treating Unix signals as
    if they represented the hardware interrupts implied
    by IOTRANSFER.  Mask and unmask these signals as 
    implied by coroutine priorities, assigning to each of
    the huge multitude of Unix signals its own priority
    level, in some arbitrary order.  Note that with this
    implementation, the entire family of coroutines
    will still go "to sleep" if one of them performs
    a system call like "read", for example.  Another
    difficulty is the time-dependent and non-atomic
    interactions between signals and Unix processes.
    Finally, Modula-2 programs wouldn't work well in
    harmony with C functions that play with signals
    outside the domain of the Modula-2 compiler.

D . Assert that the coroutine abstraction isn't very
    useful if you already have a more powerful operating
    system, and instead let the users use the ordinary
    "fork/exec" mechanism to create "real" Unix processes.
    Leave NEWPROCESS, TRANSFER, and IOTRANSFER out 
    altogether, or let users build them themselves.

In the 1.0 implementation of Modula-2 on Sun, recently
introduced, I have chosen approach B because it involves
the least risk and provides reasonable functionality
while allowing migration to the other alternatives later
if that looks advisable.  If I get significant levels
of consensus from you users out there, it is probable that
our implementation can be enhanced in the future.

Fire away, and thanks in advance!

Chuck Bilbe                  cbilbe@Sun.COM
Project Leader, Modula-2
Sun Microsystems, Inc.
Mountain View, CA.