home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1202 < prev    next >
Encoding:
Text File  |  1992-11-17  |  3.8 KB  |  88 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: IS Occam3 recursive?
  5. Message-ID: <rob.722005143@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: <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford> <1992Nov17.093335.11067@inmos.co.uk>
  10. Date: Tue, 17 Nov 1992 12:59:03 GMT
  11. Lines: 75
  12.  
  13. In <1992Nov17.093335.11067@inmos.co.uk> roger@gimli.inmos.co.uk (Roger Shepherd) writes:
  14.  
  15. >In article <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford>, 
  16. >michael@uk.ac.oxford.robots (& Stevens) writes:
  17.  
  18. [BTW, Michael, your original article never made it to this site - did you
  19.  restrict the distribution or did a local system goof up?]
  20.  
  21. >|> Now the arguments about recursion and OCCAM have been going a while I
  22. >|> though I would make a quick summary.
  23.  
  24. >|>     2. Code generation isn't hard. Handle the stack extension is possible.
  25. >|> If it can be done for C, you can do it for OCCAM.
  26.  
  27. >Errr. C doesn't has concurrency. It is the COMBINATION of concurrency and
  28. >recursion which leads to problems. Code generation is possible certainly,
  29. >but the resulting code is likely either to waste memory (if you allocate
  30. >vast amounts of memory to each process) or will run slowly (dynamic allocation
  31. >on every procedure call).
  32.  
  33. Why do you think C has no concurrency?  Just because many C compilers
  34. provide no elegant language constructs to specify concurrency, doesn't
  35. mean C has no concurrency.
  36.  
  37. There exists a parallel dialect of C [guess who makes it? :-] that
  38. is just as concurrent as Occam.  It is certainly possible to have
  39. recursion and concurrency:  by allocating stack space in chunks it
  40. is even possible to have recursion and concurrency at a very low
  41. cost.  The cost of stack checking and expansion in our PACT Parallel
  42. C compiler is more than compensated for by the code optimizations
  43. and generation!
  44.  
  45. >|>     3. You don't need to use it. If you want to be able to
  46. >|> predetermine memory usage at compile time don't recurese.
  47.  
  48. >Unless you provide a system which implements both recursive and non-recursive
  49. >occam you will pay the price of supporting recursion even when it is not used.
  50.  
  51. It is very well possible to introduce stack checking code during linking,
  52. when a call-graph of the program can be used to determine if and when
  53. it is possible.  This would result in ZERO overhead for a program written
  54. without recursion, and minimum overhead for recursive programs.  We
  55. are currently working on this feature in PACT Parallel C.
  56.  
  57. >|>     4. Why single out memory as the single resource that should be
  58. >|> predetermined at compile time. Time is another resource that runs out,
  59. >|> and so does disk space.
  60.  
  61. >Running out of memory is just one issue - performance is another. Also, this 
  62. >argument strikes me as somewhat specious - "because you can't do everything
  63. >correctly, you shouldn't bother doing anything!"+
  64.  
  65. As indicated above (which is confirmed by our actual measurements, BTW),
  66. performance is not a reason to disallow recursion.  Yes, recursion does
  67. complicate the design of your compiler system and runtime environment
  68. somewhat, but it is very well possible to support stack checking and
  69. expansion that can be tuned by the programmer for speed if and when he
  70. feels like it, thus resulting in negligible overhead.
  71.  
  72. Because you _can_ do recursion correctly, and it is so valuable for so
  73. many problems, you _should_ bother to do it.  If the compiler doesn't
  74. support it, and users need it anyway, they will just build their own
  75. stacks, at a much higher cost.
  76.  
  77. >Actually, a recurive occam-like language is a good idea, and very good fun
  78. >to use.  [...]
  79.  
  80. Yes, we think so, indeed.
  81.  
  82. Cheers. - Rob
  83. --
  84.      PACT                   Rob Kurver
  85.     Foulkeslaan 87         rob@pact.nl
  86.    2625 RB Delft     ph: +31 15 616864 
  87.   The Netherlands   fax: +31 15 610032
  88.