Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56536 > unrolled thread
| Started by | krishna.myneni@ccreweb.org |
|---|---|
| First post | 2017-04-01 06:36 -0700 |
| Last post | 2017-04-06 10:53 -0700 |
| Articles | 20 on this page of 127 — 22 participants |
Back to article view | Back to comp.lang.forth
LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 06:36 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 14:57 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:55 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 15:24 +0000
Re: LLVM and Forth rickman <gnuarm@gmail.com> - 2017-04-01 11:21 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:57 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:02 -0500
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-02 06:35 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 14:41 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 01:09 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:32 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 13:52 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 07:59 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 16:08 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 12:22 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-03 20:10 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 22:19 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:12 +0200
Re: LLVM and Forth Walter Banks <walter@bytecraft.com> - 2017-04-05 17:27 -0400
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 14:29 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:17 -0500
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 05:04 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 12:55 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 10:08 -0500
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 17:05 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 11:29 -0500
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:11 +0200
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-04 21:29 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-05 15:01 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-05 18:42 +0100
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:01 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 18:48 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 18:42 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-07 04:02 -0500
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 21:18 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:43 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 20:54 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:53 +0000
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-12 15:29 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-10 18:38 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 11:54 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-10 10:17 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:02 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 10:03 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 03:25 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 11:24 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 04:55 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 12:28 +0000
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:16 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 15:38 +0200
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:06 +0200
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 17:57 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-05 00:44 -0400
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 00:00 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 08:47 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 11:04 -0500
Re: LLVM and Forth john <anon@example.com> - 2017-04-05 18:04 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-05 13:04 -0700
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:20 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:14 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 12:33 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:49 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 18:55 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 20:41 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:47 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:56 +0100
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 23:59 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 17:10 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-07 03:33 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:48 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 15:06 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 22:45 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:27 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-09 21:26 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 13:35 -0400
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-09 14:07 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 12:16 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:27 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:24 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 03:26 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-06 04:05 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 06:50 -0500
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:23 -0400
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:44 -0500
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 10:57 +0100
Re: LLVM and Forth peter.m.falth@gmail.com - 2017-04-05 05:29 -0700
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-14 02:04 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:03 +0200
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 00:44 +0000
Re: LLVM and Forth alex@rivadpm.com - 2017-04-16 05:53 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:43 +0000
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:27 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 02:45 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-18 18:26 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 19:51 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 19:08 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:42 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:29 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:48 +0100
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 11:49 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-03 20:39 -0400
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-02 21:15 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-02 15:18 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 13:07 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 09:45 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 22:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 15:25 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:35 +0100
Re: LLVM and Forth antispam@math.uni.wroc.pl - 2017-04-06 01:36 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 22:00 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-06 20:15 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:20 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:11 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 17:43 +0100
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:53 -0700
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-04 15:38 +0200 |
| Message-ID | <oc07kj$il8$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #56690 |
In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>, <krishna.myneni@ccreweb.org> wrote: >On Monday, April 3, 2017 at 3:17:59 AM UTC-5, Andrew Haley wrote: >> krishna.myneni@ccreweb.org wrote: >> > On Sunday, April 2, 2017 at 4:02:26 AM UTC-5, Andrew Haley wrote: >> >> krishna.myneni@ccreweb.org wrote: >> >> >=20 >> >> > Supposedly Java virtual machines have been developed with LLVM. >> >>=20 >> >> It is very difficult, partly for the reasons described: LLVM uses C >> >> semantics for its intermedieate language, so if your language is along >> >> way from C this can be problematic. Optimizing without specific >> >> language semantics is somewhere between hard and impossible. >> >=20 >> > The fundamental question appears to be independent of LLVM: >> >=20 >> > If one were to write a Forth to C translator, how likely is it that >> > the translator would result in C code which is considered undefined >> > in the new C standard, i.e. how problematic would "nasal demons" be >> > in the translated code? >>=20 >> Single-threaded, it wouldn't be problematic at all. The nasal daemons >> tend to happen if you're pushing the envelope of optimization. As >> long as you translated into well-defined C, ... > >Let's consider an example. Here is the Forth code: > >variable v >0 v ! > >v @ 1+ 2 + v ! > >Now this could be translated into C in a couple of ways: > >T1) > >int v =3D 0; >v =3D ++v + 2; >=20 >T2) > >int v =3D 0; >v =3D v++ + 2; > Both are wrong in my book. v++ implies that v is a pointer A good translation is v = v+1+2; Having a special action for 1+ is silly anyway. The ++ operator is a remnance of the PDP11 era, there is not a shred of a reason to use it in output for a translator. It mixes address manipulation into an expression. We know that for a variable v the expression v in Forth is an address. In c sometime it is and sometimes it isn't. The ++ operator optimises that confusion. 1 V +! could become v++ but that is stupid because it only works for 1. I think 12 V +! should become v += 12; and that is about it. None of the other ++ -- += -= /= etc. symbols need be present in the c-output. >My understanding is that, per the C standard, translation T1 is well-define= >d, but translation T2 results in undefined code. I'm still trying to wrap m= >y head around sequence points, but understanding why one translation is wel= >l-defined while the other is undefined seems to presents a challenge for wr= >iting a translator. That story applies if v is a pointer. I don't go into that, because the conclusion is already: Everyone using ++ or -- in the output of a Forth to C translator is an idiot. > >Krishna -- 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]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-04 16:06 +0200 |
| Message-ID | <oc0996$it9$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #56704 |
In article <oc07kj$il8$1@cherry.spenarnc.xs4all.nl>,
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>,
> <krishna.myneni@ccreweb.org> wrote:
>>On Monday, April 3, 2017 at 3:17:59 AM UTC-5, Andrew Haley wrote:
>>> krishna.myneni@ccreweb.org wrote:
>>> > On Sunday, April 2, 2017 at 4:02:26 AM UTC-5, Andrew Haley wrote:
>>> >> krishna.myneni@ccreweb.org wrote:
>>> >> >=20
>>> >> > Supposedly Java virtual machines have been developed with LLVM.
>>> >>=20
>>> >> It is very difficult, partly for the reasons described: LLVM uses C
>>> >> semantics for its intermedieate language, so if your language is along
>>> >> way from C this can be problematic. Optimizing without specific
>>> >> language semantics is somewhere between hard and impossible.
>>> >=20
>>> > The fundamental question appears to be independent of LLVM:
>>> >=20
>>> > If one were to write a Forth to C translator, how likely is it that
>>> > the translator would result in C code which is considered undefined
>>> > in the new C standard, i.e. how problematic would "nasal demons" be
>>> > in the translated code?
>>>=20
>>> Single-threaded, it wouldn't be problematic at all. The nasal daemons
>>> tend to happen if you're pushing the envelope of optimization. As
>>> long as you translated into well-defined C, ...
>>
>>Let's consider an example. Here is the Forth code:
>>
>>variable v
>>0 v !
>>
>>v @ 1+ 2 + v !
>>
>>Now this could be translated into C in a couple of ways:
>>
>>T1)
>>
>>int v =3D 0;
>>v =3D ++v + 2;
>>=20
>>T2)
>>
>>int v =3D 0;
>>v =3D v++ + 2;
>>
>
>Both are wrong in my book.
But one gives the intended outcome.
------------
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
int i;
i=12;
printf("%d\n",i++);
i=12;
printf("%d\n",++i);
return 0;
}
----------
This gives
12
13
>
>v++ implies that v is a pointer
Oops that is absolutely not true. I meant to say that
using ++ in and expression normally is done for pointers.
>A good translation is
>
>v = v+1+2;
>
>Having a special action for 1+ is silly anyway.
>The ++ operator is a remnance of the PDP11 era, there is not a shred
>of a reason to use it in output for a translator.
>It mixes address manipulation into an expression. We know that
>for a variable v the expression v in Forth is an address.
>In c sometime it is and sometimes it isn't.
>The ++ operator optimises that confusion.
>
> 1 V +!
>could become
> v++
>but that is stupid because it only works for 1.
>I think
> 12 V +!
>should become
> v += 12;
>and that is about it.
>None of the other ++ -- += -= /= etc. symbols need be present in
>the c-output.
>
>>My understanding is that, per the C standard, translation T1 is well-define=
>>d, but translation T2 results in undefined code. I'm still trying to wrap m=
>>y head around sequence points, but understanding why one translation is wel=
>>l-defined while the other is undefined seems to presents a challenge for wr=
>>iting a translator.
>
>That story applies if v is a pointer.
Please ignore that line.
Of course you can use v++ instead of (v) in an expression and have v
changed at the same time, in other words it involves the address of v
too.
Of course you can use ++v instead of (v+1) in an expression and have v
changed at the same time.
If you use that expression then to store it into the v that you're
in the process of changing already, it may or may not work.
To find that out, it is more of a headache than I want to spent
right know. You know it: "Doctor, it aches when I do this."
"Then don't do that!"
> I don't go into that,
>because the conclusion is already:
>
> Everyone using ++ or -- in the output of a Forth to C translator
> is an idiot.
I stand by that conclusion.
>
>>
>>Krishna
>--
>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
>
--
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]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-04 17:57 -0700 |
| Message-ID | <c7b0253d-7f8d-4eb7-a6f3-2a9b43f66509@googlegroups.com> |
| In reply to | #56704 |
On Tuesday, April 4, 2017 at 8:37:46 AM UTC-5, Albert van der Horst wrote: > In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>, > <krishna.myneni@ccreweb.org> wrote: ... > >Let's consider an example. Here is the Forth code: > > > >variable v > >0 v ! > > > >v @ 1+ 2 + v ! > > > >Now this could be translated into C in a couple of ways: > > > >T1) > > > >int v =3D 0; > >v =3D ++v + 2; > >=20 > >T2) > > > >int v =3D 0; > >v =3D v++ + 2; > > > > Both are wrong in my book. > T2 is certainly an incorrect translation and does not have the meaning of the original Forth code. But my point here was not about the correctness of the translation, but about the boundary between well-defined and undefined behavior of C code per the standard. ... > Having a special action for 1+ is silly anyway. > The ++ operator is a remnance of the PDP11 era, there is not a shred > of a reason to use it in output for a translator. ... Isn't there an INC operation in x86? > None of the other ++ -- += -= /= etc. symbols need be present in > the c-output. > In effect, you are you recommending that all of these operations be stricken from the C language itself. Translating from some source language into C is just a place holder for transcribing a mental model of a computation or algorithm directly into the target language, i.e. for coding in C. > Everyone using ++ or -- in the output of a Forth to C translator > is an idiot. > I would think the criteria for being an idiot is more general than that, at least with present day C compilers. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-05 00:44 -0400 |
| Message-ID | <20170405004435.4706b792@_> |
| In reply to | #56734 |
On Tue, 4 Apr 2017 17:57:52 -0700 (PDT)
krishna.myneni@ccreweb.org wrote:
> On Tuesday, April 4, 2017 at 8:37:46 AM UTC-5, Albert van der Horst
> wrote:
> > In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>,
> > <krishna.myneni@ccreweb.org> wrote:
> > Having a special action for 1+ is silly anyway.
> > The ++ operator is a remnance of the PDP11 era, there is not a shred
> > of a reason to use it in output for a translator. ...
>
> Isn't there an INC operation in x86?
>
16-bit. Yes.
32-bit. Yes.
64-bit. No. (It was reassigned for the REX prefix.)
You can see this on Sandpile.org's "1 byte opcodes" page:
http://www.sandpile.org/x86/opc_1.htm
Sandpile.org
"The world's leading source for technical x86 processor information."
http://www.sandpile.org/
> > Everyone using ++ or -- in the output of a Forth to C translator
> > is an idiot.
> >
>
> I would think the criteria for being an idiot is more general than
> that, at least with present day C compilers.
>
Today, adding one or subtracting one optimizes just as well, but isn't
as compact to code.
There is nothing wrong with ++ or -- , AS LONG AS you follow the ANSI C
rules for using them. Of course, almost no one knows or remembers or
uses these rules ...
ANSI C introduced rules for their use with the "sequence points"
concept of ANSI C. This resulted in the pre- and post-decrement or
pre- and post-increment operations to sometimes erroneously affect the
result of a computed value when the sequence is optimized or compiled.
I.e., the order of operations for ANSI C was changed and is not
guaranteed to be identical to that of K&R C or earlier.
The ANSI C rules say that you must separate out the usage or pre- and
post-decrement and pre- and post-increment from other C code. These
rules carry over into ISO C, even if not stated.
This, for ANSI C compliance,
v = ++v + 2;
should be rewritten as this:
++v;
v = v + 2:
This, for ANSI C compliance,
v = v++ + 2;
should be rewritten as this:
v = v + 2;
v++;
Of course, these are equivalent:
v += 2;
v = v + 2;
The rules are because of situations like this one:
v += ++v + 2; /* coded */
v = v + ++v + 2; /* equivalent */
If v is 3, is the result 9 or 10?
Historically, the expected result in C is 10. I.e., it's equivalent to:
++v;
v += v + 2;
This is because historically pre-increment was supposed to occur first,
prior to any other operations. However, ANSI C's sequence points
concept meant that the operation could occur anywhere prior to the
semicolon. It doesn't have to explicitly come first. I.e., ANSI C
fiddled with the expected order of operations and completion.
v++, v=4, v = 4 + 4 + 2, v=10; /* pre-ANSI C, v++ occurs first */
v = 3 + 3 + 2, v++, v=9; /* valid for ANSI C ... */
v++ (2nd only), v = 3 + 4 + 2, v=9; /* valid for ANSI C ... */
It becomes more complicated with sequence points if multiple increments
or decrements are involved:
v = ++v + ++v + 2 ;
The compiler can apply both pre-increments before, both after, one
before and one after ... as long as the operations are applied prior to
the semicolon.
C also has the rarely used comma ',' operator (sequential expression)
which allows for multiple statements to occur during the same sequence
point. IMO, the sequence point concept is an abomination, but is
needed for compilers. And, it is not the only mistake ANSI C committee
introduced into C. They spent years correcting a number of other
serious mistakes.
Rod Pemberton
--
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-05 00:00 -0700 |
| Message-ID | <cdc8055a-160a-46e4-a466-e289edfe1e45@googlegroups.com> |
| In reply to | #56739 |
Am Mittwoch, 5. April 2017 06:43:37 UTC+2 schrieb Rod Pemberton: > On Tue, 4 Apr 2017 17:57:52 -0700 (PDT) > krishna.myneni@ccreweb.org wrote: > > > On Tuesday, April 4, 2017 at 8:37:46 AM UTC-5, Albert van der Horst > > wrote: > > > In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>, > > > <krishna.myneni@ccreweb.org> wrote: > > > > Having a special action for 1+ is silly anyway. > > > The ++ operator is a remnance of the PDP11 era, there is not a shred > > > of a reason to use it in output for a translator. ... > > > > Isn't there an INC operation in x86? > > > > 16-bit. Yes. > 32-bit. Yes. > 64-bit. No. (It was reassigned for the REX prefix.) > > You can see this on Sandpile.org's "1 byte opcodes" page: > http://www.sandpile.org/x86/opc_1.htm > > Sandpile.org > "The world's leading source for technical x86 processor information." > http://www.sandpile.org/ > > > > Everyone using ++ or -- in the output of a Forth to C translator > > > is an idiot. > > > > > > > I would think the criteria for being an idiot is more general than > > that, at least with present day C compilers. > > > > Today, adding one or subtracting one optimizes just as well, but isn't > as compact to code. > > There is nothing wrong with ++ or -- , AS LONG AS you follow the ANSI C > rules for using them. Of course, almost no one knows or remembers or > uses these rules ... > > ANSI C introduced rules for their use with the "sequence points" > concept of ANSI C. This resulted in the pre- and post-decrement or > pre- and post-increment operations to sometimes erroneously affect the > result of a computed value when the sequence is optimized or compiled. > I.e., the order of operations for ANSI C was changed and is not > guaranteed to be identical to that of K&R C or earlier. > > The ANSI C rules say that you must separate out the usage or pre- and > post-decrement and pre- and post-increment from other C code. These > rules carry over into ISO C, even if not stated. > > This, for ANSI C compliance, > v = ++v + 2; > > should be rewritten as this: > ++v; > v = v + 2: > > > This, for ANSI C compliance, > v = v++ + 2; > > should be rewritten as this: > v = v + 2; > v++; > > > Of course, these are equivalent: > v += 2; > v = v + 2; > > > The rules are because of situations like this one: > v += ++v + 2; /* coded */ > v = v + ++v + 2; /* equivalent */ > > If v is 3, is the result 9 or 10? > > Historically, the expected result in C is 10. I.e., it's equivalent to: > ++v; > v += v + 2; > > This is because historically pre-increment was supposed to occur first, > prior to any other operations. However, ANSI C's sequence points > concept meant that the operation could occur anywhere prior to the > semicolon. It doesn't have to explicitly come first. I.e., ANSI C > fiddled with the expected order of operations and completion. > > v++, v=4, v = 4 + 4 + 2, v=10; /* pre-ANSI C, v++ occurs first */ > v = 3 + 3 + 2, v++, v=9; /* valid for ANSI C ... */ > v++ (2nd only), v = 3 + 4 + 2, v=9; /* valid for ANSI C ... */ > > It becomes more complicated with sequence points if multiple increments > or decrements are involved: > > v = ++v + ++v + 2 ; > > The compiler can apply both pre-increments before, both after, one > before and one after ... as long as the operations are applied prior to > the semicolon. > > C also has the rarely used comma ',' operator (sequential expression) > which allows for multiple statements to occur during the same sequence > point. IMO, the sequence point concept is an abomination, but is > needed for compilers. And, it is not the only mistake ANSI C committee > introduced into C. They spent years correcting a number of other > serious mistakes. > > > Rod Pemberton > > -- > All it takes for humanity to conquer the world's toughest problems > is to hope, to believe, to share, and to do, in cooperation. So what the heck? Your contrived examples violate basic software engineering rules to not write obscure code. C and Assembler are well suited to shoot one's own foot. But that does not imply that you have to protect the shootist. Forth is full of unspecified corners as well. No reason for language talibanism.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-05 08:47 -0700 |
| Message-ID | <e5a4671c-9847-4940-b089-d0c08260c175@googlegroups.com> |
| In reply to | #56740 |
On Wednesday, April 5, 2017 at 2:00:45 AM UTC-5, minf...@arcor.de wrote: ... > C and Assembler are well suited to shoot one's own foot. But that does not imply that you have to protect the shootist. Forth is full of unspecified corners as well. No reason for language talibanism. You miss an important distinction between C and assembler -- the ability to predict the actual instructions executed by the processor and the order in which they are executed. One can look at assembly language code and predict exactly which machine instructions will be executed and in what order. That ability is gone with optimized C compilers which are given license to eliminate and/or reorder source code instructions during compilation. C is very different from assembly language in this sense. With Forth, because of its stack-based nature, I think the predictability of run-time execution of source code is much higher than it is for C, but perhaps I'm wrong on this point. Incidentally, I always compile my Forth system, written in a mix of C++, C, and assembly language, at the lowest optimization level (-O0) for the C and C++ source files. The assembler of course has no optimization settings (of which I'm aware). The speed of my system is largely independent of the C/C++ compiler optimization anyway since the bulk of the dictionary is implemented in assembly code. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-05 11:04 -0500 |
| Message-ID | <CZednRNE7OwXiHjFnZ2dnUU7-QudnZ2d@supernews.com> |
| In reply to | #56746 |
krishna.myneni@ccreweb.org wrote: > On Wednesday, April 5, 2017 at 2:00:45 AM UTC-5, minf...@arcor.de wrote: > ... >> C and Assembler are well suited to shoot one's own foot. But that >> does not imply that you have to protect the shootist. Forth is full >> of unspecified corners as well. No reason for language talibanism. > > You miss an important distinction between C and assembler -- the > ability to predict the actual instructions executed by the processor > and the order in which they are executed. One can look at assembly > language code and predict exactly which machine instructions will be > executed and in what order. Not necessarily, no. There are lots of things one can do in assembly code which lead to behaviour you or I, the programmer, can't predict. It happens to me all the time. All you have to do is overwite some critical register or forget to initialize it. Or forget to insert a memory fence instruction. That's one of the favourites because it causes rare and hard-to-find bugs. Or, or... > That ability is gone with optimized C compilers which are given > license to eliminate and/or reorder source code instructions during > compilation. C is very different from assembly language in this > sense. I don't think there's really any difference. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-04-05 18:04 +0100 |
| Message-ID | <MPG.334f341a522dc7bb989705@news.virginmedia.com> |
| In reply to | #56747 |
In article <CZednRNE7OwXiHjFnZ2dnUU7-QudnZ2d@supernews.com>, andrew29@littlepinkcloud.invalid says... > > > That ability is gone with optimized C compilers which are given > > license to eliminate and/or reorder source code instructions during > > compilation. C is very different from assembly language in this > > sense. > > I don't think there's really any difference. > > Andrew. I seem to remember when I was looking at assemblers that fasm does multiple passes to perform some optimisation. Perhaps a fasm user could confirm that? -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-05 13:04 -0700 |
| Message-ID | <678dcde6-dd47-4662-8a5e-e8d5f9c11d03@googlegroups.com> |
| In reply to | #56748 |
On Wednesday, April 5, 2017 at 10:05:08 AM UTC-7, john wrote: > In article <CZednRNE7OwXiHjFnZ2dnUU7-QudnZ2d@supernews.com>, > andrew29@littlepinkcloud.invalid says... > > > > > > That ability is gone with optimized C compilers which are given > > > license to eliminate and/or reorder source code instructions during > > > compilation. C is very different from assembly language in this > > > sense. > > > > I don't think there's really any difference. > > > > Andrew. > > I seem to remember when I was looking at assemblers that fasm does > multiple passes to perform some optimisation. Perhaps a fasm user could > confirm that? FASM is multi-pass --- FASM does not eliminate and/or reorder source-code instructions --- the multiple passes are mostly for reducing Jxx operand size. My MFX included an assembler. I did reorder the source-code instructions significantly to maximize parallelization --- but I did so in a manner that would guarantee that the program did the same thing as if the instructions were executed sequentially in the same order that they appeared in the source-code. Eliminating instructions is an extremely bad idea --- this assumes that the programmer is an idiot to writes needless instructions --- there are only two people in the world who know how to program in MFX assembly (myself and my coworker), neither of whom are idiots (in my estimation, although I'm obviously biased on the matter).
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-05 18:20 -0700 |
| Message-ID | <87zifu9vs2.fsf@nightsong.com> |
| In reply to | #56748 |
john <anon@example.com> writes: > I seem to remember when I was looking at assemblers that fasm does > multiple passes to perform some optimisation. Perhaps a fasm user could > confirm that? I don't know about fasm, but there are instruction sets where branch instructions can be encoded more compactly if the branch target is within a certain distance. But that distance might depend on the encodings of intervening branch instructions, so it can take a few iterations to get the shortest possible encoding.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-05 20:14 -0700 |
| Message-ID | <cf7e8f98-9839-4faa-b734-8e0ad9f8d1d1@googlegroups.com> |
| In reply to | #56747 |
On Wednesday, April 5, 2017 at 11:04:31 AM UTC-5, Andrew Haley wrote: > krishna.myneni@ccreweb.org wrote: > > On Wednesday, April 5, 2017 at 2:00:45 AM UTC-5, minf...@arcor.de wrote: > > ... > > >> C and Assembler are well suited to shoot one's own foot. But that > >> does not imply that you have to protect the shootist. Forth is full > >> of unspecified corners as well. No reason for language talibanism. > > > > You miss an important distinction between C and assembler -- the > > ability to predict the actual instructions executed by the processor > > and the order in which they are executed. One can look at assembly > > language code and predict exactly which machine instructions will be > > executed and in what order. > > Not necessarily, no. There are lots of things one can do in assembly > code which lead to behaviour you or I, the programmer, can't predict. > It happens to me all the time. All you have to do is overwite some > critical register or forget to initialize it. Or forget to insert a > memory fence instruction. That's one of the favourites because it > causes rare and hard-to-find bugs. Or, or... > Given the full initial state of the processor+memory at a given instant, prior to executing a finite set of instructions, expressed as a set of source code lines in assembly, it is not impossible to simulate the executed sequence of instructions and the successive states of the processor+memory. I'm not talking about solving the halting problem. All I'm saying is that the assembly code source permits such a trace of the system. Now, given a specific C compiler and a specific set of lines of C code, it is also possible to do the same, but only by knowing its optimization rules in full detail, or by examining the intermediate assembly code. Two different C compilers on the same system, or a single compiler at different optimization levels, will generate a different set of machine instructions. Two different assemblers on the same system, with the same assembly source, and allowing for syntax differences, better generate the same sequence of machine instructions, except for maybe minor differences such as near or long jumps. It is in that sense that I'm saying assembly language source is more predictable than C source code. > > That ability is gone with optimized C compilers which are given > > license to eliminate and/or reorder source code instructions during > > compilation. C is very different from assembly language in this > > sense. > > I don't think there's really any difference. > It's a matter of trusting the compiler will code what you ask it to do, and understanding the cases of undefined behavior when the compiler may not generate expected code. It's not clear to me that mere mortals can keep track of all of the cases of UB in the C standard, and the latitude given to compilers to do different things in those cases. Certainly coding guidelines, e.g. NASA's C coding guidelines (ref. 1) can help avoid such difficulties. But, it's also clear that mere mortal programmers may be easily confused. See the old thread on comp.std.c (ref. 2). Even some of the experts had problems with the interpretation of the standard; but, to be fair, that's an old thread. I intend to continue using the GNU C++ and C compilers, but with -O0 and -Wall flags turned on. Some of the code it generates at -O0 is fairly ugly, but I expect it's reliable when the source is not UB. Krishna 1. http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/ 2. https://groups.google.com/d/msg/comp.std.c/9lYbeLVaZCA/__behqP09dIJ
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-06 12:33 +0000 |
| Message-ID | <IAqFA.243119$0L.131983@fx12.am4> |
| In reply to | #56767 |
Since this has become about C now , I'm crossposting to comp.lang.c
and setting follow-ups to the same.
On Wed, 5 Apr 2017 20:14:27 -0700 (PDT)
krishna.myneni@ccreweb.org wrote:
> It's a matter of trusting the compiler will code what you ask it to do,
> and understanding the cases of undefined behavior when the compiler may
> not generate expected code. It's not clear to me that mere mortals can
> keep track of all of the cases of UB in the C standard, and the latitude
> given to compilers to do different things in those cases.
I'm a mere mortal and I can certainly keep track of UB relevant to the code
I write. In most cases it's actually common sense. For example I don't need
to consult the C standard to know that trying to read beyond the bounds of
an array will probably not result in anything useful because , even *conceptually*
(i.e. without referring to the standard of any specific language) , it doesn't
make sense. Perhaps the confusion arises because some people when programming
in C are not thinking in terms of C but in terms of assembly. So they translate
mentally the C code in some generic assembly instructions and then try to decide
if the C code does something meaningful based on what those hypothetical assembly
instructions will do.
Example : the expression array[i] where i is beyond the end of the array.
Thinking in terms of C : Not defined which means you aren't going to get anything
useful so you shouldn't use it. Pondering or testing what's the most crazy thing
which might happen , may be a bit of fun every now and again but is not relevant to
practical programming.
Thinking in terms of assembly : "array[i] will be translated into an assembly
instruction which calculates an address of the form base + i * constant .
This will always point into some address in memory so I should get some value
or at least a segmentation fault ; so not a totally unpredictable result."
Note first that not thinking in terms of C is more complicated and requires more
knowledge than thinking in terms of C. Second , if one wants to think in terms of
assembly then , from a practical point of view , it makes sense to program in
assembly , not C.
> Certainly coding guidelines, e.g. NASA's C coding guidelines (ref. 1) can
> help avoid such difficulties. But, it's also clear that mere mortal
> programmers may be easily confused. See the old thread on comp.std.c (ref. 2).
> Even some of the experts had problems with the interpretation of the standard;
> but, to be fair, that's an old thread.
[ References are
1. http://sdtimes.com/nasas-10-rules-developing-safety-critical-code
and
2. https://groups.google.com/d/msg/comp.std.c/9lYbeLVaZCA/__behqP09dIJ
]
Regarding the NASA guidelines , they are unsuitable for a lot of desktop software.
For example "Do not use dynamic memory allocation after initialization." .How
are you going to implement for example the Unix sort utility without using
realloc() (depending on the size of the input) ?
Your second reference has
char *index;
....
*index++ = toupper(*index);
.He doesn't explain why he decided to write code like this as opposed to
*index = toupper(*index);
index++ ;
.The latter seems to me more readable. So unless he had good reasons to prefer the
first version then worrying whether it's undefined behaviour is irrelevant for
programming ; one simply shouldn't write code like this. Do you have an example
of C code which satisfies the following 3 criteria ?
1. Is not contrived (according to your judgement).
2. You are not sure whether it has defined behaviour.
3. You do not see an obvious and easy way to change it so that it does what you
want *and* doesn't look contrived (according to your judgement) *and* you are
sure is not undefined behaviour.
> I intend to continue using the GNU C++ and C compilers, but with -O0 and
> -Wall flags turned on. Some of the code it generates at -O0 is fairly ugly,
> but I expect it's reliable when the source is not UB.
I don't think the -O0 part makes sense. If the compiler has bugs and miscompiles
correct code then you want to find this out as early as possible rather than at a
later point where you many need a higher optimisation level because otherwise the
code does not run fast enough. If your code has undefined behaviour then if it does
what you want then it's only by coincidence and your luck may run out even if you
always use -O0 .So in my opinion , one should at least conduct some tests with
other optimisation levels (and preferably using multiple compilers) to see if the
code continues to run correctly.
--
Every application has an inherent amount of irreducible complexity. The only
question is: Who will have to deal with it\u2014the user, the application
developer, or the platform developer?
http://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-06 10:49 -0700 |
| Message-ID | <97720dd3-8636-4e86-a752-b97ed54ef596@googlegroups.com> |
| In reply to | #56782 |
On Thursday, April 6, 2017 at 7:33:45 AM UTC-5, Spiros Bousbouras wrote: > Since this has become about C now , I'm crossposting to comp.lang.c > and setting follow-ups to the same. > > On Wed, 5 Apr 2017 20:14:27 -0700 (PDT) > krishna.myneni@ccreweb.org wrote: > > It's a matter of trusting the compiler will code what you ask it to do, > > and understanding the cases of undefined behavior when the compiler may > > not generate expected code. It's not clear to me that mere mortals can > > keep track of all of the cases of UB in the C standard, and the latitude > > given to compilers to do different things in those cases. > > I'm a mere mortal and I can certainly keep track of UB relevant to the code > I write. In most cases it's actually common sense. For example I don't need > to consult the C standard to know that trying to read beyond the bounds of > an array will probably not result in anything useful because , even *conceptually* > (i.e. without referring to the standard of any specific language) , it doesn't > make sense. ... There are over 200 undefined behavior cases documented in the C11 standard. I haven't reviewed the full list, and without doing so, I won't comment further on how "common sense" such cases are. However, the cases which are of most concern are the ones which were idioms typically in use, and relied upon by programmers. Destroying that backwards compatibility seems foolish. > Note first that not thinking in terms of C is more complicated and requires more > knowledge than thinking in terms of C. Second , if one wants to think in terms of > assembly then , from a practical point of view , it makes sense to program in > assembly , not C. > I'm not sure what the above means. I don't think in a computer language when I have a computation problem at hand that I want to express in code. Although I'm guessing many programmers skip this part, it's useful to write down the computation problem in pseudo-code, which is usually a high-level abstraction. I don't immediately start writing C or assembly code. > > [ References are > 1. http://sdtimes.com/nasas-10-rules-developing-safety-critical-code > and > 2. https://groups.google.com/d/msg/comp.std.c/9lYbeLVaZCA/__behqP09dIJ > ] > > Regarding the NASA guidelines , they are unsuitable for a lot of desktop software. > For example "Do not use dynamic memory allocation after initialization." ... Good point. Not all of the guidelines apply for every case. Their focus is on embedded systems which must run continuously for years. > Your second reference has > char *index; > .... > *index++ = toupper(*index); > > .He doesn't explain why he decided to write code like this as opposed to > *index = toupper(*index); > index++ ; ... The point of referring to this thread was not the coding problem at hand, which was use of an idiom that was common. It was the pervasive confusion among many C experts, including at least one who was apparently present for the standards meeting, about how to classify the statement as undefined behavior in terms of the language of the (developing) standard at that time. Even Dennis Ritchie chimes in, apparently with some comments not relevant to the discussion at hand. Reading the full thread will reveal that it may not be so easy as you think to determine when code will have undefined behavior based on the standards language. > So unless he had good reasons to prefer the first version then worrying whether it's undefined behaviour is irrelevant for programming ; ... > For the rest of your query, I will refer you to Anton's paper, http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf > > I intend to continue using the GNU C++ and C compilers, but with -O0 and > > -Wall flags turned on. Some of the code it generates at -O0 is fairly ugly, > > but I expect it's reliable when the source is not UB. > > I don't think the -O0 part makes sense. If the compiler has bugs and miscompiles > correct code then you want to find this out as early as possible rather than at a > later point where you many need a higher optimisation level because otherwise the > code does not run fast enough. If your code has undefined behaviour then if it does > what you want then it's only by coincidence and your luck may run out even if you > always use -O0 . The -O0 is to prevent the compiler from optimizing the code, although as Anton shows in his paper, GCC still seems to make some optimizations at this level. If the compiler is buggy, that will hopefully come out in the testing of the code. The -Wall option is used to find undefined behavior in the C source. For example, for the source statement i = i++ + 2; GCC with -Wall -O0 flags gives the following output: warning: operation on ‘i’ may be undefined [-Wsequence-point] > So in my opinion , one should at least conduct some tests with > other optimisation levels ... Agreed, but, as I mentioned earlier, the efficiency of the C++ and C code is not relevant to my Forth system, since the words are mostly in assembler, as well as the virtual machine. When very high efficiency is a concern, I've come to prefer implementing the algorithm in assembler, including in the Forth assembler. For example, the following numerical integration algorithm is implemented in assembler and can be called from within the Forth environmen. No doubt an optimizing Forth compiler can achieve the same or perhaps exceed the efficiency of this code. However, I can maintain, debug, or extend this code, which is something I can't do with the C optimizer output. ftp://ccreweb.org/software/kforth/examples/fsl/extras/numerov_x86.4th Krishna
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-06 18:55 +0100 |
| Message-ID | <oc5v92$k13$1@dont-email.me> |
| In reply to | #56786 |
On 4/6/2017 18:49, krishna.myneni@ccreweb.org wrote: > For the rest of your query, I will refer you to Anton's paper, > > http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29..pdf Corrected link http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-06 20:41 +0000 |
| Message-ID | <OJxFA.617542$nT1.544483@fx44.am4> |
| In reply to | #56788 |
On Thu, 6 Apr 2017 18:55:36 +0100
Alex <alex@rivadpm.com> wrote:
> On 4/6/2017 18:49, krishna.myneni@ccreweb.org wrote:
> > For the rest of your query, I will refer you to Anton's paper,
> >
> > http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29..pdf
>
> Corrected link
> http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
Krishna's link was already correct. To be precise , his post has
http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29=
.pdf
and
Content-Transfer-Encoding: quoted-printable
in the header so after the required unfolding
http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29=
.pdf
becomes
http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
It would seem that your newsreader has a bug (or undefined behaviour ;-)
w3m also displays it wrong ("29..pdf" instead of "29.pdf"). Interesting ;
I can't imagine what coding error would create the same mistake in 2 different
readers.
https://groups.google.com/d/msg/comp.lang.forth/pPVv1nVH0ZI/hw7J_1KhAQAJ
shows it right.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-06 21:47 +0100 |
| Message-ID | <oc69c6$ovj$1@dont-email.me> |
| In reply to | #56790 |
On 4/6/2017 21:41, Spiros Bousbouras wrote: > It would seem that your newsreader has a bug Thunderbird 45.8.0 -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-06 21:56 +0100 |
| Message-ID | <oc69s2$qrb$1@dont-email.me> |
| In reply to | #56791 |
On 4/6/2017 21:47, Alex wrote: > On 4/6/2017 21:41, Spiros Bousbouras wrote: >> It would seem that your newsreader has a bug > > Thunderbird 45.8.0 > As does Google Groups. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-06 23:59 -0400 |
| Message-ID | <20170406235909.38ff9560@_> |
| In reply to | #56792 |
On Thu, 6 Apr 2017 21:56:24 +0100 Alex <alex@rivadpm.com> wrote: > On 4/6/2017 21:47, Alex wrote: > > On 4/6/2017 21:41, Spiros Bousbouras wrote: > >> It would seem that your newsreader has a bug > > > > Thunderbird 45.8.0 > > > The OP's link appears correct here. Claws-mail 3.13.1. It appears correct in the message source view too. > As does Google Groups. Google Groups link appears correct here. Firefox 52.0.2. It appears correct in the message source view too. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-04-06 17:10 -0700 |
| Message-ID | <e159e6aa-1237-4bfb-8891-4bb144dd34bb@googlegroups.com> |
| In reply to | #56782 |
On Thursday, April 6, 2017 at 9:33:45 PM UTC+9, Spiros Bousbouras wrote:
> Since this has become about C now , I'm crossposting to comp.lang.c
> and setting follow-ups to the same.
I'm using Google groups because I'm lazy, so I have no idea whether this will maintain the cross-post.
> On Wed, 5 Apr 2017 20:14:27 -0700 (PDT)
> krishna(something)@(something).(something) wrote:
> > It's a matter of trusting the compiler will code what you ask it to do,
> > and understanding the cases of undefined behavior when the compiler may
> > not generate expected code. It's not clear to me that mere mortals can
> > keep track of all of the cases of UB in the C standard, and the latitude
> > given to compilers to do different things in those cases.
>
> I'm a mere mortal and I can certainly keep track of UB relevant to the code
> I write. In most cases it's actually common sense. For example I don't need
> to consult the C standard to know that trying to read beyond the bounds of
> an array will probably not result in anything useful because , even *conceptually*
> (i.e. without referring to the standard of any specific language) , it doesn't
> make sense. Perhaps the confusion arises because some people when programming
> in C are not thinking in terms of C but in terms of assembly. So they translate
> mentally the C code in some generic assembly instructions and then try to decide
> if the C code does something meaningful based on what those hypothetical assembly
> instructions will do.
>
> Example : the expression array[i] where i is beyond the end of the array.
The problem here is knowing whether your loop properly accesses the first and last elements of an array. Too many programmers are too lazy to understand the concept of where the exit comes in a loop, and too lazy to learn to track the state of the variables relevant to the loop control.
"Undefined Behavior" has two meanings here. Perhaps the C standard should have said "undefinable behavior", but that has certain potential misinterpretations as well.
> Thinking in terms of C : Not defined which means you aren't going to get anything
> useful so you shouldn't use it.
That's the approach Anton seems to be rather militant about. (And I don't blame him.)
But it's actually a third meaning for UB.
According to a common-sense interpretation (unless you are one who spews demons from your nose when faced with code that does not generalize well in certain corner-cutting hardware contexts), the standard defines UB as having the potential to be mean something different or nothing at all in certain contexts that the standards committee chose to accept as permissible relative to the standard, mostly because of the charismatic influence of the practitioners of said hardware.
("Charismatic" here refers to the sort of the charisma that includes the Kim family among leaders who rule by "charisma".)
> Pondering or testing what's the most crazy thing
> which might happen , may be a bit of fun every now and again but is not relevant to
> practical programming.
Being unable to specify target hardware is another way to invite bugs.
> Thinking in terms of assembly : "array[i] will be translated into an assembly
> instruction which calculates an address of the form base + i * constant .
> This will always point into some address in memory so I should get some value
> or at least a segmentation fault ; so not a totally unpredictable result."
Some people conflate segmentation fault with UB, partly, we might guess, because they do not understand why, uhm, segmentation should fault. ;->
> Note first that not thinking in terms of C is more complicated and requires more
> knowledge than thinking in terms of C.
I'm not sure I could agree with this. Current "standard" C is way more complicated than most of the practitioners thereof have any idea.
> Second , if one wants to think in terms of
> assembly then , from a practical point of view , it makes sense to program in
> assembly , not C.
Hear! Hear!
(Which is what attracts some people to Forth, really.)
> > Certainly coding guidelines, e.g. NASA's C coding guidelines (ref. 1) can
> > help avoid such difficulties. But, it's also clear that mere mortal
> > programmers may be easily confused.
No one who claims to be an engineer should ever refer to him/herself as a mere mortal as an excuse for not understanding the tools he or she as fully as possible.
Sure, it easily becomes idolatry, and is among the sins of society, to require certain occupations to operate in hero mode, but if engineers don't operate in hero mode, airplanes fall from the sky, etc.
> > See the old thread on comp.std.c (ref. 2).
> > Even some of the experts had problems with the interpretation of the standard;
> > but, to be fair, that's an old thread.
>
> [ References are
> 1. http://sdtimes.com/nasas-10-rules-developing-safety-critical-code
> and
> 2. https://groups.google.com/d/msg/comp.std.c/9lYbeLVaZCA/__behqP09dIJ
> ]
>
> Regarding the NASA guidelines , they are unsuitable for a lot of desktop software.
> For example "Do not use dynamic memory allocation after initialization." .How
> are you going to implement for example the Unix sort utility without using
> realloc() (depending on the size of the input) ?
>
> Your second reference has
> char *index;
> ....
> *index++ = toupper(*index);
>
> .He doesn't explain why he decided to write code like this as opposed to
> *index = toupper(*index);
> index++ ;
>
> .The latter seems to me more readable. So unless he had good reasons to prefer the
> first version then worrying whether it's undefined behaviour is irrelevant for
> programming ; one simply shouldn't write code like this.
I'll say amen to that, too.
I used to be a fan of auto-increment modes, but then I realized how many times I had been writing i++ when I really meant ++i, just because some pedant was scared of surprising later programmers with an idiom that wasn't probably taught in schools. (And ten years later, those who breath demons have finally begun to recognize that i = i + 1 in a C program is ++i, not i++. And get too excited about the fact.)
> Do you have an example
> of C code which satisfies the following 3 criteria ?
>
> 1. Is not contrived (according to your judgement).
> 2. You are not sure whether it has defined behaviour.
> 3. You do not see an obvious and easy way to change it so that it does what you
> want *and* doesn't look contrived (according to your judgement) *and* you are
> sure is not undefined behaviour.
I'm a late-comer to the conversation, but I have a few sitting around in my piles of old code.
I remember being excited to recognize that the reason my old assembler for the 6800, which I had written in college, was failing to run on my modern stuff was that I had, without realizing it, depended on a run-time semantic of dereferencing a NULL pointer. That one I understand now. But I know there are still dark corners hiding in code that I think I understand.
Yes, illuminating those dark corners is important. But it would be nice for the drunk policeman to allow me to continue looking where they wallet fell, rather than insist that I look under the lamp where there is light. So to speak.
> > I intend to continue using the GNU C++ and C compilers, but with -O0 and
> > -Wall flags turned on. Some of the code it generates at -O0 is fairly ugly,
> > but I expect it's reliable when the source is not UB.
>
> I don't think the -O0 part makes sense. If the compiler has bugs and miscompiles
> correct code then you want to find this out as early as possible rather than at a
> later point where you many need a higher optimisation level because otherwise the
> code does not run fast enough. If your code has undefined behaviour then if it does
> what you want then it's only by coincidence and your luck may run out even if you
> always use -O0 .So in my opinion , one should at least conduct some tests with
> other optimisation levels (and preferably using multiple compilers) to see if the
> code continues to run correctly.
Wish management would be more willing to put up with this kind of exploration, but that almighty false proxy of value is the bottom line.
> --
> Every application has an inherent amount of irreducible complexity. The only
> question is: Who will have to deal with it\u2014the user, the application
> developer, or the platform developer?
> http://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html
--
Joel Rees
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-07 03:33 -0400 |
| Message-ID | <20170407033309.1b6469f0@_> |
| In reply to | #56782 |
On Thu, 06 Apr 2017 12:33:44 GMT Spiros Bousbouras <spibou@gmail.com> wrote: This post was intended for c.l.f. since the issues dealt with comparison of Forth and C functionality. I've re-posted it here since it made it to c.l.c. instead of c.l.f. Spiros redirected which was not expected as I took note of the topic from a reply to him on c.l.f. ... Hopefully, those on c.l.c. will not redirect their crap here. I'm not even interested in seeing what type of shit those idiots posted in response. > Example : the expression array[i] where i is beyond the end of the > array. FYI, C explicitly allows you to access one element past the end of the array. This is to allow you to access the nul character when comparing strings to check for string termination. If you go beyond that though, it's undefined ... However, many C implementations use the ability to access outside a C object behind the scenes without any issues, e.g., to access a memory header prior to malloc'd memory blocks. > Thinking in terms of assembly : "array[i] will be translated into an > assembly instruction which calculates an address of the form base + > i * constant . This is a requirement of the subscript operator [] for K&R, ANSI, and ISO C. It's in all the standards. They define "E1[E2]" to be equivalent to "*((E1)+(E2))". The subscript operator takes a pointer to a type and also an index. The index is scaled by the size of the data type pointed to. The pointer which cannot be a pointer-to-void 'void *' since 'void' has no data type, i.e., no size, pointer only. The pointer used in the subscript operator can be any pointer to any valid type, not just pointer for array types. The arguments to the subscript operator can be either order, e.g., "0123456789"[i] is equivalent to i["0123456789"] . Technically, you should think of the subscript operator as just the left-brace, then you'll understand it's like any other operator in C, e.g., arithmetic +, -> component selection, or whatever. BTW, the other required equivalence is "E1->MOS" is equivalent to "(*E1).MOS". This is the equivalence between the two component selection operators . and -> > This will always point into some address in memory so > I should get some value or at least a segmentation fault ; so not a > totally unpredictable result." C's objects don't have bounds checks built in. It's not an object-oriented language. So, it's up to the programmer to make sure that they're within range. > Note first that not thinking in terms of C is more complicated and > requires more knowledge than thinking in terms of C. Second , if one > wants to think in terms of assembly then , from a practical point of > view , it makes sense to program in assembly , not C. Non sequitur. IMO, the key reasons to use C instead of assembly are the ability to use variables and the portability of the code. Even so, you need to understand how your code is converted to assembly or at least check the compiler output. > How are you going to implement for example > the Unix sort utility without using realloc() (depending on the > size of the input) ? I don't follow. I've never had to use realloc() for anything, ever. If you're manipulating large data sets in C, it's better to use files instead of memory. > Your second reference has > char *index; > .... > *index++ = toupper(*index); > > .He doesn't explain why he decided to write code like this as opposed > to *index = toupper(*index); > index++ ; I'm guessing that this is most likely just pre-ANSI C. Most C style guides etc are older and are for K&R C. E.g., most will recommend that you use #defines and mask with logical-and instead of using bit-fields, since many earlier C compilers were broken. They also recommend avoiding enums for similar reasons. They also recommend placing numbers in comparisons as "if(0==value)" instead of "if(value==0)" to detect incorrect assignments such as "if(value=0)". etc. They'll also say not to use the address of a struct by itself, i.e., as a pointer, since an early, widespread C compiler, PCC, didn't keep track of the struct's name or somesuch issue ... ANSI C added other problems, e.g., obsoleted implicit int's since they caused a syntax conflict with typedef's, messed up pre- and post- increment and decrement operators, etc. Of course, C has some required behavior, which is not part of some of the standards, such as the C struct hack and Duff's device, which must work correctly. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web