home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8938 < prev    next >
Encoding:
Text File  |  1992-08-17  |  1.3 KB  |  31 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol
  3. From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
  4. Subject: Re: PALcode instructions vs TRAP instructions
  5. Message-ID: <1992Aug18.004501.1@cc.curtin.edu.au>
  6. Lines: 19
  7. Sender: news@cujo.curtin.edu.au (News Manager)
  8. Organization: Curtin University of Technology
  9. References: <1992Aug10.211215.25582@nntpd.lkg.dec.com> <1992Aug12.094231.1767@uklirb.informatik.uni-kl.de> <1992Aug12.092211.58077@cc.usu.edu> <34303@cbmvax.commodore.com>
  10. Date: Mon, 17 Aug 1992 15:45:01 GMT
  11.  
  12. In article <34303@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
  13. > 
  14. >     This would seem to be dangerous, because of wild pointers.  Just
  15. > because the OS doesn't know about the memory doesn't mean that there won't
  16. > be a write to those locations.  I do hope that PALcode fetches are checked
  17. > for illegal accesses.
  18. > 
  19.  
  20. If you are worried about wild pointers at this level, it's 'fat owl' time
  21. any way.
  22.  
  23. What would set up the checks for the PAL code? Note that on a EV-4 the initial
  24. PALcode executes with NO acess to memory till it sets up the secondary
  25. cache control registers, BIU control ect. The only thing you can do at this
  26. level of do-do is dump as much info as possible in a safe place, and quit
  27. before you make things worse.
  28.  
  29. ~Paul
  30.  
  31.