Address sizes on 64-bit MIPS targets

Thiemo Seufer ica2_ts@csv.ica.uni-stuttgart.de
Wed Mar 2 14:59:00 GMT 2005


Richard Sandiford wrote:
> Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> > Richard Sandiford wrote:
> > [snip]
> >> However, if the sequence is:
> >> 
> >>         dla     $2,0xa8000000000000
> >>         lw      $2,0x100000($2)
> >> 
> >> then the lw will use 32-bit address arithmetic:
> >> 
> >>         lui     $1,0x10
> >>         addu    $1,$1,$2
> >>         lw      $2,0($1)
> >> 
> >> and the behaviour will be unpredictable.
> >
> > Which isn't exactly a problem, because 0xa8000000000000 is an invalid
> > address for n32. For 32bit sign-extended addresses it works fine.
> 
> Sure.  But you seem to be missing the whole point.  0xa8000000000000 was
> just as invalid in the other two examples as well.  I see no fundamental
> difference between the example quoted above and the two previous ones.

My point was that all those examples don't occur in real-world code.

[snip]
> >>         lw      $2,0x1000($2)
> >> 
> >> The behaviour of this instruction is unpredicatable for 32-bit address
> >> spaces on 64-bit targets if $2 + 0x1000 overflows (for example, if
> >> $2 == 0x7ffffff0).
> >
> > What is unpredictable there? It will point to the start of CKSEG0, and
> > trigger an address exception.
> 
> It depends.  You only get wrap-around when running in user mode.
> n32 code running in kernel or supervisor mode will not wrap around,
> so the results are sensitive to processor mode.
>
> And I'm not sure how predicatable the behaviour is for all 64-bit
> processors.  The MIPS64 spec guarantees wrap-around for user mode
> programs when UX=0, but (for example) the description of supervisor
> and kernel addressing in the VR4100 manual says:
> 
>    Usually, it is impossible for 32-bit mode programs to generate
>    invalid addresses.  In an operation of base register + offset
>    for addressing, however, a two's complement overflow may occur,
>    causing an invalid address.  Note that the result becomes undefined.
> 
> But maybe I'm being overly influenced by that ;)

We have (potentially) two cases where all of this is used. A (currently
not existing) n32 userland non-PIC mode, and n32 non-PIC kernel mode.
In both cases, addresses which could wrap-around are invalid. There's
just not point in handling them better than we already do.

[snip]
> Like I say, SGI (who defined n32 in the first place ;) use 64-bit
> arithmetic in their assemblers.  I don't think we can claim that
> we're being more ABI-compliant by using 32-bit arithmetic for the
> example above instead.

AFAIH SGI used special kernel compilers.

> >> I'd like to change things so that:
> >> 
> >>     - "dla"s with no symbolic component use 64-bit arithmetic
> >>     - "la"s with no symbolic component use 32-bit arithmetic
> >>     - "la"s and "dla"s with a symbolic component use 64-bit arithmetic
> >>       iff HAVE_64BIT_ADDRESSES (i.e. they use whatever the ABI dictates). [*]
> >> 
> >>     - loads and stores with no symbolic component use 64-bit arithmetic
> >>       iff HAVE_64BIT_GPRS.
> >>     - loads and stores with a symbolic component use 64-bit arithmetic
> >>       iff HAVE_64BIT_ADDRESSES. [*]
> >
> > Instead of changing the behaviour of this already fragile hack I would
> > prefer an explicit -msym32 switch for ABI N64.
> 
> And I have a patch for that. ;)  Hope to get it polished up and posted
> tonight.  But as I said at the beginning of yesterday's message, this
> patch is paving the way for -msym32 by auditing existing uses of
> HAVE_{32,64}BIT_ADDRESSES.

But -msym32 obsoletes that HAVE_{32,64}BIT_ADDRESSES stuff.

> I couldn't really tell from your reply whether you object to the changes
> outright.  Is there any way I can persuade you to go with this?  FWIW,
> restricting the influence of HAVE_64BIT_ADDRESSES to symbolic arithmetic
> really does make the -msym32 behaviour more obvious.

Keep in mind that the whole thing is a rather fragile optimization, and
it isn't that widely used (the patch for using n32/o64 never went in
the linux-mips CVS). IMHO we should either leave it with exactly the
behaviour it has now, or we should drop it completely in favour of
-msym32, where we can handle things better.


Thiemo



More information about the Binutils mailing list