| PLEX86 | ||
virtual memory 4493virtual memory 4494 in this previous incarnation of the thread-subject from 7aug2004 there was the issue of paging virtual memory being a flavor of cache managed by LRU-type replacement algorithms. besides the similarity between global...
Right. All you had to was zero the word, or half word, or bit, that pointed at the index of the page table. But, now you have the decision of when does the data within that page get zeroed when it is placed into the next address space usage list. I don't think it matters as long as they're all done on the same side of usage.
They didn't keep a count of how many were sharing the code? This means that user data pages had the same priority as code? One would buttume that all user data pages would have be written out. Was there a difference between exec pages and user pages? Then a subset of those categories would have to be code and data, with the rare exception where code is data (writable code segment which god never meant happen). I suppose there would also have to be special handling of data pages that were suddenly changed to code. Comments on the discussion: 1. An OS did not need VM to do relocation. Example: KA10. 2. Do not confuse paging hardware with virtual memory. They are different. The reason this confusion happens is because both were usually done during the same major version OS release. If your new CPU has paging hardware, you might as well schedule your VM project at the same time. You might as well subject the customer to both pains all at the same time. It was like pulling a tooth: yank it and get it over with or tweak it and have years of long drawn annoying pain in the nethers. virtual memory 4495 Brian Inglis Lynn's exposition is not always easy (at least for me) to follow completely, but his expansion on this topic in other posts (see, for reference... BAH
|
||||
Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||