• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Odd GCC Behavior
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Odd GCC Behavior


  • Subject: Re: Odd GCC Behavior
  • From: "J. Aaron Pendergrass" <email@hidden>
  • Date: Mon, 30 Jun 2008 14:32:37 -0400


On Jun 30, 2008, at 1:12 PM, Steve Sisak wrote:

At 12:36 PM -0400 6/30/08, J. Aaron Pendergrass wrote:
Of course there's a choice to be made.
The compiler has to do something. It chose to do something on powerpc that is
completely different from what it chooses to do on other architectures, and on other
programs which have very similar undefined usages, and which seemed somewhat
unintuitive (in the sense that if I were to define a particular behavior it would not have
been the one I observed).


I'm curious what the motivation is for this particular choice.
If you don't know the answer don't respond.

Because PPC and Intel have different instruction sets and therefor different optimizers. What the spec is saying by "undefined" is that "if a programmer writes code like this it's a bug" so there's no need for compiler writers to do anything but what's most convenient.


This is a very common interview question to test basic literacy in the in the C programming language.

If you see someone writing code like this it's a good signal not to trust other they write (and not to hire them). :-)

To be correct, you MUST write it on 2 lines:

{
	long stack[4] = {1,2,3,4};
	long *sp  = test + 4;   /* top of stack is at (sp - 1) */

	/* add the top of stack to the next element and pop */
	sp -= 1;
	*(sp - 2) += *sp;
}

There are still some people who think that reducing the number of lines of C somehow reduces code size.

Are you sure you aren't trying to get us to do your homework? ;-)

Cheers,

-Steve

Thanks for the more detailed response. I understand what "undefined" means, and that different
architectures are different. but I was also under the impression that programmers wrote buggy code
fairly frequently. I may have been wrong in this. But I point out that in Andrew Pinski's previous email he
enumerated a number of options for the possible semantics of "*(sp-2) += *(--sp)":


sp = sp - 1;
*(sp - 2) += *(sp)
or
*(sp - 2) += *(sp);
sp = sp -1 ;
or even:
tmp = sp -1;
(sp - 2) += (*tmp);
sp = tmp;

None of which actually match the observed behavior of:

tmp = *(sp - 2);
sp -= 1;
*(sp - 2) = tmp + (*sp);

I stumbled upon this behavior when converting code which made heavy use of macros to do stack manipulation
from using array indices to using pointers and found that the semantics were totally different (as are the dissaembly
for PPC).


I was somewhat surprised that the "most convenient thing for the programmer" was something like
"if the left hand of side of a compound assignment statement is a pointer dereference,
then determine it's r-value first, then evaluate the right hand side (including any pre/post
increments/decrements), perform the arithmetic for the compound assignment, then determine the
l-value of the left hand side and perform the actual assignment
otherwise evaluate the left-hand side to determine both its r-value and l-value, then evaluate the right
hand side (including any pre/post increments/decremetns), perform the arithmetic for the compound
assignment, then store the result in the previously computed l-value."


I'm certainly not trying to get anyone to do my work, merely pointing out what seemed like a peculiar implementation
and potential source of cross-platform incompatibilities, and perhaps to gain some insight into exactly what decisions
led to this piece of behavior.


-Aaron
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Odd GCC Behavior
      • From: Eli Bach <email@hidden>
    • Re: Odd GCC Behavior
      • From: Jonas Maebe <email@hidden>
References: 
 >Odd GCC Behavior (From: "J. Aaron Pendergrass" <email@hidden>)
 >Re: Odd GCC Behavior (From: Jim Jagielski <email@hidden>)
 >Re: Odd GCC Behavior (From: "J. Aaron Pendergrass" <email@hidden>)
 >Re: Odd GCC Behavior (From: "Clark Cox" <email@hidden>)
 >Re: Odd GCC Behavior (From: "J. Aaron Pendergrass" <email@hidden>)
 >Re: Odd GCC Behavior (From: Steve Sisak <email@hidden>)

  • Prev by Date: Re: Odd GCC Behavior
  • Next by Date: Re: Odd GCC Behavior
  • Previous by thread: Re: Odd GCC Behavior
  • Next by thread: Re: Odd GCC Behavior
  • Index(es):
    • Date
    • Thread