hyttemor wrote:Which math are you talking about? Can you elaborate?So how does the math look like? You have a 32-bit virtual address pointing to something that is larger than can be expressed with 32 bits
Personal computing discussed
Moderators: renee, mac_h8r1, Nemesis
hyttemor wrote:Which math are you talking about? Can you elaborate?So how does the math look like? You have a 32-bit virtual address pointing to something that is larger than can be expressed with 32 bits
hyttemor wrote:On a 32-bit OS, no you can't (Data Center versions of Windows server OS excepted). The motherboard and chipset can address more than 32-bit in hardware.No matter what you do, an application always uses 32-bit virtual pointers, correct? But if the physical address space is much larger than 4GB, how can such a pointer, with only 32 bits in it, point to something that is larger...
Flying Fox wrote:On a 32-bit OS, no you can't (Data Center versions of Windows server OS excepted). The motherboard and chipset can address more than 32-bit in hardware.
hyttemor wrote:I'll try to keep this simple; if you want more details, I'll dig up some links.No matter what you do, an application always uses 32-bit virtual pointers, correct? But if the physical address space is much larger than 4GB, how can such a pointer, with only 32 bits in it, point to something that is larger...
SilverOmega wrote:Let me guess -- you have two 768MB GeForce 8800 in SLI?Sorry to interrupt but I have a quick question. I understand I won't see all 4 gigs on vista 32-bit and am not worried about it right now, but vista only sees 2.3 gigs instead of the normal 3-3.5 gigs. Any help? BIOS reads all 4 gigs if that helps.
Captain Ned wrote:So, if I read it correctly, PAE is about the same with respect to WinXP as EMM was to DOS 5.0, within the limitations of the respective OSs.
Krogoth wrote:Well, no. EMM then is more like AWE now, in the sense that it's totally up to the app to handle it (often badly). PAE is completely transparent to the application; the entire burden is on the OS. But a fundamental assumption about virtual memory systems is that the virtual address space is bigger (a lot bigger) than the physical address space. When that's not true, all sorts of inefficiencies and ugliness begin to show up. The user, and the application, is largely oblivious to this but it makes OS designers crazy -- if you look back through this thread, you'll find links to Linus Torvalds' rather, uh, intense opinions on the subject.Captain Ned wrote:Yep, and the whole 4GB problem mirrors the nastiness of EMS back in 1980s where 640KB didn't cut it.So, if I read it correctly, PAE is about the same with respect to WinXP as EMM was to DOS 5.0, within the limitations of the respective OSs.
todd wrote:I have the same problem as noob. Can't find the memory remap.
Gigabyte GA-M69G-S3H, which according to gigabyte supports 16 GB of ram. 4 one GB sticks in there but only shows 3.25. Not that big a deal right now, but I'd like to know my board has the bios settings to overcome this if it ever becomes a problem.
bhtooefr wrote:I thought they patched that already, and that was only on Vista?
AGP/PCIe aperture definitely does affect the memory addresses you're giving up, though, IIRC.
Flying Fox wrote:Yeah, I grabbed the manual off Gigabyte's site and I don't see anything in there. Assuming the support is in the hardware (I don't know) you may need them to do a BIOS update. If the support isn't in the hardware, you're screwed.I take it you meant the GA-MA69G-S3H board?
Try hitting Ctrl-F1 to get the Advanced Settings to see if the option is there. I don't even see CnQ there that's a little odd.
todd wrote:It can still support 16GBm but you'll only have access to ~15GB of that. (With hoisting, physical RAM lives 0-3GB and then 4-17GB, avoiding the PCI addresses between 3 and 4; without hoisting, RAM just runs 0-16GB and the chunk between 3 and 4 is "lost" to PCI). Of course, just because a board uses a chipset claiming to support 16GB doesn't mean that particular board's implementation will support 16GB.I was wondering if the hoisting might be built in? Otherwise, how can the board support 16GB of ram? I'm guessing that is incorrect thinking?
todd wrote:Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.
morphine wrote:Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.todd wrote:Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.
Uh dude... you're not going anywhere until you install a 64-bit OS, sorry. The 32-bit limit itself is up to 4GB, and that has to go for your RAM *and* the devices. That's why you only get 3.odd GB of RAM, that's 4GB less chunk and change for the graphics card and other devices.
UberGerbil wrote:Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.
bhtooefr wrote:Yeah, if you read back through this very thread you'll see I made that point several times. But PAE is a bad solution to the problem except in very specific (mostly server) situations, it's significantly more expensive in the Windows world, and ultimately it's a dead end. We should stop talking about it. The future is 64bit, and we really shouldn't be confusing the issue for most users. The users who understand PAE, have a specific case where it makes sense, and (if they're Windows users) have the budget for Windows Server generally already know what they're getting into and aren't asking for advice here.UberGerbil wrote:Actually, any 32-bit OS that supports PAE EXCEPT FOR WORKSTATION VERSIONS OF WINDOWS will work, too.Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.
Windows Server 2003, Linux, BSD, etc., etc.
UberGerbil wrote:morphine wrote:Yes, that's quite true. I was assuming he was planning on moving to 64bit, but perhaps I was assuming too much. In any case, that wouldn't affect whether remapping was available in the BIOS -- but if it was available, he'd still need a 64bit OS to benefit from it.todd wrote:Yeah, it's a GA-MA69G-S3H. XP pro 32bit. I'll try to put up a bios shot later.
Uh dude... you're not going anywhere until you install a 64-bit OS, sorry. The 32-bit limit itself is up to 4GB, and that has to go for your RAM *and* the devices. That's why you only get 3.odd GB of RAM, that's 4GB less chunk and change for the graphics card and other devices.
just brew it! wrote:l33t-g4m3r wrote:then this would be the most relevant article.
http://en.wikipedia.org/wiki/X86-64
you're talking about whether or not the hardware supports the memory.
No, he's not.
He's talking about whether the hardware supports splitting the physical RAM addresses into two blocks, to avoid the addresses which are reserved for I/O devices in the 3-4GB range. This is a different issue.
Shining Arcanine wrote:Link please?The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them.
Flying Fox wrote:See Chapter 10 of the Intel Architecture Software Developer's Manual, Volume 1: Basic Architecture (PDF)Shining Arcanine wrote:Link please?The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them.
UberGerbil wrote:Flying Fox wrote:See Chapter 10 of the Intel Architecture Software Developer's Manual, Volume 1: Basic Architecture (PDF)Shining Arcanine wrote:Link please?The memory addresses in the 3-4GB range are not reserved for I/O devices. The I/O devices have their own separate 4GB address range that is in x86 exclusively intended for them.
Don't go blaming the driver writers for this. It was the IHVs, with Intel's encouragement, who went with memory mapped IO. And with good reason. The IO address space (which dates back to the 8080) is not 4GB. It is 64KB. Sixty-four Kilobytes. For all devices. So you're back to 16bit addressing limitations. Have fun moving big textures through that. And, btw, you're using the In/Out opcodes to move bytes/words, and the Ins/Outs to move strings. No Mov or any of the other string instructions for you. And it has to go somewhere, which in practical terms means the memory is going to be in use anyway, just by the OS or the individual programs to buffer it before/after the IO. Also, the IO operation is guaranteed to be atomic, so you have a pipeline stall: no other instruction on that thread can execute until the IO operation completes.
There's a reason why every serious architecture uses memory-mapped IO
The driver writers, if they wanted to, could write drivers that just use IN and OUT. But the devices would still occupy memory -- they just wouldn't be doing anything with it. To make the devices not occupy any of the memory map, they'd also have to modify the firmware on the device to change the configuration registers so no memory was requested. And sure, Intel could extend the IO address space, update the instructions to use it, and add a bunch more IO instructions to match what is available for memory.
But why? To avoid occupying memory? There are terabytes available! We had this problem before, when we were running into 64K. And 640K. The solution is to go to 64bit, not to hack around trying to re-use some old 16bit technology to eke a little more life out of a 32bit design.
Flying Fox wrote:Perhaps the notorious Appendix H.It wouldn't be Chapter 13 by any chance?
Read that. I never knew it existed.