This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: AM33: Not adding `0,' to `(SP)'
- To: law at cygnus dot com
- Subject: Re: AM33: Not adding `0,' to `(SP)'
- From: Alexandre Oliva <aoliva at cygnus dot com>
- Date: 01 May 2000 13:35:10 -0300
- Cc: Richard Henderson <rth at cygnus dot com>, gcc-patches at gcc dot gnu dot org
- Organization: Cygnus Solutions, a Red Hat Company
- References: <14399.957193273@upchuck>
On May 1, 2000, Jeffrey A Law <law@cygnus.com> wrote:
> In message <20000430112638.A1778@cygnus.com>you write:
> Yes, this is an encoding issue, there is no mem (sp) addressing mode, only
> mem (sp + disp).
On mn10300, indeed, there isn't, but on am33, there is, and it does
make a difference. Fortunately, in the mn10300 case, the assembler is
smart enough to encode (sp) as (0,sp), so it's ok if GCC emits them.
Unless we must maintain compatibility with some other assembler, in
which case I suggest that we replace `stack_pointer_rtx' with
`gen_rtx_PLUS(SImode, stack_pointer_rtx, GEN_INT (0))' only when
! TARGET_AM33.
> 1. When did we actually try to generate mem (sp), or were we using
> this code for something other than memory references?
We didn't. We'd only do it with the patch I posted.
> 2. If we did generate mem (sp), why didn't the assembler complain?
Because (presumably) you added opcodes to match `(sp)' even when an
offset is mandated by the mn10300 assembler specification: :-)
{ "mov", 0x5800, 0xfcff, 0, FMT_S1, 0, {MEM(SP), DN0}},
{ "mov", 0x5800, 0xfc00, 0, FMT_S1, 0, {MEM2(IMM8, SP), DN0}},
--
Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me