home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / atari / st / tech / 4517 < prev    next >
Encoding:
Text File  |  1992-08-21  |  2.5 KB  |  59 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!ilepore
  3. From: ilepore@nyx.cs.du.edu (Ian Lepore)
  4. Subject: Re: Help with prog. Execption handlers on ST
  5. Message-ID: <1992Aug21.185809.6263@mnemosyne.cs.du.edu>
  6. Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
  7. Organization: University of Denver, Dept. of Math & Comp. Sci.
  8. References: <18373.2a951810@levels.unisa.edu.au>
  9. Date: Fri, 21 Aug 92 18:58:09 GMT
  10. Lines: 47
  11.  
  12. Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
  13. X-Disclaimer: Nyx is a public access Unix system run by the University
  14.     of Denver for the Denver community.  The University has neither
  15.     control over nor responsibility for the opinions of users.
  16.  
  17.  
  18.  
  19. > * this is the exception processing routine
  20. > BusErrHandler   move.b    #$FF,BusErrFlag    * set flag for Bus error
  21. >                 rte
  22. >*** this is where i get "address errors" when I try to execute a
  23. >    RTE from the exeception handler.
  24.  
  25.  For exceptions 2 & 3, there's an extra 8 bytes of info on the stack on
  26. entry to the exception handler.  The extra bytes provide info on what type
  27. of memory access was happening (instruction/data fetch, etc).  You have to
  28. clean them off the stack before you can RTE.  Another issue, one I'm not
  29. as familiar with, is that the return address on the stack may point into
  30. the middle of the instruction that failed, depending on what type of 
  31. failure occurred.  Logic for returning to the next instruction after the
  32. failure would be complex for a general solution, but I think you can cheat,
  33. since you know the exact place you're expecting the failure, and the exact
  34. instruction that you expect to fail.
  35.  
  36.  Try something like this:
  37.  
  38.   BusErrHandler:   move.b   #$FF,BusErrFlag  ; set local flag
  39.                    addq.l   #8,sp            ; clean extra info off stack
  40.                    addq.l   #nnnn,2(sp)      ; adjust return address
  41.                    rte                       ; return from exception
  42.  
  43.  You'll need to do a little trial-and-error to get the right value for
  44. #nnnn for adjusting the return address.  (Or, get better info from someone
  45. who knows this stuff better than I do.  My exception-handling experience
  46. has never included returning to the fail code in this way.)
  47.  
  48.  One other issue is processor type:  I have this vague notion that chips
  49. upwards in the 68k family may put even more than 8 bytes of extra info
  50. on the stack -- you may need a couple different exception handlers, and 
  51. install the right one for the chip type you're running on.
  52.  
  53.  
  54.  
  55. --
  56. - Ian
  57. (void *) where prohibited by law
  58.  
  59.