Date: Thu, 8 Nov 2001 11:28:17 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Peter Wemm <peter@wemm.org>, <ia64@FreeBSD.ORG> Subject: Re: Region usage Message-ID: <Pine.BSF.4.33.0111081124080.88856-100000@herring.nlsystems.com> In-Reply-To: <20011107145044.A10229@kayak.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Nov 2001, Marcel Moolenaar wrote: > On Wed, Nov 07, 2001 at 10:13:48AM +0000, Doug Rabson wrote: > > > > > > R0 - 32-bit applications; 4KB pages > > > R1 - 64-bit applications; 8KB pages (or larger) > > > R5 - VM; paged global; 8KB pages (or larger) > > > R6 - uncached global; 256M pages; Id mapping > > > R7 - cached global; 256M pages; Id mapping > > > > > Clearly IA-32 applications are limited to using R0. > > Yes, that's what I ment with 32-bit applications. > > > IA-64 32bit > > applications are more flexible though. There is a choice of zero-extension > > (i.e. R0 only), sign extension (i.e. R0 or R7) or 'pointer swizzling' > > which uses the top two bits of the 32bit address as a region number. This > > allows access to (the initial segment of) regions R0, R1, R2 and R3. > > Pointer swizzling is only meaningful if the ILP32 runtime uses > regions as well. If we don't use multiple regions per process in > the LP64 case, I don't think we have a use for swizzling. > I don't see a problem with having ILP32 processes life in region 0. > > From another angle: > The only reason to support ILP32 is for performance reasons. In > that case, the overhead of pointer swizzling works against the > objective. True. I can just about imagine an ILP32 app wanting to share address spaces with other apps but it seems unlikely. > > > > I see little advantage to have text, data/heap and stack be > > > seperate regions, other than a nice side-effect while debugging > > > (it's easy to see what an address references). The possibility > > > of either of those segments taking up more than, say, 48 bits > > > is very small ATM, although it's possible that I'm stuck in the > > > a-couple-of-megabytes-is-large mindset and thus underestimate > > > a typical "large" application. > > > > A truly 'large' application can always overflow into the other regions. > > The question is if this can be done automagically or if it requires > compile-time options or even ELF object tuning (ie flags). This would happen automatically. If the elf sections were rooted in specific regions, the loader would automatically put them there and the VM system would allocate spaces as required. If a running app wants to use a new region, its as simple as giving an explicit address to mmap(2). > > > > I'll double-check the various ia64 conventions tomorrow to see > > > how the above fits in. > > I have found no incompatibilities. The use of regions has been > abstracted correctly. It's documented that segments are allowed > to span regions (ie cross region boundaries). Multiple RRs may > point to the same region as well. Thats good to hear. Basically, if we link an app with a script that puts all the sections in one region, it would just work. Conversely, a linker script which spreads an app over several regions would also work with no changes to either the elf loader or the VM system. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0111081124080.88856-100000>