public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: rth@cygnus.com
Cc: cort@attis.cs.nmt.edu, gas2@sourceware.cygnus.com
Subject: Re: ppc instructions in gas
Date: Thu, 06 May 1999 20:43:00 -0000	[thread overview]
Message-ID: <19990507034233.10892.qmail@daffy.airs.com> (raw)
In-Reply-To: <19990506201322.A14952@cygnus.com>

   Date: Thu, 6 May 1999 20:13:22 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Fri, May 07, 1999 at 03:05:30AM -0000, Ian Lance Taylor wrote:
   > I don't have the context of the original message.  The addis/lis
   > instruction is documented to take a signed operand.  I don't know why
   > it makes sense to remove PPC_OPERAND_SIGNED.

   Context is that gcc doesn't emit signed, and some of the ppc linux
   kernel sources don't use signed values either.  This worked for 
   ppc32 due to the PPC_OPERAND_SIGNOPT hack, and only showed up when
   Cort started work on ppc64. 

   We iterated enough to conclude that we should in fact fix gcc, and
   the kernel sources.  The one remaining question is whether to continue
   to silently accept unsigned values for ppc32, or whether we should
   warn for them.

   Thoughts on that last?

I believe we should continue to silently accept them.  The patch was
put in there because of existing code which should continue to work.

I now remember that I opposed it at the time, and argued David
Edelsohn (I believe it was) into only accepting unsigned values in 32
bit mode, and requiring people to fix their code as they upgraded to
64 bits.

I even have a vague recollection that the Power liu instruction was
documented to load an unsigned value.  The Power was only 32 bits, so
of course it didn't really matter.  The PowerPC renamed liu to lis,
and made it signed for the 64 bit version.  Power code and Power
programmers naturally used unsigned values, so we made gas permit
unsigned values for lis.

Ian

      reply	other threads:[~1999-05-06 20:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19990504180843.A31050@attis.cs.nmt.edu>
     [not found] ` <19990505145806.H9469@cygnus.com>
     [not found]   ` <19990505165232.A8594@attis.cs.nmt.edu>
1999-05-06 15:07     ` Richard Henderson
     [not found]       ` <19990506161159.A27229@attis.cs.nmt.edu>
1999-05-06 15:35         ` Richard Henderson
     [not found]           ` <19990506171639.A26711@attis.cs.nmt.edu>
1999-05-06 16:56             ` Richard Henderson
     [not found]               ` <19990506180806.A5113@attis.cs.nmt.edu>
1999-05-06 17:49                 ` Richard Henderson
     [not found]                   ` <19990506185754.A12025@attis.cs.nmt.edu>
1999-05-06 18:43                     ` Richard Henderson
1999-05-06 20:06       ` Ian Lance Taylor
1999-05-06 20:13         ` Richard Henderson
1999-05-06 20:43           ` Ian Lance Taylor [this message]

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=19990507034233.10892.qmail@daffy.airs.com \
    --to=ian@airs.com \
    --cc=cort@attis.cs.nmt.edu \
    --cc=gas2@sourceware.cygnus.com \
    --cc=rth@cygnus.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).