h a l f b a k e r yI like this idea, only I think it should be run by the government.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Currently, 32-bit operating systems (like XP, Vista) can only use 3 gigs of memory max, because I believe they do not have the number range to access any memory past that. Everyone isn't switching over to 64-bit OSes because of possible incompatibility with all the older 32-bit software.
But would
it be possible to write a 64-bit memory manager that would simulate 32-bit addresses by subtracting 2^32 from the address? The memory manager would act as an interface between an app and the physical memory, and act as almost like a packet switcher, directing the app to the right range of addresses, while simulating a standard 32 bit memory address. Everything the program accesses would need to be contained in that extra ram, but that should be fine.
I don't know much about OS and memory usage, but I was curious if this is possible.
Bank Switching
http://www.faqs.org...pervga-programming/
in VESA SVGA programming. [kamathln, Nov 20 2008]
Wikipedia: Physical Address Extension
http://en.wikipedia...l_Address_Extension
How this kind of thing is normally done. [jutta, Nov 20 2008]
[link]
|
| |
You don't mean "subtracting", do you? |
|
| |
The original sixteen bit Intel processors sort of did that. It was awful the way it was implemented, and i really wouldn't want it back. What i really don't get, though, is why they don't access four gigabytes, which is their address space. |
|
| |
reminds me of the "Bank switching" in VESA SVGA programming. [Link] |
|
| |
I think this is fairly close to how this stuff is actually done - addresses are mapped to physical addresses using a per-segment lookup table. See link for details? |
|
| |
Oh no! Shades of expanded and extended memory drivers from the days of DOS! Himem.sys, anyone? |
|
| |