New
#11
Now i m confused whether H2SO4 is right or the OP.
I think H2SO4 and the OP are saying similar things. OP says its possible in hardware and it is but its microsofts fault. Sulphuric is saying its possible but here is why it wasnt done and shouldn't be done.
Im sure if I have mis represented either they will let me know. Im no expert
Ken
Hi there
This issue is slightly more complicated than would seem at first sight.
From a purely Mathematical standpoint 4GB is the maximum address that a 32 bit system can address -- 2 **32.
However some OS'es can "poodle fake" the addressing scheme to allow a higher range than this -- it also needs some extra hardware BTW.
What Server 2003 R2 (32 bit system) does for example (it can address up to 64GB RAM) is to arrange the addressing scheme as follows.
Instead of using a 32 bit address it takes the First 4 bits and uses these like a telephone area code for example 213 / 450 etc etc.
This means that the other 28 bits can be used as an address but you can have up to 16 banks of these.
So your address ranges could be something like this
1FFF FFFF
2FFF FFFF etc.
Note the OS must have methods of saving and "switching" the prefix byte to correctly address the the correct range of memory -- and it needs to be FAST otherwise the OS suffers.
I believe the hardware feature is called something like PAE and it must be enabled in the CPU for this to work -- I'm not sure of the exact name but that's conceptually how it works.
This feature isn't really of any use in 32 bit desktop os'es but was implemented for servers --when you have large Databases / servers with lots of concurrent users you DO need a load more RAM -- and at that time 64 bit CPU's weren't generally available so the method outlined above was a bit of a workaround.
Cheers
jimbo
What logicearth said. That's the crux of the matter.
My disagreement is primarily with the author of the referenced article. His conclusions are painted in such a way as to encourage people to feel ripped off, even though I suspect he probably has sufficient technical knowledge to understand that he's being deliberately biased. Longer version:zigzag3143 said:
No pure 32-bit system can EVER go beyond 4GB (using the flat memory model). There are insufficient bits to describe any bigger numbers.
In the mid-90s, Intel recognised a looming problem and released processors capable of 36-bit addressing. When plugged into a corresponding motherboard, such processors could theoretically address up to 2^36 or 64GB of memory. It required the OS and drivers to support a mechanism known as PAE remapping so that regions of memory above 4GB became visible and usable.
This is not a trivial thing to support from a driver's point of view. Many of the numerous consumer-grade drivers (NICs, audio, video, AV, whatever...) were fine in a pure 32-bit environment, but they exhibited severe problems when attempting to deal with the complexities of PAE remapping. These issues manifested themselves as BSODs or silent data corruption.
Eventually, MS came to the conclusion that the 99% of home/small business Windows users who had 4GB of RAM or less were paying a BSOD penalty for the other 1% to be able to enjoy their >4GB machines. Their response was to deactivate PAE remapping functionality in "client" versions of Windows (XP, Vista, Win7).
"Server" flavours are different because the drivers are generally written to a much higher standard, plus the onus is on the (expert) system administrator to be judicious in their driver selection. Hence, 32(36)-bit "Server" Windows builds can still utilise PAE remapping to go beyond 4GB and all the way up to 64GB for the "Enterprise" and "Datacenter" versions.
Before you guys write more about x86 architecture, PAE and driver development in Windows, why don't you try and research it first? Not much of what has been said here is true.
The driver issue: as long as you write your driver according to the rules (and proper API), you don't need to care about what mode you might or might not run in, and how much ram there is installed. Some driver developers just think they are smarter than Windows and know every possible hardware configuration out there (which they don't and therefore might crash).
You said something about integer and register size. That is not relevant. PAE is about physical addressing only, not virtual.
I think it's a tautology to say that perfect software behaves perfectly.
Surely you didn't join this fine forum just now only to point out that the 'P' in PAE stands for "physical"? If you believe there are technical inaccuracies in the information provided, please consider expanding on your points and providing details so that everyone can learn.
Yeah good call because I think most of us are in agreement in this thread so far.
Most of what has been said is in agreement with posts before it and simply adds more facts to the discussion. And what has been said so far is in fact truth not just blabber from people that have not done homework on this.
Where did the original topic come from? Research into the subject how else would this all have been brought about.
Anyways so far those who have contributed to the discussion have all pretty much been stating the same thing except with added bits and pieces that help fill this all in nicely.
I think there is a lot to be learned reading this thread so far.
As for the author of the article? Well I won't say I completely agree with the view he has because he makes microsoft out to be a bad guy when really they never sat there and conjured up some way to limit ram so that we would have to pay more money to get more performance. I think that over the years developing the OS things just kind of fell in place to be what they are today.
But this thread is only intended as a learning experience because there is so much misleading information floating around the net related to PAE (Physical Address Extension) and memory mapping in general. I figured perhaps we could all gain a bit of knowledge from this. I think we have accomplished just that.