public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Åke Forslund" <aforslund@lasermaxroll.se>
To: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: Evaluate 16-bit signed value 0x8000 after left shift by 2
Date: Fri, 13 Jun 2014 14:33:00 -0000	[thread overview]
Message-ID: <E993883FF752B04C97E12BAA9E4DC824714B6620@SEMAIL2.rollsys.com> (raw)
In-Reply-To: <b22d5b5f7a8a46bcb436966230f76e64@HKXPR03MB166.apcprd03.prod.outlook.com>

On fre, 2014-06-13 at 06:42 +0000, Sandeep Kumar Singh wrote:
> Hi,
> 
> I need some help/clarification,
> I am expecting zero value of 16-bit signed value 0x8000 after left shift by 2
> Below is my test case.
> 
> Test case:
> ========
> int main()
> {
> 	register signed short val1 = 0x8000 ;
> 	signed short val2 ;
> 	val2 = ( ( val1 << 2 ) >> 2 ) ;              /* val2 should be 0. */
> 	printf( "\nval2 is :%x\n", val2 ) ;    /* But Val2 is ffff8000 */
> 	return 0 ;
> }
> 
> Steps to reproduce:
> $gcc   test.c
> $run   a.out
> 
> I have verified the same behavior with 32-bit compilers and expected (val2=0)
> with 16-bit compiler. I can correct this by shifting 18 in place of 2 as a
> workaround. I want some verify my understanding for this point and another 
> way to get expected result (if any).
> 
> Best Regards,
> Sandeep Kumar Singh
> 
> 
I'm a bit rusty on how C does things but:

if I run your example and replaces %x in the printf with %hx my computer
prints "8000" which is somewhat logical since h asks printf to consider
the variable to be a short int and not a regular int.

The other thing could be that the architecture is 32 bit and the
operations are made on 32 bit words. so you'r short is represented as

	0xffff8000 in memory and then the value is shifted and left to
	0xff800000 the next right shift just moves it back
	0xffff8000

I believe the returning f could be a cpu feature that automatically adds
ones where bits would be unknown.

Regards
/Åke

  reply	other threads:[~2014-06-13 13:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13 13:47 Sandeep Kumar Singh
2014-06-13 14:33 ` Åke Forslund [this message]
2014-06-13 15:08 ` Andrew Haley
2014-06-13 15:23   ` Åke Forslund
2014-06-14  8:01     ` Andrew Haley

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=E993883FF752B04C97E12BAA9E4DC824714B6620@SEMAIL2.rollsys.com \
    --to=aforslund@lasermaxroll.se \
    --cc=gcc-help@gcc.gnu.org \
    /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).