public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@wasabisystems.com>
To: Savithri Venkatachalapathy <snvpathy@yahoo.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Question on .md file
Date: Mon, 22 Sep 2003 03:49:00 -0000	[thread overview]
Message-ID: <m33cep7a9q.fsf@gossamer.airs.com> (raw)
In-Reply-To: <20030922032528.20718.qmail@web14204.mail.yahoo.com>

Savithri Venkatachalapathy <snvpathy@yahoo.com> writes:

Your questions are all answered by the gcc internals manual.  Check
there first.

> 1.In the .md file I noticed that there are certain
> instructions defined as: define_insn "aaa_internal1",
> "aaa_internal2a" etc..
> What does this actually mean? What does "internal"
> suggest?

The only names which matters are the standard names used to generate
RTL instructions.  These are defined here:
    http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html#Standard%20Names

Other insn names are used only as comments.  A name like aaa_internal
might mean that aaa is a standard name represented by a define_expand,
and that aaa_internal is a particular implementation for a particular
CPU class.  Or it might mean something else entirely.

> 2. I have 4 brach instructions:
>  BNE (Branch on Not Equal)
>  BEQ (Branch on EQual)
>  BEQZ(Branch on EQual to Zero)
>  BNEZ(Branch on Not Equal to Zero)
> 
> I have defined the first 2 instructions as define_insn
> "bne" and define_insn "beq".
> But I am not sure which name I should use for the last
> 2 instructions. 

The name doesn't matter as such, because gcc will never generate beqz
or bnez.  It may generate a comparison instruction against a constant
zero followed by a bne or beq.  Exactly how you should handle this
depends upon your CPU and how it handles comparisons and branches.
Look at other similar MD files.

> 3. Also I noticed in arm.md, sh.md, that the branch
> instructions have define_expand and not define_insn.
> Why is that?

Well, for the ARM it's because the branch instruction wants to pick up
the comparison information saved by cmpsi define_expand.  For example,
when gcc wants to generate a branch when two operands are equal, it
will call cmpsi and then beq.  On the ARM cmpsi will save the
operands.  The beq will pick up the operands, generate the compare (in
arm_gen_compare_reg()), and generate a branch insn.  At assembler
generation time, if the branch hasn't been optimized into something
else, it will be recognized by arm_cond_branch which will generate the
actual branch.

Ian

  reply	other threads:[~2003-09-22  3:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-22  3:25 Savithri Venkatachalapathy
2003-09-22  3:49 ` Ian Lance Taylor [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-09-21  5:01 Savithri Venkatachalapathy

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=m33cep7a9q.fsf@gossamer.airs.com \
    --to=ian@wasabisystems.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=snvpathy@yahoo.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).