This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: [patch] tc-h8300.c: Don't output a wrong warning.
- From: Kazu Hirata <kazu at hxi dot com>
- To: 'Nick Clifton' <nickc at cambridge dot redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 24 Jan 2002 11:13:50 -0500
- Subject: 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