home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1206 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.4 KB  |  57 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!sol.ctr.columbia.edu!ira.uka.de!gmd.de!Germany.EU.net!mcsun!sun4nl!dutrun!dutrun2!dutncp8!rob
  3. From: rob@pact.nl (Rob Kurver)
  4. Subject: Re: IS Occam3 recursive?
  5. Message-ID: <rob.722034771@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: <rob.721665532@dutncp8> <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford> <2292@eagle.ukc.ac.uk>
  10. Date: Tue, 17 Nov 1992 21:12:51 GMT
  11. Lines: 44
  12.  
  13. In <2292@eagle.ukc.ac.uk> wgd@ukc.ac.uk (Warren Day) writes:
  14.  
  15. >I would very much like such a language that has all the things that
  16. >parallelism prevents: recursion, pointers, dynamic memory and data
  17. >structures.
  18.  
  19. I'm afraid you've lost me:  why do you think parallelism prevents
  20. recursion, pointers, dynamic memory and (especially) data structures?
  21. Parallelism may complicate matters, but it doesn't actually prevent any
  22. of these things.
  23.  
  24. >and there appears to be quite an argument along the lines of Michael's "why
  25. >don't you have it and just not use it when you don't need it", which as
  26. >Roger Shepherd said, means having two compilations approachs (if I understand
  27. >correctly).
  28.  
  29. Not necessarily.  A smart enough compiler system may well be able to
  30. support recursion at a small price if used, but without any overhead if
  31. not used.  This can be implemented by a smart linker, which uses a call
  32. graph to locate recursion and inserts stack allocation and expansion
  33. code where necessary.  If no recursion is used, no stack expansion code
  34. is introduced.
  35.  
  36. >             Perhaps Inmos have a market for a family of occam languages,
  37. >occam.par and occam.seq.
  38.  
  39. I don't believe it would be wise for Inmos or any other transputer
  40. compiler vendor to have parallel and sequential versions of their tools.
  41. It may make sense to provide compiler options to allow stack stacking
  42. and expansion to be tuned, in the absence of aforementioned smart
  43. linker.
  44.  
  45. The CSP paradigm as supported by Occam and PACT Parallel C is a very
  46. powerful one, and is especially interesting with the support provided
  47. by the transputer.  It is up to the implementation to avoid unnecessary
  48. overhead.
  49.  
  50. Cheers. - Rob
  51.  
  52. --
  53.      PACT                   Rob Kurver
  54.     Foulkeslaan 87         rob@pact.nl
  55.    2625 RB Delft     ph: +31 15 616864 
  56.   The Netherlands   fax: +31 15 610032
  57.