I personally think it's long overdue that we really invest some time/effort in the 64-bit version. I mean, anything past 0.5 GiB is really a hack on 32-bit.... I, for one, am willing to lend a pair of hands to this... but I need to know what needs doing, first. Could someone give me an overview of how you're supposed to do a handoff between a 32-bit loader and a 64-bit app? I'm guessing there has to be a way to do it, but what I do know about the 64-bit stuff doesn't show me how this is accomplished (I have visions of UX bits floating in my head...) Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Jun Sun > Sent: Wednesday, May 15, 2002 3:00 PM > To: Daniel Jacobowitz > Cc: Matthew Dharm; Linux-MIPS > Subject: Re: MIPS 64? > > > Daniel Jacobowitz wrote: > > > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > > >>So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > >>That kinda blows the 32-bit MIPS port option right out of > the water... > >> > > > > Not unless you count bits differently than I do... 32-bit > is 4 GiB. Is > > there any reason MIPS has special problems in this area? > > > > > MIPS has lower 2GB fixed for user space. Then you have > kseg0, .5GB for cached > physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping > of the same area. > You can map another 1GB of RAM into kseg2/3, but you will > then have no space > left for IO. > > So you really can't do 1.5GB on 32 bit kernel. > > It is interesting that PPC allows one to adjust user space > size and kernel > space size. So on PPC you can get up to 2.5GB system RAM > with 1GB user space. > > Back to 64bit port, it seems to me much of the 32bit work > we have done in the > past a year or so needs to be moved over. Or better yet, > if we can clean up > integer/long issues, we might be able to use 32bit kernel > code straight for > 64bit kernel. > > > Jun > >
