From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thiemo Seufer To: binutils@sources.redhat.com Subject: Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas Date: Fri, 31 Aug 2001 18:22:00 -0000 Message-id: <20010901032235.A4969@rembrandt.csv.ica.uni-stuttgart.de> References: <20010825032615.E309@rembrandt.csv.ica.uni-stuttgart.de> <20010831181657.A17249@rembrandt.csv.ica.uni-stuttgart.de> <200108311711.KAA19709@geoffk.org> <20010831193107.A10362@rembrandt.csv.ica.uni-stuttgart.de> <20010831204556.C17249@rembrandt.csv.ica.uni-stuttgart.de> X-SW-Source: 2001-08/msg00747.html cgd@broadcom.com wrote: [snip] > yes, i know that the pointer is going to be constrainted to being a > sign-extended 32-bit value, but neither the compiler or any assembly > code that uses it needs to know that (or should). As far as they're > concerned, pointers are 64-bit values and they're loaded with ld, etc. I see. Btw, my patch actually doesn't change this behaviour, the HAVE_32BIT_ADDRESSES macro cares about macro expansion, so it changes an address load via immediates from a "lui; daddiu" sequence to "lui; addiu", this makes no difference. An "ld" isn't changed. > yes, there's code that actually uses this. why? it's really nice to > have code that is linked into a 32-bit address space, but can have > 'usable' 64-bit pointers in C code. e.g. code that lives at the boot > vector, but wants to address data in xkphys... This is something similiar to the technique used for the current mips64-linux kernels. Thiemo