public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Mohamed Shafi <shafitvm@gmail.com>
Cc: GCC <gcc@gcc.gnu.org>
Subject: Re: Need help in deciding the instruction set for a new target.
Date: Mon, 23 Aug 2010 19:00:00 -0000	[thread overview]
Message-ID: <mcr7hjhxjra.fsf@google.com> (raw)
In-Reply-To: <AANLkTimKoa7xNV4dgqQdysJGB6bc2_O7bQrKruiMXhEL@mail.gmail.com>	(Mohamed Shafi's message of "Mon, 23 Aug 2010 21:05:39 +0300")

Mohamed Shafi <shafitvm@gmail.com> writes:

> I want to know if it is good to have both sign and zero extension for
> 16bit immediate.

Hard to say.  It really depends on the kind of constants you expect your
programs to use.  It's generally a good idea to have an efficient way to
load small constants which many programs use, such as 0, 1, -1.  The
latter implies that you will want sign extending immediate operations.
Whether your programs will benefit from an efficient way to load 0xffff,
I don't know.

> Will it be of any use with a configuration where char == short == int == 32bit?

Yes, the size of supported immediate constants is really orthogonal to
the size of the data types.  Your programs are certainly going to refer
to numbers like 0, 1, and -1.  Efficient ways of using those constants
will generally pay off, though of course it is a tradeoff like
everything else in architecture design.

> Will I be able to support these kinds of instructions in a GCC port?

Yes.

> Or will it good to have a separate sign and zero extension
> instruction, which the current instruction set doesn’t have.
> Do I need a separate sign and zero ext instructions along with the
> above instructions?

When char is 32 bits, you don't really need sign and zero extension of
unknown values.  So the question is whether you need them for immediate
constants.  As I mention above, it will probably pay off to have
instructions which support sign extending immediate constants.  Whether
that is done via operands to add, etc., or via a load-immediate
instruction, really depends on other characteristics of your
architecture and of the programs you expect to write.

Hope this helps.

Ian

  reply	other threads:[~2010-08-23 18:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23 18:25 Mohamed Shafi
2010-08-23 19:00 ` Ian Lance Taylor [this message]
2010-08-23 20:24 ` Bernd Schmidt
2010-08-23 22:20 ` Richard Henderson

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=mcr7hjhxjra.fsf@google.com \
    --to=iant@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=shafitvm@gmail.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).