Sequence point question (function result semantics) 
Author Message
 Sequence point question (function result semantics)

Quote:



> >But that doesn't sound like it delivers into c what it should.  I understand
> >computer
> >architectures can support all sorts of complicated atomic executions - no
> >problem
> >there, but c is getting the value of a.  If the compiler design increments a
> >first,
> >then
> >either it puts the result in a different register and "remembers" that a has
> >moved
> >from one register to another and c is now in the register that used to hold a,
> >or
> >there
> >is some sort of temporary created for the incremented value:

> >temp = a+1;
> >c = a;
> >a = temp;

> No, you have missed the point. There is no intermediate register, some
> machines provided a mechanism whereby a++ actually happened in memory
> so:

I'll admit it, between you and arcane architectures I am completely baffled.

Quote:
> load a to register

load r-value a to register or l-value a to register, at least be precise if you're
going to talk like you came from the other side of Alice's looking glass.

Quote:
> increment a // increase item stored in memory

ok, you're incrementing the r-value of a in memory.  I hope this is at least local
memory or does your computer's architecture have the ability to increment an
r-value on disk?

Quote:
> save register to a

You can't seem to follow your own argument, no wonder I'm having problems.  You
apparently mean save register (and we know which register we're talking about) to
l-value c.  Mere child's play for ENIAC is it you're describing?  Just curious.

Quote:
> Note that this allows:

> load address register with address of a
> load 'accumulator' (from memory addressed by register)
> increment contents of memory addressed by register
> load address register with address of c
> save accumulator (to address in address register)

at least you seem to have your logic straightened out.  C thus gives Intel a run
for its money in the "We put the backwards in backwards compatibility" competition.

Quote:
> With such an architecture insisting on saving before incrementing is
> less efficient.

Rah, Hahvahd, rah!
--



Wed, 30 Jul 2003 17:29:51 GMT  
 Sequence point question (function result semantics)

Quote:


> > I'm certainly glad that logic wasn't a deciding factor in writing
> > the C standard!

> Why don't you just learn the difference between an l-value and an
> r-value instead of putting hexes on the standards committee, etc.?

I know the difference between an l-value and an r-value.  The first
characters differ by six in ASCII text.  But thanks so much for your
valuable contribution.

--Jeff Turner

PS.  I don't give my l-value to just anyone.
--



Wed, 30 Jul 2003 17:30:00 GMT  
 Sequence point question (function result semantics)

Quote:



> >  If someone can explain an architecture where this can be implemented more
> > efficiently than doing the assignment first I'd really be very interested to
> learn
>> something new about uP architectures.
> If you take a PowerPC, for example: A good compiler will translate c =
> ++a; into assembler instructions that are equivalent to "c = a + 1; a = a
> + 1; " and not "a = a + 1; c = a; ".

> The PowerPC has no "move register" instruction. It only has an instruction
> "register1 = register2 + constant" and you can pick a constant of 0 to get
> a "move register". If a PowerPC needs the old value of a, it just
> calculates new value - 1 at no extra cost.

Thanks.  It seems to me that every other respondent seems to have missed
the sentence above which I left from my original post.  I didn't mean to be
arrogant or appear to know _everything_ but I do take umbrage at the
responses which failed to mention an architecture where a "good compiler"
would generate such counter-intuitive code.  As the PowerPC is a modern
and powerful architecture, I feel enlightened.  In fact I feel impelled to
understand why it was designed this way.  Thanks again.

--Jeff Turner

PS.  the original statement would translate as "c = a + 0; a = a + 1;"  which
is just the order I expected them to be done in the first place.  Ah, well.
--



Wed, 30 Jul 2003 17:30:32 GMT  
 Sequence point question (function result semantics)

Quote:



> > > void foo()
> > > {
> > >   int a[3] = { 1, 2, 3 };
> > >   int *p = a + 1;

> > >   assert( (-1)[p] != -1[p] );
> > > }

> > OK, I plead ignorance and throw myself on the mercy of the newsgroup.  I
> > know one of them evaluates to 1, which and what does the other evaluate to?
> > Thanks.

> (-1)[p] or essentially p[-1] which is a[0] or 1
> -1[p] is -(1[p]) or -(p[1]) which is -a[2] or -3

If this is an example of logic being the deciding factor in the C standard...

--Jeff Turner

void * logic_of_C89(void)
{
   int *bowel, *p;
   int a[3];

   *p = a + 1;
   *bowel = (-1)[p] > -1[p] ?  (-1)[p] : -1[p];
   return (void *) bowel;

Quote:
}

--



Wed, 30 Jul 2003 17:30:44 GMT  
 Sequence point question (function result semantics)

Quote:



>> > I suppose that since C was developed to be easy for compiler writers
>> > the obvious solution is to write my own compiler that does the
>> > logical thing with c = f(x)++.

>> What on earth might the "logical thing" be?

>> > I'm certainly glad that logic wasn't a deciding factor in writing the
>> > C standard!

>> It was.  You should try it before you knock it.

>OK, since you've been following this thread so closely, you should be able
>to tell me what I think the logical thing is.  OTOH, (apologies to our
>regular listening audience) I think the logical thing is that, as with c =
>x++;  c gets assigned the value of f(x).  f(x) is incremented but since it
>cannot be used henceforth, the incrementation is optimized away.  If you
>find this illogical, then I'm probably correct in assuming you were on the
>standards committee.

     I find it more logical that since ++ can't be applied to a
function call, that it isn't allowed.  Have you considered using
          c=f(x)+1;
?

Quote:
>Logic was not the deciding factor in the C standard.  The biggest factor,

     Maybe that's that "What Jeffrey Turner thinks the logical thing
is was not the deciding factor in the C Standard.".

Quote:
>as far as I can find is to not make 'incorrect' any previously existing C
>code.  Dennis Ritchie himself has admitted as much - certainly in relation

     Sure.  An advantage of this is that any such rule has already
been tested.  It's not a perfect system, but then, there isn't one.

Quote:
>to the relative precedence of &, ==, and &&.  If you want to argue the
>point with Mr. Ritchie, please don't let me stand in your way - I'd just
>like an audio tape for the laughs.

     My complients to our Esteemed Moderator.  It appears Peter is
becoming rather subtle.  This is much more fun than a homework thread.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
--



Fri, 01 Aug 2003 06:09:21 GMT  
 Sequence point question (function result semantics)

Quote:

>      I find it more logical that since ++ can't be applied to a
> function call, that it isn't allowed.  Have you considered using
>           c=f(x)+1;
> ?

This does not give the same results I would expect from c=f(x)++;  if it was
c=++f(x);
then this would be an obvious solution.  Just using c=f(x) would be adequate.
The
question I had - no longer because, well "that's just what the standard says" -
is why
undefined behaviour which does not effect the execution or results of a program
is
allowed to do anything at all including decapitating the operator if the
samurai sword
hardware and driver are installed?

Quote:
> >Logic was not the deciding factor in the C standard.  The biggest factor,

>      Maybe that's that "What Jeffrey Turner thinks the logical thing
> is was not the deciding factor in the C Standard.".

> >as far as I can find is to not make 'incorrect' any previously existing C
> >code.  Dennis Ritchie himself has admitted as much - certainly in relation

>      Sure.  An advantage of this is that any such rule has already
> been tested.  It's not a perfect system, but then, there isn't one.

Yes, it's a reasonable goal, but that doesn't contradict the statement
that the deciding factor was logic, or consistency - just pragmatism.

--Jeff Turner
--



Sat, 02 Aug 2003 04:22:43 GMT  
 Sequence point question (function result semantics)

Quote:

> The question I had ... is why undefined behaviour which does not
> effect the execution or results of a program is allowed to do
> anything at all ...

That's not the situation.  The actual situation is that if the
program does not strictly conform to the requirements of the
standard then it can no longer rely on the guarantees made by
the standard on behalf of implementations that conform to the
standard.  The C standard acts as a treaty point between
programmer and implementor; it established the terms of the
treaty.  Once the treaty has been violated by either side,
the treaty has become inapplicable to the actuality and thus
is no longer a reliable guide for interpreting what happens.

It's the same in essence as the square pegs and round holes
most of us learned about as toddlers -- if you feed something
inappropriate to a system, it might not be able to handle it.
(Sometimes it might be all right, but you have no guarantee.)
--



Sat, 02 Aug 2003 14:42:24 GMT  
 Sequence point question (function result semantics)

Quote:


>>      I find it more logical that since ++ can't be applied to a
>> function call, that it isn't allowed.  Have you considered using
>>           c=f(x)+1;
>> ?

>This does not give the same results I would expect from c=f(x)++;  if it was
>c=++f(x);
>then this would be an obvious solution.  Just using c=f(x) would be adequate.
>The
>question I had - no longer because, well "that's just what the standard says" -
>is why
>undefined behaviour which does not effect the execution or results of a program
>is
>allowed to do anything at all including decapitating the operator if the
>samurai sword
>hardware and driver are installed?

     Because it's undefined.  Any limitation would mean that it wasn't
undefined.

Quote:
>> >Logic was not the deciding factor in the C standard.  The biggest factor,

>>      Maybe that's that "What Jeffrey Turner thinks the logical thing
>> is was not the deciding factor in the C Standard.".

>> >as far as I can find is to not make 'incorrect' any previously existing C
>> >code.  Dennis Ritchie himself has admitted as much - certainly in relation

>>      Sure.  An advantage of this is that any such rule has already
>> been tested.  It's not a perfect system, but then, there isn't one.

>Yes, it's a reasonable goal, but that doesn't contradict the statement
>that the deciding factor was logic, or consistency - just pragmatism.

     It's logical to be pragmatic.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
--



Sun, 03 Aug 2003 05:05:27 GMT  
 
 [ 38 post ]  Go to page: [1] [2] [3]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software