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 17:45:58 +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.1021206165118.26674N-100000@delta.ds2.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20021206135110.GD23743@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.3.96.1021206165118.26674N-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:
> 
> > Er, well, for some values of 'fine'. In principle, 64 bit code shouldn't
> > be disguised in O32 objects. OTOH i must admit it's a bit early to use
> > binutils N32 for this purpose.
> 
>  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.

> 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.


Thiemo

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