ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/sr/info-sr.1991

Internet Message Format | 1991-12-31 | 35KB

From [e-mail]  Fri Jan 11 05:56:10 1991
Received: from inria.inria.fr by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA13514; Fri, 11 Jan 91 05:56:10 -0700
Received: from loria.crin.fr by inria.inria.fr (5.65+/90.0.9)
    via Fnet-EUnet id AA09672; Fri, 11 Jan 91 13:55:31 +0100 (MET)
Received: from quiche.crin.fr by loria.crin.fr (5.61/AFUU-2.0/LORIA-1.2), Fri, 11 Jan 91 13:53:58 +0100
Date: Fri, 11 Jan 91 13:53:30 +0100
Received: by quiche.crin.fr (4.1/AFUU-2.0/CRIN-1.1), Fri, 11 Jan 91 13:53:30 +0100
From: [e-mail] (Laurent Thomas)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: A naive question


I just installed SR 1.1 on our SUNs and tried to write my first
program. I looked at the examples and following the dinning philo.
solution I wrote :

resource ServOps
   op passL ( p1 , p2 , p3 : int)  # WITH parameters
end
resource Servant
   extend ServOps
body Servant()
   process server
      var u,v,w : int
      receive passL (u,v,w)
   end
end
resource main
   import ServOps,Servant
body main()
   initial
      const n := 10
      var s [1:n] : cap Servant
      var si [1:n] : cap ServOps
      fa i := 1 to n ->
     s[i] := create Servant
     si[i].passL := s[i].passL   # PROBLEM
      af
   end
end

The only difference is that passL has arguments, when there are none
in the philosopher problem. The compiler says :

sr -c essai.sr
"essai.sr", line 21: warning: missing syntactic unit: (
"essai.sr", line 21: fatal: invalid term in expression: .
"essai.sr", line 21: warning: missing syntactic unit: )
"essai.sr", line 21: fatal: signature mismatch: too many arguments
"essai.sr", line 21: fatal: signature mismatch: assignment
"essai.sr", line 21: fatal: invalid token ':=' at start of statement
"essai.sr", line 23: warning: identifier declared but not used: si
*** Error code 4
make: Fatal error: Command failed for target `Interfaces/ServOps.i'

What am i missing ? (As in dinning/dinning.sr, i want to pass these
operations between some of the s[i] resoures in order to simulate a
fixed topology between them.)
While reading previous messages from this mailing list, it appears
that a new version is in preparation. Could we have some info upon
its availability ?

Thanks.

Laurent Thomas
EMAIL : [e-mail]
POST : Centre de Recherche en Informatique de Nancy.
       BP 239, 54506 Vandoeuvre-les-Nancy CEDEX, France
FAX : [phone]

From gmt  Fri Jan 11 10:04:44 1991
Received: from owl.cs.arizona.edu by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA24008; Fri, 11 Jan 91 10:04:44 -0700
Date: Fri, 11 Jan 91 10:04:43 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Fri, 11 Jan 91 10:04:43 MST
To: [e-mail]
Subject: Re: A naive question
Cc: info-sr

> [problems with an SR program]

You are missing the () on the create:  it should be
    s[i] := create Servant()

However, the signature mismatch remains after fixing that;
that appears to be a compiler bug.

> While reading previous messages from this mailing list, it appears
> that a new version is in preparation. Could we have some info upon
> its availability ?

We are making progress but are still a long way from completion.
There are too many variables to make a good estimate, but it will
be many months at a minimum even if everything goes well and we
don't have too many other things to do.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From [e-mail]  Fri Feb  1 18:51:09 1991
Received: from unido.informatik.uni-dortmund.de by megaron.cs.arizona.edu (5.61/15) via SMTP
    id AA19672; Fri, 1 Feb 91 18:51:09 -0700
Received: from mpifrrouter-x25a.extern.Uni-Dortmund.DE
    by unido.informatik.uni-dortmund.de with SMTP (UNIDO-2.0.3.e) via EUnet
    for cs.arizona.edu
    id AA23373; Fri, 1 Feb 91 13:44:43 GMT
Received: from mpirbn.mpifr-bonn.mpg.de by mpifrrouter.mpifr-bonn.mpg.de (4.1/SMI-4.0)
    id AA20544; Fri, 1 Feb 91 14:44:07 +0100
Received: by mpirbn.mpifr-bonn.mpg.de (5.61/7.0)
    id AA08045; Fri, 1 Feb 91 14:43:34 +0100
To: [e-mail]
Date: Fri, 1 Feb 91 14:09:26 +0100
From: [e-mail] (Ignatios Souvatzis)
Sender: [e-mail]
Message-Id: <[e-mail]>
Subject: I picked up SR by ftp.
Reply-To: [e-mail]
Return-Receipt-To: [e-mail]
X-Mailer: GNU Emacs 18.51.0

I just (yesterday evening) picked up SR by ftp. I intend to use it to
distribute a astronomical simulation program, which I am developing at
the moment, over a couple of DECstations available at our site (and
empty most of the nights).

In the file "mips.s", the author(s) write(s):
 *  We don't save the floating point registers; they shouldn't be needed.

As I want to (mis)use the SR system to do distributed floating point
calculations, (calling C or F77 workhorses as external functions) do I
have to:

    1) wait for floating point SR?
    2) modify mips.s to save them? (if yes, how?)
    3) just use it (because the compilers saves them for me anyway)?

I don't want to 1) [thesis work...]
    Ignatios Souvatzis
--
Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der
            Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG
Internet:   [e-mail]

From [e-mail]  Tue May 28 00:36:41 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA20594; Tue, 28 May 91 00:36:41 MST
Received: from pawpaw.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Tue, 28 May 91 17:36:34 +1000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Assigning to resource/operation capability pointers (possible?)
Date: Tue, 28 May 91 17:36:33 +1000
From: Andrew Moran <[e-mail]>


I am trying to make an any ptr point to an operation capability (at the moment,
but a resource capability could be needed/used).  I need to do this because of
the mutually-recursive nature of a data structure I am using.

Is it legal SR to do this:

    optype OP ()
    type OP_cap = cap OP

    ...

    op op_1 : OP

    proc some_proc (...)

        var op_1_ptr : ptr any

        var temp : ptr cap OP
        temp := new(OP_cap)
        temp^ := op_1

        op_1_ptr := temp

        some_other_proc (op_1_ptr) /* data constructor, takes an any ptr */

        ...

    end some_proc

The compiler tells me that there is a signature mismatch with the assignment

    temp^ := op_1

I know it's dodgy to use "type x = cap y" (as mentioned in the bugs handout),
but new requires either a simple type or a type identifier.  I can't use

    var temp : ptr OP_cap

because the compiler crashes in sigcmp.c (line 127).

Can anyone help?

Andrew Moran

---------
"He's mad, totally mad.  He's madder than Mad Jack McMad, winner of last year's
 Mr. Madman competition." -- Edmund, a butler.
----------------

From [e-mail]  Tue May 28 05:41:30 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA01841; Tue, 28 May 91 05:41:30 MST
Received: from pawpaw.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Tue, 28 May 91 22:40:08 +1000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Problem solved (was Re: Assigning to operation capability pointers)
In-Reply-To: Your message of "Tue, 28 May 91 17:36:33 +1000."
Date: Tue, 28 May 91 22:40:07 +1000
From: Andrew Moran <[e-mail]>


Since sending my inquiry, I have solved the problem I had.  All I need to do is
to enclose the capabilities in question in a record.  Then I can assign any
ptrs easily and hide the caps as required.

Thanks to those who may respond before they see this,

Andrew Moran

----------
"It's about as impressive as Stumpy Oleg McNoleg's personal best in the Market
 Harborough's Marathon." -- Lord Edmund Blackadder, loyalist
-----------------

From [e-mail]  Wed Jul  3 00:56:50 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA05293; Wed, 3 Jul 91 00:56:50 MST
Received: from pawpaw.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Wed, 3 Jul 91 17:56:37 +1000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Problem with data locking mechanism
Date: Wed, 03 Jul 91 17:56:36 +1000
From: Andrew Moran <[e-mail]>


Some of you may recall an earlier query of mine about mechanisms for enforcing
mutual exclusion on data.  I have had to revise the solution supplied by Ron
Olsson because my needs are slightly more complex than originally thought.

To recap, we associate three semaphore-like operations with each instance of
the data in question: one for requesting locks (req_lock), one for releasing
locks (rel_lock) and one for freeing the lock operations (free_ops).  When the
lock record is created, an instance of each of these operations hangs around
and is served as in new_lock below:

    op lock (v : ptr VALUE)
    op unlock (v : ptr VALUE)
    op new_lock () returns l : ptr LOCK

    proc lock (v)
        call v^.v_lock^.l_req_lock ()
    end lock

    proc unlock (v)
        send v^.v_lock^.l_rel_lock ()
        if v^.v_lock^.l_free_ops () ->
        v^.v_lock := null
        fi
    end unlock

    proc new_lock () returns l
        op req_lock, rel_lock : LockSem
        op free_ops : FreeSem

        l := new(LOCK)
        l^.l_req_lock := req_lock
        l^.l_rel_lock := rel_lock
        l^.l_free_ops := free_ops

        reply
        send rel_lock ()

        do true ->
        write (stderr, "Entering lock loop")
        flush (stderr) ; nap (1000)

        in req_lock () ->
            write (stderr, "Lock requested")
            flush (stderr) ; nap (1000)
            receive rel_lock ()
            write (stderr, "Lock gained")
            flush (stderr) ; nap (1000)
        [] free_ops () returns freed ->
            write (stderr, "Lock free ops called")
            flush (stderr) ; nap (1000)

            if ((? rel_lock) > 0) & ((? req_lock) = 0) ->
            write (stderr, "Lock operations freed")
            flush (stderr) ; nap (1000)
            freed := true
            exit
            [] else ->
            write (stderr, "Lock operations not freed")
            flush (stderr) ; nap (1000)
            freed := false
            fi
        ni
        od
    end new_lock

Note the cumbersome diagnostic writes.  These operations are part of a much
larger system, a parallel functional abstract machine.

This compiles fine, but when run produces this output:

> Entering lock loop
> Lock requested
> Lock gained
> Entering lock loop
> signal SEGV (no mapping at the fault address) in memcpy at 0xdd7e40e
> memcpy+0x26:            movb    a0@+,a1@+

Using dbx, we find out "where":

> (dbx) where
> memcpy(0x8ba20, 0x8ba58, 0x90178, 0x0) at 0xdd7e40e
> sr_invoke(ibp = 0x90178), line 126 in "invoke.c"
> `address`Plock(rp = 0x8ba20 "", rv = 0x8ba58 "^A", pb = 0x90178 "", wc = 0), line 400 in "address.c"
> sr_invoke(ibp = 0x90120), line 126 in "invoke.c"

So one invocation of req_lock is allowed and then something happens.  Is this a
symptom of something obvious that the gurus have seen before ... or is it more
insidious?

Thanks for your help,

Andrew

---------
"He's mad, mad.  He's madder than Mad Jack McMad, winner of last year's
 Mr. Madman competition." -- Edmund, a butler.
----------------

From ntmtv![e-mail]  Wed Jul 10 16:42:22 1991
Received: from ames.arc.nasa.gov by optima.cs.arizona.edu (4.1/15)
    id AA18406; Wed, 10 Jul 91 16:42:22 MST
Received: by ames.arc.nasa.gov (5.65b/1.2); Wed, 10 Jul 91 16:42:20 -0700
Received: by ntmtv.com (3.2/SMI-3.2)
    id AA10447; Wed, 10 Jul 91 15:58:51 PDT
Date: Wed, 10 Jul 91 15:58:51 PDT
From: ntmtv![e-mail]
Message-Id: <[e-mail]>
To: ames![e-mail]

Received: from ariel. by ntmtv.com (3.2/SMI-3.2)
    id AA10441; Wed, 10 Jul 91 15:58:48 PDT
Received: by ariel. (4.0/SMI-4.0)
    id AA05231; Wed, 10 Jul 91 15:57:29 PDT
Date: Wed, 10 Jul 91 15:57:29 PDT
From: hildum@ariel (Eric Hildum)
Message-Id: <9107102257.AA05231@ariel.>
To: [e-mail]
Subject: SR 2.0?


What has happened to SR 2.0? I thought that was to be out last year, but have
not heard anything...


                Eric

From gmt  Thu Jul 11 10:05:38 1991
Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (4.1/15)
    id AA23121; Thu, 11 Jul 91 10:05:38 MST
Date: Thu, 11 Jul 91 10:05:37 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Thu, 11 Jul 91 10:05:37 MST
To: info-sr
Subject: Re: SR 2.0?

    From: hildum@ariel (Eric Hildum)

    What has happened to SR 2.0?  I thought that was to be out last year,
    but have not heard anything...


We are actively working on SR version 2 and hope to release it before the
end of this year.  We did underestimate the task, and any dream of finishing
it in 1990 was unrealistic.  Stay tuned to this mailing list for further
information.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From [e-mail]  Fri Jul 26 22:45:37 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA02106; Fri, 26 Jul 91 22:45:37 MST
Received: from zinnia.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Sat, 27 Jul 91 15:45:32 +1000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Broadcasting in SR
Date: Sat, 27 Jul 91 15:45:31 +1000
From: Andrew Moran <[e-mail]>


I have an application for broadcasting, i.e. an unknown number of clients wish
to know when an event has occurred.  If the event has already occurred when
they ask, they should be told anyway.

This is what I came up with:

    resource R

    op Start ()
    op Wait ()
    op Fini ()

    ...

    body R ()

    ...

    proc Start ()
        finito := false
        send Waiting ()

        ...

    end Start

    ...

    proc Waiting ()
        in Wait () ->
        if finito ->
            send Waiting ()
        [] else ->
            call Waiting ()
        fi
        [] Fini () ->
        finito := true
        send Waiting ()
        ni
    end Waiting

    ...

    end R

Instances of R can wait upon other instances of R.

Initially, each instance starts the Waiting operation, so it now has a process
waiting to serve invocations of Wait and Fini.  To wait for an instance to
finish, you call R_i.Wait ().  When an instance is finished its work, it calls
Fini ().

So we can build up a stack of invocations of Wait, each hanging on until the
next one finishes.  When Fini is called, the in statement at that level will
terminate, as will the invocation of Waiting at that level.  Thus each call to
Wait will finish as its invocation of Waiting does.

Note that Fini (and Wait when the work is done, i.e. finito is true) invokes
Waiting with a send.  This is to allow the instance to be waited upon for its
entire lifespan, even after it has called Fini.

Can anyone see any problems with this approach?  Or any improvements?

On a tangential note, could this error:

    signal BUS (alignment error) in sr_finished_input ()

merely require an increase in one of the run time maxima or is it likely to
be a more serious flaw?  It occurs when I incorporate the above broadcasting
into my larger system.  The broadcasting works perfectly when
tested on its own.  In the larger system, R is an execution resource, which
implements an abstract machine.  A parent execution instance is waiting on two
children, with this code:

    proc WaitForArgs (lower, upper)
    fa mach := lower to upper ->
        arg_exec [mach].Wait ()
    af

    fa mach := lower to upper ->
        destroy arg_exec [mach] ; arg_exec [mach] := noop
    af
    end WaitForArgs

where lower and upper are bounds of the interval of the array of child
execution instances for which we wish to wait.  When this is used by a parent
to wait for two children, it invokes Wait () for the first, and then halts with
the above error.  The sr_finished_input () is called from within PWaiting (),
so I can only assume it has something to do with the broadcasting method.
However, I cannot reproduce the error in the test model (i.e. the one without
actual execution).  I have taken great pains to ensure that all communication
is as close to the error case as possible, but it runs perfectly.

So, once again, I make my pathetic plea to the SR community:

    Help?

Thanks,

Andrew

---------
  Lt. G: "If we do happen to stand on a mine, sir, what do we do ?"
Capt. B: "Normal procedure, Lieutenant, is to jump 200 feet into the air
      and scatter oneself over a wide area."

    -- somewhere in no man's land, "Blackadder Goes Forth"
---------------

From greg  Sun Jul 28 14:34:15 1991
Date: Sun, 28 Jul 91 14:34:15 MST
From: "Greg Andrews" <greg>
Message-Id: <[e-mail]>
Received: by optima.cs.arizona.edu (4.1/15)
    id AA00352; Sun, 28 Jul 91 14:34:15 MST
To: [e-mail], [e-mail]
Subject: Re:  Broadcasting in SR

    Subject: Broadcasting in SR
    Date: Sat, 27 Jul 91 15:45:31 +1000
    From: Andrew Moran <[e-mail]>

    I have an application for broadcasting, i.e. an unknown number of clients wish
    to know when an event has occurred.  If the event has already occurred when
    they ask, they should be told anyway.

    This is what I came up with: ...

I'm not sure I fully understand what you are trying to do, but your
approach looks much more cumbersome (and inefficient) than I think
is required.  If I do understand correctly, the following is sufficient:

        resource R

        op Wait ()
        op Fini ()
        ...

        body R ()

        process Waiting
            receive Fini()  # wait for finished signal
            do true ->
                receive Wait()  # awaken all processes who are waiting
                                # now or call Wait() later
            od
        end

        end

This can be used only once.  However, if you know how many processes will
call Wait(), you can embed the body of Waiting in a "do true" loop and
change the inner loop to terminate after enough calls of Wait have been
received.  I don't see any need for a finito flag variable.

    On a tangential note, could this error:

        signal BUS (alignment error) in sr_finished_input ()

    merely require an increase in one of the run time maxima or is it likely to
    be a more serious flaw?

Not likely.  However, someone else will have to explain what triggers
this message.

-- Greg Andrews

From [e-mail]  Sun Jul 28 19:31:14 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA09284; Sun, 28 Jul 91 19:31:14 MST
Received: from zinnia.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Mon, 29 Jul 91 12:31:08 +1000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Broadcasting in SR
In-Reply-To: Your message of "Sun, 28 Jul 91 14:34:15 MST."
             <[e-mail]>
Date: Mon, 29 Jul 91 12:31:07 +1000
From: Andrew Moran <[e-mail]>


> This can be used only once.  However, if you know how many processes will
> call Wait(), you can embed the body of Waiting in a "do true" loop and
> change the inner loop to terminate after enough calls of Wait have been
> received.  I don't see any need for a finito flag variable.

The flag is needed because a resource may need do perform its action more
than once; i.e. Fini may be called more than once.  I use finito to reset the
state of operation Waiting.

> -- Greg Andrews

Andrew Moran

----------
"It's about as impressive as Stumpy Oleg McNoleg's personal best in the Market
 Harbourer's Marathon." -- Lord Edmund Blackadder, loyalist
-----------------

From [e-mail]  Mon Jul 29 17:34:27 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA26640; Mon, 29 Jul 91 17:34:27 MST
Received: from zinnia.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Tue, 30 Jul 91 10:34:21 +1000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Broadcasting in SR
In-Reply-To: Your message of "Mon, 29 Jul 91 08:46:49 MST."
             <[e-mail]>
Date: Tue, 30 Jul 91 10:34:20 +1000
From: Andrew Moran <[e-mail]>


> It sounds like an address pointer somewhere may have been clobbered, possibly
> due to a store outside array bounds or something like that.

I think it had something to do with timing because when I removed diagnostic
writes (they were writing to files) it worked!  So my system, as it was, was
very vulnerable to timing changes.

Is this a common problem?  Or is it flawed design?

>     Gregg Townsend

Andrew Moran

--------
"Men can't deal with commitment.  They're afraid they'll get married and then
 meet the woman of their dreams at the reception." -- Carrie Snow
-------------

From gmt  Mon Jul 29 18:45:45 1991
Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (4.1/15)
    id AA29369; Mon, 29 Jul 91 18:45:45 MST
Date: Mon, 29 Jul 91 18:45:42 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Mon, 29 Jul 91 18:45:42 MST
To: [e-mail], [e-mail]
Subject: Re: Broadcasting in SR

I don't recall seeing an alignment error before, so I don't think that
particular problem is common.  That is not to say that SR is without bugs,
but it could also be caused by a bad array index in the user code.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From [e-mail]  Mon Jul 29 19:59:39 1991
Received: from uqcspe.cs.uq.oz.au by optima.cs.arizona.edu (4.1/15)
    id AA01528; Mon, 29 Jul 91 19:59:39 MST
Received: from zinnia.cs.uq.oz.au by uqcspe.cs.uq.oz.au
    id <[e-mail]>; Tue, 30 Jul 91 12:59:35 +1000
Message-Id: <[e-mail]>
To: "Gregg Townsend" <[e-mail]>
Cc: [e-mail]
Subject: Re: Broadcasting in SR
In-Reply-To: Your message of "Mon, 29 Jul 91 18:45:42 MST."
             <[e-mail]>
Date: Tue, 30 Jul 91 12:59:35 +1000
From: Andrew Moran <[e-mail]>


> I don't recall seeing an alignment error before, so I don't think that
> particular problem is common.  That is not to say that SR is without bugs,
> but it could also be caused by a bad array index in the user code.

Yeah, I'll look into it (certainly, I have arrays of resource caps, but I'm
fairly sure everything was fine there).  Is it possible that the file I/O
clobberred some global somewhere?  I was using sprintf as an external also.

If I track it down, I'll be sure to let you know.

>     Gregg Townsend

Thanks for your help,

Andrew Moran

----------
"It's about as impressive as Stumpy Oleg McNoleg's personal best in the Market
 Harbourer's Marathon." -- Lord Edmund Blackadder, loyalist
-----------------

From [e-mail]  Thu Aug 22 07:42:10 1991
Received: from quiche.crin.fr by optima.cs.arizona.edu (4.1/15)
    id AA23947; Thu, 22 Aug 91 07:42:10 MST
Received: by quiche.crin.fr id AA15480
  (5.65c+/IDA-1.4.3 for [e-mail]); Thu, 22 Aug 91 14:47:37 +0200
From: Laurent Thomas <[e-mail]>
Message-Id: <[e-mail]>
Subject: mutually recursive type
To: [e-mail]
Date: Thu, 22 Aug 91 14:47:24 MET DST
X-Mailer: ELM [version 2.3 PL11]

I want to define mutually recursive types :
    type x = rec ( ...; y : z ; ... )
    optype z ( one_x : x )
As said in the reference manual this is not allowed. So i say :
    type x = rec ( ...; y : ptr any ; ... )
    optype z ( one_x : x )

and somewhere in a resource :

    op d : z
    proc d ( one_x )
      var p : ptr cap z
      p := one_x.y
      send p^( one_x )    # fatal: signature mismatch: invoke
        end

However if i define :

    type dummy = rec ( a_z : cap z )
    proc d ( one_x )
      var p : ptr dummy
      p := one_x.y
      send p^.a_z( one_x )    # it compiles fine !!!
        end

What the hell am i missing ?

Laurent Thomas
EMAIL : [e-mail]
POST : Centre de Recherche en Informatique de Nancy.
       Campus Universitaire. BP 239.
       F-54506 Vandoeuvre-les-Nancy CEDEX, France
FAX : [phone]

From gmt  Thu Aug 22 08:29:59 1991
Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (4.1/15)
    id AA25680; Thu, 22 Aug 91 08:29:59 MST
Date: Thu, 22 Aug 91 08:29:55 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Thu, 22 Aug 91 08:29:55 MST
To: [e-mail], [e-mail]
Subject: Re:  mutually recursive type

I don't think you're missing anything there.  It looks like a bug to me.
That sort of signature problem was one of the motivations for the rewrite
of the SR compiler that is now in progress.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From [e-mail]  Sun Sep 29 15:25:13 1991
Received: from mcs.drexel.edu (king.mcs.drexel.edu) by optima.cs.arizona.edu (4.1/15)
    id AA18553; Sun, 29 Sep 91 15:25:13 MST
Received: by mcs.drexel.edu (4.1/SMI-4.0)
    id AA28273; Sun, 29 Sep 91 18:20:30 EDT
Date: Sun, 29 Sep 91 18:20:30 EDT
From: [e-mail] (Stephen J. Hartley)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Sequent code

  We have a Sequent (i386 CPU's) running DYNIX V3.0.17.9 and I would like to
run SR on it.  Has anybody written the necessary rts/sequent.s module?
  Thanks for your help.

Stephen J. Hartley, Visiting Assistant Professor, office ph: [phone]
Math and Computer Science, Drexel University, Philadelphia, PA  19104
[e-mail]

From [e-mail]  Sun Sep 29 17:22:57 1991
Received: from mcs.drexel.edu (king.mcs.drexel.edu) by optima.cs.arizona.edu (4.1/15)
    id AA21936; Sun, 29 Sep 91 17:22:57 MST
Received: by mcs.drexel.edu (4.1/SMI-4.0)
    id AA01875; Sun, 29 Sep 91 20:18:13 EDT
Date: Sun, 29 Sep 91 20:18:13 EDT
From: [e-mail] (Stephen J. Hartley)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SR concurrency
Cc: [e-mail]

  By playing around with the following program on an Encore available to me
(amax.npac.syr.edu), I have been able to determine that multiple SR processes
within the same virtual machine are run in one UNIX process (using one of
the CPU's) with apparent or simulated concurrency, i.e. SR's own scheduler
switches the CPU among the SR processes in the virtual machine.  Two processes
in separate virtual machines operate with true concurrency on different Encore
CPU's.  But the SR processes in the latter case cannot share any data (version
1.1 of SR).  So on the Encore, SR does not facilitate shared memory multiple
CPU programming to the extent that it could.
  Will the next version of SR let multiple SR processes in the same virtual
machine use multiple physical CPU's (threadlike)?

Stephen J. Hartley, Visiting Assistant Professor, office ph: [phone]
Math and Computer Science, Drexel University, Philadelphia, PA  19104
[e-mail]
------------------------------------------------------------------------------

resource TestOp
    op ReadyToGo(machine_num : int) {send}
end TestOp

resource Helper
    import TestOp
    op SignalToStart() {send}

body Helper(machine_num : int; qcap : cap TestOp)
    var sum : int

    initial
        write("Helper", machine_num, "starting up")
        flush(stdout)
    end initial

    process do_it
        send qcap.ReadyToGo(machine_num)
        receive SignalToStart()
        sum := 0
# spin for a few seconds
        fa i := 1 to 1000000 -> sum := sum + 1 af
        send qcap.ReadyToGo(machine_num)
        write("Helper", machine_num, "finished at", age(), "ms")
        flush(stdout)
    end do_it

end Helper

resource Test
    extend TestOp
    import Helper

body Test()

    process main
        var num_machines : int := 3
        var machine_num : int

        var machine_cap[1:num_machines] : cap vm
        var Helper_cap[1:num_machines] : cap Helper
        var my_cap : cap Test

        my_cap := myresource()

        fa i := 1 to num_machines ->
            machine_cap[i] := create vm()
        af

        fa i := 1 to num_machines ->
            Helper_cap[i] := create Helper(i, my_cap)
# Pick one of the following two and comment out the other.
                on machine_cap[1]
#                on machine_cap[i]
        af

        fa r := 1 to num_machines ->
            receive ReadyToGo(machine_num)
            send Helper_cap[machine_num].SignalToStart()
        af

        fa i := 1 to num_machines ->
            receive ReadyToGo(machine_num)
        af
        write("Done")
    end main
end Test

From greg  Mon Sep 30 08:45:17 1991
Received: from paloverde.cs.arizona.edu by optima.cs.arizona.edu (4.1/15)
    id AA26818; Mon, 30 Sep 91 08:45:17 MST
Date: Mon, 30 Sep 91 08:45:17 MST
From: "Greg Andrews" <greg>
Message-Id: <[e-mail]>
Received: by paloverde.cs.arizona.edu; Mon, 30 Sep 91 08:45:17 MST
To: [e-mail]
Subject: Re:  SR concurrency
Cc: info-sr

    Date: Sun, 29 Sep 91 20:18:13 EDT
    From: [e-mail] (Stephen J. Hartley)
    Subject: SR concurrency

      By playing around with the following program on an Encore available to me
    (amax.npac.syr.edu), I have been able to determine that multiple SR processes
    within the same virtual machine are run in one UNIX process (using one of
    the CPU's) with apparent or simulated concurrency, i.e. SR's own scheduler
    switches the CPU among the SR processes in the virtual machine.  Two processes
    in separate virtual machines operate with true concurrency on different Encore
    CPU's.  But the SR processes in the latter case cannot share any data (version
    1.1 of SR).  So on the Encore, SR does not facilitate shared memory multiple
    CPU programming to the extent that it could.

You are correct.  We have a multiprocessor version of SR here for
our Sequent multiprocessor.  Also, Ron Olsson and a student have an
Encore version at UC Davis, but I don't know the current status
of that.  Contact [e-mail] to inquire.

      Will the next version of SR let multiple SR processes in the same virtual
    machine use multiple physical CPU's (threadlike)?

Neither multiprocessor version is an "official" part of the
current SR distribution, but we hope to have them as part of the
distribution of version 2.0.

-- Greg Andrews

From gmt  Mon Sep 30 09:27:11 1991
Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (4.1/15)
    id AA28393; Mon, 30 Sep 91 09:27:11 MST
Date: Mon, 30 Sep 91 09:27:10 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Mon, 30 Sep 91 09:27:10 MST
To: [e-mail], [e-mail]
Subject: Sequent context switch code

Here is a context switch routine for the Intel 386 architecture.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m




/*  i386.s - intel 80386 context switching code for Sequent Symmetry
 *
 *  (This should work also for other Intel 80386 machines if they use the same
 *   calling sequences and register conventions.)
 *
 *  A context array is laid out like this:
 *
 *    saved registers (%ebp, %ebx, %esi, %edi)
 *      magic word for checking integrity
 *    unused stack space
 *    saved %esp            <--- saved ebp points here
 *    saved pc (return address)
 *    error routine addr (if code returns, which is an error, it will go here)
 *    arguments from sr_build_context call
 *
 *  Registers %ebp, %ebx, %esi, and %edi are saved at the base of the array.
 *  %eax, %ecx, and %edx aren't saved because C doesn't expect them to survive
 *  over function calls.  %esp is saved on the stack at subroutine entry.
 */

#define MAGIC 79797979         /* any unlikely long integer */
#define RSIZE 16        /* size of register save area */



    .data
    .align 2

dummy_stack:             /* fake initial context */
    .long    0          /* 00 offset - %ebp */
    .long    0          /* 04 offset - %ebx */
    .long    0          /* 08 offset - %esi*/
    .long     0          /* 12 offset - %edi */
    .long    MAGIC       /* 16 offset - magic word for sanity check */

curr_stack:            /* saves addr of current context (stack) */
    .long    dummy_stack

    .text
    .align 2



/*  sr_build_context(code,buf,bufsize,a1,a2,a3,a4) -- create a new context.
 *
 *  code     entry point of the code to be executed in the context
 *  buf         buffer for holding the context array
 *  bufsize     size of the buffer
 *  a1 - a4     four int-sized arguments to be passed to the code
 */

    .globl    _sr_build_context

_sr_build_context:
    pushl    %ebp         /* save caller's frame pointer */
    movl    %esp,%ebp    /* save caller's stack pointer */

    movl    12(%ebp), %eax    /* %eax = pointer to context array */
    movl    %eax, %esp
    addl    16(%ebp), %esp    /* point stack to end of context array */

    pushl    32(%ebp)    /* push arg4 */
    pushl    28(%ebp)    /* push arg3 */
    pushl    24(%ebp)    /* push arg2 */
    pushl    20(%ebp)    /* push arg1 */
    pushl    $under        /* push error addr in case context returns */
    pushl    8(%ebp)        /* push address for startind execution */
    pushl    $0        /* push dummy frame pointer */

    movl    %esp, (%eax)    /* set initial frame pointer*/
    movl    $MAGIC, RSIZE(%eax)  /* store magic word for integrity check */

    leave            /* restore stack and frame pointers */
    ret            /* return */



/*  sr_chg_context(newstack) -- switch context to the specified stack  */

    .globl    _sr_chg_context
_sr_chg_context:
    pushl    %ebp        /* save old frame pointer */
    movl    %esp,%ebp    /* save old stack pointer in frame pointer */

    movl    curr_stack,%eax    /* load address of current context stack */
    movl    %ebp,  0(%eax)    /* save registers in user context block */
    movl    %ebx,  4(%eax)
    movl    %esi,  8(%eax)
    movl    %edi, 12(%eax)

    addl    $RSIZE,%eax
    cmpl    %eax,%esp    /* check that stack isn't overflowing */
    jle    over
    cmpl    $MAGIC,(%eax)    /* catch earlier overflow (maybe) */
    jne    over

    movl    8(%ebp), %eax    /* load address of new context */
    cmpl    $MAGIC, RSIZE(%eax)    /* make sure new stack looks okay */
    jne    bad

    movl    %eax, curr_stack /* save address of new context */
    movl     0(%eax), %ebp    /* load registers for new context */
    movl     4(%eax), %ebx
    movl     8(%eax), %esi
    movl    12(%eax), %edi

    leave            /* restore %esp and %ebp */
    ret            /* return into new context */



/*  sr_check_stk() -- check that the stack is not overflowing  */

    .globl    _sr_check_stk
_sr_check_stk:
    movl    curr_stack, %eax
    addl    $RSIZE, %eax
    cmpl    %eax, %esp
    jle    over
    ret



/*  stack problem handlers  (these calls do not return)  */

over:    call    _sr_stk_overflow
under:    call    _sr_stk_underflow
bad:    call    _sr_stk_corrupted