From thomas@loria.crin.fr 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: thomas@loria.crin.fr (Laurent Thomas) Message-Id: <9101111253.AA24979@quiche.crin.fr> To: info-sr@cs.arizona.edu 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 : thomas@loria.crin.fr POST : Centre de Recherche en Informatique de Nancy. BP 239, 54506 Vandoeuvre-les-Nancy CEDEX, France FAX : 83413079 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" Message-Id: <9101111704.AA19166@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Fri, 11 Jan 91 10:04:43 MST To: thomas@loria.crin.fr 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 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From u502sou@c1a.mpifr-bonn.mpg.de 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: info-sr@cs.arizona.edu Date: Fri, 1 Feb 91 14:09:26 +0100 From: u502sou@c1a.mpifr-bonn.mpg.de (Ignatios Souvatzis) Sender: u502sou@c1a.mpifr-bonn.mpg.de Message-Id: <9102011309.AA06766@mpirbn.mpifr-bonn.mpg.de> Subject: I picked up SR by ftp. Reply-To: u502sou@c1a.mpifr-bonn.mpg.de Return-Receipt-To: u502sou@c1a.mpifr-bonn.mpg.de 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: u502sou@mpirbn.mpifr-bonn.mpg.de From angst@cs.uq.oz.au 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 ; Tue, 28 May 91 17:36:34 +1000 Message-Id: <9105280736.AA12608@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu Subject: Assigning to resource/operation capability pointers (possible?) Date: Tue, 28 May 91 17:36:33 +1000 From: Andrew Moran 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 angst@cs.uq.oz.au 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 ; Tue, 28 May 91 22:40:08 +1000 Message-Id: <9105281240.AA16096@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu 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 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 angst@cs.uq.oz.au 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 ; Wed, 3 Jul 91 17:56:37 +1000 Message-Id: <9107030756.AA25435@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu Subject: Problem with data locking mechanism Date: Wed, 03 Jul 91 17:56:36 +1000 From: Andrew Moran 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!daemon@ames.arc.nasa.gov 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!daemon@ames.arc.nasa.gov Message-Id: <9107102258.AA10447@ntmtv.com> To: ames!info-sr@cs.arizona.edu 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: info-sr@cs.arizona.edu 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" Message-Id: <9107111705.AA02839@owl.cs.arizona.edu> 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 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From angst@cs.uq.oz.au 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 ; Sat, 27 Jul 91 15:45:32 +1000 Message-Id: <9107270545.AA28429@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu Subject: Broadcasting in SR Date: Sat, 27 Jul 91 15:45:31 +1000 From: Andrew Moran 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" Message-Id: <9107282134.AA00352@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA00352; Sun, 28 Jul 91 14:34:15 MST To: angst@cs.uq.oz.au, info-sr@cs.arizona.edu Subject: Re: Broadcasting in SR Subject: Broadcasting in SR Date: Sat, 27 Jul 91 15:45:31 +1000 From: Andrew Moran 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 angst@cs.uq.oz.au 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 ; Mon, 29 Jul 91 12:31:08 +1000 Message-Id: <9107290231.AA21904@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu Subject: Re: Broadcasting in SR In-Reply-To: Your message of "Sun, 28 Jul 91 14:34:15 MST." <9107282134.AA00352@optima.cs.arizona.edu> Date: Mon, 29 Jul 91 12:31:07 +1000 From: Andrew Moran > 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 angst@cs.uq.oz.au 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 ; Tue, 30 Jul 91 10:34:21 +1000 Message-Id: <9107300034.AA11389@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu Subject: Re: Broadcasting in SR In-Reply-To: Your message of "Mon, 29 Jul 91 08:46:49 MST." <9107291546.AA09109@owl.cs.arizona.edu> Date: Tue, 30 Jul 91 10:34:20 +1000 From: Andrew Moran > 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" Message-Id: <9107300145.AA10165@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 29 Jul 91 18:45:42 MST To: angst@cs.uq.oz.au, info-sr@cs.arizona.edu 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 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From angst@cs.uq.oz.au 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 ; Tue, 30 Jul 91 12:59:35 +1000 Message-Id: <9107300259.AA14816@uqcspe.cs.uq.oz.au> To: "Gregg Townsend" Cc: info-sr@cs.arizona.edu Subject: Re: Broadcasting in SR In-Reply-To: Your message of "Mon, 29 Jul 91 18:45:42 MST." <9107300145.AA10165@owl.cs.arizona.edu> Date: Tue, 30 Jul 91 12:59:35 +1000 From: Andrew Moran > 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 thomas@quiche.crin.fr 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 info-sr@cs.arizona.edu); Thu, 22 Aug 91 14:47:37 +0200 From: Laurent Thomas Message-Id: <9108221247.AA15480@quiche.crin.fr> Subject: mutually recursive type To: info-sr@cs.arizona.edu 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 : thomas@loria.crin.fr POST : Centre de Recherche en Informatique de Nancy. Campus Universitaire. BP 239. F-54506 Vandoeuvre-les-Nancy CEDEX, France FAX : 83413079 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" Message-Id: <9108221529.AA23810@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Thu, 22 Aug 91 08:29:55 MST To: Laurent.Thomas@loria.crin.fr, info-sr@cs.arizona.edu 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 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From shartley@king.mcs.drexel.edu 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: shartley@king.mcs.drexel.edu (Stephen J. Hartley) Message-Id: <9109292220.AA28273@mcs.drexel.edu> To: info-sr@cs.arizona.edu 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: (215) 895-2668 Math and Computer Science, Drexel University, Philadelphia, PA 19104 shartley@mcs.drexel.edu From shartley@king.mcs.drexel.edu 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: shartley@king.mcs.drexel.edu (Stephen J. Hartley) Message-Id: <9109300018.AA01875@mcs.drexel.edu> To: greg@cs.arizona.edu Subject: SR concurrency Cc: info-sr@cs.arizona.edu 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: (215) 895-2668 Math and Computer Science, Drexel University, Philadelphia, PA 19104 shartley@mcs.drexel.edu ------------------------------------------------------------------------------ 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" Message-Id: <9109301545.AA19694@paloverde.cs.arizona.edu> Received: by paloverde.cs.arizona.edu; Mon, 30 Sep 91 08:45:17 MST To: shartley@king.mcs.drexel.edu Subject: Re: SR concurrency Cc: info-sr Date: Sun, 29 Sep 91 20:18:13 EDT From: shartley@king.mcs.drexel.edu (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 olsson@cs.ucdavis.edu 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" Message-Id: <9109301627.AA17940@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 30 Sep 91 09:27:10 MST To: info-sr@cs.arizona.edu, shartley@king.mcs.drexel.edu 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 +1 602 621 4325 gmt@cs.arizona.edu 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