de Kameel wrote:
> Ian Pawson wrote:
>
>> Mike Smith wrote:
>>> On Fri, 11 Jul 2008 16:31:49 +0100, Ian Pawson wrote:
>>>
>>>> Install the PAE kernel and it should all be available.
>>> Can you do that on workstation or only in the server version?
>> Yes, works on the 'desktop' version. Not greater than 4GB though.
>
> Please explaing that? The whole idea of PAE is ... using more than 4GB
> memory. Quote from http://en.wikipedia.org/wiki/Physical_Address_Extension
>
> "In computing, Physical Address Extension (PAE) refers to a feature of x86
> and x86-64 processors that allows more than 4 gigabytes (GB) of physical
> memory to be used in 32-bit systems, given appropriate operating system
> support."
>
> de Kameel
>
Sorry, I missed out a word. I meant to say that 'I had not tried it with
more than 4gb' which is all my mobo will take. Sorry for any confusion

General Schvantzkopf wrote:
>
>> Now the other end of the nuance is how much physical memory a 32-bit
>> system can see? If you have 4GB of RAM installed on a 32-bit system,
>> then your system will only see upto 3.25GB of that 4GB. The remaining
>> RAM is ignored because it is used for peripheral hardware such as video
>> cards, ROM, and other stuff. I think this is a problem on 32-bit
>> systems, in that they will always lop that extra 0.75GB of memory from
>> system usage, even if you have 8 or 16GB of RAM installed (so you'll
>> only see 7.25GB or 15.25GB). This won't be a problem on 64-bit systems,
>> they can typically remap all of the system RAM to higher locations.
>>
>> Yousuf Khan
>
> 32 bit PAE kernels don't lop off anything, if you have 4G of RAM all of
> it will be available to the system although only 3G will be available to
> any individual thread. If the kernel is compiled with regular 32 bit
> addressing instead or PAE then it will have to map the IO space into the
> top of it's 4G address space which will limit the RAM to less than 4G.
> There can also be a BIOS issue with early AMD64 systems. In those BIOSes
> you had to explicitly enable something called Memory Hole Remapping which
> would move the IOMMU above the RAM space, if you didn't do that then even
> a 64 bit kernel couldn't see all of the RAM. I don't know if there are
> any current BIOSes that still make Memory Hole Remapping an option, I
> think they just do what needs to be done so that all of the RAM is
> accessible.
>
> 32 bit Linux distros all have PAE kernels available so there is no reason
> that any Linux user would be able to use all of the RAM in their system.
> Windows users don't have that luxury. 32 bit XP and 32 bit Vista are
> compiled without PAE so users of those OSes are limited to less than 4G
> of RAM. Obviously 64 bit XP and Vista can access all of their RAM.

And that's another one of the many horrors of using Windows. Pay extra
(for a 64 bit OS, and obviously the hardware too) or there are hidden
catches. Switch to Linux and you get all of the extra features you pay
for with Windows for absolutely free.

At 14 Jul 2008 13:34:28 GMT phil-news-nospam@ipal.net wrote:

>
> In comp.os.linux.misc Robert Heller wrote:
>
> | At 13 Jul 2008 13:55:54 GMT phil-news-nospam@ipal.net wrote:
> |
> |>
> |> In comp.os.linux.misc Ben wrote:
> |> | phil-news-nospam@ipal.net wrote:
> |> |> In comp.os.linux.misc Ben wrote:
> |> |> | curiousdave@AOL.com wrote:
> |> |> |> Is that correct that the sum total of all virtual memory allocations
> |> |> |> on a 32 bit OS cannot exceed 4 GB?
> |> |> |>
> |> |> |> For example, if I have 4 GB of RAM, can I run 20 programs that take 500
> |> |> |> MB each? (with most memory swapped out, and big swap file, of course).
> |> |> |>
> |> |> |> Also, is it true that 32 bit install cannot use more than 4 GB of
> |> |> |> physical RAM?
> |> |> |>
> |> |> |> Dave
> |> |> |
> |> |> | This problem was solved with Physical Address Extension. As long as both
> |> |> | your CPU (nearly all modern 32-bit CPUs do now) and your kernel supports
> |> |> | PAE, and the mainline Linux kernel does now, then you should be easily
> |> |> | able to run up to 64GB RAM.
> |> |>
> |> |> Beyond that, things should be shifting to 64-bit. But can we have a 32-bit
> |> |> virtual address space on a 64-bit kernel?
> |> |>
> |> |
> |> | Everything is backwards compatible with 32 bit anyways, so that's not a
> |> | problem.
> |>
> |> But that's not an answer to my question. If I bring up a 64-bit kernel, will
> |> it DIRECTLY run /sbin/init and all other processes started from there from a
> |> 32-bit root file system tree? IOW, will 32-bit ABI syscalls still work from
> |> within a 32-bit virtual address space?
> |
> | The 32-bit PAE kernels are 32-bit kernels, with kernel mode mapping
> | magic to allow a 36-bit virtual address space. *User Mode* processes won't
> | even be aware that more then 4gig of address space even exists. This is
> | NOT a true 64-bit kernel.
> |
> | If you have a true 64-bit processor and not just a i686 with PAE, but a
> | x86_64 or i64 processor, AND you want a full 64-bit system, then you
> | need to install a full 64-bit *distribution*, which will include a
> | 64-bit kernel, plus a full set of 64-bit base system utilities. Most
> | (all?) such distros also include the 32-bit shared libraries, which
> | means that 32-bit x86 (i32) programs will also be runable -- the kernel
> | / program loader will set them up with a 32-bit address space and the
> | resulting processes behave just like they are running on a generic
> | 32-bit i686.
>
> However, these 32-bit compatibility libraries in the 64-bit distribution could
> be converting the 32-bit library-calling-ABI into the 64-bit syscall-ABI and
> interacting with the kernel on a 64-bit level.

No, they don't do that -- I don't think they can. There are no '32-bit
compatibility libraries', they are just the 32-bit libraries. When a
32-bit program in running, that process is 'locked' in 32-bit
processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
level, at least in *user mode*. The 32-bit libraries are the *same*
32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
installed 32-bit libraries from a 32-bit distro on a 64-bit system
(running a 64-bit kernel) [I had an old 32-bit program that used old
shared libraries and it was too much trouble to mess with re-building it
on the 64-bit box]. The 32-bit libraries use the 32-bit
library-calling-ABI, just like on a 32-bit i[3456]86 system. The
*kernel* runs in 64-bit mode and has access to the 64-bit address
space, in *kernel* mode.

>
> My question was NOT "can I run a 32-bit dynamically linked application
> executable run on a 64-bit Linux distribution (that has 32-bit compatibility
> libraries)?".

There is no such thing as '32-bit compatibility libraries'. The x86_64
processor can run as a ia32 (eg i686) processor and can run 32-bit
programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
processor bit (or whatever) to put it into the proper 'mode'.

>
> My question IS "can a complete 32-bit root tree, with 32-bit libraries that
> work on a 32-bit kernel, and many 32-bit statically linked executables, work
> on a 64-bit kernel?".

Very likely they will run, but why? If you are just going to run a
32-bit system, install a 32-bit kernel. If you are going to install a
64-bit kernel, you might as well install a 64-bit root tree.

>
> The question might need to be extended in the case of virtualization such as
> Xen. But until someone grasps the conceptual difference between running a
> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
THERE IS NO SUCH THING!!! GET THIS OUT
OUT OF YOUR MIND!!!!!!!!!!!

> under a 64-bit kernel, I shall try to keep the question simple in the hopes
> of actually getting an answer from someone who actually knows whether or not
> this concept matters for 32-bit kernels vs. 64-bit kernels on at least the
> x86-64 hardware architecture.

The virtualization systems (eg Xen) handle all of this. I am sure that
if you install a 64-bit virtualization system on a 64-bit system and
have it provide a batch of virtual 32-bit systems, it will work just
fine -- each of the virtual 32-bit systems will have a 32-bit kernel.

You can *probably* install and run a 32-bit version of the
virtualization system (eg Xen), but why would you do this on a 64-bit
system with a 64-bit kernel?

What *exactly* are you trying to achieve here?

>

--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

In comp.os.linux.misc Robert Heller wrote:

| No, they don't do that -- I don't think they can. There are no '32-bit
| compatibility libraries', they are just the 32-bit libraries. When a
| 32-bit program in running, that process is 'locked' in 32-bit
| processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
| level, at least in *user mode*. The 32-bit libraries are the *same*
| 32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
| installed 32-bit libraries from a 32-bit distro on a 64-bit system
| (running a 64-bit kernel) [I had an old 32-bit program that used old
| shared libraries and it was too much trouble to mess with re-building it
| on the 64-bit box]. The 32-bit libraries use the 32-bit
| library-calling-ABI, just like on a 32-bit i[3456]86 system. The
| *kernel* runs in 64-bit mode and has access to the 64-bit address
| space, in *kernel* mode.

I have seen "compatibility" libraries. Maybe that was done due to earlier
Linux work that was pure 64-bit.

For this to work, the 64-bit kernel has to understand an ABI to get the
32-bit pointers from the 32-bit process doing syscalls. Further, it has
to be sure points it gives back are not only in 32 bits of space, but are
valid in a 32-bit address space. Consider mmap(). It can choose what
address to map space into, if not asked to use a specific address. For
a 32-bit process, it has to know the limits of what it can choose during
the kernel code carrying out these steps.


| There is no such thing as '32-bit compatibility libraries'. The x86_64
| processor can run as a ia32 (eg i686) processor and can run 32-bit
| programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
| processor bit (or whatever) to put it into the proper 'mode'.

There's more to this than just processor mode. There's an ABI for the
syscalls. 32-bit libraries don't just make 64 bits of space to pass the
pointers to the kernel with. So the kernel has to be able to handle
both ABIs if it can handle true pure-32-bit processes.


|> The question might need to be extended in the case of virtualization such as
|> Xen. But until someone grasps the conceptual difference between running a
|> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
|> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| THERE IS NO SUCH THING!!! GET THIS OUT
| OUT OF YOUR MIND!!!!!!!!!!!

Sorry, but memory just doesn't erase like that. I have seen it, so I know
it does exist. Maybe it's all moot today.


| The virtualization systems (eg Xen) handle all of this. I am sure that
| if you install a 64-bit virtualization system on a 64-bit system and
| have it provide a batch of virtual 32-bit systems, it will work just
| fine -- each of the virtual 32-bit systems will have a 32-bit kernel.
|
| You can *probably* install and run a 32-bit version of the
| virtualization system (eg Xen), but why would you do this on a 64-bit
| system with a 64-bit kernel?
|
| What *exactly* are you trying to achieve here?

I'm trying to get to the full truth.

There are a lot of issues when dealing with a mix of 32-bit and 64-bit.
A 64-bit kernel that can fully handle either pure 32-bit processes or
pure 64-bit processes has to be able to deal with those issues, such as
having both 32-bit and 64-bit ABIs. Maybe it's as simple as a .config
setting to include or not include the 32-bit ABI (because maybe someone
that does not intend to run anything at 32-bit wants to save the space
and not include that).

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

At 15 Jul 2008 19:23:57 GMT phil-news-nospam@ipal.net wrote:

>
> In comp.os.linux.misc Robert Heller wrote:
>
> | No, they don't do that -- I don't think they can. There are no '32-bit
> | compatibility libraries', they are just the 32-bit libraries. When a
> | 32-bit program in running, that process is 'locked' in 32-bit
> | processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
> | level, at least in *user mode*. The 32-bit libraries are the *same*
> | 32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
> | installed 32-bit libraries from a 32-bit distro on a 64-bit system
> | (running a 64-bit kernel) [I had an old 32-bit program that used old
> | shared libraries and it was too much trouble to mess with re-building it
> | on the 64-bit box]. The 32-bit libraries use the 32-bit
> | library-calling-ABI, just like on a 32-bit i[3456]86 system. The
> | *kernel* runs in 64-bit mode and has access to the 64-bit address
> | space, in *kernel* mode.
>
> I have seen "compatibility" libraries. Maybe that was done due to earlier
> Linux work that was pure 64-bit.

The only 'compatibility' libraries I've seen are ones that provide
compatibility to older systems (eg libc5 compatibility libraries or
compatibility libraries for other older libraries). I have *never* seen
32/64 bit compatibility libraries *ever*. You are confusing something
else. Maybe MS-Windows plays this sort of games?

Note: I might have seen compatibility libraries on 32/64 bit Irix (MIPS
processor) or Solaris (32/64 bit Sparc), but never on x86 64-bit Linux.

>
> For this to work, the 64-bit kernel has to understand an ABI to get the
> 32-bit pointers from the 32-bit process doing syscalls. Further, it has
> to be sure points it gives back are not only in 32 bits of space, but are
> valid in a 32-bit address space. Consider mmap(). It can choose what
> address to map space into, if not asked to use a specific address. For
> a 32-bit process, it has to know the limits of what it can choose during
> the kernel code carrying out these steps.

The kernel ABI is the same for both 32 and 64 bit kernels. The kernel
*knows* if the calling process was 32-bit or 64-bit (there is status info in a
status register telling it this).

>
>
> | There is no such thing as '32-bit compatibility libraries'. The x86_64
> | processor can run as a ia32 (eg i686) processor and can run 32-bit
> | programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
> | processor bit (or whatever) to put it into the proper 'mode'.
>
> There's more to this than just processor mode. There's an ABI for the
> syscalls. 32-bit libraries don't just make 64 bits of space to pass the
> pointers to the kernel with. So the kernel has to be able to handle
> both ABIs if it can handle true pure-32-bit processes.

The 32-bit libraries use the same syscalls on a 64-bit machine with a
64-bit kernel as they do on a 32-bit machine with a 32-bit kernel. They
pass 32-bit pointers and get 32-bit addresses back.

>
>
> |> The question might need to be extended in the case of virtualization such as
> |> Xen. But until someone grasps the conceptual difference between running a
> |> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
> |> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | THERE IS NO SUCH THING!!! GET THIS OUT
> | OUT OF YOUR MIND!!!!!!!!!!!
>
> Sorry, but memory just doesn't erase like that. I have seen it, so I know
> it does exist. Maybe it's all moot today.

I would thing so.

>
>
> | The virtualization systems (eg Xen) handle all of this. I am sure that
> | if you install a 64-bit virtualization system on a 64-bit system and
> | have it provide a batch of virtual 32-bit systems, it will work just
> | fine -- each of the virtual 32-bit systems will have a 32-bit kernel.
> |
> | You can *probably* install and run a 32-bit version of the
> | virtualization system (eg Xen), but why would you do this on a 64-bit
> | system with a 64-bit kernel?
> |
> | What *exactly* are you trying to achieve here?
>
> I'm trying to get to the full truth.
>
> There are a lot of issues when dealing with a mix of 32-bit and 64-bit.
> A 64-bit kernel that can fully handle either pure 32-bit processes or
> pure 64-bit processes has to be able to deal with those issues, such as
> having both 32-bit and 64-bit ABIs. Maybe it's as simple as a .config
> setting to include or not include the 32-bit ABI (because maybe someone
> that does not intend to run anything at 32-bit wants to save the space
> and not include that).

I'm going to check on a 64bit machine, but I don't think it works that
way. You can *always* grab the kernel sources and look for yourself.
To misquote Ben: "Use the Source, Phil"

The kernel config for the 64bit machine starts with:

CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y

Unless the 'CONFIG_X86' corresponds to the 32-bit ABI (not sure if that
even makes sense)


>

--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

Robert Heller wrote:
> At 15 Jul 2008 19:23:57 GMT phil-news-nospam@ipal.net wrote:
>
>> In comp.os.linux.misc Robert Heller wrote:
>>
>> | No, they don't do that -- I don't think they can. There are no '32-bit
>> | compatibility libraries', they are just the 32-bit libraries. When a
>> | 32-bit program in running, that process is 'locked' in 32-bit
>> | processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
>> | level, at least in *user mode*. The 32-bit libraries are the *same*
>> | 32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
>> | installed 32-bit libraries from a 32-bit distro on a 64-bit system
>> | (running a 64-bit kernel) [I had an old 32-bit program that used old
>> | shared libraries and it was too much trouble to mess with re-building it
>> | on the 64-bit box]. The 32-bit libraries use the 32-bit
>> | library-calling-ABI, just like on a 32-bit i[3456]86 system. The
>> | *kernel* runs in 64-bit mode and has access to the 64-bit address
>> | space, in *kernel* mode.
>>
>> I have seen "compatibility" libraries. Maybe that was done due to earlier
>> Linux work that was pure 64-bit.
>
> The only 'compatibility' libraries I've seen are ones that provide
> compatibility to older systems (eg libc5 compatibility libraries or
> compatibility libraries for other older libraries). I have *never* seen
> 32/64 bit compatibility libraries *ever*. You are confusing something
> else. Maybe MS-Windows plays this sort of games?
>
> Note: I might have seen compatibility libraries on 32/64 bit Irix (MIPS
> processor) or Solaris (32/64 bit Sparc), but never on x86 64-bit Linux.
>
>> For this to work, the 64-bit kernel has to understand an ABI to get the
>> 32-bit pointers from the 32-bit process doing syscalls. Further, it has
>> to be sure points it gives back are not only in 32 bits of space, but are
>> valid in a 32-bit address space. Consider mmap(). It can choose what
>> address to map space into, if not asked to use a specific address. For
>> a 32-bit process, it has to know the limits of what it can choose during
>> the kernel code carrying out these steps.
>
> The kernel ABI is the same for both 32 and 64 bit kernels. The kernel
> *knows* if the calling process was 32-bit or 64-bit (there is status info in a
> status register telling it this).
>
>>
>> | There is no such thing as '32-bit compatibility libraries'. The x86_64
>> | processor can run as a ia32 (eg i686) processor and can run 32-bit
>> | programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
>> | processor bit (or whatever) to put it into the proper 'mode'.
>>
>> There's more to this than just processor mode. There's an ABI for the
>> syscalls. 32-bit libraries don't just make 64 bits of space to pass the
>> pointers to the kernel with. So the kernel has to be able to handle
>> both ABIs if it can handle true pure-32-bit processes.
>
> The 32-bit libraries use the same syscalls on a 64-bit machine with a
> 64-bit kernel as they do on a 32-bit machine with a 32-bit kernel. They
> pass 32-bit pointers and get 32-bit addresses back.
>
>>
>> |> The question might need to be extended in the case of virtualization such as
>> |> Xen. But until someone grasps the conceptual difference between running a
>> |> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
>> |> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> | THERE IS NO SUCH THING!!! GET THIS OUT
>> | OUT OF YOUR MIND!!!!!!!!!!!
>>
>> Sorry, but memory just doesn't erase like that. I have seen it, so I know
>> it does exist. Maybe it's all moot today.
>
> I would thing so.
>
>>
>> | The virtualization systems (eg Xen) handle all of this. I am sure that
>> | if you install a 64-bit virtualization system on a 64-bit system and
>> | have it provide a batch of virtual 32-bit systems, it will work just
>> | fine -- each of the virtual 32-bit systems will have a 32-bit kernel.
>> |
>> | You can *probably* install and run a 32-bit version of the
>> | virtualization system (eg Xen), but why would you do this on a 64-bit
>> | system with a 64-bit kernel?
>> |
>> | What *exactly* are you trying to achieve here?
>>
>> I'm trying to get to the full truth.
>>
>> There are a lot of issues when dealing with a mix of 32-bit and 64-bit.
>> A 64-bit kernel that can fully handle either pure 32-bit processes or
>> pure 64-bit processes has to be able to deal with those issues, such as
>> having both 32-bit and 64-bit ABIs. Maybe it's as simple as a .config
>> setting to include or not include the 32-bit ABI (because maybe someone
>> that does not intend to run anything at 32-bit wants to save the space
>> and not include that).
>
> I'm going to check on a 64bit machine, but I don't think it works that
> way. You can *always* grab the kernel sources and look for yourself.
> To misquote Ben: "Use the Source, Phil"
>
> The kernel config for the 64bit machine starts with:
>
> CONFIG_X86_64=y
> CONFIG_64BIT=y
> CONFIG_X86=y
>
> Unless the 'CONFIG_X86' corresponds to the 32-bit ABI (not sure if that
> even makes sense)
>
>
>

If someone came up with cli search string to locate the compatibility
library enabling i386 Canon-Linux files on a Hardy AMD64 OS I would have
far more room on my computer desk
ftp://download.canon.jp/pub/driver/bj/linux/

(Posted the link because so many insisted there's no Canon cups for Linux)


--
Bob
Calling alcoholism 'a disease' is
the politically correct substitute for 'a self induced insanity.'

phil-news-nospam@ipal.net wrote:
> There's nothing the PAE design that would prevent a 32-bit PAE system from
> remapping the lost 0.75GB of RAM into a location above the 4GB address as
> long as the system is not fully populated to the PAE limit of 64GB. However,
> the real question is whether or not real implementations have been made to
> do just that.



There are a couple of things preventing that. If you map the 0.75GB up
above the 4GB address space, then your applications won't be able to see
it. Despite PAE, each individual app is still limited to 4GB of address
space. Multiple applications can exist in different 4GB spaces, but as
far as they are concerned they occupy the space from 0-4GB in the
address range. So mapping the missing 0.75GB to the range from 4GB upto
4.75GB will result in the application not seeing that memory. Also if
you do manage to map the memory below the 4GB limit, then the reserved
hardware addresses will no longer function.

Yousuf Khan

Yousuf Khan wrote:
> phil-news-nospam@ipal.net wrote:
>> There's nothing the PAE design that would prevent a 32-bit PAE system
>> from
>> remapping the lost 0.75GB of RAM into a location above the 4GB address as
>> long as the system is not fully populated to the PAE limit of 64GB.
>> However,
>> the real question is whether or not real implementations have been
>> made to
>> do just that.
>
>
>
> There are a couple of things preventing that. If you map the 0.75GB up
> above the 4GB address space, then your applications won't be able to see
> it. Despite PAE, each individual app is still limited to 4GB of address
> space. Multiple applications can exist in different 4GB spaces, but as
> far as they are concerned they occupy the space from 0-4GB in the
> address range. So mapping the missing 0.75GB to the range from 4GB upto
> 4.75GB will result in the application not seeing that memory. Also if
> you do manage to map the memory below the 4GB limit, then the reserved
> hardware addresses will no longer function.
>
> Yousuf Khan

For the foreseeable future, I don't see how many desktop users would
want to exceed the 4GB/process limit in PAE. Servers, maybe, and they
should have 64bit processors except for the low-end ones which can get
away with using 32 bit processors.

The only applications which would really need more than 4GB for a
process on the desktop market in the next couple of years are probably
games and 3D design, etc., but for a simple office machine, 32 bit will
suffice for a few years yet.

On Wed, 16 Jul 2008 13:38:11 -0400, Yousuf Khan wrote:

> phil-news-nospam@ipal.net wrote:
>> There's nothing the PAE design that would prevent a 32-bit PAE system
>> from remapping the lost 0.75GB of RAM into a location above the 4GB
>> address as long as the system is not fully populated to the PAE limit
>> of 64GB. However, the real question is whether or not real
>> implementations have been made to do just that.
>
>
>
> There are a couple of things preventing that. If you map the 0.75GB up
> above the 4GB address space, then your applications won't be able to see
> it. Despite PAE, each individual app is still limited to 4GB of address
> space. Multiple applications can exist in different 4GB spaces, but as
> far as they are concerned they occupy the space from 0-4GB in the
> address range. So mapping the missing 0.75GB to the range from 4GB upto
> 4.75GB will result in the application not seeing that memory. Also if
> you do manage to map the memory below the 4GB limit, then the reserved
> hardware addresses will no longer function.
>
> Yousuf Khan

You are confusing physical and logical addresses. The physical space with
PAE is 64G, the logical space that a process sees is 4G. The MMU maps
each page of virtual memory to a page of physical memory by translating
the 32 bit virtual address into a 36 physical address. The 36 bit
physical address can point to any page in the 64G space so you can map
the RAM and IO space anywhere you want within the 64G space.