h a l f b a k e r y"It would work, if you can find alternatives to each of the steps involved in this process."
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? |
|
| |