Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #38202 > unrolled thread

rhel 7 and kforth

Back to article view | Back to comp.lang.forth

Contents

  rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 11:20 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-15 19:09 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:13 -0700
      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 04:55 -0700
        Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:08 +0000
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 05:29 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 07:07 -0700
              Re: rhel 7 and kforth franck.bensusan@gmail.com - 2015-04-16 07:44 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:14 -0700
            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 14:02 +0000
              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 08:12 -0700
        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 12:25 -0700
          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:02 -0700
            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:06 -0700
              Re: rhel 7 and kforth foxaudioresearch@gmail.com - 2015-04-16 17:24 -0700
                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 17:39 -0700
                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 17:47 -0700
                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:44 -0700
                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 18:50 -0700
                      Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 19:10 -0700
                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 19:29 -0700
                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-16 20:10 -0700
                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:27 -0700
                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 02:04 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 11:41 +0000
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:45 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:01 +0000
                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:47 -0700
                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:35 -0700
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 10:33 -0700
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 11:15 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 11:47 -0700
                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:51 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:41 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:42 -0700
                                              Re: rhel 7 and kforth "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 09:02 -1000
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 10:53 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-05-03 17:22 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 10:23 +0000
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 00:10 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 17:45 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 13:08 +0000
                                  Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:27 +0000
                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 14:41 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:11 +0000
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-17 15:47 -0700
                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:34 +0000
                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-18 14:09 -0700
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-19 20:31 -0700
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:35 +0000
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:07 -0700
                                              Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:21 +0000
                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 19:34 -0700
                                                  Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 08:36 +0000
                                                    Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 11:36 +0000
                                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:29 +0000
                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:08 +0000
                                Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-19 20:11 -0700
                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 12:05 +0000
                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-22 01:27 +0200
                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-21 18:18 -0700
                                      Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 11:00 +0000
                                        Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 11:28 -0700
                                          Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:34 +0200
                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-24 21:07 -0700
                                            Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:41 +0000
                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-25 10:06 -0700
                                                Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 14:56 +0000
                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-26 20:22 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:02 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 03:59 -0700
                                                      Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 15:45 +0000
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:09 -0400
                                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:55 +0200
                                                      Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:30 -0700
                                                        Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-27 19:44 -0700
                                                        Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 02:03 -0400
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 01:44 -0700
                                                            Re: rhel 7 and kforth Mark Wills <markwills1970@gmail.com> - 2015-04-28 02:44 -0700
                                                            Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 16:47 -0700
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:00 -0700
                                                                Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 17:14 -0700
                                                                  Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 17:59 -0700
                                                                    Re: rhel 7 and kforth Paul Rubin <no.email@nospam.invalid> - 2015-04-28 21:41 -0700
                                                                  Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-29 03:07 +0200
                                                                    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 18:13 -0700
                                                              Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-29 00:07 +0000
                                                        Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 22:22 +0200
                                                          Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 14:23 -0700
                                                            Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 23:51 +0200
                                                              Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-28 16:50 -0700
                                                            Re: rhel 7 and kforth David Thompson <dave.thompson2@verizon.net> - 2015-05-10 12:24 -0400
                                                  Re: rhel 7 and kforth mhx@iae.nl - 2015-04-26 22:16 -0700
                                                    Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:19 +0000
                                                      Re: rhel 7 and kforth mhx@iae.nl - 2015-04-27 04:03 -0700
                                                      Re: rhel 7 and kforth "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-27 18:21 -0400
                                          Re: rhel 7 and kforth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:46 +0000
                                      Re: rhel 7 and kforth Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-23 16:46 +0200
                          Re: rhel 7 and kforth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:35 +0000
                            Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:43 -0700
    Re: rhel 7 and kforth krishna.myneni@ccreweb.org - 2015-04-17 08:41 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#38248

On Thursday, April 16, 2015 at 9:10:31 PM UTC-5, Paul Rubin wrote:
> krishna.myneni@ccreweb.org writes:
> >    *sp-- = *(sp + 1)
> > This lays out a pretty specific sequence for access and
> > assignment. Are you saying that the LHS can be (partially) evaluated
> > before the RHS?
> 
> Yes, I believe so.  The condition that says thing A must be evaluated
> before thing B is the presence of a sequence point between A and B.  And
> it's explicit that an assignment operator (the = sign) does not create a
> sequence point.  See the paragraph in that FAQ starting
> 
>     The second sentence can be quite difficult to understand. It turns out
>     that it disallows code like
>             a[i] = i++
>     ...
> 
> for more discussion.  This is similar, I think.

Hmm... I need to think about this some more. In the case of the statement,

  a[i] = i++;

the rationale for making it an invalid statement is, "there's no good way to define--either for our understanding or the compiler's--whether the access should take place before or after the incremented value is stored."

It's not clear that the same rationale applies to,

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

but, maybe it does. To me, the statement above appears free of ambiguity since sp is not being modified on the RHS.

Krishna

[toc] | [prev] | [next] | [standalone]

#38249

On Thursday, April 16, 2015 at 9:29:52 PM UTC-5, krishna...@ccreweb.org wrote:
> On Thursday, April 16, 2015 at 9:10:31 PM UTC-5, Paul Rubin wrote:
> > krishna.myneni@ccreweb.org writes:
> > >    *sp-- = *(sp + 1)
> > > This lays out a pretty specific sequence for access and
> > > assignment. Are you saying that the LHS can be (partially) evaluated
> > > before the RHS?
> > 
> > Yes, I believe so.  The condition that says thing A must be evaluated
> > before thing B is the presence of a sequence point between A and B.  And
> > it's explicit that an assignment operator (the = sign) does not create a
> > sequence point.  See the paragraph in that FAQ starting
> > 
> >     The second sentence can be quite difficult to understand. It turns out
> >     that it disallows code like
> >             a[i] = i++
> >     ...
> > 
> > for more discussion.  This is similar, I think.
> 
> Hmm... I need to think about this some more. In the case of the statement,
> 
>   a[i] = i++;
> 
> the rationale for making it an invalid statement is, "there's no good way to define--either for our understanding or the compiler's--whether the access should take place before or after the incremented value is stored."
> ...

Interestingly, gcc 4.9 does not complain at all about a statement like

   a[i] = i++;

It compiles and executes without problem, per the example below.

Krishna


=======
/*
Check gcc 4.8/4.9 compilation of following code.

Compile with "gcc -o miscomp3 miscomp3.c"
*/

#include <stdio.h>
int main()
{
        unsigned int  stk[10];
	int i;
	
	for (i = 0; i < 9; ) {
           stk[i] = i++;
           printf( "%d %d\n", i, stk[i] );
	}

        return(0);
}
==========

$ gcc -o miscomp3 miscomp3.c
$ ./miscomp3
1 0
2 1
3 2
4 3
5 4
6 5
7 6
8 7
9 8
$

========

[toc] | [prev] | [next] | [standalone]

#38250

krishna.myneni@ccreweb.org writes:
> Interestingly, gcc 4.9 does not complain at all about a statement like
>    a[i] = i++;
> It compiles and executes without problem, per the example below.

The statement has undefined semantics, which means the compiler can do
whatever it wants, including doing what you expected it to do, as it did
there.  It's just not -required- to do what you expected, and the
behavior can change from one compiler or compilation to another.  This
is one of the reasons C sucks so bad.  

If you compile with -Wall you should get a warning message about that
operation.

[toc] | [prev] | [next] | [standalone]

#38260

On Thursday, April 16, 2015 at 10:27:17 PM UTC-5, Paul Rubin wrote:
> krishna.myneni@ccreweb.org writes:
> > Interestingly, gcc 4.9 does not complain at all about a statement like
> >    a[i] = i++;
> > It compiles and executes without problem, per the example below.
> 
> The statement has undefined semantics, which means the compiler can do
> whatever it wants, including doing what you expected it to do, as it did
> there.  It's just not -required- to do what you expected, and the
> behavior can change from one compiler or compilation to another.  This
> is one of the reasons C sucks so bad.  

Yes, I understand the distinction. But, it begs the question, is there any existing C compiler which does anything different from gcc with regard to compiling, a[i] = i++ ? If not, it is absurd to write a standard that breaks universal practice, for the sake of some theoretical possibility of improved efficiency.

After reflecting a bit further, I don't buy the argument given at the link for invalidating the statement, 

   a[i] = i++;

The distinction between the prefix and suffix use of increment and decrement operators in C is well-known and has been in use for many, many years. I don't know if it goes all the way back to Kernighan and Ritchie (the K&R book). But, the statement is unambiguous if one considers that i++ on the rhs means to use "i" first in the expression, then increment it. This was certainly common practice among C programmers for many many years. I don't know if the ISO C standard revoked the distinction between prefix and suffix use of the increment and decrement operators, but it seems like it has effectively done so.


> 
> If you compile with -Wall you should get a warning message about that
> operation.

Yes, I see the compiler warnings for both examples with -Wall (output below). For the moment, I will have to make a band-aid patch for kForth, to deal with the (absurd) compiler problems of gcc 4.8 and higher. The better solution, for the next release, will be to rely less on the C compiler, and move the functions to pure assembly language implementations.

Krishna

===

$ gcc -o miscomp3 -Wall miscomp3.c
miscomp3.c: In function 'main':
miscomp3.c:14:22: warning: operation on 'i' may be undefined [-Wsequence-point]
            stk[i] = i++;

and

$ gcc -o miscomp -Wall miscomp.c
miscomp.c: In function 'main':
miscomp.c:14:12: warning: operation on 'sp' may be undefined [-Wsequence-point]
         *sp-- = *(sp + 1);

[toc] | [prev] | [next] | [standalone]

#38270

krishna.myneni@ccreweb.org writes:
>On Thursday, April 16, 2015 at 10:27:17 PM UTC-5, Paul Rubin wrote:
>Yes, I understand the distinction. But, it begs the question, is there any =
>existing C compiler which does anything different from gcc with regard to c=
>ompiling, a[i] =3D i++ ? If not, it is absurd to write a standard that brea=
>ks universal practice, for the sake of some theoretical possibility of impr=
>oved efficiency.

Yes, that is absurd, and I believe that they (the C89 standards
people) did not do that (instead they did not define such things for
other reasons such as the existence of compiler/target combinations
that behaved differently).  But the defenders of miscompilers often
claim that the theoretical possibility of improved efficiency is the
reason for "undefined behaviour", and the miscompiler maintainers
certainly take that view when they add another miscompilation to their
compiler.

>After reflecting a bit further, I don't buy the argument given at the link =
>for invalidating the statement,=20
>
>   a[i] =3D i++;
>
>The distinction between the prefix and suffix use of increment and decremen=
>t operators in C is well-known and has been in use for many, many years. I =
>don't know if it goes all the way back to Kernighan and Ritchie (the K&R bo=
>ok). But, the statement is unambiguous if one considers that i++ on the rhs=
> means to use "i" first in the expression, then increment it.

Even then it is not obvious whether the "i" in "a[i]" uses the value
of i before or after the increment.

> This was cert=
>ainly common practice among C programmers for many many years. I don't know=
> if the ISO C standard revoked the distinction between prefix and suffix us=
>e of the increment and decrement operators, but it seems like it has effect=
>ively done so.

No, the distiction is still there: i++ returns the value of i before
the increment, ++i returns the value of i after the increment.  The C
standard does not tell what other uses of i in the expression return,
though.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38302

On Friday, April 17, 2015 at 7:10:15 AM UTC-5, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
...
> >After reflecting a bit further, I don't buy the argument given at the link 
> >for invalidating the statement,
> >
> >   a[i] =3D i++;
...
> >But, the statement is unambiguous if one considers that i++ on the rhs=
> > means to use "i" first in the expression, then increment it.
> 
> Even then it is not obvious whether the "i" in "a[i]" uses the value
> of i before or after the increment.
> 

If the standard prescribed instantiation of all occurences of "i" in the expression to its value prior to the expression, then, I think there is no ambiguity. But the restriction that "i" can be changed only once in the expression must still be enforce. Maybe such a prescription has other side effects I can't see.

Krishna

[toc] | [prev] | [next] | [standalone]

#38339

krishna.myneni@ccreweb.org writes:
>If the standard prescribed instantiation of all occurences of "i" in the ex=
>pression to its value prior to the expression, then, I think there is no am=
>biguity.

Sure, that would be one way to resolve the ambiguity.  But I guess
that there are a number of compiler/target combinations that use
autoincrement addressing modes, and that don't behave like that in all
cases.  So if you standardize this case the way you propose, you would
break the programs that rely on the behaviour of these compiler/target
combinations.

> But the restriction that "i" can be changed only once in the expre=
>ssion must still be enforce.

Such cases could be disambuguated in the same way.  I.e.,

r = ++i * ++i * i++ * i++

would be equivalent to

++i; ++i; r=i*i*i*i; i++; i++;

It's just that there is probably no common practice among C compilers
for this kind of stuff and never has been.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38274

krishna.myneni@ccreweb.org writes:
> is there any existing C compiler which does anything different from
> gcc with regard to compiling, a[i] = i++ ? 

It's difficult to tell whether even GCC 4.9 always does it the same way,
or whether all existing versions of GCC do it the same way.  So you
can't count on it. 

> If not, it is absurd to write a standard that breaks universal
> practice, 

There's no such thing as universal practice (literally everybody does
it), there's only widespread practice, common practice, uncommon, etc.
Any choice is going to annoy someone.  The standards committee is tasked
by the C community to make these choices and trade-offs and produce a
document, the standard.  After that, in the C world, such questions are
resolved by the standard being the final word.  

As far as I know, this process works the way it's supposed to: the
committee doesn't impose its weird stupid choices on a wider C community
that wants something different.  The committee really does do what the C
community wants it to do.  So those decisions you find objectionable are
actually what the C community wants, or at least wanted back at the time
the decisions were made.  One could reasonably say the computing
atmosphere has changed since then, so maybe the decisions should be
revisited in some forthcoming revision, but we don't have that right
now.

> for the sake of some theoretical possibility of improved efficiency.

I don't think it was a only theoretical.  The idea was to allow
compilers to generate faster code on machines with parallel execution
units, and some compilers (I think including for the Cray supercomputer
of the 1980's) really did that.  What to do with "a[i] = i++;" was a
topic of considerable discussion back then.  The outcome wasn't an
oversight or accident or a concession to some vendor who was too lazy to
fix his compiler.  Given a choice between doing X and getting fewer
bugs, or doing Y and getting faster code, they chose faster code on the
theory that C programmers are supposed to be hypervigilant.  One finds a
somewhat similar attitude in statements like "Forth is an amplifier".

> the statement is unambiguous if one considers that i++ on the
> rhs means to use "i" first in the expression, then increment it. 

Sure, and 2+3=9 if one considers that 3=7.  C is simply not defined that
way.  "Do X, then do Y" in C jargon is phrased as "there is a sequence
point between x and y".  But we know that the assignment operator does
not introduce a sequence point.  Therefore the compiler is not required
to use i on the lhs before incrementing it on the rhs.  Another way to
look at it is that the compiler is free to treat "a[i] = i++" as

  int i; ...
  int f() { return i++; }
  a[i] = f();

and in that case, the increment obviously happens before the subscript
dereference.

> This was certainly common practice among C programmers for many many
> years.

> I don't know if the ISO C standard revoked the distinction between
> prefix and suffix use of the increment and decrement operators, but it
> seems like it has effectively done so.

No it hasn't.  If you say "x = i++", x gets the old version of i.  You
only don't know whether the memory location holding i has already been
incremented, at the time that the old value is copied to the location
holding x.  In the "a[i]=i++" case, that ambiguity matters because you
don't know if the increment has happened when the location of a[i] is
computed.

> Yes, I see the compiler warnings for both examples with -Wall (output
> below). For the moment, I will have to make a band-aid patch for
> kForth, to deal with the (absurd) compiler problems of gcc 4.8 and
> higher. 

It's not a compiler problem, it's a problem with C itself, which in turn
stems from the optimization-crazed C culture that doesn't consider it to
be a problem.

More recently maybe there has been some movement about this, because the
economics of computing have changed since these decisions were made,
and we've seen the consequences of lots of bugs caused by C hazards.
http://blog.regehr.org/archives/1180 might be of interest.

> The better solution, for the next release, will be to rely less on the
> C compiler, and move the functions to pure assembly language
> implementations.

That's one approach, but I think it's more accurate to say it's relying
less on your knowledge of the C language.

[toc] | [prev] | [next] | [standalone]

#38278

On Friday, April 17, 2015 at 9:47:16 AM UTC-5, Paul Rubin wrote:
> krishna.myneni@ccreweb.org writes:
...
> > If not, it is absurd to write a standard that breaks universal
> > practice, 
> 
> There's no such thing as universal practice (literally everybody does
> it), there's only widespread practice, common practice, uncommon, etc.
> Any choice is going to annoy someone.  ...

I'm not claiming there is universal practice for compiling this expression. In my experience with C compilers, I haven't seen any exceptions. But, I haven't seen everything.

> 
> As far as I know, this process works the way it's supposed to: the
> committee doesn't impose its weird stupid choices on a wider C community
> that wants something different.  The committee really does do what the C
> community wants it to do.  So those decisions you find objectionable are
> actually what the C community wants, or at least wanted back at the time
> the decisions were made.  One could reasonably say the computing
> atmosphere has changed since then, so maybe the decisions should be
> revisited in some forthcoming revision, but we don't have that right
> now.
>

I'm willing to be convinced of the necessity in breaking past practices that cause unforeseen problems. Obviously, I'm peeved at having my code unnecessarily broken by poor choices made by the compiler. But, the actual fix is relatively simple. I can't see that the fix was justified by the standard.


> > the statement is unambiguous if one considers that i++ on the
> > rhs means to use "i" first in the expression, then increment it. 
> 
> Sure, and 2+3=9 if one considers that 3=7.  C is simply not defined that
> way.  "Do X, then do Y" in C jargon is phrased as "there is a sequence
> point between x and y".  But we know that the assignment operator does
> not introduce a sequence point.  Therefore the compiler is not required
> to use i on the lhs before incrementing it on the rhs.  Another way to
> look at it is that the compiler is free to treat "a[i] = i++" as
> 
>   int i; ...
>   int f() { return i++; }
>   a[i] = f();
> ...

The standard could have stated that the expression, "a[i] = i++;" uses the instantaneous value of i just before the expression, for every reference of i. But, perhaps this leads to consistency problems with other expressions.



> > Yes, I see the compiler warnings for both examples with -Wall (output
> > below). For the moment, I will have to make a band-aid patch for
> > kForth, to deal with the (absurd) compiler problems of gcc 4.8 and
> > higher. 
> 
> It's not a compiler problem, it's a problem with C itself, which in turn
> stems from the optimization-crazed C culture that doesn't consider it to
> be a problem.
> 

I'll still argue that it is a compiler problem, because the compiler implementers could have chosen to default to the past behavior to avoid breaking older code, since the standard declares it to be undefined, particularly in the case of,

  *sp-- = *(sp+1)


...
> > The better solution, for the next release, will be to rely less on the
> > C compiler, and move the functions to pure assembly language
> > implementations.
> 
> That's one approach, but I think it's more accurate to say it's relying
> less on your knowledge of the C language.

I agree with your last statement.

Krishna

[toc] | [prev] | [next] | [standalone]

#38285

krishna.myneni@ccreweb.org writes:
> I'm not claiming there is universal practice for compiling this
> expression. In my experience with C compilers, I haven't seen any
> exceptions. 

You mean exceptions with a[i]=i++?  How many compilers did you try that
with?  If you mean exceptions with *sp-- = *(sp + 1), obviously you did
just encounter a different compilation than what you expected.  

> Obviously, I'm peeved at having my code unnecessarily broken by poor
> choices made by the compiler.

Whether it was a poor choice is necessarily somewhat subjective.  The
compiler writers take the view that the good-vs-poor decision was made
during the standardization process and if it was a poor choice, the
standard wouldn't have allowed it.  So when they're left with a set of
options neutrally allowed by the standard, they naturally pick the one
that generates the fastest code that they can.  If they generated
different (slower) code earlier, that only means last year's optimizers
were less advanced than this year's.

> But, the actual fix is relatively simple. I can't see that the fix was
> justified by the standard.

Did you micro-benchmark both versions?  If the "broken" code was faster,
that is the justification.

> The standard could have stated that the expression, "a[i] = i++;" uses
> the instantaneous value of i just before the expression, for every
> reference of i. But, perhaps this leads to consistency problems with
> other expressions.

I dunno about consistency problems but I can tell you from having gotten
in arguments with those guys, the #1 thing they cared about was fast
code, and they opted for it over an "err on the side of caution"
approach.  I'd agree that this has caused problems that are being
recognized somewhat in hindsight (one reason I'm terrified of anything
written in C today).  But, the choices made back then were at least
arguably a sane fit for the knowledge and priorities that existed at the
time.

GCC has various command line options to disable some of the more
surprising optimizations and I like Regehr's proposal of a less
aggressive dialect, that could be enabled by a single option or even
made the default.

>> > Yes, I see the compiler warnings for both examples with -Wall 

It's probably worth compiling the whole program with -Wall and checking
all the messages for other problems.  -Wall has apparently gotten pretty
good.

[toc] | [prev] | [next] | [standalone]

#38286

On Friday, April 17, 2015 at 12:33:51 PM UTC-5, Paul Rubin wrote:
> krishna.myneni@ccreweb.org writes:
> > I'm not claiming there is universal practice for compiling this
> > expression. In my experience with C compilers, I haven't seen any
> > exceptions. 
> 
> You mean exceptions with a[i]=i++?  How many compilers did you try that
> with?  If you mean exceptions with *sp-- = *(sp + 1), obviously you did
> just encounter a different compilation than what you expected.  
> 

A poor choice of words. I don't mean either of the two expressions above, but for pointer-arithmetic based expressions in general, I don't recall finding C compilers giving different results. This is roughly from about 1990 to the present. Compilers I have used included Microsoft Visual C, Borland Turbo C, Symantec C/C++, GCC, and various micro-controller C compilers. Nowadays, I don't have immediate access to a wide range of compilers, so I can't check the compilation of either of those two specific expressions. It would be an interesting exercise to compile and document the behavior of the two test programs, miscomp.c and miscomp3.c, given in this thread, on different compilers and present the results.

> > Obviously, I'm peeved at having my code unnecessarily broken by poor
> > choices made by the compiler.
> 
> Whether it was a poor choice is necessarily somewhat subjective.  The
> compiler writers take the view that the good-vs-poor decision was made
> during the standardization process and if it was a poor choice, the
> standard wouldn't have allowed it.  So when they're left with a set of
> options neutrally allowed by the standard, they naturally pick the one
> that generates the fastest code that they can. ...
> 

No, I don't think it is the natural choice to pick the faster code option. In my opinion, it is the unwise choice to make when there is a significant possibility of breaking existing code.

...


> It's probably worth compiling the whole program with -Wall and checking
> all the messages for other problems.  -Wall has apparently gotten pretty
> good.

That, I have learned the hard way, is a very good piece of advice, for as long as a C compiler is involved with building a Forth system, or any other application with C code.

Krishna

[toc] | [prev] | [next] | [standalone]

#38288

krishna.myneni@ccreweb.org writes:
> I don't recall finding C compilers giving different results. This is
> roughly from about 1990 to the present.

1990 was 25 years ago, which is multiple glacial epochs in computer
technology.  These optimizations surprising people started to become a
significant issue around 5 years ago I think.  Regehr's blog has a bunch
of entries about it and he has written a paper or two.  He's suggested
redefining C or defining a safer subset that has some hazards removed,
at some cost in code speed.  I remember one commenter responding that
those hazards were the only reason to use C any more, because if you
were willing to take a slight slowdown you could just use a safer
language.

> No, I don't think it is the natural choice to pick the faster code
> option. In my opinion, it is the unwise choice to make when there is a
> significant possibility of breaking existing code.

Their reaction would likely be that they didn't break existing code--the
existing code was already broken, and improvements in compiler
technology finally made the latent defect visible.  So you should be
thanking them for finding your bugs ;-).

[toc] | [prev] | [next] | [standalone]

#38303

On Friday, April 17, 2015 at 1:47:36 PM UTC-5, Paul Rubin wrote:
> ... These optimizations surprising people started to become a
> significant issue around 5 years ago I think.  Regehr's blog has a bunch
> of entries about it and he has written a paper or two...

I haven't had any big surprises from the compiler until now, and kForth began in 1998. But the compilers are already a few years old. 

I was looking at some of the links on Regehr's blog. Interesting and concerning. I expect there will be a market for people who know the ISO C standard well, to clean up after major software failures created by programmers who are not so familiar with it.

> So you should be thanking them for finding your bugs ;-).

Or detaching myself from C ... But, thanks for pointing out the relevant parts of the standard!

Krishna

[toc] | [prev] | [next] | [standalone]

#38343

Paul Rubin <no.email@nospam.invalid> writes:
>krishna.myneni@ccreweb.org writes:
>> I don't recall finding C compilers giving different results. This is
>> roughly from about 1990 to the present.
>
>1990 was 25 years ago, which is multiple glacial epochs in computer
>technology.  These optimizations surprising people started to become a
>significant issue around 5 years ago I think.

A little earlier than that, but yes.  And that demonstrates that it's
the fault of the compiler maintainers, not the C standard.  C89 is now
26 years old, i.e., glacial in your view, and it had all the holes
that the C compiler maintainers use as justifications for their
miscompilations, yet the C compiler maintainers of those days, such as
Richard Stallman, knew how to optimize without breaking lots of code.

>I remember one commenter responding that
>those hazards were the only reason to use C any more, because if you
>were willing to take a slight slowdown you could just use a safer
>language.

This commenter was totally wrong.  Unfortunately, I could not longer
point out how wrong he was and why in the comments section, because
one could no longer post comments when I saw that blog entry.

>Their reaction would likely be that they didn't break existing code--the
>existing code was already broken, and improvements in compiler
>technology finally made the latent defect visible.  So you should be
>thanking them for finding your bugs ;-).

Yes, that would be their reaction, which shows that they either don't
know how people program, or they pretend not to know it.  Not sure
which is worse.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38573

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>These optimizations surprising people started to become a significant
>>issue around 5 years ago I think.
> A little earlier than that, but yes.  And that demonstrates that it's
> the fault of the compiler maintainers, not the C standard.

The standard was written with those optimizations in mind, but they
didn't start making their way into the popular compilers until the
implementations became advanced enough to include them.  That also
partly results from hardware improvements in the past decades making it
possible for compilers to do more stuff in a compilation run, and making
development easier in general.  I'd be curious to know whether the
optimizations were already present in the Cray compilers of the
1980's-90's.

> C compiler maintainers of those days, such as Richard Stallman, knew
> how to optimize without breaking lots of code.

I might ask him about this next time I get a chance.  I know that he is
skeptical of the concept of writing reliable programs in C these days,
probably for about the same reasons as me.

>>I remember one commenter [on Regehr's blog] responding
> This commenter was totally wrong.  Unfortunately, I could not longer
> point out how wrong he was and why in the comments section, because
> one could no longer post comments when I saw that blog entry.

A typical reason for closing old comment sections is to avoid having to
deal with automated spam in them, on the basis that on-topic discussion
has mostly quieted down.  People still read that entry, so if you can
write a reasonably informative response backed by evidence, it might be
worth sending it to Regehr and asking him to post it.

> Yes, that would be their reaction, which shows that they either don't
> know how people program, or they pretend not to know it. 

The current entry on Regehr's blog mentions someone is working on a
precise semantics of C the way people actually use it.  That might be a
reasonable thing for compiler writers to target.

[toc] | [prev] | [next] | [standalone]

#38578

On 4/24/15 8:42 AM, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> These optimizations surprising people started to become a significant
>>> issue around 5 years ago I think.
>> A little earlier than that, but yes.  And that demonstrates that it's
>> the fault of the compiler maintainers, not the C standard.
>
> The standard was written with those optimizations in mind, but they
> didn't start making their way into the popular compilers until the
> implementations became advanced enough to include them.  That also
> partly results from hardware improvements in the past decades making it
> possible for compilers to do more stuff in a compilation run, and making
> development easier in general.  I'd be curious to know whether the
> optimizations were already present in the Cray compilers of the
> 1980's-90's.
>
>> C compiler maintainers of those days, such as Richard Stallman, knew
>> how to optimize without breaking lots of code.
>
> I might ask him about this next time I get a chance.  I know that he is
> skeptical of the concept of writing reliable programs in C these days,
> probably for about the same reasons as me.
>
>>> I remember one commenter [on Regehr's blog] responding
>> This commenter was totally wrong.  Unfortunately, I could not longer
>> point out how wrong he was and why in the comments section, because
>> one could no longer post comments when I saw that blog entry.
>
> A typical reason for closing old comment sections is to avoid having to
> deal with automated spam in them, on the basis that on-topic discussion
> has mostly quieted down.  People still read that entry, so if you can
> write a reasonably informative response backed by evidence, it might be
> worth sending it to Regehr and asking him to post it.
>
>> Yes, that would be their reaction, which shows that they either don't
>> know how people program, or they pretend not to know it.
>
> The current entry on Regehr's blog mentions someone is working on a
> precise semantics of C the way people actually use it.  That might be a
> reasonable thing for compiler writers to target.
>

I just love it when these discussions about the faults of C standards 
and compilers break out. It's reassuring to be reminded that Forth isn't 
alone in struggling with these issues!

Actually, I knew that. In the early years of the Forth94 effort I 
received mailings from Fortran and C TCs, which were generating 
firestorms of wrath leading to massive law suits in the late 80's. 
Fortunately, we were able to avoid that.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#38766

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> A little earlier than that, but yes.  And that demonstrates that it's
>> the fault of the compiler maintainers, not the C standard.
>
>The standard was written with those optimizations in mind

You repeat that claim without supplying evidence.  As mentioned,
P.J.Plaugers articles explaining what happened in the C89 committee
contained nothing of the kind.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38805

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>The standard was written with those optimizations in mind
> You repeat that claim without supplying evidence. 

Here are some posts from committee member Doug Gwyn, concerning a UB
when a variable is read and modified without an intervening sequence
point other than with autoincrement:

1. He explains that the UB is to enable special optimizations on vector
machines:

https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/7fSMidjs044J

    ...if a swath of a vector is being operated on it might be that
    nominally the "same" element has different values at different
    places in the pipeline.  It is in order to avoid forcing the
    generated code to have to pessimistically flush pipelines etc. (nor
    to have to add a preliminary test of whether j == a[j]) that the
    default policy is to not require such pessimism by the
    implementation.

2. He says it's fine for a given code fragment to be UB as long as the
standard gives the programmer a way to get the desired sequencing:

https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/L9blvboMpL0J

    Even if it is "obvious" by Tom St Denis thought he meant by that
    source, in a real implementation one can have register caching,
    vector instructions, etc. which all could make the fast code that
    almost every user would expect to be generated produce an effect
    different from what Tom thought it should be.  The license for
    implementations to be *efficient* is important in the success of C
    as a systems programming language, and in order to prevent excessive
    liberties being taken by code optimizers the standard provides ways
    for programmers to *portably* and *reliably* express what they
    intend; the most notable tool in this regard being the sequence
    point guarantees.

3. Here he's explicit, C's philosophy is to generate fast code for
careful users:

https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/xgVrnRbpV84J

    Rather than penalize *everybody* by default, we support the best
    code generation for the careful user by default, and when a more
    strict order of evaluation is necessary for the correctness of some
    algorithms there are ways for those programmers to obtain it.

He was always writing stuff like that, and I got into long discussions
with him that are now hard to find because of the crappy new interface
of Google Groups.  His basic attitude was that C programmers were
supposed to use NASA-like processes to ensure freedom from UB and other
errors.  He blamed the whole phenomenon of buffer overruns on failure to
use those processes.
    
> As mentioned, P.J.Plaugers articles explaining what happened in the
> C89 committee contained nothing of the kind.

Are these articles online?  Did they discuss the issue of UB at all?

[toc] | [prev] | [next] | [standalone]

#38809

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>The standard was written with those optimizations in mind
>> You repeat that claim without supplying evidence. 
>
>Here are some posts from committee member Doug Gwyn, concerning a UB
>when a variable is read and modified without an intervening sequence
>point other than with autoincrement:
>
>1. He explains that the UB is to enable special optimizations on vector
>machines:
>
>https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/7fSMidjs044J

Sorry, that link just tells me "Um Google Groups Discussions nutzen zu
können, aktivieren Sie JavaScript in Ihren Browsereinstellungen und
aktualisieren Sie dann diese Seite.".  Could you provide the
Message-Ids so that I can use it with an NNTP server or a more useful
web service than google (E.g.,
<http://reusenet.froehlich.priv.at/posting.php?msgid=l53gv8.2dc.1@msgid.suchanek.de>
or <http://al.howardknight.net/>).

>    ...if a swath of a vector is being operated on it might be that
>    nominally the "same" element has different values at different
>    places in the pipeline.  It is in order to avoid forcing the
>    generated code to have to pessimistically flush pipelines etc. (nor
>    to have to add a preliminary test of whether j == a[j]) that the
>    default policy is to not require such pessimism by the
>    implementation.

I don't quite understand what he is referring to here, but it seems to
me that all operations from the source program occur in the target
program.  This is certainly not about "optimizing" a bounded loop into
an endless loop.

>2. He says it's fine for a given code fragment to be UB as long as the
>standard gives the programmer a way to get the desired sequencing:
>
>https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/L9blvboMpL0J
>
>    Even if it is "obvious" by Tom St Denis thought he meant by that
>    source, in a real implementation one can have register caching,
>    vector instructions, etc. which all could make the fast code that
>    almost every user would expect to be generated produce an effect
>    different from what Tom thought it should be.  The license for
>    implementations to be *efficient* is important in the success of C
>    as a systems programming language, and in order to prevent excessive
>    liberties being taken by code optimizers the standard provides ways
>    for programmers to *portably* and *reliably* express what they
>    intend; the most notable tool in this regard being the sequence
>    point guarantees.

Again, it seems that he is not saying that the intention of the C
standard is to "optimize" bounded loops into endless loops.  It is
interesting that he writes that the sequence point guarantees are a
tool to reliably express intent, because nasal demon "optimizations"
do not give a damn about sequence points.  I am sure gcc will
miscompile "x1=x+1; if (x1<=x)" just as happily as "if (x+1<=x)".

>3. Here he's explicit, C's philosophy is to generate fast code for
>careful users:
>
>https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/xgVrnRbpV84J
>
>    Rather than penalize *everybody* by default, we support the best
>    code generation for the careful user by default, and when a more
>    strict order of evaluation is necessary for the correctness of some
>    algorithms there are ways for those programmers to obtain it.

This is again about order of evaluation, not about "optimizing" a
bounded loop into an endless loop.

>His basic attitude was that C programmers were
>supposed to use NASA-like processes to ensure freedom from UB and other
>errors.

I don't know what processes NASA uses, but if they are significantly
more expensive than the usual development processes (using testing for
QA), then it is an unrealistic attitude in many cases.

>> As mentioned, P.J.Plaugers articles explaining what happened in the
>> C89 committee contained nothing of the kind.
>
>Are these articles online?  Did they discuss the issue of UB at all?

I doubt that they are online; but you could go to your library and dig
up issues of "Computer Language" from the late 1980s.

I don't remember any mentioning of undefined behaviour, but it may
have occured; portability issues were certainly discussed.  I do
remember an explanation about why the committee standardized the
length of identifiers.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38461

Paul Rubin wrote:

> krishna.myneni@ccreweb.org writes:
>> I don't recall finding C compilers giving different results. This is
>> roughly from about 1990 to the present.
> 
> 1990 was 25 years ago, which is multiple glacial epochs in computer
> technology.  These optimizations surprising people started to become a
> significant issue around 5 years ago I think.  Regehr's blog has a bunch
> of entries about it and he has written a paper or two.  He's suggested
> redefining C or defining a safer subset that has some hazards removed,
> at some cost in code speed.  I remember one commenter responding that
> those hazards were the only reason to use C any more, because if you
> were willing to take a slight slowdown you could just use a safer
> language.

There are parts in C, where the lack of safety net corresponds to speed, 
e.g. the fact that array boundaries or overflows are not checked: This is an 
operation that costs time.

I'm completely happy with that, because Forth doesn't check that stuff, 
either, so C's semantics seem to map 1:1 to Forth's semantics.  But I 
learned that no, that's not the case.

E.g. if I do a + in Forth on a two's complement system, it will wrap around, 
because + is defined for both signed and unsigned numbers, and what's an 
overflow for a signed number is a normal operation for the unsigned number 
and vice versa.  So Forth has -fwrapv behavior; C has it only with this GCC 
flag (introduced in GCC 3.4, but 2.95.2 already miscompled code which used 
that wrapv behaviour previously found in GCC).

That's one topic.  The other topic is about order, here with things like

*sp-- = sp[1]; // over

My expectation as Forth programmer is that you first do the right hand side, 
and then the left hand side, because the Forth equivalence is

1 cells sp @ + @ -1 sp +! sp @ !

Funny enough, that is *exactly* what K&R's compiler did, including 
converting it to postfix threaded code.

Performance?  That's an expression with a well-defined semantics in K&R C, 
all you are allowed for optimization purposes is to shuffle around the 
operations, allocate registers and such, to make it execute faster.  What an 
optimizing compiler is *not* allowed is to change the semantics.  So, let's 
assume a RISC processor, you are allowed to allocate SP into a register, and 
then do (32 bit processor):

mov 4(sp), tmp
mov tmp, -4(sp)
add #-4, sp

Modifying sp in between the two move operations would create an AGU pipeline 
bubble, and therefore should be avoided for speed reasons.  So all the 
actual pointer updates are accumulated and deferred; if you have more 
expressions like that, e.g.

2dup:
*sp-- = sp[1];
*sp-- = sp[1];

you generate code like that:

mov 4(sp), tmp1
mov 0(sp), tmp2
mov tmp1, -4(sp)
mov tmp2, -8(sp)
add #-8, sp

So you see, the pointer operations do affect the offsets of the pointer, but 
not the actual register until it needs to.  That's a very typical 
optimization.  If you have this tool for optimization, then the actual 
interpretation of the order of right hand, left hand and such doesn't matter 
- for speed.  So the only argument left which semantics to use is user 
happyness.  And the users are usually way more happy if their code is not 
broken.

IMHO the most obvious misconception of the C developers is that "undefined = 
fast".  That's not the point.  When you write a program, you want to express 
your algorithms, so it has to be well-defined.  If you don't check array 
bounds to gain speed, your compiler still can be well-defined: a[100] of an 
int a[something]; array is accessing the memory location 100 ints further 
from the start of a, no matter how big that "something" really is.  That's 
defined behavior, undefined is only what kind of data there is at a[100], 
because if something<100, it's certainly not part of the array a[], and the 
memory layout of the rest of the system isn't easy to predict.

A standard body of course simply writes "it's undefined", because vendor IBM 
AS/400 actually does implement array boundary checking even for C.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.forth

csiph-web