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

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

Average swaps per word?

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

Contents

  Average swaps per word? trans <transfire@gmail.com> - 2016-11-08 22:03 -0800
    Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-08 20:20 -1000
    Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-09 08:16 +0000
    Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-09 03:34 -0500
      Re: Average swaps per word? trans <transfire@gmail.com> - 2016-11-09 02:53 -0800
        Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-09 11:50 -0500
          Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-09 18:37 +0000
            Re: Average swaps per word? Harold <hzrabbie@gmail.com> - 2016-11-10 16:28 -0800
              Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-11 17:51 +0000
              Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 12:23 +0000
                Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:09 +0100
                  Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-13 14:55 +0000
                    Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 20:34 +0100
                      Re: Average swaps per word? Paul Rubin <no.email@nospam.invalid> - 2016-11-13 11:43 -0800
                        Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-13 16:58 -0800
                          Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-14 16:41 +0100
                            Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-14 16:38 -0800
                        Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:42 +0000
                          Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-14 16:39 -0500
                            Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:40 +0000
                              Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:10 +0100
                                Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:14 +0000
                                  Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-20 18:16 +0100
                                    Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 10:29 +0000
                                      Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-22 15:54 +0100
                                      Re: Average swaps per word? James Kuyper <jameskuyper@verizon.net> - 2016-11-22 11:50 -0500
                                        Re: Average swaps per word? raltbos@xs4all.nl (Richard Bos) - 2016-11-24 17:27 +0000
                          Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-15 03:55 -0600
                            Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-15 17:49 -0500
                              Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-16 02:59 -0600
                              Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 13:07 +0000
                            Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-16 22:57 +0000
                              Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-17 03:12 -0600
                                Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 12:32 +0100
                                  Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:02 +0000
                                Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 13:23 +0000
                                  Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-17 08:54 -0600
                                    Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:54 +0000
                                      Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-18 12:37 -0600
                      Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:32 +0000
                        Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 02:09 -0800
                        Re: Average swaps per word? jim <anon@example.com> - 2016-11-15 10:44 +0000
                          Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 03:12 -0800
                          Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-15 13:01 +0000
                            Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:51 +0000
                              Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-17 14:02 +0000
                                Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-17 14:06 +0000
                                Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:26 +0000
                                  Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-18 18:33 +0000
                                    Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-19 03:32 -0600
                            Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:29 +0100
                        Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 13:51 +0100
                          Re: Average swaps per word? jim <anon@example.com> - 2016-11-15 13:01 +0000
                          Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:46 +0000
                            Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:16 +0100
                Re: Average swaps per word? Harold <hzrabbie@gmail.com> - 2016-11-13 11:08 -0800
                  Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:08 +0000
                    Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 02:04 -0800
                    Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 14:04 +0100
                      Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 14:05 +0100
                      Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:58 +0000
                        Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 15:16 +0100
                          Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:41 +0000
                            Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-20 18:12 +0100
    Re: Average swaps per word? minforth@arcor.de - 2016-11-09 03:15 -0800
      Re: Average swaps per word? trans <transfire@gmail.com> - 2016-11-09 11:22 -0800
      Re: Average swaps per word? "HAA" <someone@microsoft.com> - 2016-11-10 12:20 +1100
        Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-09 21:04 -1000
        Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 03:45 -0600
          Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 11:52 -0500
            Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 11:42 -0600
              Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 13:34 -0500
                Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 12:54 -0600
                  Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 16:33 -0500
                    Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-10 15:56 -1000
                      Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 21:30 -0500
                        Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-11 03:04 -0600
                          Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 13:25 +0000
                            Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-14 03:34 -0600
                      Re: Average swaps per word? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-11 10:41 +0000
                      Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 16:45 -0800
        Re: Average swaps per word? jim <anon@example.com> - 2016-11-10 11:17 +0000
          Re: Average swaps per word? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-10 04:34 -0800
            Re: Average swaps per word? jim <anon@example.com> - 2016-11-10 12:44 +0000
              Re: Average swaps per word? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-10 07:27 -0800
                Re: Average swaps per word? Ron Aaron <rambamist@gmail.com> - 2016-11-10 18:26 +0200
                Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-10 16:05 +0000
          Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-10 14:55 +0000
            Re: Average swaps per word? "HAA" <someone@microsoft.com> - 2016-11-12 11:36 +1100
              Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 16:56 -0800
              Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:14 +0100
            Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 12:14 +0000
              Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:16 +0100
                Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-13 14:51 +0000
                  Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 20:41 +0100
        Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-10 14:42 +0000
    Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 15:54 -0800

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

#52686

In article <2016Nov17.134040@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>>I haven't read the C specification on "volatile" in a while, but
>>"volatile" is supposed to prevent optimizing away reads or writes to
>>memory or ports.
>
>And memset() is specified to write over a block of memory.  That has
>not kept "optimizing" C compilers from "optimizing" it away.

You may be on the wrong trail here. memset() is not a c-language
instruction. So basically c-compilers have nothing with it.
It is a function call. If one insists on separate compilation
and then uses a linker that knows about relocation but not
about volatility, one has herself to blame.

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#52712

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov17.134040@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>>>I haven't read the C specification on "volatile" in a while, but
>>>"volatile" is supposed to prevent optimizing away reads or writes to
>>>memory or ports.
>>
>>And memset() is specified to write over a block of memory.  That has
>>not kept "optimizing" C compilers from "optimizing" it away.
>
>You may be on the wrong trail here. memset() is not a c-language
>instruction. So basically c-compilers have nothing with it.
>It is a function call. If one insists on separate compilation
>and then uses a linker that knows about relocation but not
>about volatility, one has herself to blame.

So much nonsense in so few lines!  memset() is standardized in the C
standard, and for a number of years, gcc has treated some of the
"library functions" not as functions, but as intrinsics.  And memset()
is treated in this way by recent gcc versions.

The part you write about linking makes no sense at all.  If memset()
was just a function called by the C compiler through the ABI, and the
compiler really performed separate compilation (no link-time
optimization), the memset() would not have been optimized away.
Indeed, separate compilation is a workaround I regularly use to
protect myself from miscompilation.

It's revealing that you blame the programmers even though you are
absolutely clueless about the issue at hand.

- 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 2016: http://www.euroforth.org/ef16/

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

#52768

In article <2016Nov18.161405@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>It's revealing that you blame the programmers even though you are
>absolutely clueless about the issue at hand.

With all due respect, I think I'm more of a professional c-programmer
than you. I've seen code from you that would not be "miscompiled"
had I phrased it.

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#52814

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov18.161405@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>It's revealing that you blame the programmers even though you are
>>absolutely clueless about the issue at hand.
>
>With all due respect, I think I'm more of a professional c-programmer
>than you.

That could easily be possible.  The days when I was paid for
programming in C are 25 years gone.

>I've seen code from you that would not be "miscompiled"
>had I phrased it.

One of the interesting aspects of miscompiling based on undefined
behaviour is that it has quite a number of fans on the net, despite
offering a lot of pain and little, if any, gain for programmers.

An explanation I currently have is that it appeals to the elitism in
these people and allows them to feel superior to others, with somewhat
different aspects to this feeling of superiority: One aspect is that
it makes it more challenging to program in C, and these people believe
they are in the elite of programmers able to deal with these
challenges.  Another aspect is that miscompilation hits programs that
make use of non-standard C* features, and these are features that some
people dislike, and it's especially irritating to them that programs
using these features have benefits over those that don't (run faster,
use less memory, ...), and miscompiling such programs vindicates their
attitude; my guess is that your statement above is due to this aspect.

[C* is the C dialect that was compiled as intended before the
"optimization" based on undefined behaviour craze hit.]

I think that VW just took the wrong PR approach for their emissions
testing optimization.  Instead of admitting that they did something
wrong, they should have insisted that they did everything right, and
that drivers who get higher emissions do something wrong.  They could
have had a bunch of spin doctors give advice on what to avoid and how
to drive right for low emissions, work on "sanitizers" that show
drivers when they are outside the low-emission envelope, etc.  With
that kind of PR, they would have found lots of people on the net who
would multiply this and who would put people who admit to driving
outside the low-emission envelope down, e.g., with statements like: "I
have seen driving by you that would not produce high emissions had I
driven".

- 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 2016: http://www.euroforth.org/ef16/

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

#52815

In article <2016Nov22.112928@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In article <2016Nov18.161405@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>It's revealing that you blame the programmers even though you are
>>>absolutely clueless about the issue at hand.
>>
>>With all due respect, I think I'm more of a professional c-programmer
>>than you.
>
>That could easily be possible.  The days when I was paid for
>programming in C are 25 years gone.
>
>>I've seen code from you that would not be "miscompiled"
>>had I phrased it.
>
>One of the interesting aspects of miscompiling based on undefined
>behaviour is that it has quite a number of fans on the net, despite
>offering a lot of pain and little, if any, gain for programmers.
>
>An explanation I currently have is that it appeals to the elitism in
>these people and allows them to feel superior to others, with somewhat
>different aspects to this feeling of superiority: One aspect is that
>it makes it more challenging to program in C, and these people believe
>they are in the elite of programmers able to deal with these
>challenges.  Another aspect is that miscompilation hits programs that
>make use of non-standard C* features, and these are features that some
>people dislike, and it's especially irritating to them that programs
>using these features have benefits over those that don't (run faster,
>use less memory, ...), and miscompiling such programs vindicates their
>attitude; my guess is that your statement above is due to this aspect.
>
>[C* is the C dialect that was compiled as intended before the
>"optimization" based on undefined behaviour craze hit.]
>
>I think that VW just took the wrong PR approach for their emissions
>testing optimization.  Instead of admitting that they did something
>wrong, they should have insisted that they did everything right, and
>that drivers who get higher emissions do something wrong.  They could
>have had a bunch of spin doctors give advice on what to avoid and how
>to drive right for low emissions, work on "sanitizers" that show
>drivers when they are outside the low-emission envelope, etc.  With
>that kind of PR, they would have found lots of people on the net who
>would multiply this and who would put people who admit to driving
>outside the low-emission envelope down, e.g., with statements like: "I
>have seen driving by you that would not produce high emissions had I
>driven".

There is a tension between this attitude of c-users and the necessity
for c-standards to apply to large set of circumstances, which is similar
but more extensive that the situation with the Forth standard.

You're invited to look at the discussion in the comp.lang.c
group about memset and volatile.
In this particular case problems can arise, but it requires ignoring
warnings from compilers without understanding them.

What you consider malice from the side of compiler maintainers,
I understand as an unfortunate consequence of general rules in
some circunstances.

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#52816

In article <2016Nov22.112928@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
...
>One of the interesting aspects of miscompiling based on undefined
>behaviour is that it has quite a number of fans on the net, despite
>offering a lot of pain and little, if any, gain for programmers.

Nobody adds features like that to a compiler just for the fun of it -
they do so because it does, in some contexts, they add a real gain for
programmers. The fact that it causes problems for defective code in
other contexts is simply something that doesn't bother them, and I think
that is as it should be.

>An explanation I currently have is that it appeals to the elitism in
>these people and allows them to feel superior to others, with somewhat
>different aspects to this feeling of superiority:

Well, I have to admit that I feel superior to those who fail to realize
that their code is defective - but I think that's an entirely justified
sense of superiority. I don't want their code to malfunction just
because they wrote it badly; I just don't care about the fact that it
malfunctions. If they wrote it deliberately, knowing it had undefined
behavior, they were implicitly saying "I don't care if this gets
miscompiled". If that's not what they actually felt, they should have
written the code so that the behavior they actually wanted to occur was
mandatory - such a re-write is almost always possible.

...
>challenges.  Another aspect is that miscompilation hits programs that
>make use of non-standard C* features, and these are features that some
>people dislike,

That shouldn't happen. Such code should only be translated using an
implementation that supports those non-standard features. If the use of
such features causes a program to be mis-translated by a given
implementation, that implementation does not, in fact, support those
features. If the implementation's documentation claims it does support
the feature, the implementor at fault - otherwise, the person who chose
to translate this code with that implementation is at fault.

>[C* is the C dialect that was compiled as intended before the
>"optimization" based on undefined behaviour craze hit.]

Ah - an imaginary dialect, from a fabled past that was better than today.

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

#52845

James Kuyper <jameskuyper@verizon.net> wrote:

> In article <2016Nov22.112928@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

> >[C* is the C dialect that was compiled as intended before the
> >"optimization" based on undefined behaviour craze hit.]
> 
> Ah - an imaginary dialect, from a fabled past that was better than today.

I think we've found supercat's real name.

Richard

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

#52644

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

> Looking at the C11 standard for memset_s, I did not see anything
> that would keep a sufficiently adverserial compiler writer from
> optimizing it away.  It says:
> 
> |Unlike memset, any call to the memset_s function shall be evaluated
> |strictly according to the rules of the abstract machine as described
> |in (5.1.2.3). That is, any call to the memset_s function shall assume
> |that the memory indicated by s and n may be accessible in the future
> |and thus must contain the values indicated by c.
> 
> Now, everything else (including memset()) in the standard also is
> evaluated according to the rules of the abstract machine, and the
> "optimization" comes in afterwards, applies the as-if rule, and poof,
> memset() is gone, and so is memset_s().  From what I read, "volatile"
> is not specified very clearly, so it probably has this problem and
> more.

That's true, but I don't believe that it's possible to do any better
with a language specification based on an abstract machine.  C11 still
says that

  What constitutes an access to an object that has volatile-qualified
  type is implementation-defined.

so it's possible for an "adversarial compiler" to optimize away
volatile too.  I don't think any do, though, which is perhaps the
point.

Andrew.

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

#52662

On Tue, 15 Nov 2016 03:55:45 -0600
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:

> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> > Looking at the C11 standard for memset_s, I did not see anything
> > that would keep a sufficiently adverserial compiler writer from
> > optimizing it away.  It says:
> > 
> > |Unlike memset, any call to the memset_s function shall be evaluated
> > |strictly according to the rules of the abstract machine as
> > described |in (5.1.2.3). That is, any call to the memset_s function
> > shall assume |that the memory indicated by s and n may be
> > accessible in the future |and thus must contain the values
> > indicated by c.
> > 
> > Now, everything else (including memset()) in the standard also is
> > evaluated according to the rules of the abstract machine, and the
> > "optimization" comes in afterwards, applies the as-if rule, and
> > poof, memset() is gone, and so is memset_s().  From what I read,
> > "volatile" is not specified very clearly, so it probably has this
> > problem and more.  
> 
> That's true, but I don't believe that it's possible to do any better
> with a language specification based on an abstract machine.  C11 still
> says that
> 
>   What constitutes an access to an object that has volatile-qualified
>   type is implementation-defined.
> 
> so it's possible for an "adversarial compiler" to optimize away
> volatile too.  I don't think any do, though, which is perhaps the
> point.
> 

Optimizing away volatile would defeat the purpose of having volatile
implemented by the language, wouldn't it?

I would think that phrase more likely means that volatile can be
entirely optional, or that the precise implementation details of
volatile is specific to each platform.  I'd guess that most C compilers
are likely to choose the latter, implementing volatile, since most also
support casting integers into pointers, which is undefined or
implementation-defined behavior too.  But, you could have a pedantic C
compiler which doesn't support volatile at all due to it being
non-portable.  Well, that's what that means to me, anyway.

If it's seriously an issue for Anton, there is always comp.std.c to
which he post, but a quick scan doesn't show any posts from the C
experts who contributed to and wrote the C specifications who posted
there years ago.


Rod Pemberton

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

#52666

Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote:
> On Tue, 15 Nov 2016 03:55:45 -0600
> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> 
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 
>> > Looking at the C11 standard for memset_s, I did not see anything
>> > that would keep a sufficiently adverserial compiler writer from
>> > optimizing it away.  It says:
>> > 
>> > |Unlike memset, any call to the memset_s function shall be evaluated
>> > |strictly according to the rules of the abstract machine as
>> > described |in (5.1.2.3). That is, any call to the memset_s function
>> > shall assume |that the memory indicated by s and n may be
>> > accessible in the future |and thus must contain the values
>> > indicated by c.
>> > 
>> > Now, everything else (including memset()) in the standard also is
>> > evaluated according to the rules of the abstract machine, and the
>> > "optimization" comes in afterwards, applies the as-if rule, and
>> > poof, memset() is gone, and so is memset_s().  From what I read,
>> > "volatile" is not specified very clearly, so it probably has this
>> > problem and more.  
>> 
>> That's true, but I don't believe that it's possible to do any better
>> with a language specification based on an abstract machine.  C11 still
>> says that
>> 
>>   What constitutes an access to an object that has volatile-qualified
>>   type is implementation-defined.
>> 
>> so it's possible for an "adversarial compiler" to optimize away
>> volatile too.  I don't think any do, though, which is perhaps the
>> point.
>> 
> 
> Optimizing away volatile would defeat the purpose of having volatile
> implemented by the language, wouldn't it?

That's why they don't do it.

> I would think that phrase more likely means that volatile can be
> entirely optional, or that the precise implementation details of
> volatile is specific to each platform.  I'd guess that most C
> compilers are likely to choose the latter, implementing volatile,
> since most also support casting integers into pointers, which is
> undefined or implementation-defined behavior too.

Of course.

> But, you could have a pedantic C compiler which doesn't support
> volatile at all due to it being non-portable.  Well, that's what
> that means to me, anyway.
> 
> If it's seriously an issue for Anton, there is always comp.std.c to
> which he post, but a quick scan doesn't show any posts from the C
> experts who contributed to and wrote the C specifications who posted
> there years ago.

It's not a serious issue from a practical C user's point of view, but
it does point to the limitations of what it's possible to do in a
programming language specification.

Andrew.

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

#52690

Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>Optimizing away volatile would defeat the purpose of having volatile
>implemented by the language, wouldn't it?

That has not stopped "optimizing" compilers from miscompiling before,
so there is no reason to assume they will stop at "volatile" if they
see a way to improve benchmark results by optimizing it away.  E.g.,
the purpose of memset() is to overwrite memory.  Yet compilers
"optimize" memset() away.

>If it's seriously an issue for Anton, there is always comp.std.c to
>which he post, but a quick scan doesn't show any posts from the C
>experts who contributed to and wrote the C specifications who posted
>there years ago.

The standard is a red herring.  The problem is the attitude of the
compiler maintainers.

- 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 2016: http://www.euroforth.org/ef16/

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

#52677

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>That's true, but I don't believe that it's possible to do any better
>with a language specification based on an abstract machine.

Yes, I don't think that fixing the specification is the way to go, yet
compiler apologists usually tell me that I should talk to the
specifiers in order to get the brokenness of the compilers fixed.

>so it's possible for an "adversarial compiler" to optimize away
>volatile too.  I don't think any do, though, which is perhaps the
>point.

In the good old times no compiler was adversarial.  They compiled the
code to behave as intended, and optimizations preserved that
behaviour.  Then, over a number of years and releases, compilers
became more and more adversarial.  So if compilers compile volatile as
intended now, that says nothing about the future; it could change with
the next release.  I guess we should be happy that benchmarks don't
use volatile much, if at all, making it less likely that it will be
singled out for "optimization"

- 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 2016: http://www.euroforth.org/ef16/

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

#52680

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>That's true, but I don't believe that it's possible to do any better
>>with a language specification based on an abstract machine.
> 
> Yes, I don't think that fixing the specification is the way to go, yet
> compiler apologists usually tell me that I should talk to the
> specifiers in order to get the brokenness of the compilers fixed.
> 
>>so it's possible for an "adversarial compiler" to optimize away
>>volatile too.  I don't think any do, though, which is perhaps the
>>point.
> 
> In the good old times no compiler was adversarial. 

Mmm.  Or something.

> They compiled the code to behave as intended, and optimizations
> preserved that behaviour.  Then, over a number of years and
> releases, compilers became more and more adversarial.  So if
> compilers compile volatile as intended now, that says nothing about
> the future; it could change with the next release.

I don't believe that, because too much stuff would break which
couldn't be fixed.  Also, the intent of volatile isn't just in the
imagination of the reader but is spelled out, so any such optimization
of volatile would clearly be contrary to that stated intent.

Andrew.

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

#52681

In article <PNidncUqaocQ6bDFnZ2dnUU7-Q-dnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>That's true, but I don't believe that it's possible to do any better
>>>with a language specification based on an abstract machine.
>>
>> Yes, I don't think that fixing the specification is the way to go, yet
>> compiler apologists usually tell me that I should talk to the
>> specifiers in order to get the brokenness of the compilers fixed.
>>
>>>so it's possible for an "adversarial compiler" to optimize away
>>>volatile too.  I don't think any do, though, which is perhaps the
>>>point.
>>
>> In the good old times no compiler was adversarial.
>
>Mmm.  Or something.
>
>> They compiled the code to behave as intended, and optimizations
>> preserved that behaviour.  Then, over a number of years and
>> releases, compilers became more and more adversarial.  So if
>> compilers compile volatile as intended now, that says nothing about
>> the future; it could change with the next release.
>
>I don't believe that, because too much stuff would break which
>couldn't be fixed.  Also, the intent of volatile isn't just in the
>imagination of the reader but is spelled out, so any such optimization
>of volatile would clearly be contrary to that stated intent.

Everybody seems to forget that volatile doesn't even make sense
outside of the context of an optimising compiler.
E.g. ciforth doesn't need a volatile keyword. If it says `` PC@ ''
PC@ it is.

So Anton's idea that there is a c-compiler that primo optimises, and
secundo ignores volatility is ludicrous in my view. It has something
to do with giving up control and passing it to a c-compiler.

Goes anything wrong if you tell the c-compiler not to optimize?

Once I start optimising ciforth, then I start thinking about
volatility issues. Probably I want optimisation to be explicit
    'fill-mu-table OPTIMISED
Then the issue goes all but away.

>
>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#52711

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Goes anything wrong if you tell the c-compiler not to optimize?

Yes, the code runs slower, typically by a factor of 3.

It's also pretty perverse that the miscompiler apologists justify
their miscompilation with performance, yet suggest at every
opportunity to turn off optimization as a workaround for
miscompilation.  So an "upgrade" to the compiler leads to the following
situation:

               old compiler       new compiler
               with optimization  without optimization
execution time    1s                   3s

Great value that the "optimization" gives us!

Also, some miscompilation occurs even with -O0.

- 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 2016: http://www.euroforth.org/ef16/

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

#52691

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> So if
>> compilers compile volatile as intended now, that says nothing about
>> the future; it could change with the next release.
>
>I don't believe that, because too much stuff would break which
>couldn't be fixed.

That counts for nothing with miscompiler maintainers.  They justify
their miscompilation by claiming that the miscompiled code has been
broken all along, and that the programmers get what they deserve.  The
bug report is marked as INVALID.  If your program is a particularly
important one, such as the Linux kernel, you get a flag for disabling
the miscompilation, but the default setting is to miscompile.

>Also, the intent of volatile isn't just in the
>imagination of the reader but is spelled out, so any such optimization
>of volatile would clearly be contrary to that stated intent.

And the intent of memset() is spelled out in the C standard even more
clearly, but that has not stopped them.

- 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 2016: http://www.euroforth.org/ef16/

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

#52697

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> 
>>Also, the intent of volatile isn't just in the
>>imagination of the reader but is spelled out, so any such optimization
>>of volatile would clearly be contrary to that stated intent.
> 
> And the intent of memset() is spelled out in the C standard even more
> clearly,

No it isn't.

Andrew.

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

#52716

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> 
>>>Also, the intent of volatile isn't just in the
>>>imagination of the reader but is spelled out, so any such optimization
>>>of volatile would clearly be contrary to that stated intent.
>> 
>> And the intent of memset() is spelled out in the C standard even more
>> clearly,
>
>No it isn't.

I find

|The memset function copies the value of c (converted to an unsigned
|char) into each of the first n characters of the object pointed to by s.

very clear, much clearer than the verbiage surrounding volatile.

- 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 2016: http://www.euroforth.org/ef16/

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

#52721

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> 
>>>>Also, the intent of volatile isn't just in the imagination of the
>>>>reader but is spelled out, so any such optimization of volatile
>>>>would clearly be contrary to that stated intent.
>>> 
>>> And the intent of memset() is spelled out in the C standard even more
>>> clearly,
>>
>>No it isn't.
> 
> I find
> 
> |The memset function copies the value of c (converted to an unsigned
> |char) into each of the first n characters of the object pointed to by s.
> 
> very clear, much clearer than the verbiage surrounding volatile.

I think the explanation of volatile in the rationale is rather nice:

   Several important optimization techniques are based on the
   principle of ???cacheing???: under certain circumstances the compiler
   can remember the last value accessed (read or written) from a
   location, and use this retained value the next time that location
   is read. (The memory, or ???cache???, is typically a hardware
   register.) If this memory is a machine register, for instance, the
   code can be smaller and faster using the register rather than
   accessing external memory.

For volatile,

   No cacheing through this lvalue: each operation in the abstract
   semantics must be performed (that is, no cacheing assumptions may
   be made, since the location is not guaranteed to contain any
   previous value). In the absence of this qualifier, the contents of
   the designated location may be assumed to be unchanged except for
   possible aliasing.

   Implementors of C translators should take into account relevant
   hardware details on the target systems when implementing accesses
   to volatile objects. For instance, the hardware logic of a system
   may require that a two-byte memory-mapped register not be accessed
   with byte operations; and a compiler for such a system would have
   to assure that no such instructions were generated, even if the
   source code only accesses one byte of the register. Whether read-
   modify-write instructions can be used on such device registers must
   also be considered.  Whatever decisions are adopted on such issues
   must be documented, as volatile access is implementation-defined.

It would take an extremely obtuse implementor to ignore this.

Andrew.

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

#52626

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov13.155518@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>On a related note, gcc likes to delete stores (including memset()) to
>>memory that is deallocated afterwards, based on the theory that it
>>would be undefined to read that memory afterwards, and that this
>>therefore cannot happen.  That was one of the contributing factors to
>>the Heartbleed vulnerability: The programmers had defensively used
>>memset() to erase the secrets after using them, that memory was then
>>deallocated, and gcc therefore "optimized" the memset() away.  And
>>while the following read from that memory (due to a buffer overflow)
>>was undefined behaviour, it still happened, revealing the secret to
>>the attacker.
>
>They should have checked what happens while optimising. Failing that
>they shouldn't have optimised.

I agree that the compiler writers should not have written their
compiler to miscompile this case.

If, OTOH, you want to blame the programmers (which many people want to
do in such discussions, for whatever reason), what if they did check
it, and the compiler actually generated the kind of code that they
intended, and only the compiler that was used for some distributions
of their software had this "optimization"?

Anyway, the general idea that you should check what the "optimizer"
does indicates that what it does is not optimization, but
miscompilation.

- 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 2016: http://www.euroforth.org/ef16/

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

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

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

csiph-web