Re: perspectives on 32 bit vs 64 bit
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.
Reply to: