Re: AM33: Not adding `0,' to `(SP)'

[Jeffrey A Law <law at cygnus dot com>]

  In message <or4s8iw7nl.fsf@zecarneiro.lsd.ic.unicamp.br>you write:
  > 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, onl
  > y
  > > mem (sp + disp).
  > 
  > On mn10300, indeed, there isn't, but on am33, there is, and it does
  > make a difference. 
Hmmm, yes, I see some mem (sp) stuff in my am33 manual.  Amazing what the
mind forgets over time.

  > Fortunately, in the mn10300 case, the assembler is
  > smart enough to encode (sp) as (0,sp), so it's ok if GCC emits them.
OK.

  > 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.
We don't have a need to be compatible with other assemblers.


  > > 	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.
OK.

  > > 	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: :-)
Oh yea..   It was one of the pseudo-ops Matsushita wanted, along with one
operand asr, lsr & asl instructions.  Ugh.  I hate this nonsense.

Anyway, now that I  know what we're really doing with the patch, it's OK. :-)

jeff