> On Sat, Feb 17, 2001 at 06:47:39PM +0000, Richard Earnshaw wrote:
> 
>  > > Oh, yah, the WinCE hack -- I don't think we want to use that feature
>  > > on the FCS-capable chips.
>  > 
>  > On handhelds (like the Ipaq), this may be exactly what is wanted.  On a 
>  > desktop machine I agree, it's unlikely to be of use because of the 
>  > restrictions it imposes.
> 
> Well, 32M is a pretty small address space -- it's going to affect where
> you put the stack, is certainly going to affect shared libraries, etc.,
> and may constitute a new ABI.
> 
> What would be really nice is if future ARM chips included *real* address
> space IDs (a'la MIPS).

With the normal layout, yes, it would be a tight fit (mainly because the 
normal layout leaves a lot of large holes.

I don't know whether it's possible to achieve the following layout, but if 
we can, and if the processor can cope with a process growing from sub-32M 
to more than that (I haven't read the docs carefully enough to know), then 
the following order might work.

0x00008000  		prog base
top of prog data	shared libs
0x017fffff		stack top
0x01800000		heap base
0x02000000		small-proc limit

this would allow most procs to run within the limit with the proviso that 
the stack does not grow down into the shared libs.  Processes could grow 
their heap to any size provided that they can move from being small to 
large procs.  The cpu can fast context switch from any small proc to any 
other small proc, and only needs a cache flush if either old or new 
process is a large proc.  On the assumption that most processes will not 
be large, this should make cache flushes for this reason quite rare.