linux-mips
[Top] [All Lists]

Re: Latest sources from CVS.

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: Latest sources from CVS.
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Date: Fri, 6 Dec 2002 18:24:38 +0100
Cc: Carsten Langgaard <carstenl@mips.com>, Ralf Baechle <ralf@linux-mips.org>, "Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
In-reply-to: <Pine.GSO.3.96.1021206175502.26674R-100000@delta.ds2.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20021206164558.GH23743@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1021206175502.26674R-100000@delta.ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4i
Maciej W. Rozycki wrote:
> On Fri, 6 Dec 2002, Thiemo Seufer wrote:
> 
> > >  Which wouldn't work either as it implies 32-bit pointers, while gcc still
> > > emits 64-bit assembly.
> > 
> > Which should be enough for smaller address spaces.
> 
>  But gas will complain of the same address truncation as for o32. 

Maybe I wasn't clear about it, I meant kernels with 32 bit address
space but 64 bit register width, allowing for userland N32 ABI.

E.g. the old DECstations with R4k CPU and limited memory would fit
in this scheme. :-)

> > > If we want to preserve the setup cleanly, we
> > > probably need yet another ABI model in gcc (especially in the face of the
> > > coming changes to get rid of assembly macros), with sign-extended 32-bit
> > > pointers for accessing program segments and 64-bit ones for the remaining
> > > addresses.
> > 
> > Do you think this is worth the hassle? N64 offers better flexibility in
> > the large memory case at some performance cost, and it's conceptionally
> > cleaner.
> 
>  Remember we are writing of the kernel -- we don't know what userland is
> going to bring us

I don't understand this. The kernel _defines_ what the userland is allowed
to do.

> -- a user pointer need not fit in 32 bits.

It needs to, if the kernel doesn't want to support 64 bit address space. :-)


Thiemo

<Prev in Thread] Current Thread [Next in Thread>