home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / transput / 1192 < prev    next >
Encoding:
Text File  |  1992-11-14  |  2.7 KB  |  62 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: Manipulating process workspace on the Transputer
  5. Message-ID: <rob.721664219@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: <6348@sersun1.essex.ac.uk>
  10. Date: Fri, 13 Nov 1992 14:16:59 GMT
  11. Lines: 49
  12.  
  13. In <6348@sersun1.essex.ac.uk> aghao@sersun2.essex.ac.uk writes:
  14.  
  15. >As part of my research, I need to be able to examine the workspace of one or 
  16. >more Transputer processes.  Clearly, this is quite feasible, as I can get hold
  17. >of the Wptr of a process.
  18.  
  19. >However, as I need to access the workspaces as separate, individual entities,
  20. >I need to know what the boundaries are, ie where each particular process' 
  21. >workspace starts and *ends*.  One possibility is to find out what the size
  22. >of each workspace is, and that is what I am hoping to be able to do.
  23.  
  24. It is not entirely clear to me what you're looking for, i.e. how you
  25. define the start and end of the workspace.  Are you interested in the
  26. memory reserved for the entire stack of the current thread, or just in
  27. the frame used by the current function invocation?
  28.  
  29. If the latter, you know the start by loading the Wptr (something
  30. like `__asm ("ldlp 0")'), and you'll have to know a bit about your
  31. compiler system to find out how to find the end.  In general, this
  32. is were any arguments passed to this function are stored, so there
  33. may be some tricks to get this info.  But again, this will most likely
  34. differ (if only slightly) between compilers.  Please send me email
  35. if you'd be interested in the solution for our PACT Parallel C compiler.
  36.  
  37. >Does anyone out there have any suggestions?  Most of my work is done using 
  38. >GENESYS C, although suggestions with ref. to any other language would be 
  39. >gratefully received.
  40.  
  41. If you're interested in finding out the start and end of the current
  42. stack for this thread, the solution will depend very much on your
  43. compiler or operating system, as the transputer process itself
  44. stores no such information.  Most decent transputer compilers for
  45. modern languages like C do stack checking in order to allow for
  46. recursion, for which they need to pass some kind of thread
  47. descriptor to each function.  This thread descriptor contains
  48. information about the start and end of the current stack, as well
  49. as info needed to get back to previous chunks of stack.  This info
  50. is most likely given in your compiler documentation.
  51.  
  52. >    Obi Aghanya
  53.  
  54. Rob Kurver
  55. PACT Parallel Architecture and Compiler Technology
  56.  
  57. --
  58.      PACT                   Rob Kurver
  59.     Foulkeslaan 87         rob@pact.nl
  60.    2625 RB Delft     ph: +31 15 616864 
  61.   The Netherlands   fax: +31 15 610032
  62.