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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-09 22:27 -0500 |
| Message-ID | <6eulech58rtdlimgkgvfc1cih7ohu7vtrk@4ax.com> |
| In reply to | #56965 |
On Sun, 9 Apr 2017 22:46:04 -0400, James Kuyper <jameskuyper@verizon.net> wrote: >On 04/09/2017 08:38 PM, Spiros Bousbouras wrote: >> [ Crossposted to comp.lang.c since we need some C lawyers ;-) ] >> >> On Sun, 09 Apr 2017 14:53:01 GMT >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >... >>> I once >>> <2015May1.155805@mips.complang.tuwien.ac.at> wrote: >>> >>> |It seems to me that >>> | >>> | if ((size_t)(dest-src) < len) >>> | >>> |is a more efficient way to test whether dest is inside [src, src+len). >>> | >>> |Of course, since this code contains more than three tokens, it is >>> |likely to contain undefined behaviour >>> >>> That was mostly in jest, but a post or two later, someone explained >>> that yes, this code is undefined. So while I do not see anything >>> undefined about the code you posted, just let the language lawyers at >>> it, and they will point it out. >> >> Ok , we'll see what the language lawyers say. > >It would help to know what the relevant data types are, but the comment >about "dest is inside [src, src+len] suggests that dest and src are both >pointers. The C standard defines subtraction of pointers in terms of >positions in the SAME array. If src and dest don't both point into or >one past the end of the same array, subtraction of those pointers has >undefined behavior (6.5.6p9). >Consider an implementation of C targeting a machine with a >segment-offset architecture, where every pointer into a given object >(including pointers to sub-objects) has the same segment value (which >implies that no object can be bigger than a single segment), while >pointers into completely unrelated objects will, in general, have >different segments. On such a machine, the fact that this behavior is >undefined means that a fully conforming implementation of C is allowed >to implement pointer subtraction by simply subtracting the offsets and >IGNORING the segment numbers. Feel free to figure out the implications >that would have for your dest-size test. > >... >>>> A >>>> *constructive* thing to do (as opposed to complaining) would be to describe >>>> what guarantees with regard to C pointer comparisons on top of the C standard >>>> would be needed to do what you want to do. Then you could ask on comp.lang.c >>>> or some compiler mailing list whether these additional guarantees can be >>>> offered by using some appropriate flag and if not how easy would be to implement >>>> them as an extension. >>> >>> If you think that's a promising approach, go ahead. My experience is >>> that they always tell you to go to the C standards committee. > >Redirecting you to the standards committee would be an inappropriate >response to a inquiry about the existence or feasibility of an extension >to C. Are you sure you didn't word your inquiry in such a way that it >sounded like you were asking for a change to the standard itself? > >> Before you go to the C standards committee you need to have a specific proposal. I >> take it that for C to be a suitable back end for implementing Forth , you want >> comparison of C pointers pointing to different objects to be defined. Could you > >Note: C++ requires that std::less<T*> must provide a total ordering of >all pointers of type T*, even if the "<" operator does not provide such >an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage >with C that the fact that the C++ standard can successfully impose this >requirement strongly suggests that the C standard could impose a similar >requirement. >However, it's telling that C++ did NOT impose this requirement on the >"<" operator itself, but only on std::less<T*>. That's because there are >some systems where meeting this requirement makes std::less<T*>(p,q) >substantially slower than p<q. It also does not (necessarily) produce the same ordering as does the built-in operator <. It does if the built-in < comparison is between objects that can be compared without undefined behavior, but if not, the two can produce different results. It also does not require any particular order for those objects, just a consistent one - that might become visible if the objects overlap in memory. IOW, if you have two overlapping objects of 10 bytes each, A and B, with an overlap of five bytes, such that A[5] is the same position in storage as B[0], there's no requirement that std::less actually order A before B. Of course, that kind of overlap is undefined behavior itself.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-10 12:36 +0000 |
| Message-ID | <Q_KGA.516603$jb5.352205@fx25.am4> |
| In reply to | #56965 |
On Sun, 9 Apr 2017 22:46:04 -0400
James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/09/2017 08:38 PM, Spiros Bousbouras wrote:
> > [ Crossposted to comp.lang.c since we need some C lawyers ;-) ]
> >
> > On Sun, 09 Apr 2017 14:53:01 GMT
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> ...
> >> I once
> >> <2015May1.155805@mips.complang.tuwien.ac.at> wrote:
> >>
> >> |It seems to me that
> >> |
> >> | if ((size_t)(dest-src) < len)
> >> |
> >> |is a more efficient way to test whether dest is inside [src, src+len).
> >> |
> >> |Of course, since this code contains more than three tokens, it is
> >> |likely to contain undefined behaviour
> >>
> >> That was mostly in jest, but a post or two later, someone explained
> >> that yes, this code is undefined. So while I do not see anything
> >> undefined about the code you posted, just let the language lawyers at
> >> it, and they will point it out.
> >
> > Ok , we'll see what the language lawyers say.
>
> It would help to know what the relevant data types are, but the comment
> about "dest is inside [src, src+len] suggests that dest and src are both
> pointers.
Actually the code in question was
int is_leap_year(unsigned int year) {
return 1 ;
}
.It was for this code that Anton posted
I don't think it is trivial to see that this is defined.
and
So while I do not see anything undefined about the code you posted,
just let the language lawyers at it, and they will point it out.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-10 14:09 +0100 |
| Message-ID | <87y3v8s936.fsf@bsb.me.uk> |
| In reply to | #56994 |
Spiros Bousbouras <spibou@gmail.com> writes:
<snip>
> Actually the code in question was
>
> int is_leap_year(unsigned int year) {
> return 1 ;
> }
>
> .It was for this code that Anton posted
>
> I don't think it is trivial to see that this is defined.
> and
> So while I do not see anything undefined about the code you posted,
> just let the language lawyers at it, and they will point it out.
It's fine. The only possible question mark is the name since some
identifiers with external linkage that start with "is" are reserved, but
the reserved names are those where the following letter be lower-case.
is_<anything> is fine.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-10 13:07 +0000 |
| Message-ID | <HsLGA.931050$vF2.237690@fx46.am4> |
| In reply to | #56965 |
On Sun, 9 Apr 2017 22:46:04 -0400
James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/09/2017 08:38 PM, Spiros Bousbouras wrote:
> > [ Crossposted to comp.lang.c since we need some C lawyers ;-) ]
> >
> > On Sun, 09 Apr 2017 14:53:01 GMT
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
[...]
> > Before you go to the C standards committee you need to have a specific proposal. I
> > take it that for C to be a suitable back end for implementing Forth , you want
> > comparison of C pointers pointing to different objects to be defined. Could you
>
> Note: C++ requires that std::less<T*> must provide a total ordering of
> all pointers of type T*, even if the "<" operator does not provide such
> an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
> with C that the fact that the C++ standard can successfully impose this
> requirement strongly suggests that the C standard could impose a similar
> requirement.
> However, it's telling that C++ did NOT impose this requirement on the
> "<" operator itself, but only on std::less<T*>. That's because there are
> some systems where meeting this requirement makes std::less<T*>(p,q)
> substantially slower than p<q.
I wonder if for Anton's purposes and for a big endian machine the following
would do
int compare_pointers_to_void(void **p1 , void **p2) {
return memcmp(*p1 , *p2 , sizeof(void *)) ;
}
For a little endian machine you would have to write it by hand :
int compare_pointers_to_void(void **p1 , void **p2) {
size_t i = sizeof(void *) - 1 ;
const unsigned char * const pc1 = *p1 , * const pc2 = *p2 ;
while (1) {
if (pc1[i] > pc2[i]) return 1 ;
if (pc1[i] < pc2[i]) return -1 ;
if (i == 0) return 0 ;
i-- ;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-10 16:18 +0100 |
| Message-ID | <87h91ws345.fsf@bsb.me.uk> |
| In reply to | #56995 |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Sun, 9 Apr 2017 22:46:04 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 04/09/2017 08:38 PM, Spiros Bousbouras wrote:
>> > [ Crossposted to comp.lang.c since we need some C lawyers ;-) ]
>> >
>> > On Sun, 09 Apr 2017 14:53:01 GMT
>> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
> [...]
>
>> > Before you go to the C standards committee you need to have a specific proposal. I
>> > take it that for C to be a suitable back end for implementing Forth , you want
>> > comparison of C pointers pointing to different objects to be defined. Could you
>>
>> Note: C++ requires that std::less<T*> must provide a total ordering of
>> all pointers of type T*, even if the "<" operator does not provide such
>> an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
>> with C that the fact that the C++ standard can successfully impose this
>> requirement strongly suggests that the C standard could impose a similar
>> requirement.
>> However, it's telling that C++ did NOT impose this requirement on the
>> "<" operator itself, but only on std::less<T*>. That's because there are
>> some systems where meeting this requirement makes std::less<T*>(p,q)
>> substantially slower than p<q.
>
> I wonder if for Anton's purposes and for a big endian machine the following
> would do
>
> int compare_pointers_to_void(void **p1 , void **p2) {
> return memcmp(*p1 , *p2 , sizeof(void *)) ;
> }
That seems unlikely. You might have meant
int compare_pointers_to_void(void **p1, void **p2) {
return memcmp(p1, p2, sizeof (void *));
}
or, possibly,
int compare_pointers_to_void(void *p1, void *p2) {
return memcmp(&p1, &p2, sizeof (void *));
}
Note that using the idiom:
memcmp(<exp1>, <exp2>, sizeof *<exp1>);
can highlight indirection issues like this. Your example written in
this style is
int compare_pointers_to_void(void **p1, void **p2) {
return memcmp(*p1, *p2, sizeof **p1);
}
and sizeof **p1 is sizeof a void object -- undefined.
But even fixed, I doubt that comparing the representation of the
pointers is a good idea. If the system uses some peculiar segmented
architecture, that's going to go wrong. Even though it's not portable,
the best solution is usually to convert to an integer type. Where that
is meaningful, C99 implementations provide the type uintptr_t in
stdint.h.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-10 11:51 -0400 |
| Message-ID | <4c1e8cea-0ec5-7fe5-d5fa-adc0b894f96f@verizon.net> |
| In reply to | #56995 |
On 04/10/2017 09:07 AM, Spiros Bousbouras wrote:
> On Sun, 9 Apr 2017 22:46:04 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
...
>> Note: C++ requires that std::less<T*> must provide a total ordering of
>> all pointers of type T*, even if the "<" operator does not provide such
>> an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
>> with C that the fact that the C++ standard can successfully impose this
>> requirement strongly suggests that the C standard could impose a similar
>> requirement.
>> However, it's telling that C++ did NOT impose this requirement on the
>> "<" operator itself, but only on std::less<T*>. That's because there are
>> some systems where meeting this requirement makes std::less<T*>(p,q)
>> substantially slower than p<q.
>
> I wonder if for Anton's purposes and for a big endian machine the following
> would do
>
> int compare_pointers_to_void(void **p1 , void **p2) {
> return memcmp(*p1 , *p2 , sizeof(void *)) ;
> }
<sidetrack>
That seems unnecessarily complicated. To use it, if the pointers you
want to compare are the values of expressions, you first have to store
those values in void*. The same is true if you wan to compare pointers
that are not of type "void*". Then you would have to pass pointers to
those objects to compare_pointers_to_void(). Wouldn't it be simpler to
define:
int compare_pointers_to_void(void *p1, void *p2)
{
return memcmp(&p1, &p2, sizeof (void *));
}
This works on pointers of arbitrary types, which would all be implicitly
converted to void* before the function call, and requires no extra work
to apply it to a pointer-valued expression, rather than a pointer stored
in an object.
</sidetrack>
It's unlikely that such a work-around would actually work as desired on
any system where "<" would not - if the above code would in fact work,
that's precisely how "<" should be implemented by the compiler.
Implementations where "<" doesn't provide a total ordering generally use
a pointer representation for which your function would sometimes give
either the wrong order, or an order that is inconsistent. On some
systems, pointers to the same location in memory can have different
representations, so your function could even return a non-zero value for
equivalent pointers.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-12 21:32 +0000 |
| Message-ID | <K1xHA.311069$Fa7.217668@fx09.am4> |
| In reply to | #57005 |
On Mon, 10 Apr 2017 11:51:37 -0400
"James R. Kuyper" <jameskuyper@verizon.net> wrote:
> On 04/10/2017 09:07 AM, Spiros Bousbouras wrote:
> > On Sun, 9 Apr 2017 22:46:04 -0400
> > James Kuyper <jameskuyper@verizon.net> wrote:
> ...
> >> Note: C++ requires that std::less<T*> must provide a total ordering of
> >> all pointers of type T*, even if the "<" operator does not provide such
> >> an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
> >> with C that the fact that the C++ standard can successfully impose this
> >> requirement strongly suggests that the C standard could impose a similar
> >> requirement.
> >> However, it's telling that C++ did NOT impose this requirement on the
> >> "<" operator itself, but only on std::less<T*>. That's because there are
> >> some systems where meeting this requirement makes std::less<T*>(p,q)
> >> substantially slower than p<q.
> >
> > I wonder if for Anton's purposes and for a big endian machine the following
> > would do
> >
> > int compare_pointers_to_void(void **p1 , void **p2) {
> > return memcmp(*p1 , *p2 , sizeof(void *)) ;
> > }
>
> <sidetrack>
> That seems unnecessarily complicated. To use it, if the pointers you
> want to compare are the values of expressions, you first have to store
> those values in void*. The same is true if you wan to compare pointers
> that are not of type "void*". Then you would have to pass pointers to
> those objects to compare_pointers_to_void(). Wouldn't it be simpler to
> define:
>
> int compare_pointers_to_void(void *p1, void *p2)
> {
> return memcmp(&p1, &p2, sizeof (void *));
> }
>
> This works on pointers of arbitrary types, which would all be implicitly
> converted to void* before the function call, and requires no extra work
> to apply it to a pointer-valued expression, rather than a pointer stored
> in an object.
> </sidetrack>
Yes , your version is better.
> It's unlikely that such a work-around would actually work as desired on
> any system where "<" would not - if the above code would in fact work,
> that's precisely how "<" should be implemented by the compiler.
Isn't it more likely that the compiler would compare pointers by a single
assembly instruction as opposed a call to memcmp() ? In any case , the
whole point of my code is that it's defined even if the pointers point to
different objects. Whereas using < , if the pointers point to different
objects then the behaviour is undefined. So if the compiler can prove they
point to different objects then instead of emitting the "obvious" assembly
instruction which presumably would do what Anton wants , it may decide
instead to be a smart ass and do something totally unpredictable.
[ If I ever write a C compiler I will consider adding a -smartass option.
Precise functionality to be decided. ]
> Implementations where "<" doesn't provide a total ordering generally use
> a pointer representation for which your function would sometimes give
> either the wrong order, or an order that is inconsistent.
When you say "wrong order" do you mean that for pointers pointing to the
same object , compare_pointers_to_void() might not give the same result
as < ? And what about inconsistent ? Do you mean not satisfy transitivity ?
> On some
> systems, pointers to the same location in memory can have different
> representations, so your function could even return a non-zero value for
> equivalent pointers.
Fascinating. Can you give an example ?
--
Apple Computer reported today that it has developed computer chips that
can store and play music inside women's breasts. This is considered to
be a major breakthrough because women are always complaining about men
staring at their breasts and not listening to them.
<S1895.ccc@netfunny.com>
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-04-12 18:29 -0400 |
| Message-ID | <376d5048-c4af-914f-30f6-4761943a5c43@verizon.net> |
| In reply to | #57179 |
On 04/12/2017 05:32 PM, Spiros Bousbouras wrote:
> On Mon, 10 Apr 2017 11:51:37 -0400
> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
>> On 04/10/2017 09:07 AM, Spiros Bousbouras wrote:
>>> On Sun, 9 Apr 2017 22:46:04 -0400
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>> ...
>>>> Note: C++ requires that std::less<T*> must provide a total ordering of
>>>> all pointers of type T*, even if the "<" operator does not provide such
>>>> an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
>>>> with C that the fact that the C++ standard can successfully impose this
>>>> requirement strongly suggests that the C standard could impose a similar
>>>> requirement.
>>>> However, it's telling that C++ did NOT impose this requirement on the
>>>> "<" operator itself, but only on std::less<T*>. That's because there are
>>>> some systems where meeting this requirement makes std::less<T*>(p,q)
>>>> substantially slower than p<q.
>>>
>>> I wonder if for Anton's purposes and for a big endian machine the following
>>> would do
...
>> <sidetrack>
...
>> int compare_pointers_to_void(void *p1, void *p2)
>> {
>> return memcmp(&p1, &p2, sizeof (void *));
>> }
...
>> </sidetrack>
>
> Yes , your version is better.
>
>> It's unlikely that such a work-around would actually work as desired on
>> any system where "<" would not - if the above code would in fact work,
>> that's precisely how "<" should be implemented by the compiler.
>
> Isn't it more likely that the compiler would compare pointers by a single
> assembly instruction as opposed a call to memcmp() ?
I should have said "that's precisely equivalent to how "<" should be
implemented by the compiler. If the above code would work as desired,
then the assembly language instruction implementing p<q must perform
essentially the same job as memcmp(&p,&q,sizeof p)<0. To put it another
way, on such a platform, a sufficiently aggressively optimizing compiler
might optimize "memcmp(&p, &q, sizeof p) < 0" into that assembly
language instruction.
> In any case , the
> whole point of my code is that it's defined even if the pointers point to
> different objects. Whereas using < , if the pointers point to different
> objects then the behaviour is undefined. So if the compiler can prove they
> point to different objects then instead of emitting the "obvious" assembly
> instruction which presumably would do what Anton wants , it may decide
> instead to be a smart ass and do something totally unpredictable.
That's a legitimate point; if I needed the ability to compare pointers
to unrelated objects, I'd probably use C++ and std::less<T*> rather than
writing such a function. I'd expect the resulting program to execute
exactly as fast as direct use of "<", on any platform where
compare_pointers_to_void() would work as desired.
However, if you can't use C++, and you know that, for all of the
implementations where you need your code to work,
compare_pointers_to_void() does produce the results that you need, it's
a valid way of preventing dangerous optimizations that use of "<" would
allow.
Our client imposes stricter portability requirements than that on my
code. It must work correctly even on implementations where
compare_pointers_to_void() would not work as desired, so that wouldn't
be an option for me. This is not stated explicitly, but is implied by a
more general prohibition on writing code that works as intended only
with specific compilers.
>> Implementations where "<" doesn't provide a total ordering generally use
>> a pointer representation for which your function would sometimes give
>> either the wrong order, or an order that is inconsistent.
>
> When you say "wrong order" do you mean that for pointers pointing to the
> same object , compare_pointers_to_void() might not give the same result
> as < ? ...
Correct.
> ... And what about inconsistent ? Do you mean not satisfy transitivity ?
That's part of it. The following paragraph is about one of the other
forms that inconsistency can take:
>> On some
>> systems, pointers to the same location in memory can have different
>> representations, so your function could even return a non-zero value for
>> equivalent pointers.
>
> Fascinating. Can you give an example ?
The case I'm most familiar with is fairly out-of-date: a segment:offset
architecture where the segment size was only 64 bytes, so that a pointer
represented as 0x1234:0x7890 would point at the exact same location as
one represented by 0x1235:0x7850. Whether any more modern architecture
has multiple valid representations for the same memory location, I have
no idea. But since the C standard allows it, and has always allowed it,
I wouldn't recommend assuming that no modern implementation takes
advantage of that fact. As I mentioned above, I'm actually prohibited
from making such assumptions.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-12 15:29 -0700 |
| Message-ID | <c446f4c4-5747-4fb6-9594-fae7bc7fc79e@googlegroups.com> |
| In reply to | #57179 |
On Wednesday, April 12, 2017 at 2:32:27 PM UTC-7, Spiros Bousbouras wrote: > On Mon, 10 Apr 2017 11:51:37 -0400 > "James R. Kuyper" <jameskuyper@verizon.net> wrote: > > On some > > systems, pointers to the same location in memory can have different > > representations, so your function could even return a non-zero value for > > equivalent pointers. > > Fascinating. Can you give an example ? The 16-bit x86 did this. Just decrement the segment register by 1 and increment the offset by 16. > Apple Computer reported today that it has developed computer chips that > can store and play music inside women's breasts. This is considered to > be a major breakthrough because women are always complaining about men > staring at their breasts and not listening to them. > <S1895.ccc@netfunny.com> That was funny! :-D
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-13 02:55 +0200 |
| Message-ID | <ocmiae$bq2$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57179 |
In article <K1xHA.311069$Fa7.217668@fx09.am4>, Spiros Bousbouras <spibou@gmail.com> wrote: >On Mon, 10 Apr 2017 11:51:37 -0400 >"James R. Kuyper" <jameskuyper@verizon.net> wrote: <SNIP> >> On some >> systems, pointers to the same location in memory can have different >> representations, so your function could even return a non-zero value for >> equivalent pointers. > >Fascinating. Can you give an example ? Come one, can't you come up with an example yourself? An example is with the segmented addressing on the 8088. 0 1A0A FAR@ and 1 19FA FAR@ access the same location. So on a Forth with a particular memory model e.g. a 32 bit Forth with 1 Mbyte memory you'd want a special address comparision where 01A0A 119FA ADDRESS= gives TRUE. The memory compare solution doesn't work and neither does the 32 bit = that works for numbers. 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]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-04-10 18:38 -0700 |
| Message-ID | <6fd2cefa-5176-492d-a2a2-b4dc9a1b21b2@googlegroups.com> |
| In reply to | #56995 |
(Not seeing anywhere in the googlegroups interface that tells me whether this will get cross-posted to clc or not. I suppose I should be using a real newsreader.)
On Monday, April 10, 2017 at 10:07:53 PM UTC+9, Spiros Bousbouras wrote:
> On Sun, 9 Apr 2017 22:46:04 -0400
> James Kuyper wrote:
> > On 04/09/2017 08:38 PM, Spiros Bousbouras wrote:
> > > [ Crossposted to comp.lang.c since we need some C lawyers ;-) ]
> > >
> > > On Sun, 09 Apr 2017 14:53:01 GMT
> > > (Anton Ertl) wrote:
>
> [...]
>
> > > Before you go to the C standards committee you need to have a specific proposal. I
> > > take it that for C to be a suitable back end for implementing Forth , you want
> > > comparison of C pointers pointing to different objects to be defined. Could you
> >
> > Note: C++ requires that std::less<T*> must provide a total ordering of
> > all pointers of type T*, even if the "<" operator does not provide such
> > an ordering (20.9.5p14). C++ has a sufficiently strong shared heritage
> > with C that the fact that the C++ standard can successfully impose this
> > requirement strongly suggests that the C standard could impose a similar
> > requirement.
> > However, it's telling that C++ did NOT impose this requirement on the
> > "<" operator itself, but only on std::less<T*>. That's because there are
> > some systems where meeting this requirement makes std::less<T*>(p,q)
> > substantially slower than p<q.
>
> I wonder if for Anton's purposes and for a big endian machine the following
> would do
>
> int compare_pointers_to_void(void **p1 , void **p2) {
> return memcmp(*p1 , *p2 , sizeof(void *)) ;
> }
>
> For a little endian machine you would have to write it by hand :
>
> int compare_pointers_to_void(void **p1 , void **p2) {
> size_t i = sizeof(void *) - 1 ;
> const unsigned char * const pc1 = *p1 , * const pc2 = *p2 ;
> while (1) {
> if (pc1[i] > pc2[i]) return 1 ;
> if (pc1[i] < pc2[i]) return -1 ;
> if (i == 0) return 0 ;
> i-- ;
> }
> }
I would guess, relative to this thread, what Anton wants is something like a pragma that says that the entire runtime environment is one huge array.
Thus, you could reliably place what other languages would consider debugging symbol table information adjacent to the functions the clot of information describes, and your various allocation techniques would not have to figure out how to live nicely with whatever the compiler and libraries provides.
As it, the safest thing to do is to separate the kernel of Forth from the things that the current session is defining. And that makes it really difficult to manage both the kernel words (functions and their headers) and the ones added on by the application being built in the current session with a single set of symbol table routines.
There are a lot of implications to this, some of them security implications, especially since Intel has never really taken proper memory management seriously and never will, as long as they can't shake themselves loose of the need to believe their junk CPU is the fastest in the universe. (Sorry about that run-on train of thought.)
The way I plan on solving this in my toy, bif-c, is to go ahead and allocate the symbol table separately from the running code, and set a second, unmovable FINAL-FENCE to ward off attempts to FORGET the kernel.
And consider that having the kernel sticking around like an atrophied appendix in a re-compiled system is just a small bit of overhead, at least until I write the code to produce an object file that the OS can recognize. Or maybe I'll be able to figure out a portable way to use the kernel as the linkage into the system provided libraries, so that it isn't just useless overhead.
And I'm sure that Anton has been through all this ahead of me, and just keep bumping into areas where the standard really goes a little too far into enabling overly aggressive compiler writers to turn their fantasies about winged monkeys flying out of dark places into a reason to delete code that doesn't appear to be reasonable to them.
--
Joel Rees
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-10 11:54 -0500 |
| Message-ID | <-4-dnQAyotwkJXbFnZ2dnUU7-cPNnZ2d@supernews.com> |
| In reply to | #56789 |
Spiros Bousbouras <spibou@gmail.com> wrote: > Here we need to make a distinction : I will term "weak undefined > behaviour" (WUB) C code which is not defined according to the C > standard and "strong undefined behaviour" (SUB) C code which is not > defined according to *anything* where "anything" could mean some > standard which enhances the C standard (like POSIX) and also > relevant documentation of the compiler or libraries one uses or > whatever. Our main conern here is predictable behaviour of the code > so I believe the deciding concept is SUB rather than WUB. This is an interesting distinction to make. I think these behaviours are more or less between what would be well-defined if C really were a kind of high-level assembly language (with well-defined overflow behaviour, freely-convertible pointers, etc, etc.) and what wouldn't. The SUB would be stuff like buffer overflows (where the buffer is on the stack) where all you know is that something very bad might happen, or nothing at all might happen, and the only way to find out is to try it. At the edges it'd be tricky to try to figure out which kind of UB applies. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-10 10:17 -0700 |
| Message-ID | <87tw5w6v2i.fsf@nightsong.com> |
| In reply to | #57006 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > The SUB would be stuff like buffer overflows ... At the edges it'd be > tricky to try to figure out which kind of UB applies. I think there have various failed attempts to do this, like "Friendly C". At the end, C is in something of an "uncanny valley" that gets both low-level and higher-level programmers confused. We'd be better of separating the two sets of requirements and not trying to address them with a one-size-fits-all solution.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-03 17:02 +0100 |
| Message-ID | <obtrho$ord$1@dont-email.me> |
| In reply to | #56659 |
On 4/3/2017 13:55, Anton Ertl wrote: > Bullshit. Bullshit. Bullshit. Bullshit. Bullshit. A whole > paragraph of bullshit, with every single sentence being bullshit. Steady on Anton. I think we got the point after the first incantation. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-03 10:03 -0700 |
| Message-ID | <35677928-3e35-419f-a620-4d81f605e286@googlegroups.com> |
| In reply to | #56659 |
On Monday, April 3, 2017 at 6:51:35 AM UTC-7, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >krishna.myneni@ccreweb.org wrote: > >> 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? > > > >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, which isn't difficult, > >you'd be fine. I don't think there are any Forth constructs that > >wouldn't translate easily. The real problem occurs when you're trying > >to generate highly efficient C. > > Bullshit. Bullshit. Bullshit. Bullshit. Bullshit. A whole > paragraph of bullshit, with every single sentence being bullshit. You > don't have to believe me, in the following I refute them by one: ... Anton --- why don't you tell us how you really feel? Also, why don't you just use 64-bit x86 assembly-language? In the old days, there were multiple processors in use: 1.) First, we had the Z80 and the 65c02, plus some others such as the MC6809 etc.. 2.) Then we had the i8086 and the MC68000, plus some others such as the i8096 etc.. 3.) Then we had the Pentium and the PowerPC and the ARM, plus some others such as the DEC Alpha etc.. 4.) Now we have the 64-bit x86 for desktop computers and the 32-bit ARM for micro-controllers, and the others (the PIC24 PIC32 etc.) have such a small market share as to be irrelevant. Gforth is for desktop computers, so just write in 64-bit x86 --- I like FASM, but NASM etc. have their fans --- there isn't going to be any other desktop-computer processor within our lifetimes. Of course, computers such as the Raspberry Pi can be used like handheld desktop-computers --- they have such a small market share as to be irrelevant --- if a gnu 32-bit ARM Forth is developed it should be designed to run without an OS so it could be used in a micro-controller, but that would be useful for writing commercial software in competition with MPE and Forth Inc., so you can't do that and continue to be on the Forth-200x committee.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-04 03:25 -0700 |
| Message-ID | <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com> |
| In reply to | #56650 |
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: > >> > > >> > Supposedly Java virtual machines have been developed with LLVM. > >> > >> 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. > > > > The fundamental question appears to be independent of LLVM: > > > > 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? > > 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 = 0; v = ++v + 2; T2) int v = 0; v = v++ + 2; My understanding is that, per the C standard, translation T1 is well-defined, but translation T2 results in undefined code. I'm still trying to wrap my head around sequence points, but understanding why one translation is well-defined while the other is undefined seems to presents a challenge for writing a translator. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-04 11:24 +0000 |
| Message-ID | <znLEA.278723$Fa7.82064@fx09.am4> |
| In reply to | #56690 |
On Tue, 4 Apr 2017 03:25:27 -0700 (PDT) krishna.myneni@ccreweb.org wrote: > On Monday, April 3, 2017 at 3:17:59 AM UTC-5, Andrew Haley wrote: > > 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 = 0; > v = ++v + 2; > > T2) > > int v = 0; > v = v++ + 2; > > My understanding is that, per the C standard, translation T1 is well-defined, > but translation T2 results in undefined code. I'm still trying to wrap my > head around sequence points, but understanding why one translation is > well-defined while the other is undefined seems to presents a challenge for > writing a translator. No , they are both undefined behaviour. A correct translation is in fact the most straightforward one , namely int v = 0; v++ ; v += 2 ; As for wrapping one's head around sequence points you make it sound as if it's some complicated topic. It's actually trivial. As I was expecting , there is a wikipedia article , en.wikipedia.org/wiki/Sequence_point (not the most authoritative source but with a quick look I don't see any obvious errors). A draft of the C standard can be found online and it even helpfully collects all the sequence points in annex C. And if you have doubts about anything in there or in the wikipedia article you can always ask on comp.lang.c .So if one has any confusion on sequence points it must be because they didn't bother to ask or search in the most obvious places. Obviously if one wants to write a Forth (or anything else) to C translator then they must know enough C (and Forth !). -- South Dakota today passed the most restrictive abortion law in the country. It includes the requirement that pregnant wives notify both their husband AND the baby's father. <S1797.1b42@netfunny.com>
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-04 04:55 -0700 |
| Message-ID | <80de56a2-860f-4024-93ab-743d6a3503cc@googlegroups.com> |
| In reply to | #56695 |
On Tuesday, April 4, 2017 at 6:24:18 AM UTC-5, Spiros Bousbouras wrote: > On Tue, 4 Apr 2017 03:25:27 -0700 (PDT) > krishna.myneni@ccreweb.org wrote: > > On Monday, April 3, 2017 at 3:17:59 AM UTC-5, Andrew Haley wrote: > > > 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 = 0; > > v = ++v + 2; > > > > T2) > > > > int v = 0; > > v = v++ + 2; > > > > My understanding is that, per the C standard, translation T1 is well-defined, > > but translation T2 results in undefined code. I'm still trying to wrap my > > head around sequence points, but understanding why one translation is > > well-defined while the other is undefined seems to presents a challenge for > > writing a translator. > > No , they are both undefined behaviour. ... See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#637 Translation T1 is supposedly not undefined behavior, even though gcc 4.8.x issues a warning with -Wall. > Obviously if one wants to write a Forth (or anything else) to C translator then they must know > enough C (and Forth !). Agreed. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-04 12:28 +0000 |
| Message-ID | <RjMEA.248866$o87.240571@fx21.am4> |
| In reply to | #56698 |
On Tue, 4 Apr 2017 04:55:40 -0700 (PDT)
krishna.myneni@ccreweb.org wrote:
> On Tuesday, April 4, 2017 at 6:24:18 AM UTC-5, Spiros Bousbouras wrote:
> > On Tue, 4 Apr 2017 03:25:27 -0700 (PDT)
> > krishna.myneni@ccreweb.org wrote:
> > > On Monday, April 3, 2017 at 3:17:59 AM UTC-5, Andrew Haley wrote:
> > > > 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 = 0;
> > > v = ++v + 2;
> > >
> > > T2)
> > >
> > > int v = 0;
> > > v = v++ + 2;
> > >
> > > My understanding is that, per the C standard, translation T1 is well-defined,
> > > but translation T2 results in undefined code. I'm still trying to wrap my
> > > head around sequence points, but understanding why one translation is
> > > well-defined while the other is undefined seems to presents a challenge for
> > > writing a translator.
> >
> > No , they are both undefined behaviour. ...
>
> See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#637
>
> Translation T1 is supposedly not undefined behavior, even though gcc 4.8.x issues a warning with -Wall.
Ok , thank you. It appears it was me who hadn't done his homework ; I'm well
familiar with the C99 standard (where both are undefined behaviour) but I
have only briefly skimmed the C11 one. But what I said in my previous post ,
namely "A correct translation is in fact the most straightforward one" ,
still stands. One only needs to understand esoteric stuff if one *must* use
esoteric stuff. But in the Forth code you presented one does not need to use
the distinction between
v = ++v + 2;
and
v = v++ + 2;
to translate the Forth code into C. In fact I can't think of an occasion
where such a distinction would be relevant to practical programming whether
one writes C directly or uses computer translation of something else into C.
Such contrived examples are only useful for clarifying what the standard
specifies.
--
What the liberal elites do now is not moral. It is self-exaltation disguised as
piety. It is part of the carnival act.
http://www.truthdig.com/report/item/donald_trumps_greatest_allies_are_the_liberal_elites_20170305
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-04 16:16 +0000 |
| Message-ID | <2017Apr4.181639@mips.complang.tuwien.ac.at> |
| In reply to | #56695 |
Spiros Bousbouras <spibou@gmail.com> writes:
>On Tue, 4 Apr 2017 03:25:27 -0700 (PDT)
>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 = 0;
>> v = ++v + 2;
>>
>> T2)
>>
>> int v = 0;
>> v = v++ + 2;
>>
>> My understanding is that, per the C standard, translation T1 is well-defined,
>> but translation T2 results in undefined code. I'm still trying to wrap my
>> head around sequence points, but understanding why one translation is
>> well-defined while the other is undefined seems to presents a challenge for
>> writing a translator.
>
>No , they are both undefined behaviour. A correct translation is in fact the
>most straightforward one , namely
>
>int v = 0;
>v++ ;
>v += 2 ;
That's not straightforward. It changes v at every step, unlike the
Forth code. Consider:
v @ 1+ 2 + w !
A correct translation looks very different from your version above.
I think a straightforward translation of Krishna Myneni's code is:
Cell v, s0, s1;
v = 0;
s0 = v;
s0 = s0+1;
s1 = 2;
s0 = s0+s1
v = s0;
And for my variant, you only need to change the last statement.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web