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: [patch] tc-h8300.c: Don't output a wrong warning.


Hi Nick,

> >   mov.w  r2,@0xff8000:16
> > 
> > In h8 assembly language, when address:16 is given, the effective
> > address is computed as follows.
> > 
> >   0x000000 + address if 0x0000 <= address <= 0x7fff
> >   0xff0000 + address if 0x8000 <= address <= 0xffff
> > 
> > People often give full 24-bit address like 0xff8000 and expect it to
> > be truncated to 0x8000.  The patch eliminates the warning when the
> > truncation is done correctly.
> 
> Surely if :16 is used a 16-bit address should be expected.  Giving a
> 24-bit address is, I would have thought, at least technically wrong.
> I can understand how programmers might want to be lazy and use :16
> instead of :24, but I think that a warning is warranted.  Maybe if the
> warning was only enabled if a command line option was given, then
> people would be happier ?

If the 16-bit address area is a separate address space, then I would
agree, but this isn't the case here.  It is a part of the whole
address range.

Let's say a symbol "some_ioport" is defined to be 0xff8000 in a linker
script, which is in the 16-bit address area.  It should be perfectly
OK to say

  mov.w r2,@some_ioport:16

Now, replacing some_ioport in the source code with 0xff8000 should not
generate a warning.  But the current implementation does issue a
warning.

After all, :16 is a modifier to make an assembly instruction shorter.
An instruction with :16 should behave just like one without as long as
the address specified before :16 resides in a valid 16-bit address
area.

Kazu Hirata


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