Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38809
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: rhel 7 and kforth |
| Date | 2015-05-04 10:23 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2015May4.122327@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <878udqwq0s.fsf@jester.gateway.pace.com> <2015Apr18.164117@mips.complang.tuwien.ac.at> <874mo5mkpn.fsf@jester.gateway.sonic.net> <2015May2.125317@mips.complang.tuwien.ac.at> <87fv7d2nv7.fsf@jester.gateway.sonic.net> |
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
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web