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
next 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).