home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gatech!rutgers!cbmvax!jesup
- From: jesup@cbmvax.commodore.com (Randell Jesup)
- Newsgroups: comp.arch
- Subject: Re: PALcode instructions vs TRAP instructions
- Message-ID: <34303@cbmvax.commodore.com>
- Date: 16 Aug 92 21:55:59 GMT
- References: <1992Aug10.211215.25582@nntpd.lkg.dec.com> <1992Aug12.094231.1767@uklirb.informatik.uni-kl.de> <1992Aug12.092211.58077@cc.usu.edu>
- Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
- Organization: Commodore, West Chester, PA
- Lines: 25
-
- ivie@cc.usu.edu (CP/M lives!) writes:
- >In article <1992Aug12.094231.1767@uklirb.informatik.uni-kl.de>, kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
- >>
- >> Access, and change of it, by system software might be possible by catching
- >> requests of page table changes and preventing write access to those pages.
- >> But doesn't this slow down the system? Every access to the page tables,
- >> which happens quite frequently, has to checked.
- >>
- >Not really. The OS will believe the console code about how much memory is
- >available. The console reports the memory size as smaller than physical by
- >the amount of memory needed for the PALcode and the console. The OS will not
- >try to use the memory thus reserved for PALcode.
-
- This would seem to be dangerous, because of wild pointers. Just
- because the OS doesn't know about the memory doesn't mean that there won't
- be a write to those locations. I do hope that PALcode fetches are checked
- for illegal accesses.
-
- --
- "Rev on the redline, you're on your own; seems like a lifetime, but soon it's
- gone..." Foreigner
- -
- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
- {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup
- Disclaimer: Nothing I say is anything other than my personal opinion.
-