Subject: Re: ARM port organisation (was: Re: NetBSD/hpcarm snap code)
To: None <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 02/18/2001 00:08:49
> 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.