home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1221 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.0 KB  |  80 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!mcsun!sun4nl!dutrun!dutrun2!dutncp8!rob
  3. From: rob@pact.nl (Rob Kurver)
  4. Subject: Re: Recursion in occam
  5. Message-ID: <rob.722177288@dutncp8>
  6. Sender: news@dutrun2.tudelft.nl (UseNet News System)
  7. Nntp-Posting-Host: dutncp8.tn.tudelft.nl
  8. Organization: PACT, Delft, The Netherlands
  9. References: <142@autro1.UUCP>
  10. Date: Thu, 19 Nov 1992 12:48:08 GMT
  11. Lines: 67
  12.  
  13. In <142@autro1.UUCP> teig@autro1.UUCP (Oyvind Teig) writes:
  14.  
  15. >Recursion of occam-2 or -3
  16.  
  17. >I have seen enough of stack overflow errors to appreciate the lack
  18. >of recursion in occam.
  19.  
  20. Recursion + stack-checking -> no stack overflow.
  21.  
  22. >Rob Kurver writes:
  23. >> It is very well possible to introduce stack checking code during linking,
  24. >> when a call-graph of the program can be used to determine if and when
  25. >> it is possible.  This would result in ZERO overhead for a program written
  26. >> without recursion, and minimum overhead for recursive programs.  We
  27. >> are currently working on this feature in PACT Parallel C.
  28.  
  29. >Ok, but you still have not removed the stack overflow!
  30.  
  31. When I say "stack checking" I mean "stack checking plus expansion if
  32. necessary".  By checking the stack and expanding it if necessary, you
  33. remove the stack overflow.  The linker can build a call-graph for the
  34. entire program, so it knows which functions call which other functions.
  35. This allows it to detect recursion.  All non-recursive branches need
  36. only have enough stack allocated once, at the start of the branch (i.e.
  37. at process or program creation).  The recursive branches, if any, need
  38. to have stack checking (+ expansion) code introduced in the loop
  39. (unless you just want to restrict the depth at linktime, of course).
  40.  
  41. This way, there's no overhead if you don't use recursion, and there is
  42. a small overhead if you do use recursion.  You don't have stack
  43. overflows in any case.
  44.  
  45. >This comes close to the discussion of exception-handling: how do
  46. >you solve that in Pact-C, and what would you recommend when stack overflow
  47. >is encountered?
  48.  
  49. Upon stack overflow, the stack is extended by allocating a new block of
  50. memory from the heap.  If this is not possible (out of memory), you get
  51. a fatal error message and your program aborts.
  52.  
  53. >If occam had been written from the philosophy that "if you don't need it,
  54. >don't use it", it definitively would have not been occam.
  55.  
  56. I guess it would not have been Occam-2, no.  It might have had data
  57. structures :-).
  58.  
  59. >Is it possible to do multi-language design with the Inmos D7205 occam
  60. >toolset and your Pact C-compiler, like it is with the Inmos C-toolset?
  61.  
  62. Yes.  You can link Occam (TCOFF) modules with PACT Parallel C modules.
  63.  
  64. >For me as an occam-user, your parallel C (:-) is of little interest because
  65. >C is not interesting, if it were, I would not have used occam (recursive
  66. >definition: interesting but little useful(%-|)
  67.  
  68. I C :-).  A lot of people do find C interesting, though.
  69.  
  70. >0yvind Teig
  71. >Autronica, Trondheim, Norway
  72.  
  73. Rob
  74.  
  75. --
  76.      PACT                   Rob Kurver
  77.     Foulkeslaan 87         rob@pact.nl
  78.    2625 RB Delft     ph: +31 15 616864 
  79.   The Netherlands   fax: +31 15 610032
  80.