4 Feb
2010
4 Feb
'10
1:02 a.m.
On Jan 3, 2010, at 4:36 PM, "Jerome H. Fine" <jhfinedp3k at compsys.to>
wrote:
I can't answer all the questions here, but I'll give it a go (pardon
the terseness, I'm on my phone...)
32-bit processes under 64-bit Windows (7 or otherwise) can directly
address at most 4gb of memory (the same is true of 64-bit Linux on
x86). There are ways for 32-bit processes (via "address windowing
extensions") to access more memory outside the 4gb range but as was
mentioned earlier it's a lot like EMS under DOS.
PAE is for 32-bit OSes only; it's a bit of a hardware hack to allow
the OS to manage memory beyond 4gb. Individual processes are still
limited to a 4gb address space (barring the AWE mentioned above).
And again, whether your 32-bit (or even 64-bit machine in some cases)
can actually see memory above 4gb depends a lot on the hardware/
chipsets involved. Which is quite lame. I personally would recommend
a 64-bit OS for anything over 3.5gb of RAM.
Also: the 2gb per-process limit on XP can be raised to 3gb by using
the /3GB boot option in your boot.ini.
Hope that clears some things up...
Josh
Patrick
Finnegan wrote:
On Monday 01 February 2010, Dave McGuire wrote:
I am confused over how the hardware responds to a physical
address for hardware as opposed to actual memory at the same
physical address? The mother board being used (ASUS P5B)
actually allows 8 GB of memory in total, so PAE hardware must
be present to allow 64 bit Windows to reference the extra 4 GB
of memory.
My less than complete understanding of how an MMU operates
is limited to the PDP-11 where the top 8 KB of memory is lost
to the IOPAGE registers. As far as I can understand, all PAR7
address references are redirected to the IOPAGE registers which
results in the top 8 KB of memory not being able to be used. This
redirection takes place BOTH with and WITHOUT an MM being
present. When there is 4 MB of memory available to the system,
the loss of 8 KB was not considered a major problem and we all
considered ourselves fortunate if we actually had 4 MB of physical
memory in the backplane.
I get the impression that a PC does something very different with
physical memory addresses (out of a 2 * 2 GB sticks for example)
vs something like the video controller which has its own memory.
However, I still get the impression that a 32 bit Windows XP could
set up the necessary pointers to allow the operating system to use
the unused 1 GB of physical memory for some rather useful functions
such as cache for the hard disk drives. Is my impression correct?
And what about Windows 7 running a 64 bit? I realize that this seems
to be a discussion about Windows, but the only goal is to be able to
run a 32 bit application, specifically Ersatz-11, with reasonable,
or at least as close to reasonable as possible, efficiency. If a 64
bit
Windows can still run a 32 bit application, are there any penalties
imposed as a result. I realize that the maximum memory that could
be assigned to a single 32 bit process will almost certainly be 4 GB,
but that is substantially more than the maximum of 2 GB under a 32 bit
version of Windows XP which is running at the moment. On Feb 1, 2010, at 2:57 AM, Alexander Schreiber
wrote:
Not all PC chipsets support the address lines to do this. My
friend's Core2 Duo box (yes, a 64-bit machine) doesn't support more
than 3.25GB of RAM because of this.
> As for total memory available to use for
temporary
> work space, when I run Ersatz-11 under WXP on a
> system with 4 GB of physical memory (I agree that
> WXP wastes almost 1 GB of that memory),
>
Not the fault of Windows. For a 32 bit PC system with 4 GB of
RAM, up to 1 GB of RAM is 'lost' because up to 1 GB of
the address space is used for the PCI address space (i.e.
memory mapped access to peripherals[0]). It can be quite bit
less (such as 500 MB), or up to the full 1 GB - that depends
on the specific hardware.
The MMU can easily get around this. And indeed, I don't have this
problem with any other OS. Does Windows not understand PAE
hardware?
Please pardon my almost total lack of understanding of the Windows
environment, however I shudder at having to learn all of that stuff
just to be able to run Ersatz-11.
Sincerely yours,
Jerome Fine