Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45809 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2016-03-03 16:24 -0800 |
| Last post | 2016-03-18 17:45 +0000 |
| Articles | 20 on this page of 108 — 21 participants |
Back to article view | Back to comp.lang.forth
OT: One of Anton's papers makes Hacker News Paul Rubin <no.email@nospam.invalid> - 2016-03-03 16:24 -0800
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-03 21:06 -0800
Re: OT: One of Anton's papers makes Hacker News Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:18 +0200
Re: OT: One of Anton's papers makes Hacker News Paul Rubin <no.email@nospam.invalid> - 2016-03-03 21:33 -0800
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:52 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 12:32 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 18:20 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-05 02:23 +0000
Re: OT: One of Anton's papers makes Hacker News hughaguilar96@gmail.com - 2016-03-04 19:06 -0800
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:32 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:28 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-06 18:02 +0000
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 23:55 +0000
Re: OT: One of Anton's papers makes Hacker News hughaguilar96@gmail.com - 2016-03-06 14:48 -0800
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-07 03:36 -0800
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 17:40 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-05 03:35 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-05 13:37 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-05 15:42 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:50 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 20:33 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 02:01 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-06 11:57 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-07 07:35 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-07 12:40 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:20 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 00:49 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 02:20 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-07 00:35 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-07 02:53 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-07 16:07 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-08 05:17 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 22:01 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-09 03:14 -0600
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-09 11:17 +0000
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-09 23:58 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-10 04:45 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-10 11:39 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-10 13:29 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:02 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-10 08:22 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 15:49 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:35 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-10 21:58 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-11 06:11 -0600
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-12 00:05 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 04:23 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 12:05 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 08:36 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:57 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:44 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 14:29 +0000
Re: OT: One of Anton's papers makes Hacker News "Elizabeth D. Rather" <erather@forth.com> - 2016-03-11 15:02 -1000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 16:20 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-12 13:53 -0600
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 13:02 +0000
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:52 +0000
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 12:42 -0600
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-06 13:12 -0600
Re: OT: One of Anton's papers makes Hacker News Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:20 +0200
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:37 +0000
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <julian.fondren@gmail.com> - 2016-03-04 11:23 -0800
Re: OT: One of Anton's papers makes Hacker News Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-09 03:24 -0600
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-04 21:01 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-05 13:51 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-05 19:43 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 01:45 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 17:24 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-13 12:27 +0000
Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-13 13:50 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-13 19:52 +0000
Re: OT: One of Anton's papers makes Hacker News Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-13 16:08 -0400
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 13:40 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 00:41 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 18:23 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 02:59 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-13 20:29 -0700
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 22:44 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 16:23 -0700
Re: OT: One of Anton's papers makes Hacker News Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-03-14 23:55 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 17:19 -0700
Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 19:26 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-15 00:48 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 22:30 -0700
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-15 07:23 +0000
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-15 10:09 +0000
Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-15 08:56 -0700
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-15 19:33 +0000
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 09:46 +0100
Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 09:37 -0400
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 18:40 +0100
Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 13:53 -0400
Re: OT: One of Anton's papers makes Hacker News invalid <address@is.invalid> - 2016-03-17 18:00 +0000
Re: OT: One of Anton's papers makes Hacker News Rosario19 <Ros@invalid.invalid> - 2016-03-17 18:37 +0100
Re: OT: One of Anton's papers makes Hacker News Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-18 14:36 +0000
Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-14 09:17 +0100
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-14 22:56 +0000
Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 20:00 -0500
Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-15 11:22 +0100
Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:38 +0000
Re: OT: One of Anton's papers makes Hacker News Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-03-14 01:40 -0500
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 11:00 +0000
Re: OT: One of Anton's papers makes Hacker News Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-07 19:19 -0500
Re: OT: One of Anton's papers makes Hacker News Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 01:02 +0000
Re: OT: One of Anton's papers makes Hacker News Julian Fondren <ayrnieu@gmail.com> - 2016-03-14 07:29 -0700
Re: OT: One of Anton's papers makes Hacker News anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-18 17:45 +0000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-03-04 07:20 +0200 |
| Message-ID | <nbb5of$n0l$3@dont-email.me> |
| In reply to | #45809 |
On 04/03/2016 02:24, Paul Rubin wrote: > Under the title "what every compiler writer should know about > programmers". The paper criticizes various compiler responses to the > presence of undefined behaviour in C programs, a topic that has come up > here in CLF several times. Very interesting paper. I think I've seen all the behaviors he mentions...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-04 17:37 +0000 |
| Message-ID | <2016Mar4.183703@mips.complang.tuwien.ac.at> |
| In reply to | #45809 |
Paul Rubin <no.email@nospam.invalid> writes:
>Under the title "what every compiler writer should know about
>programmers". The paper criticizes various compiler responses to the
>presence of undefined behaviour in C programs, a topic that has come up
>here in CLF several times.
>
>Paper:
>http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
>
>HN thread:
>https://news.ycombinator.com/item?id=11219874
Reddit Thread: <https://www.reddit.com/r/programming/comments/48sijo/what_every_compiler_writer_should_know_about/>
Fefe's Blog Entry:
https://blog.fefe.de/?ts=a8267d03
About 41000 hits to the paper in March (probably most of them since
the reddit post yesterday 16:46 +100 (26 hours ago)).
Referers:
20969 -
8132 *reddit.com*
6484 *ycombinator.com*
2068 *fefe.de*
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-03-04 11:23 -0800 |
| Message-ID | <0fb6b244-5362-46dd-920e-0ede4564e077@googlegroups.com> |
| In reply to | #45809 |
On Thursday, March 3, 2016 at 6:24:18 PM UTC-6, Paul Rubin wrote: > Under the title "what every compiler writer should know about > programmers". The paper criticizes various compiler responses to the > presence of undefined behaviour in C programs, a topic that has come up > here in CLF several times. > > Paper: > http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf > > HN thread: > https://news.ycombinator.com/item?id=11219874 Another nice comment, by nkurz: Is your positive experience with C, or C++? I think a lot of the friction is that the two languages often share a compiler but not a philosophy. Modern templated C++ depends heavily on the compiler's ability to optimize out redundant code, while many C programmers still want to more of a WYSIWYG compiler. I often get the feeling that many people involved with GCC would be happier if they could drop C compatibility and just work on a C++ compiler. Ertl's work is at a low enough level where he knows in advance what the assembly of the optimized loops should look like. For example, here's a big improvement to the Python interpreter that's based on his work: https://bugs.python.org/issue4753. What he, and I, and some small but significant number of others, wish for is that there was a way to write C that will reliably produce the output we envision. The chances that an optimizer will make better code than this is low, whereas the chance that attempts to optimize the code will produce worse code is very high.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-03-09 03:24 -0600 |
| Message-ID | <OPOdnfuoKc1IdkLLnZ2dnUU78XudnZ2d@supernews.com> |
| In reply to | #45838 |
Julian Fondren <julian.fondren@gmail.com> wrote: > > Another nice comment, by nkurz: > > Is your positive experience with C, or C++? I think a lot of the > friction is that the two languages often share a compiler but not a > philosophy. Modern templated C++ depends heavily on the compiler's > ability to optimize out redundant code, while many C programmers > still want to more of a WYSIWYG compiler. I didn't think much of this comment to begin with, but the more I think about it the more I conclude that this is an important insight. Mind you, some people write C++ programs in C! They write rather gross C code and just expect a C compiler to remove all of the junk. > I often get the feeling that many people involved with GCC would be > happier if they could drop C compatibility and just work on a C++ > compiler. Many of them, yes, but there are still some backwoodsmen. Even if you don't use any of C++'s features such a templates and classes, it's still worth using just to get type-safe linkage. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-04 21:01 -0500 |
| Message-ID | <20160304210145.16c87863@_> |
| In reply to | #45809 |
On Thu, 03 Mar 2016 16:24:16 -0800 Paul Rubin <no.email@nospam.invalid> wrote: > Under the title "what every compiler writer should know about > programmers". The paper criticizes various compiler responses to the > presence of undefined behaviour in C programs, a topic that has come > up here in CLF several times. > > Paper: > [link] I don't have time to read all of your paper, but clearly you still fail to understand the basics of C. You should really, really have a C expert review this stuff first before publishing it ... I got to this part, which I felt I needed to comment on as yet another example of why you still don't understand C: "However, this implementation is C*, but not ``C'', because p<q is not defined in ``C'' if p and q point to different objects." That is a completely wrong conclusion. Look at how memmove() is declared: void *memmove(void *dest, const void *src, size_t n) Here, p represents dest, and q represents src. So, p<q represents dest<src. What objects do dest or src point to? The answer to that question is: none. They point to no objects. So, what objects are you referring to? ... Neither dest nor src point to any data object in C. There is *NO* data type associated with dest or src. That's what "void" means. These are raw pointers to memory without any C object associated with them. The place where memmove is called may have declared data types passed, but nothing is associated with dest and src once they've been through parameter type conversion to be passed into memmove(). If there is no type associated with dest or src, then there can be no object associated with dest or src. Therefore, the fact that p<q is not defined for different objects is irrelevant here since there are no objects involved. p and q, representing, dest and src, work on raw memory which is objectless. And, you continue with the same erroneous understanding: "However, a ``C'' compiler might assume that src and dest point to the same object, ..." It, the C compiler, can do no such thing. dest and src **DO NOT** point to _any_ valid C object. That is what "void" means in C. The compiler cannot assume anything about any object from dest or src. There is no associated data type once in memmove(). dest and src are pointers to "nothing" (i.e., raw addresses for memory) due to the parameter type conversion. char a[10]; memmove(a[2],a[5],5); a[2] and a[5] "reduce" to pointers to char. These pointers to char are converted to pointers to void to be passed into memmove(). All type information is lost at that point. It does not propagate as you've indicated in your article. In memmove(), there is no type association, no object association, etc for dest and src. HTH, Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-05 13:51 +0000 |
| Message-ID | <nbeo9g$1gb$2@dont-email.me> |
| In reply to | #45846 |
Am Fri, 04 Mar 2016 21:01:45 -0500 schrieb Rod Pemberton: > char a[10]; > > memmove(a[2],a[5],5); > > a[2] and a[5] "reduce" to pointers to char. No, to char. a[2] is accessing the array. > These pointers to char are converted to pointers to void to be passed > into memmove(). > All type information is lost at that point. But not the segment information, if in a segmented architecture. > It does not propagate as you've indicated in your article. In > memmove(), there is no type association, no object association, etc for > dest and src. Ouch. You are really not a C expert, as you pass two chars to memmove, instead of two char*, as it would be with memmove(a+2, a+5, 5); On the other hand, you also don't understand segmented memory, probably because you are too young to have programmed in DOS or worse, 16 bit Windows, with the far pointer model. A pointer comparison there was only an offset comparison, for performance reasons (you would have to convert the overlapping segments in DOS into a flat address, then compare, to get meaningful results, and that would have been an expensive 32 bit operation, emulated with the available 16 bit registers). In your case, memmove has two pointers pointing to the same object. If you do a memmove(a+2, b+5, 5), you would have two different objects, likely with two different segments and the offsets 2 and 5. The thing missing from the C standard is a description why something marked UB is an UB. You however need to know that reason to understand the motivation, without context, it doesn't make sense that comparing pointers of two different objects is not allowed. You don't even understand that there can be different objects in C. AS/400 also comes in mind as an architecture where C is implemented using segmented object addresses (all pointers are segment+offset+boundary). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-05 19:43 -0500 |
| Message-ID | <20160305194309.147d27ed@_> |
| In reply to | #45855 |
On Sat, 5 Mar 2016 13:51:44 -0000 (UTC) Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Fri, 04 Mar 2016 21:01:45 -0500 schrieb Rod Pemberton: > > char a[10]; > > > > memmove(a[2],a[5],5); > > > > a[2] and a[5] "reduce" to pointers to char. > > No, to char. a[2] is accessing the array. > > > These pointers to char are converted to pointers to void to be > > passed into memmove(). > > All type information is lost at that point. > > But not the segment information, if in a segmented architecture. > > > It does not propagate as you've indicated in your article. In > > memmove(), there is no type association, no object association, etc > > for dest and src. > > Ouch. You are really not a C expert, as you pass two chars to > memmove, instead of two char*, as it would be with > memmove(a+2, a+5, 5); > Late night. Simple typo: memmove(&a[2],&a[5],5); > On the other hand, you also don't understand segmented memory, > probably because you are too young to have programmed in DOS or > worse, 16 bit Windows, with the far pointer model. (Ok, here we go again with Bernd violating German law again which prohibits German citizens from engaging in any hate speech, speech which incites, or insults. We have free speech. You don't.) I started programming in 1981. I fully understand DOS segmented memory, as DOS is the primary platform for my personal C code for the last decade or so. > A pointer comparison there was only an offset comparison, A pointer comparison is only an offset comparison for any x86 mode, be it 16-bit RM, 16-bit PM, 32-bit PM, or 64-bit PM. There are no absolute addresses in the x86 architecture. It's entirely segmented. 16-bit RM used segment and offset, and PM uses a base address plus an offset. What's your point? > In your case, memmove has two pointers pointing to the same object. No. They no longer point to an object once converted to "void *" to be passed into memmove(). They are pointers to nothing, i.e., "void". Once in memmove(), they're just a pointer in C terminology, which is usually mapped to a memory address for most implementations. > If you do a memmove(a+2, b+5, 5), you would have two different > objects, likely with two different segments and the offsets 2 and 5. No. No objects are involved once 'a+2' or 'b+5', presumed to be pointers to char, "char *", when memmover() is called, are converted to pointers to void, "void *" to pass them as parameters. How do you expect a memory function, memmove, to work with objects? ... They work on memory. > The thing missing from the C standard is a description why > something marked UB is an UB. Why? C allows for implementation defined behavior. In fact, you couldn't use C for much without defining UB to do something meaningful for each platform. E.g., conversion of pointers to various types, conversion of integers to pointers, etc. > You > don't even understand that there can be different objects in C. Not true, but neither you nor Anton seem to understand that ANSI C standard introduced the concept of a non-object. Prior to ANSI C, all C objects had both data and an address, although historically pointers to char were used as pointers to void. None of this changes my point that Anton has a bad example for something he didn't or doesn't understand in a formal paper. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-06 01:45 +0000 |
| Message-ID | <nbg248$i9m$4@dont-email.me> |
| In reply to | #45866 |
Am Sat, 05 Mar 2016 19:43:09 -0500 schrieb Rod Pemberton: > (Ok, here we go again with Bernd violating German law again which > prohibits German citizens from engaging in any hate speech, speech which > incites, or insults. We have free speech. You don't.) Hate speech is pretty well-defined: It has to cause civil unrest, or at least is very likely to cause it. If not, it is not hate speech; the thing that is prohibited is causing civil unrest. Also, insults are ok, if countered by counter-insults. So when you and I discuss and insult each others, this is perfectly legal in Germany. So a heated discussion is perfectly ok. Also note that insults have to be pretty straight- forward swearwords. Only Hugh is actually insulting people here according to German law. > I started programming in 1981. I fully understand DOS segmented memory, > as DOS is the primary platform for my personal C code for the last > decade or so. > >> A pointer comparison there was only an offset comparison, > > A pointer comparison is only an offset comparison for any x86 mode, be > it 16-bit RM, 16-bit PM, 32-bit PM, or 64-bit PM. There are no absolute > addresses in the x86 architecture. It's entirely segmented. 16-bit RM > used segment and offset, and PM uses a base address plus an offset. But for 32- and 64-bit PM, there is no far model, so all pointers have the same base address. > What's your point? That pointer comparisons in C are allowed only to compare the offset, and therefore the result of pointer comparisons with different segments is giving surprising results (which is the whole point for making it an UB). >> In your case, memmove has two pointers pointing to the same object. > > No. They no longer point to an object once converted to "void *" to be > passed into memmove(). They are pointers to nothing, i.e., "void". > Once in memmove(), they're just a pointer in C terminology, which is > usually mapped to a memory address for most implementations. A segmented memory address in the 8086 system, where the offset comparison has surprising results for overlapping segments. >> If you do a memmove(a+2, b+5, 5), you would have two different objects, >> likely with two different segments and the offsets 2 and 5. > > No. No objects are involved once 'a+2' or 'b+5', presumed to be > pointers to char, "char *", when memmover() is called, are converted to > pointers to void, "void *" to pass them as parameters. How do you > expect a memory function, memmove, to work with objects? ... They work > on memory. The terminology is not ours, but the one of the C standard. They use "object" for a lot of things, including memory regions, and it doesn't necessarily have a type. E.g. in C standard "allocated objects have no declared type" (page 67, last footnote). Page 68 clearly says that memmove works on "objects", even if there is no declared type: "If a value is copied into an object having no declared type using memcpy or memmove," I actually sympathize a lot with your thinking of memory regions: this is the way to think. That's however not the way the C standard is written, and we criticize the C standard, not the way many people think about it. You think memmove should be well-defined and not UB. We think you should be right, but unfortunately, you are wrong. And that's the C standard fuckup we are complaining about. >> The thing missing from the C standard is a description why something >> marked UB is an UB. > > Why? C allows for implementation defined behavior. In fact, > you couldn't use C for much without defining UB to do something > meaningful for each platform. E.g., conversion of pointers to various > types, conversion of integers to pointers, etc. Yes, yes, yes. But the problem is that UB is not IB. The compiler writer is *not* forced to define it. That's the essence of the problem. >> You don't even understand that there can be different objects in C. > > Not true, but neither you nor Anton seem to understand that ANSI C > standard introduced the concept of a non-object. Prior to ANSI C, all C > objects had both data and an address, although historically pointers to > char were used as pointers to void. > > > None of this changes my point that Anton has a bad example for something > he didn't or doesn't understand in a formal paper. C99, page 85, semantics part 5 (last paragraph on the bottom of the page, continuing on page 86) lists a number of cases where pointer comparisons work, and "all others are undefined"; the previous description of what is defined makes it pretty clear that only comparisons of pointers pointing to the same object (array or struct) are defined. The "all others" are summarized by Anton as "not the same object", which is C standard terminology. I.e. there are more possibilities for memmove to involve UB than just pointers not to the same object. Incompatible types are also a possibility. A cast to void only removes the type, not the "object" property. I used these two documents as reference, other documents may have different page numbers: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf Anton is right about what the C standard actually says, and you are right about what it should say, and how it should be interpreted. But the critics is not on what it should say (and how it should be interpreted), but what it actually does say, and that C implementers interpret it that way. Standards are weird things, and often misunderstood. To understand a language, you need more knowledge than what's in the standard, and if you have that, you think different about the language. You obviously have that, and the language lawyers don't. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-03-07 19:19 -0500 |
| Message-ID | <20160307191942.6aae639e@_> |
| In reply to | #45873 |
On Sun, 6 Mar 2016 01:45:45 -0000 (UTC) Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Sat, 05 Mar 2016 19:43:09 -0500 schrieb Rod Pemberton: > >> A pointer comparison there was only an offset comparison, > > > > A pointer comparison is only an offset comparison for any x86 mode, > > be it 16-bit RM, 16-bit PM, 32-bit PM, or 64-bit PM. There are no > > absolute addresses in the x86 architecture. It's entirely > > segmented. 16-bit RM used segment and offset, and PM uses a base > > address plus an offset. > > But for 32- and 64-bit PM, there is no far model, so all pointers > have the same base address. No, each descriptor can have a different base address for 32-bit PM. Correction, I'm not sure about base addresses for 64-bit PM. > > What's your point? > > That pointer comparisons in C are allowed only to compare the offset, Where is that requirement? > > How do you expect a memory function, memmove, to work > > with objects? ... They work on memory. > > The terminology is not ours, but the one of the C standard. They use > "object" for a lot of things, including memory regions, and it > doesn't necessarily have a type. Of course, one should not conflate an actual object in C with use of the word "object" in the standard to identify different things. > You think memmove should be well-defined and not UB. Where is the UB? See my reply to Anton. > > None of this changes my point that Anton has a bad example for > > something he didn't or doesn't understand in a formal paper. > > C99, page 85, semantics part 5 (last paragraph on the bottom of the > page, continuing on page 86) lists a number of cases where pointer > comparisons work, and "all others are undefined"; C99 6.5.8 sub 5 pg 85 C99 (12/01/1999 2nd Ed., ISO/IEC 9899:1999(E), not a draft) "In all other cases, the behavior is undefined." Interesting, ... I don't see a way around that being UB. It seems to apply for both 'incomplete types' such as void as well as for 'object types'. This seems to be an artifact of ANSI C's attempt to make C portable to machines with non-contiguous memory. There really should be an exception to that for void* on contiguous memory machines to reduce UB complications. If a compiler followed that and used it for an optimization, it would break C in a number of ways. Some of the ways that I think applying the UB pointer comparison would break C are: 0) Use of 6.5.8 relational operators with NULL would not work. 1) The string and memory functions could not compare pointers, and would need to find workarounds, as suggested by "as if" in memmove()'s description implying use of a temporary buffer. 2) NULL pointer comparisons shouldn't work (but do). NULL is required to "compare unequal to a pointer to any object or function" per C99 6.3.2.2 section for void. If so, then NULL would not "point to the same object" per C99 6.5.8 relational operators. Of course, 6.5.9 equality operators == and != provides an exception allowing valid comparison with "null pointer constants." This would imply a contiguous memory machine since the three most common ways of implementing NULL are: #define NULL 0 #define NULL ((void *)0) extern char __null[2]; #define NULL ((void*)&__null[1]) 3) A NULL pointer shouldn't be passed for an empty string into a function, unless there is an explicit check in the function of the pointer for NULL while only using == or != from 6.5.9 conditional operators. This would add excessive bloat and is simply never done. 4) The inability to not compare pointers pointing to the same object would also likely break all memory allocation functions, and at most assuredly break realloc(). > Anton is right about what the C standard actually says, No, he isn't. Even though I was incorrect about void pointer comparisons, the standard still provides a 100% portable way to implement memmove() by using a temporary buffer. He doesn't have to use pointer comparisons. Although, as mentioned in my reply to Anton, ANSI X3J11 committee member P.J.Plauger also used pointer comparisons for implementing memmove() in his ANSI C library in his book "The Standard C Library" which is the basis for Dinkumware's C library. It passes the Plum-Hall Validation Suite for C. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-12 17:24 +0000 |
| Message-ID | <2016Mar12.182421@mips.complang.tuwien.ac.at> |
| In reply to | #45927 |
Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes:
>No, he isn't. Even though I was incorrect about void
>pointer comparisons, the standard still provides a 100%
>portable way to implement memmove() by using a temporary
>buffer.
Where do you get the temporary buffer from? Say, you use malloc();
what do you do if malloc() returns NULL?
>Although, as mentioned in my reply to Anton, ANSI X3J11
>committee member P.J.Plauger also used pointer comparisons
>for implementing memmove() in his ANSI C library in his
>book "The Standard C Library" which is the basis for
>Dinkumware's C library.
Apparently he does not agree with the view of nasal-demon fans that it
is the intention of the committee when specifying undefined behaviour
to allow "optimizations".
>It passes the Plum-Hall Validation
>Suite for C.
That's a test suite for C implementations, not for C programs. His
memmove() will fail Clang's and GCC's "sanitizers" once they have
advanced far enough (I don't think they do such checking already),
but, when compiled with a sane C compiler (that does not "optimize"
this comparison), constitutes a valid implementation of memmove().
It's a bit schizophrenic, yes. And that's my point. If you cannot
implement a function like memmove() in Java or Haskell, that's to be
expected. But if you cannot implement it in standard C because of
undefined behaviour, there's something amiss.
Maybe, once their compilers are perverted enough, they will have to
fall back to Forth for implementing memmove(), because they can no
longer implement it in C (no sane compiler left). Fortunately it's no
problem in Forth.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-13 12:27 +0000 |
| Message-ID | <56e55ca0$0$24015$e4fe514c@news.xs4all.nl> |
| In reply to | #46004 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes: <SNIP> >>Although, as mentioned in my reply to Anton, ANSI X3J11 >>committee member P.J.Plauger also used pointer comparisons >>for implementing memmove() in his ANSI C library in his >>book "The Standard C Library" which is the basis for >>Dinkumware's C library. >Apparently he does not agree with the view of nasal-demon fans that it >is the intention of the committee when specifying undefined behaviour >to allow "optimizations". >>It passes the Plum-Hall Validation >>Suite for C. >That's a test suite for C implementations, not for C programs. His >memmove() will fail Clang's and GCC's "sanitizers" once they have >advanced far enough (I don't think they do such checking already), >but, when compiled with a sane C compiler (that does not "optimize" >this comparison), constitutes a valid implementation of memmove(). >It's a bit schizophrenic, yes. And that's my point. If you cannot >implement a function like memmove() in Java or Haskell, that's to be >expected. But if you cannot implement it in standard C because of >undefined behaviour, there's something amiss. >Maybe, once their compilers are perverted enough, they will have to >fall back to Forth for implementing memmove(), because they can no >longer implement it in C (no sane compiler left). Fortunately it's no >problem in Forth. You've seen how a C-programmer (me) writes WITHIN. It compiles on gcc. -pedantic -Wall gives only the eexpected warnings. That is because C was intended as a portable assembler, and it can still be used as such, but you have to play by the rules. No gcc detects no ambiguous conditions, just a "ok. If that's what you want". memmove() is no different from WITHIN in this respect. Plaugher is writing system level C. C is different from an Algol or Pascal, that it was intended that the language itself would be small, and much left to libraries. Writing those libraries in C itself must be possible, that is one of C's design goals. Remember, C was invented to write a portable OS system. Note that I've cross posted to comp.lang.c. >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-03-13 13:50 +0000 |
| Message-ID | <56e57023.13262531@news.xs4all.nl> |
| In reply to | #46032 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > That is because C was intended as a portable assembler, An oft-repeated myth, but no less a myth for the repeating. Richard
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-13 19:52 +0000 |
| Message-ID | <56e5c4f9$0$24031$e4fe514c@news.xs4all.nl> |
| In reply to | #46034 |
raltbos@xs4all.nl (Richard Bos) writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> That is because C was intended as a portable assembler, >An oft-repeated myth, but no less a myth for the repeating. C, Unix and the Bourne shell were create at one time to cooperate. Unix was the first operating system not written in assembler, and C was used to write it, making Unix a portable OS. This is of course painting with a large brush, but I'm really interested what you have to say more except calling it a myth. >Richard -- 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 | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-03-13 16:08 -0400 |
| Message-ID | <nc4h6d$mej$1@dont-email.me> |
| In reply to | #46038 |
On 3/13/2016 3:52 PM, Albert van der Horst wrote:
> [...]
> Unix was the first operating system not written in assembler,
> [...]
Never heard of Multics? It was written in PL/1.
Never heard of Burroughs' MCP? It was written in Algol.
Never heard of ICL's various operating systems? They
were written in S3, an Algol-68 derivative.
These three (and probably others I don't know of) all came
along before Unix -- indeed, Unix started as a "simpler Multics"
(and was originally spelled "Unics").
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-13 13:40 -0700 |
| Message-ID | <lnshzukt6t.fsf@kst-u.example.com> |
| In reply to | #46038 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
[...]
> C, Unix and the Bourne shell were create at one time to cooperate.
The Bourne shell was a replacement for the Thompson shell, and was
first released in Unix version 7.
> Unix was the first operating system not written in assembler,
> and C was used to write it, making Unix a portable OS.
Even if that were true (it isn't), that doesn't make C a "portable
assembler". Other operating systems had been written in assembly
language. Unix was written in something that was *not* assembly
language.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-14 00:41 +0000 |
| Message-ID | <nc51as$r2l$2@dont-email.me> |
| In reply to | #46040 |
Am Sun, 13 Mar 2016 13:40:26 -0700 schrieb Keith Thompson: > Even if that were true (it isn't), that doesn't make C a "portable > assembler". Other operating systems had been written in assembly > language. Unix was written in something that was *not* assembly > language. > > [...] Whatever, the most relevant answer here derives it from three statements of the introduction of K&R's first edition: http://stackoverflow.com/questions/3040276/when-did-people-first-start- thinking-c-is-portable-assembler "C is a relatively "low level" language. This characterization is not pejorative; it simply means that C deals with the same sort of objects that most computers do, namely characters, numbers, and addresses. [ ... ] Again, because the language reflects the capabilities of current computers, C programs tend to be efficient enough that there is no compulsion to write assembly language instead. [ ... ] Although C matches the capabilities of many computers, it is independent of any particular machine architecture, and so with a little care it is easy to write "portable" programs ..." The next thing you probably refute is that K&R developed the programming language C. There's a lot of nonsense in the discussion above, of people who studied C "the hard, academic way instead of the easy practical way", and who don't know anything about the history of C. It reminds me of Dostoyevsky's tale of Jesus reappearing, and being captured by the great inquisitor, because he's disturbing Christian believes. Brian and Dennis are rotating in their graves, and Brian ain't dead yet. If there is an academic school for C, which differs significantly from K&R's original school, what is the point of it? The C described by K&R was low-level, had operations that matched those of the underlying machine, and made it unnecessary to write in assembly language. C is by no means unique in that capability, nor was it the first. It is just the most popular of this class of languages. Apparently, some people don't want it to be in that class, but think it is some abstract computer science concept. There are much better languages for studying "the hard, academic way", instead of being of practical relevance (which seems to be a prejorative term in some circles), e.g. Haskell. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-13 18:23 -0700 |
| Message-ID | <lnbn6hluo0.fsf@kst-u.example.com> |
| In reply to | #46047 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Am Sun, 13 Mar 2016 13:40:26 -0700 schrieb Keith Thompson:
>> Even if that were true (it isn't), that doesn't make C a "portable
>> assembler". Other operating systems had been written in assembly
>> language. Unix was written in something that was *not* assembly
>> language.
>>
>> [...]
>
> Whatever, the most relevant answer here derives it from three statements
> of the introduction of K&R's first edition:
>
> http://stackoverflow.com/questions/3040276/when-did-people-first-start-
> thinking-c-is-portable-assembler
>
> "C is a relatively "low level" language. This characterization is not
> pejorative; it simply means that C deals with the same sort of objects
> that most computers do, namely characters, numbers, and addresses.
> [ ... ]
Yes, C is a relatively low level language. That doesn't make it an
assembler -- and the quotation from K&R1 doesn't say that it is one.
The relevant distinction, in my opinion, is that code written
in assembly language specifies a sequence of CPU instruction,
while code written in a higher level language such as C specifies
runtime behavior.
(I'm quite familiar with the history of C, BTW.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-14 02:59 +0000 |
| Message-ID | <nc59dq$5bk$1@dont-email.me> |
| In reply to | #46048 |
Am Sun, 13 Mar 2016 18:23:11 -0700 schrieb Keith Thompson: > Yes, C is a relatively low level language. That doesn't make it an > assembler -- and the quotation from K&R1 doesn't say that it is one. > > The relevant distinction, in my opinion, is that code written in > assembly language specifies a sequence of CPU instruction, > while code written in a higher level language such as C specifies > runtime behavior. > > (I'm quite familiar with the history of C, BTW.) But apparently not familiar with human expressions. "portable assembler" refers to the three properties listed: low-level, operations operating on the same data types as machine instructions, and sufficient performance and expressiveness to make it possible to write code in C that you otherwise would have written in assembler. The expression of two words which don't quite fit together (if it is portable, how can it be an assembler, which is inherently non-portable?) require an interpretation. IMHO the three paragraphs provide an interpretation: low-level, operates on the same data types as the actual instruction set, so that statements can be mapped quite directly into instructions, and sufficient performance of the result to make it unnecessary to use assembler, while still being portable with a little care = "portable assembler". "Performance" not only as "benchmark results", but also expressive power, e.g. K&R C also contained computed goto, and labels were actual addresses in the generated code (GNU C has a similar feature). Note that all ISAs I'm aware of describe the effect of their instructions as "runtime behavior", though you could argue that the assembler as isolated piece of software only translates mnemonics into machine code, and therefore itself doesn't know about semantics, but for the programmer, that is irrelevant: The semantics of the underlying machine is what is desired by the translation process. The assembler plus underlying machine code therefore is just non-portable, but still has the same specification properties. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-13 20:29 -0700 |
| Message-ID | <ln60wplotj.fsf@kst-u.example.com> |
| In reply to | #46049 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Am Sun, 13 Mar 2016 18:23:11 -0700 schrieb Keith Thompson:
>> Yes, C is a relatively low level language. That doesn't make it an
>> assembler -- and the quotation from K&R1 doesn't say that it is one.
>>
>> The relevant distinction, in my opinion, is that code written in
>> assembly language specifies a sequence of CPU instruction,
>> while code written in a higher level language such as C specifies
>> runtime behavior.
>>
>> (I'm quite familiar with the history of C, BTW.)
>
> But apparently not familiar with human expressions.
[snip]
You are entitled to your opinion. You are also entitled to insult
me if you wish. You are not, however, entitled to insult me and
then expect me to continue the discussion.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-14 22:44 +0000 |
| Message-ID | <nc7esp$tsi$1@dont-email.me> |
| In reply to | #46050 |
Am Sun, 13 Mar 2016 20:29:28 -0700 schrieb Keith Thompson: >> But apparently not familiar with human expressions. > [snip] > > You are entitled to your opinion. You are also entitled to insult me if > you wish. You are not, however, entitled to insult me and then expect > me to continue the discussion. What I wanted to say is that an overspecific definition of "portable assembler" is misleading. Human languages are weak and ambiguous, and using such an overspecific definition is erecting a straw man. That is a very common way to argument, and the counter-measure is to point this out. That's not an insult, but an attempt to improve mutual understanding of that (not very well-defined) term "portable assembler". -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web