home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / acorn / tech / 65 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.2 KB
  1. Path: sparky!uunet!mcsun!uknet!acorn!osmith
  2. From: osmith@acorn.co.uk (Owen Smith)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Re: Modules
  5. Message-ID: <17927@acorn.co.uk>
  6. Date: 20 Aug 92 17:43:42 GMT
  7. References: <1992Aug19.200810.1@vxdesy.desy.de>
  8. Sender: osmith@acorn.co.uk
  9. Organization: Acorn Computers Ltd, Cambridge, England
  10. Lines: 36
  11.  
  12. In article <1992Aug19.200810.1@vxdesy.desy.de> burke@vxdesy.desy.de writes:
  13.  
  14. >  The PRM seems a bit inconsistent on the subject of interrupts in SWIs.
  15.  
  16. Unfortunately the RISC OS 2 PRM is out of date - it describes what the
  17. situation was under Arthur. In RISC OS 2 interrupts are usually enabled when
  18. your SWI entry code in your module is called. In fact interrupts are in
  19. whatever state they were in when the SWI was issued, which means they are
  20. almost always enabled. This also means that enabling them if they were
  21. disabled may be dangerous, since IRQs were disabled for a reason by the code
  22. that called your SWI. This is fairly unusual though - how much code have you
  23. written that calls SWIs with IRQs disabled?
  24.  
  25. >  Now to the thorny subject of errors.
  26.  
  27. I'm not going to answer what you asked, but make a different point instead.
  28. Please remember that *ALL* SWIs are capable of returning V set R0 -> error,
  29. so whenever you call *ANY* SWI (including OS_WriteC and the like) you should
  30. check for a V set error return.
  31.  
  32. There are a variety of ways you can get an error from a SWI that you don't
  33. expect. If it's not an OS SWI, just RMKill the module :-). OS SWIs may be
  34. intercepted by some dodgy software, either through a vector or illegally by
  35. patching the SWI table; alternatively you may be spooling or using the
  36. printer drivers. A good case in point is Sound_InstallVoice (PRM page 1593).
  37. This says "If an error occurs, this SWI does not set V in the usual manner.
  38. Instead R1 is zero on exit, and R0 points directly to a null-terminated
  39. string." While this is strictly true, it is misleading as it implies you
  40. don't need to check for V set error return at all. This is false - if you
  41. *RMKill the SoundChannels module you get V set R0 points to a SWI not known
  42. error block. So you need to check V set first, and then check for the
  43. unusual way this SWI returns errors.
  44.  
  45. Owen.
  46.  
  47. The views expressed are my own and are not necessarily those of Acorn.
  48.