In message <
[email protected]> "Rick Raisley"
I don't disagree with your facts provided (although I may not understand
them all), but I /do/ disagree with the analogy. The 640 MB limit was
imposed by the OS. It couldn't read more than that. But the system could use
upper memory for other purposes, and did so.
The 640KB (not MB) limit was hardware and software imposed -- A portion
of the memory at 640KB or so was reserved by hardware (and still is to
this day, actually)
Since the space above that was not consistently available on all system
configurations, it was left unused by DOS until himem.sys came around.
I know and see that. I have a 768 MB memory video card (8800 GTX), and it
takes up an additional 768 out of my 4 GB of RAM. I guess I still don't see
why it does, though. The board itself has 768. And that's all it needs. Yet
the OS adds another 768 to it, resulting in a total video memory of over
1500 MB. Why is that? I kind of get the idea that the 768 out of RAM is to
communicate with the 768 on the video card, but thought that's what graphics
processors were for.
I'll try an analogy -- Analogies suck, but it might help.
First off, this is *not* an accurate representation of how memory is
allocated or addressed in x86 machines. However, for the purposes of
understanding this particular issue, I think it will make sense.
Imagine you're sitting at a desk with one or more boxes in front of you.
You can only fit 10 boxes on the desk though, and each box can only hold
one item at a time.
Now imagine your friend comes along and brings his own four boxes. He
has shorter arms, so he can only reach his four boxes and can't touch
your boxes.
If you want to share items, there are two possibilities.
1) Your friend can ask you for the contents of a box and you can pass it
over when requested, one at a time. This is slow, because it means
neither of you can do anything else while you're helping each other out,
but it's pretty simple to implement and it works fine for slow devices
on a PC.
2) He puts his boxes on your table, and you can reach into each other's
boxes.
If you only have six boxes (or less), he can fit his four on the table
too, and you can reach all ten (six of yours, four of his), so when you
want to give something to him, you can just dump it in his box, rather
then handing it over and he puts it in his own box.
The downside is that he is taking up some room on the table, so you only
get six boxes whether or not you're giving items to your friend.
64bit gives you a bigger table and longer arms -- Technically the same
problem exists, but with up to 18.45 exabytes addressable, we won't run
into the problem for quite a while.
These are all 64-bit PCs (modern machines like my E6700), but how can it
take advantage of more than 4 MB if the OS is still 32-bit?
Lets take the above example, and stretch it a bit further. There is a
trick which can be used to access a bit more then 4GB of memory.
With a 64-bit computer, your table is bigger, but with 32-bit OS, your
arms can still only reach ten boxes at once. So what you do is hire a
helper, this helper moves the boxes around, so even though you can only
reach ten boxes at once, you can sometimes reach different boxes.
This solution adds a huge amount of complexity into the system, and
requires a non-trivial amount of overhead, basically it means you need a
list of what other boxes are available and what is in each, plus when
you trade boxes, it takes your friend a moment to switch them around.
Hopefully that explains the concept a little bit, I'm sure there are
holes in this analogy I haven't even thought of, and it is definitely
not in any way representative of how memory is managed or used on a x86
computer, but the concept of relating arm length to address space might
be valid enough to make sense.
