home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / parallel / 2574 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.6 KB  |  70 lines
  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gatech!hubcap!fpst
  3. From: don@ohm.york.ac.uk (Don Goodeve)
  4. Subject: Re: Manipulating process workspace on the Transputer
  5. Message-ID: <1992Nov20.151414.7613@hubcap.clemson.edu>
  6. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  7. Organization: Electronics Department, University of York, UK
  8. References: <1992Nov17.132507.14895@hubcap.clemson.edu>
  9. Date: Fri, 20 Nov 92 14:13:48 GMT
  10. Approved: parallel@hubcap.clemson.edu
  11. Lines: 57
  12.  
  13. In <1992Nov17.132507.14895@hubcap.clemson.edu> aghao@sersun2.essex.ac.uk writes:
  14.  
  15. >To this I would add that I need this information at run-time.  The idea is that
  16. >there are low-priority processes executing code implemented as functions
  17. >(A and B, say).  Each of these processes would have an associated workspace,
  18. >pointed to by Wptr, for local vars, params, etc.  I need to know exactly what
  19. >the size of the allocated workspace is, and I would like to design a separate
  20. >function (G, say), which, executed by a high priority process, would be able to
  21. >examine, access and manipulate the workspaces for A and B.  
  22.  
  23. The only way that I think you could get this information is from
  24. the compiler/builder. Tcode is relocatable and hence can be started
  25. anywhere in memory without modification. However, on startup the
  26. WPtr and IPtr need to be set (base addresses). You can easily find
  27. this value if you can ensure that no variables in your code are
  28. allocated before you do something like
  29.  
  30. LDLP 0
  31. STNL address  (pass in as a f. parameter)
  32.  
  33. The top limit is a matter for whatever you are using to do memory
  34. allocation (icollect in Inmos toolsets). This will depend on the
  35. requirements of your compiled code and any stuff that you link
  36. in. I do not know of any way you could determine it at run time.
  37.  
  38. If you have the available memory, you could always write a bogus
  39. piece of code that does something like (Occam)
  40.  
  41. SEQ
  42.   [ridiculously.large.number]INT dud.array :
  43.   PLACE dud.array IN WORKSPACE :
  44.   SEQ
  45.     SKIP    -- (may have to be more meaningful to avoid being
  46.             --  optimised out)
  47.   ... Rest of function
  48.  
  49. This way, you should be able to guarantee the upper limit by
  50. choosing an appropriate ridiculously.large.number.
  51.  
  52. Not necassarily the most elegant approach, but it may save
  53. a lot of hassling around trying to extract the information
  54. you need.
  55.  
  56. I dont know what the situation is like for other language
  57. platforms, but you should be able to do something similar.
  58.  
  59. Cheers
  60.     Don
  61.  
  62. don@ohm.york.ac.uk
  63.  
  64.  
  65. -- 
  66.  ---------------------------------------------
  67. | Don --- Well why not? Someone has got to be!|
  68.  ---------------------------------------------
  69.  
  70.