home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / dec / 4218 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  1.5 KB
  1. Path: sparky!uunet!caen!hellgate.utah.edu!cc.usu.edu!ivie
  2. From: ivie@cc.usu.edu (CP/M lives!)
  3. Newsgroups: comp.sys.dec
  4. Subject: Re: VAX question
  5. Message-ID: <1992Jul27.104443.57514@cc.usu.edu>
  6. Date: 27 Jul 92 10:44:42 MDT
  7. References: <1992Jul26.015003.1@matrix.cs.wright.edu> <1992Jul27.134542.4845@ryn.mro4.dec.com>
  8. Organization: Utah State University
  9. Lines: 22
  10.  
  11. In article <1992Jul27.134542.4845@ryn.mro4.dec.com>, bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
  12. > The P0 space begins at virtual address 0 and grows in the direction of larger
  13. > addresses. P1 starts at virtual address 2**31-1 and grows in the direction of
  14. > smaller addresses. Since the P1 region grows towards smaller addresses, the
  15. > base and length registers describe the part of P1 space that is not accessible.
  16.  
  17. I think that the reason for this is so that you can put the user stack
  18. way the heck up there in the address space without having to have a page
  19. table large enough to map the entire virtual space for each process. If you
  20. put the stack at the top of P0 space, for instance, the page table for the
  21. process would have to have enough entries to map all of P0 space. Since most
  22. of P0 space is unused, it doesn't make sense to require the page table to
  23. include all of it.
  24.  
  25. Separating the stack into P1 space and making P1 space grow down lets the
  26. machine keep the stack in a separate page table.
  27.  
  28. RISC processors sidestep the issue by pushing page table lookup into
  29. softwareland.
  30.  
  31. Roger Ivie
  32. ivie@cc.usu.edu
  33.