home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / TURBOM2 / MONITOR.TM2 < prev    next >
Text File  |  2000-06-30  |  5KB  |  101 lines
  1.                Notes on the Turbo Modula-2 "Monitor" Function
  2.                             by D. McCord, Echelon
  3.  
  4.  
  5. 1. Overview
  6.  
  7. Turbo  Modula-2  possesses,  as per the  Modula-2  language  definition,  the 
  8. feature of "coroutines".  Coroutines are an important feature of Modula-2, as 
  9. they  incorporate  into  the language itself the concepts  of  concurrency  - 
  10. multiple  software processes executing, apparently or actually, at  the  same 
  11. time.  This is a quite useful feature for situations where there may be  more 
  12. than  one  central processing unit (CPU) available, or when  a  situation  of 
  13. needing multiple programs operating simultaneously occurs.
  14.  
  15. Of course, in the context of Turbo Modula-2, which operates on a single  Z80-
  16. compatible  microprocessor, multiple CPU's are not a consideration.  But  the 
  17. capability  of using multiple Modula-2 programs simultaneously can  be  quite 
  18. useful.  A good example of this is software which utilizes hardware interrupt 
  19. functions.    Turbo  Modula-2  implements  generic  Modula-2  features,   via 
  20. coroutine-oriented functions, to provide interrupt handlers which operate  in 
  21. a  clearly defined, yet autonomous manner from whatever the  Modula-2  "main" 
  22. module  may  be doing.  This is quite unusual among high  level  languages  - 
  23. typically,  interrupt  handlers  are done in assembly language  and  must  be 
  24. "kludged"  into  an  application written in a high  level  language  such  as 
  25. Modula-2.
  26.  
  27. In  an interrupt environment, it is sometimes necessary to control the  state 
  28. of  the host CPU's interrupt handling.  In the case of Turbo  Modula-2,  this 
  29. control  is best thought of as simply enabling or disabling  interrupts,  and 
  30. the  generic Modula-2 "monitor" function is implemented in order  to  provide 
  31. this function.
  32.  
  33. This  note  is  not  intended  to be  a  tutorial  on  usage  of  interrupts, 
  34. coroutines,  and interrupt handlers with Turbo Modula-2.  For  more  detailed 
  35. information on those topics, see Steve Hirch's informative notes contained in 
  36. the  file TM2NOT10.LBR, available from Echelon on SUS disk or on most  Z-Node 
  37. Remote Access Systems.
  38.  
  39. This  note  is intended to supplement the information given  in  the  product 
  40. documentation regarding the operation of Turbo Modula-2 monitors.
  41.  
  42.  
  43. 2. What is a monitor?
  44.  
  45. A  monitor  under  Turbo  Modula-2 is a module  which  locks  out  (disables) 
  46. hardware interrupts.  Refer to the Turbo Modula-2 User's Guide (TM2UG),  page 
  47. 192,  for  the  information  contained  on the  topic  of  monitors  (in  the 
  48. discussion of the IOTRANSFER procedure from the SYSTEM module).
  49.  
  50. A  monitor's  capability  of disabling interrupts can  be  useful,  and  even 
  51. necessary  in certain situations.  Consider a type-ahead  keyboard  function.  
  52. Typically, an interrupt handler for this kind of function will be written  in 
  53. a  simple way which presumes interrupts will be disabled while the  interrupt 
  54. handler  is  executing; to write it in such a way that interrupts  would  not 
  55. have  to  be disabled could be very "expensive" in terms of  code  speed  and 
  56. memory usage (it would have to be written to be reentrant).
  57.  
  58.  
  59. 3. Incomplete information in TM2UG
  60.  
  61. TM2UG  indicates  on page 192 how the monitor function may be enabled  for  a 
  62. module.   An  important  bit of information not included there  is  that  the 
  63. monitor  function  is  only active during execution of  procedures  and  sub-
  64. modules;  thus, interrupts are not disabled during the "initialization  code" 
  65. section  of  a module, which is cometimes referred to as the  "module  body", 
  66. defined as the code between the BEGIN and END statements of the module.
  67.  
  68. The following code example should clarify this.
  69.  
  70. MODULE Monitor[1];  (* monitor function invoked here *)
  71.  
  72. (* This procedure disables interrupts when it executes, also any *)
  73. (* procedures called from this procedure will also have interrupts *)
  74. (* disabled *)
  75. PROCEDURE Pr;
  76. BEGIN
  77.   WRITELN("Interrupts are disabled here");
  78. END Pr;
  79.  
  80. (* This is the initialization code.  Interrupts are not disabled here *)
  81. BEGIN
  82.   WRITELN("Interrupts are enabled here");
  83.   Pr;
  84. END Monitor.
  85.  
  86.  
  87. 4. Summary
  88.  
  89. The  programmer  using the monitor function of Turbo Modula should  be  aware 
  90. that, contrary to what is implied in the manual, hardware interrupts are  not 
  91. disabled  at  all  places  in  a module declared  as  a  monitor.   Only  the 
  92. procedures and sub-modules of a monitor module have interrupts disabled.  The 
  93. initialization  code or module body will have interrupts enabled,  unless  it 
  94. has been called from a procedure or sub-module of another monitor module.
  95.  
  96. Echelon, Inc.
  97. 885 N. San Antonio Road
  98. Los Altos, CA  94022  USA
  99. 415/948-3820 order line/tech support
  100. 415/958-6656 Z-Node Central (data)
  101.