![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
64-bit operating systems are coming in and are rapidly replacing 32-bit ones as the platforms of choice. The 32-bit edition of Windows 7 is a bit of a minority choice and the 32-bit version of Windows 8 will be more so.
One of the main reasons is that if you have a 32-bit OS, you can only access rather less than 4GB of RAM. But given that a 32-bit CPU can access a full 4 gig, why is this?
Well, the biggest culprits are graphics cards. Most modern 3D cards come with a large amount of on-board video RAM - 256MB is stingy, 512MB is small, 1 to 2GB is common and there are bigger cards out there.
The problem is that some or all of this RAM on the graphics card is also visible in the CPU's address space: the graphics card's onboard RAM is mapped into the CPU's memory space. (Not always all of it - sometimes just a large chunk, such as 256MB of it.)
This means that you lose access to that part of your machine's RAM (assuming that your PC has 4GB fitted.)
This doesn't just apply to low-end CPU-integrated or chipset-integrated graphics; they have a different, related problem but the upshot is the same.
With integrated graphics, there is no separate video memory - the graphics chip just uses a bit of the main system RAM for what is called the framebuffer. This works fine but it's slower because of contention - basically, only 1 chip/chipset can access the RAM at once, either the CPU or the GPU, so they have to take turns. Result, the RAM effectively runs at half the speed.
So dedicated graphics memory is preferable.
I am carefully using the somewhat vague term "graphics memory" and not "video RAM". Video RAM - VRAM for short - is a different kind of memory chip, which has 2 ports per byte, so that, say, the CPU can write values into it at the same time as the GPU reads them out in order to display the contents. This costs more but it runs much quicker as there's no contention.
Dedicated graphics cards have their own, entirely-separate onboard RAM - but the CPU has to communicate with the device somehow, so the graphics card's VRAM is mapped into the CPU's memory space. A 32-bit CPU can only access a flat linear address space of 4GB, therefore, some of that space must be taken up by the video card's memory in order for the OS to be able to write stuff into it and display it.
(All right, in theory, you could use one byte of RAM and just write all the stuff consecutively to it really fast but in actual practice that would be horribly slow and inefficient. It's not so many years ago that 4GB was an inconceivably vast amount of memory, so why not just nick a few hundred meg of space up at the top of the memory map, where you'll never get any real RAM because it would cost tens of thousands of quid, and map the graphic's card's VRAM in there? Simple, efficient, quick.)
So, basically, yes, your fancy graphics card's RAM is mapped into the CPU's address space, right up in the top GB between 3GB and 4GB, which was fine until PCs had so much RAM that they had actual RAM there.
Other devices are mapped in there as well. In fact pretty much all your hardware is mapped in there somewhere, but most of it only needs a few bytes or at most a few KB here or there, so the space is insignificant - but this is why you can't use all your 4GB of RAM in a PC with a 32-bit OS. Some of the space is reserved for I/O devices and their ROMs and so on, and these days, the bulk of that will be the graphics card's VRAM.
There's another caveat.
If you are old enough to remember MS-DOS and the 640KB memory limit, this is exactly the same problem as the 640KB limit writ large.
The original PCs's hybrid 8/16-bit CPU could only access 1MB of RAM. Some of that area of the memory map had to be reserved for I/O and ROM. IBM put it at the top, between 640KB and 1MB. That meant that a few years later, when you could actually afford 1MB of RAM, you couldn't use it all in DOS - the top 384KB of the address space was already in use for I/O and ROM and couldn't be used. Result: 640KB of available space and the "DOS Conventional memory" limit.
Once the 386 came in, which can rearrange RAM in hardware ("memory mapping", a form of virtual memory), you could fill in the unused gaps in that 384KB with bits of actual RAM. It wouldn't be contiguous with main RAM, but in DOS with its various little resident programs to give you a CD drive or a mouse or a sound card or a UK keyboard, you could use all those new 8 or 16 or 32KB fragments of RAM in the top 384KB - "upper memory blocks" they were called - to stash your "terminate and stay resident" (TSR) programs in. This was a bit of a black art, but one of which I was a past master, if I say so myself. I could find every tiny unused block, map it and fill it with some tiny fragment of DOS and keep all 640KB of conventional memory free for apps.
A mate and one-time colleague of mine, Carlton, was fascinated by this and got me to teach him. He came into my office a few weeks later with a printout of his home PC's memory map, to show me how he'd optimised it to hell. He was really proud.
About three months later, some salesdroid in a Mondeo hit Carlton on his bike on the M5 and killed him.
Anyway.
If you bought Quarterdeck's QEMM386 memory manager, it could do this automatically. I could usually beat it. MS-DOS 6 included a somewhat half-hearted tool called MEMMAKER to do this that wasn't very good, but by hand, a skilled techie [*ahem*] could do with EMM386 what Quarterdeck's QEMM and OPTIMISE could do.
32-bit CPUs have 4GB of space and again the top part was reserved for ROM and I/O space, and sure enough, a few years later, this became a problem as people got so much RAM that they needed all of their address space.
But to be fair, it had to go somewhere. The thing is that in the DOS days, some computer manufacturers, such as Sirius and Apricot, put the I/O area somewhere else - e.g. at the start of the 1MB of address space. So those of them still making computers when 1MB of RAM became doable could offer more - 800 or 900KB of RAM - because they didn't reserve the whole top 384KB of address space. These machines ran MS-DOS but weren't PC compatible -- in part because of their weird memory maps -- and they all died out before the advent of the 386.
The bit of this that is actually relevant is this:
Back in the DOS days, there was a kludgey way to access more than 640KB of RAM from DOS, called Expanded memory. You could have megabytes of the stuff, accessed by paging little bits of it in and out of a 64KB window in the upper memory area, called the "page frame". The spec was set by Lotus, Intel and Microsoft and it was sometimes called LIM-spec expanded memory. Just what you wanted for ginormous Lotus 1-2-3 spreadsheets of up to several megabytes! (Seriously, that was its main reason for existence.)
(Expanded RAM is not to be confused with Extended memory, which was just anything above the 1MB mark in a 286 or 386. That's what Windows 3 and later wanted but it was no use to DOS.)
In 8088/8088/80286 PCs, you needed physical hardware to have Expanded RAM.
But the 386 could do it in software - that was the original primary purpose of QEMM
The LIM spec version 4 allowed an arbitrarily large page frame, anywhere in RAM. This meant that a DOS multitasker (such as Quarterdeck's DESQview) could swap DOS programs in and out of conventional memory on demand, allowing you to multitask multiple DOS apps at once.
Anyway, the point of all the history is that later-model Pentium Pro and subsequent chips also support something very like LIM 4 expanded memory. If you have more than 4GB of RAM, these CPUs let you page parts of the memory above 4GB - invisible to 32-bit OSs - into the "base" 4GB of RAM. This means that even if you have 8GB of RAM, you can't run a 7GB application, but you can run three 2GB applications side-by-side.
It's just like LIM4 Expanded RAM paging memory above 1MB into the base 640KB; this time, it's paging memory above 4GB into the base sub-4GB area.
It's called PAE - Physical Address Extension.
The snag is, Microsoft won't let you use it. The feature is only enabled in server versions of Windows - you can't use it with XP, or with 32-bit Vista or Win7 workstation, "pro", "ultimate" editions and so on.
Not a problem with Linux - 32-bit Linux can access loads of RAM, way more than 4GB. The limit is imposed on 32-bit Windows by Microsoft licencing, not by a technical restriction. Blame them for the fact that you can't access more than 3-and-a-bit gig. You could if only they would let you.
One of the main reasons is that if you have a 32-bit OS, you can only access rather less than 4GB of RAM. But given that a 32-bit CPU can access a full 4 gig, why is this?
Well, the biggest culprits are graphics cards. Most modern 3D cards come with a large amount of on-board video RAM - 256MB is stingy, 512MB is small, 1 to 2GB is common and there are bigger cards out there.
The problem is that some or all of this RAM on the graphics card is also visible in the CPU's address space: the graphics card's onboard RAM is mapped into the CPU's memory space. (Not always all of it - sometimes just a large chunk, such as 256MB of it.)
This means that you lose access to that part of your machine's RAM (assuming that your PC has 4GB fitted.)
This doesn't just apply to low-end CPU-integrated or chipset-integrated graphics; they have a different, related problem but the upshot is the same.
With integrated graphics, there is no separate video memory - the graphics chip just uses a bit of the main system RAM for what is called the framebuffer. This works fine but it's slower because of contention - basically, only 1 chip/chipset can access the RAM at once, either the CPU or the GPU, so they have to take turns. Result, the RAM effectively runs at half the speed.
So dedicated graphics memory is preferable.
I am carefully using the somewhat vague term "graphics memory" and not "video RAM". Video RAM - VRAM for short - is a different kind of memory chip, which has 2 ports per byte, so that, say, the CPU can write values into it at the same time as the GPU reads them out in order to display the contents. This costs more but it runs much quicker as there's no contention.
Dedicated graphics cards have their own, entirely-separate onboard RAM - but the CPU has to communicate with the device somehow, so the graphics card's VRAM is mapped into the CPU's memory space. A 32-bit CPU can only access a flat linear address space of 4GB, therefore, some of that space must be taken up by the video card's memory in order for the OS to be able to write stuff into it and display it.
(All right, in theory, you could use one byte of RAM and just write all the stuff consecutively to it really fast but in actual practice that would be horribly slow and inefficient. It's not so many years ago that 4GB was an inconceivably vast amount of memory, so why not just nick a few hundred meg of space up at the top of the memory map, where you'll never get any real RAM because it would cost tens of thousands of quid, and map the graphic's card's VRAM in there? Simple, efficient, quick.)
So, basically, yes, your fancy graphics card's RAM is mapped into the CPU's address space, right up in the top GB between 3GB and 4GB, which was fine until PCs had so much RAM that they had actual RAM there.
Other devices are mapped in there as well. In fact pretty much all your hardware is mapped in there somewhere, but most of it only needs a few bytes or at most a few KB here or there, so the space is insignificant - but this is why you can't use all your 4GB of RAM in a PC with a 32-bit OS. Some of the space is reserved for I/O devices and their ROMs and so on, and these days, the bulk of that will be the graphics card's VRAM.
There's another caveat.
If you are old enough to remember MS-DOS and the 640KB memory limit, this is exactly the same problem as the 640KB limit writ large.
The original PCs's hybrid 8/16-bit CPU could only access 1MB of RAM. Some of that area of the memory map had to be reserved for I/O and ROM. IBM put it at the top, between 640KB and 1MB. That meant that a few years later, when you could actually afford 1MB of RAM, you couldn't use it all in DOS - the top 384KB of the address space was already in use for I/O and ROM and couldn't be used. Result: 640KB of available space and the "DOS Conventional memory" limit.
Once the 386 came in, which can rearrange RAM in hardware ("memory mapping", a form of virtual memory), you could fill in the unused gaps in that 384KB with bits of actual RAM. It wouldn't be contiguous with main RAM, but in DOS with its various little resident programs to give you a CD drive or a mouse or a sound card or a UK keyboard, you could use all those new 8 or 16 or 32KB fragments of RAM in the top 384KB - "upper memory blocks" they were called - to stash your "terminate and stay resident" (TSR) programs in. This was a bit of a black art, but one of which I was a past master, if I say so myself. I could find every tiny unused block, map it and fill it with some tiny fragment of DOS and keep all 640KB of conventional memory free for apps.
A mate and one-time colleague of mine, Carlton, was fascinated by this and got me to teach him. He came into my office a few weeks later with a printout of his home PC's memory map, to show me how he'd optimised it to hell. He was really proud.
About three months later, some salesdroid in a Mondeo hit Carlton on his bike on the M5 and killed him.
Anyway.
If you bought Quarterdeck's QEMM386 memory manager, it could do this automatically. I could usually beat it. MS-DOS 6 included a somewhat half-hearted tool called MEMMAKER to do this that wasn't very good, but by hand, a skilled techie [*ahem*] could do with EMM386 what Quarterdeck's QEMM and OPTIMISE could do.
32-bit CPUs have 4GB of space and again the top part was reserved for ROM and I/O space, and sure enough, a few years later, this became a problem as people got so much RAM that they needed all of their address space.
But to be fair, it had to go somewhere. The thing is that in the DOS days, some computer manufacturers, such as Sirius and Apricot, put the I/O area somewhere else - e.g. at the start of the 1MB of address space. So those of them still making computers when 1MB of RAM became doable could offer more - 800 or 900KB of RAM - because they didn't reserve the whole top 384KB of address space. These machines ran MS-DOS but weren't PC compatible -- in part because of their weird memory maps -- and they all died out before the advent of the 386.
The bit of this that is actually relevant is this:
Back in the DOS days, there was a kludgey way to access more than 640KB of RAM from DOS, called Expanded memory. You could have megabytes of the stuff, accessed by paging little bits of it in and out of a 64KB window in the upper memory area, called the "page frame". The spec was set by Lotus, Intel and Microsoft and it was sometimes called LIM-spec expanded memory. Just what you wanted for ginormous Lotus 1-2-3 spreadsheets of up to several megabytes! (Seriously, that was its main reason for existence.)
(Expanded RAM is not to be confused with Extended memory, which was just anything above the 1MB mark in a 286 or 386. That's what Windows 3 and later wanted but it was no use to DOS.)
In 8088/8088/80286 PCs, you needed physical hardware to have Expanded RAM.
But the 386 could do it in software - that was the original primary purpose of QEMM
The LIM spec version 4 allowed an arbitrarily large page frame, anywhere in RAM. This meant that a DOS multitasker (such as Quarterdeck's DESQview) could swap DOS programs in and out of conventional memory on demand, allowing you to multitask multiple DOS apps at once.
Anyway, the point of all the history is that later-model Pentium Pro and subsequent chips also support something very like LIM 4 expanded memory. If you have more than 4GB of RAM, these CPUs let you page parts of the memory above 4GB - invisible to 32-bit OSs - into the "base" 4GB of RAM. This means that even if you have 8GB of RAM, you can't run a 7GB application, but you can run three 2GB applications side-by-side.
It's just like LIM4 Expanded RAM paging memory above 1MB into the base 640KB; this time, it's paging memory above 4GB into the base sub-4GB area.
It's called PAE - Physical Address Extension.
The snag is, Microsoft won't let you use it. The feature is only enabled in server versions of Windows - you can't use it with XP, or with 32-bit Vista or Win7 workstation, "pro", "ultimate" editions and so on.
Not a problem with Linux - 32-bit Linux can access loads of RAM, way more than 4GB. The limit is imposed on 32-bit Windows by Microsoft licencing, not by a technical restriction. Blame them for the fact that you can't access more than 3-and-a-bit gig. You could if only they would let you.
