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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#52647

On Monday, 14 November 2016 17:42:46 UTC, Anton Ertl  wrote:
> 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.
> 

The trouble with that is, if you're down to having to check/test/verify
the output of optimised code, then you might as well write the darned
thing in assembler!

Sure, you can write test cases, but test cases will only test the 
particular set of circumstances that the test engineer has conceived.
I doubt that any competent test engineer would have written a test
to check that particular security vulnerability. A penetration specialist
would, but this is open source software, right? Who's gonna feed the
guys with pizza and beer while they do all this?

Further more, as you correctly point out, a particular compiler may work
fine, and another not. Even different versions of the same brand of
compiler may have issues.

There's no easy solution to this particular set of problems.

That's probably why problems like this slip through.

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

#52648

In article <2016Nov14.183225@mips.complang.tuwien.ac.at>, 
anton@mips.complang.tuwien.ac.at says...
> 
> Anyway, the general idea that you should check what the "optimizer"
> does indicates that what it does is not optimization, but
> miscompilation.
> 
> - anton
> 

That is a very good point.



-- 
jim

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

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

#52651

On Tuesday, 15 November 2016 10:46:38 UTC, jim  wrote:
> In article <2016Nov14.183225@mips.complang.tuwien.ac.at>, 
> anton@mips.complang.tuwien.ac.at says...
> > 
> > Anyway, the general idea that you should check what the "optimizer"
> > does indicates that what it does is not optimization, but
> > miscompilation.
> > 
> > - anton
> > 
> 
> That is a very good point.
> 
> 
> 
> -- 
> jim
> 
> =========================
> http://johntech.co.uk
> 
> "Bleeding Edge Forum"
> http://johntech.co.uk/forum/ 
> 
> =========================

Yes.

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

#52658

On 11/15/2016 10:44, jim wrote:
> In article <2016Nov14.183225@mips.complang.tuwien.ac.at>,
> anton@mips.complang.tuwien.ac.at says...
>>
>> Anyway, the general idea that you should check what the "optimizer"
>> does indicates that what it does is not optimization, but
>> miscompilation.
>>
>> - anton
>>
>
> That is a very good point.
>
>
>

It's not as good as it appears, since for a large class of programming 
languages, compilation is the act of imprecise translation. Even simple 
statements such as a=b+1 translated to machine code such as ADD A, B, 1 
are a form of optimisation, since overflow is unaccounted for in the 
source language (or at least, the programmer may not realise that it is 
an issue), and yet overflow is a feature of the target.

-- 
Alex

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

#52685

Alex <alex@rivadpm.com> writes:
>On 11/15/2016 10:44, jim wrote:
>> In article <2016Nov14.183225@mips.complang.tuwien.ac.at>,
>> anton@mips.complang.tuwien.ac.at says...
>>>
>>> Anyway, the general idea that you should check what the "optimizer"
>>> does indicates that what it does is not optimization, but
>>> miscompilation.
>>>
>>> - anton
>>>
>>
>> That is a very good point.
...
>It's not as good as it appears, since for a large class of programming 
>languages, compilation is the act of imprecise translation. Even simple 
>statements such as a=b+1 translated to machine code such as ADD A, B, 1 
>are a form of optimisation, since overflow is unaccounted for in the 
>source language (or at least, the programmer may not realise that it is 
>an issue), and yet overflow is a feature of the target.

That's not optimization, that's just filling the holes in the
specification.  Optimization happens on the program with the holes
filled; i.e., if a=b+1 performs modulo arithmetic (wraparound) without
optimization, then it's an optimization to produce a faster program
that also performs modulo arithmetic, otherwise it's 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]

#52693

On 11/17/2016 12:51, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
>> On 11/15/2016 10:44, jim wrote:
>>> In article <2016Nov14.183225@mips.complang.tuwien.ac.at>,
>>> anton@mips.complang.tuwien.ac.at says...
>>>>
>>>> Anyway, the general idea that you should check what the "optimizer"
>>>> does indicates that what it does is not optimization, but
>>>> miscompilation.
>>>>
>>>> - anton
>>>>
>>>
>>> That is a very good point.
> ...
>> It's not as good as it appears, since for a large class of programming
>> languages, compilation is the act of imprecise translation. Even simple
>> statements such as a=b+1 translated to machine code such as ADD A, B, 1
>> are a form of optimisation, since overflow is unaccounted for in the
>> source language (or at least, the programmer may not realise that it is
>> an issue), and yet overflow is a feature of the target.
>
> That's not optimization, that's just filling the holes in the
> specification.  Optimization happens on the program with the holes
> filled; i.e., if a=b+1 performs modulo arithmetic (wraparound) without
> optimization, then it's an optimization to produce a faster program
> that also performs modulo arithmetic, otherwise it's miscompilation.
>
> - anton
>

This paper (which I suspect you may already know of) makes the point 
that I believe you make as per the complaint; 
http://www.cs.utah.edu/~regehr/papers/overflow12.pdf pg 3

---

2)  Time  Bombs: Undefined behavior also leads to time bombs: code that 
works under today’s compilers, but breaks unpredictably in the future 
as optimization technology improves.  The  Internet  is  rife  with 
stories  about  problems caused  by  GCC’s  ever-increasing  power to 
exploit signed overflows. For example, in 2005 a principal PostgreSQL 
developer was annoyed that his code was broken by a recent version of GCC:

It seems that gcc is up to some creative reinterpre-
tation of basic C semantics again; specifically, you
can no longer trust that traditional C semantics of
integer overflow hold ...

This highlights a fundamental and pervasive misunderstanding: the 
compiler was not “reinterpreting” the semantics but rather was beginning 
to take advantage of leeway explicitly provided by the C standard.

---

The complaint about optimisation may be a complaint about ambiguous or 
under-specification; but the author of the compiler and the author of 
the optimiser cannot be held accountable for that, and it is (imho) your 
responsibility to make sure that your programmatic incantations are 
correctly treated by both.

-- 
Alex

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

#52695

On 11/17/2016 14:02, Alex wrote:

> correctly treated by both.
>

. ^^^^^^^^^

treated as you wish them to be treated; correctly implies something I 
did not mean.

-- 
Alex

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

#52714

Alex <alex@rivadpm.com> writes:
>On 11/17/2016 12:51, Anton Ertl wrote:
>> Alex <alex@rivadpm.com> writes:
>>> It's not as good as it appears, since for a large class of programming
>>> languages, compilation is the act of imprecise translation. Even simple
>>> statements such as a=b+1 translated to machine code such as ADD A, B, 1
>>> are a form of optimisation, since overflow is unaccounted for in the
>>> source language (or at least, the programmer may not realise that it is
>>> an issue), and yet overflow is a feature of the target.
>>
>> That's not optimization, that's just filling the holes in the
>> specification.  Optimization happens on the program with the holes
>> filled; i.e., if a=b+1 performs modulo arithmetic (wraparound) without
>> optimization, then it's an optimization to produce a faster program
>> that also performs modulo arithmetic, otherwise it's miscompilation.
>>
>> - anton
>>
>
>This paper (which I suspect you may already know of) makes the point 
>that I believe you make as per the complaint; 
>http://www.cs.utah.edu/~regehr/papers/overflow12.pdf pg 3

Yes, I know this paper.

>The complaint about optimisation may be a complaint about ambiguous or 
>under-specification; but the author of the compiler and the author of 
>the optimiser cannot be held accountable for that, and it is (imho) your 
>responsibility to make sure that your programmatic incantations are 
>correctly treated by both.

Yes, that's the usual party line of miscompiler apologists.  Blame the
standard, blame the programmers.  But that's not a very useful
approach when dealing with C (or Forth, but fortunately this mental
illness has not spread to serious Forth compiler maintainers yet); it
just means that there is no strictly conformant terminating C program,
and the compiler is always right, and the programmer always to blame,
whatever the compiler does.

- 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]

#52720

On 11/18/2016 15:26, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
>> On 11/17/2016 12:51, Anton Ertl wrote:
>>> Alex <alex@rivadpm.com> writes:
>>>> It's not as good as it appears, since for a large class of programming
>>>> languages, compilation is the act of imprecise translation. Even simple
>>>> statements such as a=b+1 translated to machine code such as ADD A, B, 1
>>>> are a form of optimisation, since overflow is unaccounted for in the
>>>> source language (or at least, the programmer may not realise that it is
>>>> an issue), and yet overflow is a feature of the target.
>>>
>>> That's not optimization, that's just filling the holes in the
>>> specification.  Optimization happens on the program with the holes
>>> filled; i.e., if a=b+1 performs modulo arithmetic (wraparound) without
>>> optimization, then it's an optimization to produce a faster program
>>> that also performs modulo arithmetic, otherwise it's miscompilation.
>>>
>>> - anton
>>>
>>
>> This paper (which I suspect you may already know of) makes the point
>> that I believe you make as per the complaint;
>> http://www.cs.utah.edu/~regehr/papers/overflow12.pdf pg 3
>
> Yes, I know this paper.
>
>> The complaint about optimisation may be a complaint about ambiguous or
>> under-specification; but the author of the compiler and the author of
>> the optimiser cannot be held accountable for that, and it is (imho) your
>> responsibility to make sure that your programmatic incantations are
>> correctly treated by both.
>
> Yes, that's the usual party line of miscompiler apologists.  Blame the
> standard, blame the programmers.  But that's not a very useful
> approach when dealing with C (or Forth, but fortunately this mental
> illness has not spread to serious Forth compiler maintainers yet); it
> just means that there is no strictly conformant terminating C program,
> and the compiler is always right, and the programmer always to blame,
> whatever the compiler does.
>
> - anton
>

I would include compiler writers and optimiser writers in the set of 
programmers; so yes, the error falls somewhere, but blame not so much.

You argue (correct me if I'm wrong here) that eliminating memset during 
optimisation is a bug; to which the compiler maintainers response 
appears to be that such a thing is bad programming, since the block 
should not be addressable anyhow.

A (probably poor) analogy: When building a house, you should inspect the 
work of the plumber to make sure the work has been done & the pipes you 
asked for are plumbed in. When you specify pipework that appears to 
terminate in mid air, it's not unreasonable to find it's been eliminated 
when you ask for the job to be done optimally (that is, faster or more 
cheaply).

You're complaining that by removing what looked like unneeded pipes the 
plumber has denied you your novelty fountain.

Attributing this kind of problem to miscompilation is fine; but 
suggesting that blame lies with the compiler writer (or that there is 
some malice in their approach) seems as pointless as blaming the 
programmer. I still contend that it's your responsibility to make sure 
that your programmatic incantations are correctly treated according to 
your desires.

-- 
Alex

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

#52730

Alex <alex@rivadpm.com> wrote:
> 
> You argue (correct me if I'm wrong here) that eliminating memset during 
> optimisation is a bug; to which the compiler maintainers response 
> appears to be that such a thing is bad programming, since the block 
> should not be addressable anyhow.

It's also problematic because a compiler -- and indeed an operating
system -- might make several copies of security-critical information
as part of its usual operation.  I don't think there's any way to
prevent completely this if your entire system runs on a
general-purpose operating system.  The Forth approach of running
native on the hardware would work (because you control what the OS can
do) as would using a hardware security module.

Andrew.

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

#52689

In article <o0f0v7$ihp$1@dont-email.me>, Alex  <alex@rivadpm.com> wrote:
>On 11/15/2016 10:44, jim wrote:
>> In article <2016Nov14.183225@mips.complang.tuwien.ac.at>,
>> anton@mips.complang.tuwien.ac.at says...
>>>
>>> Anyway, the general idea that you should check what the "optimizer"
>>> does indicates that what it does is not optimization, but
>>> miscompilation.
>>>
>>> - anton
>>>
>>
>> That is a very good point.
>>
>>
>>
>
>It's not as good as it appears, since for a large class of programming
>languages, compilation is the act of imprecise translation. Even simple
>statements such as a=b+1 translated to machine code such as ADD A, B, 1
>are a form of optimisation, since overflow is unaccounted for in the
>source language (or at least, the programmer may not realise that it is
>an issue), and yet overflow is a feature of the target.

I hate the use of optimisation instead of "speed issues".
What you hint out is leaving out error detection in order to
gain some speed. It is fully within the specifications of the
c language to throw exceptions on overflows.
If you now have defined your Forth in C, and it doesn't work any
more in such an compiler, than your Forth is wrong, at least
"relying on system-dependant features" of the c-compiler.
If you're not aware of the features that you use, or have no
way to enforce that the c-compiler keeps on supplying those
features, you're in trouble.

>--
>Alex

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]

#52655

In article <2016Nov14.183225@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 <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.

I don't agree. For mission critical stuff, you've to test the actual
compiled program, which implicates the compiler.
If the task of the programmers was to deliver a correct c-program
source they are off the hook.
If the task of the company was to deliver a mission critical
application the company is not.

>
>- 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]

#52659

In article <o0f0c4$jgr$1@cherry.spenarnc.xs4all.nl>, 
albert@cherry.spenarnc.xs4all.nl says...
> I don't agree. For mission critical stuff, you've to test the actual
> compiled program, which implicates the compiler.
> If the task of the programmers was to deliver a correct c-program
> source they are off the hook.
> If the task of the company was to deliver a mission critical
> application the company is not.
> 

If you are trying to second guess the compiler you may as well hand code it 
yourself. Trying to understand what a compiler has done and why and whether 
it is safe or not seems like a very costly exercise to me. (Unless you are
writing the compiler itself of course)

You can always pre-suppose a trade off for some code sections but then there 
will always be doubts. For safety/mission critical work in such a situation formal 
proofs for compiler activity are required I would think. And then you'd need to 
trust it.

-- 
jim

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

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

#52684

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov14.183225@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>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.
>
>I don't agree. For mission critical stuff, you've to test the actual
>compiled program, which implicates the compiler.

Who is "you"?  Everyone who compiles the program should check it?  Or
everybody who installs the compiled program on a computer?  Or
everybody who runs such a program?  So now we are from "blame the
programmer" to "blame the packager", "blame the sysadmin", or "blame
the user", just to avoid blaming the real culprit: the compiler
maintainer.

- 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]

#52687

In article <2016Nov17.134603@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 <2016Nov14.183225@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>>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.
>>
>>I don't agree. For mission critical stuff, you've to test the actual
>>compiled program, which implicates the compiler.
>
>Who is "you"?  Everyone who compiles the program should check it?  Or
>everybody who installs the compiled program on a computer?  Or
>everybody who runs such a program?  So now we are from "blame the
>programmer" to "blame the packager", "blame the sysadmin", or "blame
>the user", just to avoid blaming the real culprit: the compiler
>maintainer.

Think more in legal terms, and you know who is to blame.
There is not a single compiler maintainer who is insured against
accidents with nuclear power plants. Instead they have disclaimers
a mile long that shift the responsability to the builders of a power
plant.
>
>- 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]

#52587

On Saturday, November 12, 2016 at 5:24:03 AM UTC-8, Anton Ertl wrote:

> AFAIK VFX optimizes such a @ DROP sequence (but, trying it out now,
> not C@ DROP) away in the PC version, but leaves it alone in the
> embedded version.
> 
> But even if the PC version left it alone, too, that would slow down
> real-world code by exactly 0%, because you don't write @ DROP unless
> you want the side effect.

You can get the @ DROP sequence as a result of in-lining. It doesn't have to be written explicitly.  Maybe Forth needs a standardized compiler barrier, that tells the optimizer to keep its hands off.

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

#52624

Harold <hzrabbie@gmail.com> writes:
>You can get the @ DROP sequence as a result of in-lining.

Any evidence of that occuring to any relevant extent?  No?  Thought so.

Justifying some "optimization" of code that nobody would write except
in cases where the "optimization" is actually miscompilation (i.e.,
the code no longer behaves as intended) with cases resulting from
macro expansion, inlining and similar stuff is a common tactic by
"optimization" apologists.  But I have yet to see any evidence
supporting such claims.

>Maybe Forth needs a standardized compiler barrier, that tells the optimizer to keep its hands off.

An optimization barrier always assumes a certain model of
optimization, and code using such a barrier will likely be not
portable to compilers with more aggressive optimizers.  Specifying the
semantics of code is a more lasting approach.  I.e., if we really
wanted to allow optimizing @ DROP, we could have RAM@ and PORT@, with
PORT@ DROP not being optimizable.

- 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]

#52646

On Monday, 14 November 2016 17:31:51 UTC, Anton Ertl  wrote:
> An optimization barrier always assumes a certain model of
> optimization, and code using such a barrier will likely be not
> portable to compilers with more aggressive optimizers.  Specifying the
> semantics of code is a more lasting approach.  I.e., if we really
> wanted to allow optimizing @ DROP, we could have RAM@ and PORT@, with
> PORT@ DROP not being optimizable.

^^^^^^^^ Much better solution.

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

#52656

In article <2016Nov14.180809@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Harold <hzrabbie@gmail.com> writes:
>>You can get the @ DROP sequence as a result of in-lining.
>
>Any evidence of that occuring to any relevant extent?  No?  Thought so.

I expect this or things similar to this to happen all the time.
Think of FIND. It leaves an immediate flag too.
In cases where the flag is needed and FIND is inlined, the
optimisation trickles down to the place where something is fetched.

>
>Justifying some "optimization" of code that nobody would write except
>in cases where the "optimization" is actually miscompilation (i.e.,
>the code no longer behaves as intended) with cases resulting from
>macro expansion, inlining and similar stuff is a common tactic by
>"optimization" apologists.  But I have yet to see any evidence
>supporting such claims.
>
>>Maybe Forth needs a standardized compiler barrier, that tells the optimizer to keep its hands off.
>
>An optimization barrier always assumes a certain model of
>optimization, and code using such a barrier will likely be not
>portable to compilers with more aggressive optimizers.  Specifying the
>semantics of code is a more lasting approach.  I.e., if we really
>wanted to allow optimizing @ DROP, we could have RAM@ and PORT@, with
>PORT@ DROP not being optimizable.

In my optimiser design each word carries an indication of its side
effects. Then it suffices to set an output side effect flag in
: resettimer timer PC@ DROP ;
This would only allow correct optimisations, still allowing the inlining.
(In fact in this case it would be automatic, because `PC@ would have
the 'output side effect' bit set, of course. That is basically
your idea, but within the total framework of the optimiser, not
as an add on.)

>
>- anton
-- 
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]

#52657

In article <o0f145$jjd$1@cherry.spenarnc.xs4all.nl>,
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
..
>In cases where the flag is needed and FIND is inlined, the
                           ^
                          not

>optimisation trickles down to the place where something is fetched.
-- 
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]

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

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

csiph-web