home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1215 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.5 KB
  1. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!nuug!autro1!teig
  2. From: teig@autro1.UUCP (Oyvind Teig)
  3. Newsgroups: comp.sys.transputer
  4. Subject: Recursion in occam
  5. Message-ID: <142@autro1.UUCP>
  6. Date: 19 Nov 92 09:18:37 GMT
  7. Reply-To: teig@autro1.UUCP (Oyvind Teig)
  8. Organization: Autronica A/S, Trondheim, Norway
  9. Lines: 30
  10.  
  11. Recursion of occam-2 or -3
  12.  
  13. I have seen enough of stack overflow errors to appreciate the lack
  14. of recursion in occam.
  15.  
  16. Rob Kurver writes:
  17. > It is very well possible to introduce stack checking code during linking,
  18. > when a call-graph of the program can be used to determine if and when
  19. > it is possible.  This would result in ZERO overhead for a program written
  20. > without recursion, and minimum overhead for recursive programs.  We
  21. > are currently working on this feature in PACT Parallel C.
  22.  
  23. Ok, but you still have not removed the stack overflow!
  24.  
  25. This comes close to the discussion of exception-handling: how do
  26. you solve that in Pact-C, and what would you recommend when stack overflow
  27. is encountered?
  28.  
  29. If occam had been written from the philosophy that "if you don't need it,
  30. don't use it", it definitively would have not been occam.
  31.  
  32. Is it possible to do multi-language design with the Inmos D7205 occam
  33. toolset and your Pact C-compiler, like it is with the Inmos C-toolset?
  34.  
  35. For me as an occam-user, your parallel C (:-) is of little interest because
  36. C is not interesting, if it were, I would not have used occam (recursive
  37. definition: interesting but little useful(%-|)
  38.  
  39. 0yvind Teig
  40. Autronica, Trondheim, Norway
  41.