This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mipsisa32-unknown-elf-as: Error: too large constantspecified


At Wed, 15 Oct 2003 01:55:02 +0100, Nigel Stephens wrote:
> I'm happy with it. But note that this doesn't return the behaviour to
> what cgd was seeing on the old assembler when compiling for a 64-bit
> ISA. It will now compile
> 
>         or      $2, $2, 0xe0000000
>         and     $2, $2, ~0xe0000000
> 
> to the same sequence for both a 32 and 64-bit arch:
> 
>    0:   3c01e000        lui     at,0xe000
>    4:   00411025        or      v0,v0,at
>    8:   3c011fff        lui     at,0x1fff
>    c:   3421ffff        ori     at,at,0xffff
>   10:   00411024        and     v0,v0,at


> But I'd claim that's correct: it's not sensible for the assembler to
> interpret immediate operands differently depending on the
> architecture.

See the thread:

        http://sources.redhat.com/ml/binutils/2002-02/msg00208.html

Yes, that's from me (but the discussed there was made by somebody
else).  I think i've been here before!  8-)

I got hit in the face with it (pretty hard) when it was initially
implemented, but i believe the behaviour as implemented at that time
was correct, and matching other implementations (e.g. SGI assembler).

AFAICT, there was no specific NEWS entry that mentioned that change.


> It should only interpret immediates as truly 64-bit if they are used
> with explicit 64-bit instructions (e.g. daddu, dli, etc), which is
> what this patch will do.

I believe that the IRIX assembler disagrees with your interpretation,
but can't easily re-verify my earlier findings right now.



chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]