On Friday 14 October 2005 18:53, Lennart Sorensen wrote: > On Fri, Oct 14, 2005 at 12:18:50PM -0400, Adam Skutt wrote: > > That means it's logically impossible to have a 48-bit pointer, at all > > period. > > Sure. You have 32bit pointers. > > > Yes, but it's obvious now you didn't understand what I said. > > > > You /cannot/ have more than 32-bits of virtual address space. Period. > > There is no way to do it. > > That is true. However you could have an OS that provided overlay style > replacements of blocks of data or code at the request of the > application. This of course requires custom applications to take > advantage of such a feature.
Not entirely true. You can (theoretically) use the high bits of segment registers to give an application 45 bit pointers[*]. This requires OS support and recompiling the application. It does not require explicit bank switching/overlay support in the application. ie. Well written protable applications should require no source level changes. As someone else said, performance is probably going to suck in the general case but may be reasonable if an application has good data locality. This may be acceptable if your application really needs a larger virtual address space on a 32-bit x86 cpu. With the advent of cheap 64-bit cpus this is all fairly academic. Paul [*] The bottom two bits are the DPL, so can't be used. The third bit selects between GDT/LDT, so you can get 2^46 - 2^35 bytes of useable application address space. However you'd need to sacrifice at least 1 address bit to allow efficient simultaneous access to logically discontiguous memory areas. One bit allows code and data to be far apart, more bits mean you can access multiple far-away data areas without incurring the fault overhead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]