public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>
To: fcook37@hotmail.com
Cc: gcc@gcc.gnu.org, uweigand@de.ibm.com
Subject: Re: Different addressing modes?
Date: Wed, 21 May 2003 22:11:00 -0000	[thread overview]
Message-ID: <200305212202.AAA08810@faui11.informatik.uni-erlangen.de> (raw)

Fred Cook wrote:

>I am still trying to get addressing modes correctly in my port. 
>Basically my architecture has the following addressing modes:
> 
> 1) absolute
> 2) register indirect
> 3) register + offset
> 4) register + register

I'm assuming this means the following RTX represent valid 
memory operands:

 1)  (mem (symbol_ref ...))
 2)  (mem (reg ...))
 3)  (mem (plus (reg ...) (const_int ...)))
 4)  (mem (plus (reg ...) (reg ...)))

>I want to specify in my define_insn for "call" that 1+2 are allowed 
>and in my define_insn for "movsi" that 2, 3, and 4 are allowed for 
>loads and 2 and 3 for stores.

"call" can be handled specially.  It is fine to have a pattern
that matches
  (call (mem (symbol_ref ...))
even if (mem (symbol_ref ...)) is not a valid memory operand.

I would suggest to do the following:

- Define GO_IF_LEGITIMATE_ADDRESS so that 2), 3), and 4) above
  are accepted.  This means that usual memory accesses (i.e.
  those for loads) simply use the "m" constraint.

- Define an additional constraint letter "S" to denote
  'memory reference without a second register', and define
  EXTRA_CONSTRAINTS to only accept 2) and 3) above for
  this letter.

  As this definition fulfils the requirements "a subset of
  all memory references including all those consisting of
  solely a base register", you can (and must) mark the
  constraint letter "S" as EXTRA_MEMORY_CONSTRAINT.  This
  will cause reload to fix up the address if required
  (note that you *must* provide a load-address type pattern
  that accepts the full range of memory addresses as source).

With this set up, you can define movsi like this:

(define_insn "movsi"
       [(set (match_operand:SI 0 "nonimmediate_operand" "=r,S")
             (match_operand:SI 1 "general_operand" "m,r"))]
       ""
       "@
         ld %1 -> %0
         st %0 %1"
)

All this is actually similar to the s390 setup, so you
might want to check out our backend for comparison ... 
 
Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

             reply	other threads:[~2003-05-21 22:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-21 22:11 Ulrich Weigand [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-21 16:32 Fred Cook
2003-05-21 16:48 ` Peter Barada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200305212202.AAA08810@faui11.informatik.uni-erlangen.de \
    --to=weigand@immd1.informatik.uni-erlangen.de \
    --cc=fcook37@hotmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).