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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-14 16:23 -0700 |
| Message-ID | <lny49kiqyc.fsf@kst-u.example.com> |
| In reply to | #46065 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> 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".
I'll accept that it wasn't intended as an insult. You could have made
your point without telling me that I'm "not familiar with human
expressions".
You seem to be saying that the word "assembler" has no specific meaning,
therefore it's acceptable to refer to C as an "assembler".
In my opinion, the phrase "portable assembler" is based on a
misunderstanding of what C and assembly languages are.
To some extent, C was designed to replace assembly language. That
doesn't mean that it is one -- any more than an automobile is a kind of
horse.
--
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 | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-03-14 23:55 +0000 |
| Message-ID | <20160314235501.6b3f99c3@t500> |
| In reply to | #46068 |
On Mon, 14 Mar 2016 16:23:55 -0700 Keith Thompson <kst-u@mib.org> wrote: [snip] > In my opinion, the phrase "portable assembler" is based on a > misunderstanding of what C and assembly languages are. > > To some extent, C was designed to replace assembly language. > That doesn't mean that it is one -- any more than an > automobile is a kind of horse. Early automobiles were called 'horse-less carriages' Whether the horses or carriage makers took great offence over this naming I do not know. Jan Coombs. -- > -- > 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" Thanks for the reminder, I do often think too much and make too few decisions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-14 17:19 -0700 |
| Message-ID | <lnr3fciodl.fsf@kst-u.example.com> |
| In reply to | #46069 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
> On Mon, 14 Mar 2016 16:23:55 -0700
> Keith Thompson <kst-u@mib.org> wrote:
>
> [snip]
>
>> In my opinion, the phrase "portable assembler" is based on a
>> misunderstanding of what C and assembly languages are.
>>
>> To some extent, C was designed to replace assembly language.
>> That doesn't mean that it is one -- any more than an
>> automobile is a kind of horse.
>
> Early automobiles were called 'horse-less carriages'
Yes, and that description was accurate. An automobile is a carriage
(though we no longer call it that), one that (usually) operates without
a horse.
Automobiles largely replaced both horse-drawn carriages and horses, both
of which were commonly used for transportation.
The argument I'm trying to refute is that, since C was designed to
*replace* assemblers, it *is* an assembler. Similarly, automobiles are
not horses.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-03-14 19:26 -0500 |
| Message-ID | <k8leebdae59jskuuj77j8hil0dhe6hv14u@4ax.com> |
| In reply to | #46069 |
On Mon, 14 Mar 2016 23:55:01 +0000, Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: >On Mon, 14 Mar 2016 16:23:55 -0700 >Keith Thompson <kst-u@mib.org> wrote: > >[snip] > >> In my opinion, the phrase "portable assembler" is based on a >> misunderstanding of what C and assembly languages are. >> >> To some extent, C was designed to replace assembly language. >> That doesn't mean that it is one -- any more than an >> automobile is a kind of horse. > >Early automobiles were called 'horse-less carriages' > >Whether the horses or carriage makers took great offence over >this naming I do not know. I think that exactly illustrates Keith's point - automobiles are fairly reasonably a type of carriage, but are *not* horses (hence "horse-less"). C is something of an assembler-less low-level language.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-15 00:48 +0000 |
| Message-ID | <nc7m5h$ckk$1@dont-email.me> |
| In reply to | #46068 |
Am Mon, 14 Mar 2016 16:23:55 -0700 schrieb Keith Thompson: > Bernd Paysan <bernd.paysan@gmx.de> writes: > I'll accept that it wasn't intended as an insult. You could have made > your point without telling me that I'm "not familiar with human > expressions". Or the fact that humans have floppy, imprecise expressions, which you can either willfully twist words in the mouth, or cooperatively give a meaningful interpretation. You have shown a very narrow understanding of what "portable assembler" could possibly mean, and based on that narrow understanding, you come to the conclusion that C isn't. > You seem to be saying that the word "assembler" has no specific meaning, > therefore it's acceptable to refer to C as an "assembler". It has a specific meaning. An assembler is a low-level programming language that directly corresponds to particular machine language instructions. Now, of course, that excludes "portable", therefore, if you want a "portable assembler", what do you get, what particular properties do you have to remove from an assembler to fit? You get a low-level programming language, where the operations correspond closely to machine instructions (in so far that most of them can be translated into single instructions on most CPUs), but abstracting from the actual mnemonics and the actual number and names of registers (because those two are clearly non-portable attributes of assemblers), and allow the compiler to reschedule the instructions for higher ILP following an "as-if" rule (similar to the as-if rules of OoO execution CPUs). C IMHO is such a language. There are others, but less popular ones. > In my opinion, the phrase "portable assembler" is based on a > misunderstanding of what C and assembly languages are. And my opinion is that you are misunderstanding what "portable assembler" wants to express, and use that straw man to argue that it is not. IMHO you should try to understand what somebody who's looking for a "portable assembler" actually wants: He wants to rewrite his non-portable assembler code in a portable language, and still get similar output in terms of performance and functionality, so the expressiveness of the "portable assembler" should be roughly equal to that of an actual assembler plus underlying machine model, and the compiler should produce similar code quality as an assembler. > To some extent, C was designed to replace assembly language. That > doesn't mean that it is one -- any more than an automobile is a kind of > horse. But of course an automobile is a kind of carriage, just one with no horse. If people have demand for "a horse that does not eat hay and shit on the road", you would argue that a car is not that replacement, because you can't make horse meat out of it. Have they asked for horse meat? No, though they didn't specify very precise requirements. Just "not eat hay and not shit on the road". And "is a" in logic is a relationship which allows multiple terms to apply on the left hand for the same right hand (property). A programming language can be both a portable assembler *and* a functional and object oriented high-level language. JavaScript with asm.js would be an example of such a language which is both. The fact that some people use C as portable assembler does not exclude any other use of the C programming language, or any other characterization. C is certainly more than just a portable assembler. Take the property "portable assembler" out of C, and a number of users get angry. Take the other properties out, and more users get angry. This is really way too much discussion about hermeneutics, and bogs down to why I wrote "you don't understand enough about human expressions": Assume that people produce statements with coherent meanings. If your interpretation of their words result in incoherent meanings, hermeneutics suggests that you should adjust your interpretation. But overall, I think it's the same problem that leads to the UB fuckup in C compilers: instead of trying to figure out what interpretation of an UB statement could be meaningful in that context (e.g. that overflowing integers on a two's complement machine probably intents to wrap around), the argument is that the programmer was stupid (by failing to express himself clearly and unambiguously), and that the compiler can use any crazy interpretation possible. So the discussion about the core problem gets to the point where the core problem makes the discussion impossible. That's very insightful. -- 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-14 22:30 -0700 |
| Message-ID | <lnmvq0i9yw.fsf@kst-u.example.com> |
| In reply to | #46073 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Am Mon, 14 Mar 2016 16:23:55 -0700 schrieb Keith Thompson:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> I'll accept that it wasn't intended as an insult. You could have made
>> your point without telling me that I'm "not familiar with human
>> expressions".
>
> Or the fact that humans have floppy, imprecise expressions, which you can
> either willfully twist words in the mouth, or cooperatively give a
> meaningful interpretation. You have shown a very narrow understanding of
> what "portable assembler" could possibly mean, and based on that narrow
> understanding, you come to the conclusion that C isn't.
You have shown an understanding of what an "assembler" is that (a)
differs from mine, and (b) is, in my opinion, less useful than the
understanding I have of the word.
>> You seem to be saying that the word "assembler" has no specific meaning,
>> therefore it's acceptable to refer to C as an "assembler".
>
> It has a specific meaning. An assembler is a low-level programming
> language that directly corresponds to particular machine language
> instructions. Now, of course, that excludes "portable", therefore, if
> you want a "portable assembler", what do you get, what particular
> properties do you have to remove from an assembler to fit?
For a moment, I thought you were agreeing that C is not an assembler.
C code does not directly correspond to machine language instructions.
Does i++ correspond to an "INC" instruction? What if the target CPU
doesn't have an "INC" instruction?
> You get a low-level programming language, where the operations correspond
> closely to machine instructions (in so far that most of them can be
> translated into single instructions on most CPUs), but abstracting from
> the actual mnemonics and the actual number and names of registers
> (because those two are clearly non-portable attributes of assemblers),
> and allow the compiler to reschedule the instructions for higher ILP
> following an "as-if" rule (similar to the as-if rules of OoO execution
> CPUs).
>
> C IMHO is such a language. There are others, but less popular ones.
C abstracts away the actual mnemonics, the number and names of
registers, *and the CPU instructions*.
An assembler translates a symbolic representation of machine code into
machine code. Some assemblers include macro facilities, but what
distinguishes an assembler from a compiler is that the assembly source
code completely specifies the sequence of CPU instructions in the
generated binary.
C doesn't do that.
I can imagine an actual "portable assembler", where the input program
specifies (for the most part) one CPU instruction per line, and the
assembler can translate it to different target instruction sets.
Register sets vary, so the choice of registers would have to be done by
the assembler, not by the programmer. I don't know whether such a thing
has ever been done, or whether it would be useful. But it wouldn't look
much like C.
>> In my opinion, the phrase "portable assembler" is based on a
>> misunderstanding of what C and assembly languages are.
>
> And my opinion is that you are misunderstanding what "portable assembler"
> wants to express, and use that straw man to argue that it is not.
I think I have a pretty good idea what people who use the phrase
"portable assembler" are trying to express. I just happen to think that
it's an incorrect use of the word "assembler". Calling C an "assembler"
makes the word "assembler" less useful, because it no longer expresses a
particularly useful concept.
> IMHO
> you should try to understand what somebody who's looking for a "portable
> assembler" actually wants: He wants to rewrite his non-portable assembler
> code in a portable language, and still get similar output in terms of
> performance and functionality, so the expressiveness of the "portable
> assembler" should be roughly equal to that of an actual assembler plus
> underlying machine model, and the compiler should produce similar code
> quality as an assembler.
Someone who wants to rewrite his non-portable assembler code in a
portable language can do so by rewriting it *in a non-assembler
language* such as C.
>> To some extent, C was designed to replace assembly language. That
>> doesn't mean that it is one -- any more than an automobile is a kind of
>> horse.
>
> But of course an automobile is a kind of carriage, just one with no
> horse. If people have demand for "a horse that does not eat hay and shit
> on the road", you would argue that a car is not that replacement, because
> you can't make horse meat out of it. Have they asked for horse meat?
> No, though they didn't specify very precise requirements. Just "not eat
> hay and not shit on the road".
Sure, it's a kind of carriage, but it's still not a horse.
> And "is a" in logic is a relationship which allows multiple terms to
> apply on the left hand for the same right hand (property). A programming
> language can be both a portable assembler *and* a functional and object
> oriented high-level language. JavaScript with asm.js would be an example
> of such a language which is both.
I'm not familiar with asm.js, so I can't comment intelligently on it.
From what little I've seen (a quick glance at the FAQ while writing
this), I'd say it's analagous to an assembler, but it isn't one.
[...]
> This is really way too much discussion about hermeneutics, and bogs down
> to why I wrote "you don't understand enough about human expressions":
> Assume that people produce statements with coherent meanings. If your
> interpretation of their words result in incoherent meanings, hermeneutics
> suggests that you should adjust your interpretation.
If someone uses a phrase incorrectly, it's useful to understand what
they actually meant by it, but it's also useful to use the phrase
correctly.
People commonly say that C arrays are really pointers. I understand,
more or less, what they mean by that. But I'm not going to adjust my
interpretation, because C arrays simply are not pointers.
[...]
I've redirected followups to comp.lang.c. If you want to continue this
discussion in comp.lang.forth for some reason, you can override it.
--
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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-03-15 07:23 +0000 |
| Message-ID | <2016Mar15.082323@mips.complang.tuwien.ac.at> |
| In reply to | #46078 |
Keith Thompson <kst-u@mib.org> writes:
>C code does not directly correspond to machine language instructions.
>
>Does i++ correspond to an "INC" instruction? What if the target CPU
>doesn't have an "INC" instruction?
In that sense, assembly language does not correspond to machine
language, either. E.g., in Alpha assembly language, does "lbx"
correspond to the machine instruction that is disassembled as "lbx"?
(Answer: not necessarily) What if the target architecture does not
have that instruction? (Answer: the assembler generates some code
that has the same behaviour as the instruction disassembled as "lbx"
on CPUs that support it)
Was there any protest among assembly language programmers because of
this deviation from what you claim "assembler" means? No. Why not?
Because assembly language programs are also about behaviour, not about
the bit patterns of the resulting code, unlike you claim.
>I can imagine an actual "portable assembler", where the input program
>specifies (for the most part) one CPU instruction per line, and the
>assembler can translate it to different target instruction sets.
>Register sets vary, so the choice of registers would have to be done by
>the assembler, not by the programmer. I don't know whether such a thing
>has ever been done, or whether it would be useful. But it wouldn't look
>much like C.
The only reason for that is your arbitrary restriction on "one CPU
instruction per line", which non-portable assemblers do not satisfy,
either. The register allocation issue is much more fundamental, BTW,
not just because it means that the bits in the instructions may vary,
but because it has ramifications throughout the language, in
particular for calls.
Anyway, instead of nitpicking of what an assembler is, let's look at
the Rationale for the C99 standard:
On Page 2 it says:
|C code can be non-portable. Although it strove to give programmers
|the opportunity to write truly portable programs, the C89 Committee
|did not want to force programmers into writing portably, to preclude
|the use of C as a "high-level assembler": the ability to write
|machine-specific code is one of the strengths of C. It is this
|principle which largely motivates drawing the distinction between
|strictly conforming program and conforming program.
Of course that uses a different meaning of "portable" than the
"portable assembler" phrase, but your problem seems to be more with
the "assembler" part of that phrase. So the C standards committee
obviously did not take your narrow view of what an assembler is.
>I think I have a pretty good idea what people who use the phrase
>"portable assembler" are trying to express. I just happen to think that
>it's an incorrect use of the word "assembler". Calling C an "assembler"
>makes the word "assembler" less useful, because it no longer expresses a
>particularly useful concept.
Depends on what you mean with C. If you mean nasal-demon-C, yes,
that's not a particularly useful concept, at least for programming
(Brainfuck programmers may disagree), and I certainly would not call
that a portable assembler. That's exactly what spawned this
discussion and in this discussion "portable assembler" (or "high-level
assembler") is the usage of C that is contrasted with nasal-demon-C.
- 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-15 10:09 +0000 |
| Message-ID | <56e7df44$0$24111$e4fe514c@news.xs4all.nl> |
| In reply to | #46078 |
Keith Thompson <kst-u@mib.org> writes:
<SNIP>
>I think I have a pretty good idea what people who use the phrase
>"portable assembler" are trying to express. I just happen to think that
>it's an incorrect use of the word "assembler". Calling C an "assembler"
>makes the word "assembler" less useful, because it no longer expresses a
>particularly useful concept.
We in Holland we talk about can (blik which means tin plated steal)
that is made of ... plastic. Original battery (at least in Europe) means
several electric cells tied together. Now it is often used
for a monocell, which is in fact incorrect, but not after 100+ years.
"portable assembler" is metaphorical and after a while the expression
takes on a meaning of its own.
You understand what it means, that is good enough for me.
Let me use scare quotes in order to not annoy you.
Original C was usable and used as a "portable assembler".
Do you agree that the concept that "portable assembler" tries
to describe, is important, and helps to convey insight?
Gcc is used to implement other languages.
Giving the central place gcc takes, does gcc have the
(moral not legal) obligation to make good on an implied promise
to function as a "portable assembler"?
What do you say about the complaints of Anton Ertl, that gcc
doesn't, as set Forth in his document?:
http://www.google.com/url?q=http%3A%2F%2Fwww.complang.tuwien.ac.at%2Fkps2015%2Fproceedings%2FKPS_2015_submission_29.pdf&sa=D&sntz=1&usg=AFQjCNFzi3tGVat7LrA4FUXiJYWKGaKz1A
I tend to agree with him, but then he complains that he gets not his
intended code out from:
"
int d[16];
int SATD (void)
{
int satd = 0, dd, k;
for (dd=d[k=0]; k<16; dd=d[++k]) {
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
"
My take is that the out of bounds access (d[++k]) should be avoided,
because it can. (This code throws off gcc optimizer).
I'm enough of a c-programmer to feel bad about this code and I
certainly would never write it.
Another weak example is that in implementing Forth one wants to
compare raw pointers.
void *memmove(void *dest, const void *src, size_t n) {
if (dest<src)
memcpy_pos_stride(dest,src,n);
else
memcpy_neg_stride(dest,src,n);
}
This is expressible in C without resorting to undefined behaviour.
(And I've shown him, how to did that with code that gives warnings,
but nothing more. Of course there are warnings in this kind of code.)
I think he weakens his case by such examples, but I hope that
you can look through that.
<SNIP>
>I've redirected followups to comp.lang.c. If you want to continue this
>discussion in comp.lang.forth for some reason, you can override it.
I've added comp.lang.forth because I got the subject back on track.
>--
>Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-15 08:56 -0700 |
| Message-ID | <ln60wnivkq.fsf@kst-u.example.com> |
| In reply to | #46081 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
> <SNIP>
>>I think I have a pretty good idea what people who use the phrase
>>"portable assembler" are trying to express. I just happen to think that
>>it's an incorrect use of the word "assembler". Calling C an "assembler"
>>makes the word "assembler" less useful, because it no longer expresses a
>>particularly useful concept.
>
> We in Holland we talk about can (blik which means tin plated steal)
> that is made of ... plastic. Original battery (at least in Europe) means
> several electric cells tied together. Now it is often used
> for a monocell, which is in fact incorrect, but not after 100+ years.
> "portable assembler" is metaphorical and after a while the expression
> takes on a meaning of its own.
> You understand what it means, that is good enough for me.
> Let me use scare quotes in order to not annoy you.
>
> Original C was usable and used as a "portable assembler".
>
> Do you agree that the concept that "portable assembler" tries
> to describe, is important, and helps to convey insight?
Tries to describe? Sure.
Is important? Meh.
Helps to convey insight? No.
> Gcc is used to implement other languages.
> Giving the central place gcc takes, does gcc have the
> (moral not legal) obligation to make good on an implied promise
> to function as a "portable assembler"?
I'm not sure what that means.
> What do you say about the complaints of Anton Ertl, that gcc
> doesn't, as set Forth in his document?:
>
> http://www.google.com/url?q=http%3A%2F%2Fwww.complang.tuwien.ac.at%2Fkps2015%2Fproceedings%2FKPS_2015_submission_29.pdf&sa=D&sntz=1&usg=AFQjCNFzi3tGVat7LrA4FUXiJYWKGaKz1A
For anyone else who wants to read it, here's a shorter link:
http://www.complang.tuwien.ace.at/kps2015/proceedings/KPS_2015_submission_29.pdf
I haven't read it myself. I might later.
[...]
> Another weak example is that in implementing Forth one wants to
> compare raw pointers.
> void *memmove(void *dest, const void *src, size_t n) {
> if (dest<src)
> memcpy_pos_stride(dest,src,n);
> else
> memcpy_neg_stride(dest,src,n);
> }
>
> This is expressible in C without resorting to undefined behaviour.
Did you omit a "not" in that sentence?
Evaluating (dest<src) has undefined behavior if dest and src don't
point into the same object (or just past the end of it).
You could check for overlap (without necessarily detecting which
pointer is "less than" the other one) using equality comparisons
in a loop. There's no way to implement memmove() efficiently in
portable C. I'm sympathetic to arguments that there should be,
but there isn't.
[...]
--
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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-15 19:33 +0000 |
| Message-ID | <56e86383$0$24033$e4fe514c@news.xs4all.nl> |
| In reply to | #46086 |
Keith Thompson <kst-u@mib.org> writes:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>> Another weak example is that in implementing Forth one wants to
>> compare raw pointers.
>> void *memmove(void *dest, const void *src, size_t n) {
>> if (dest<src)
>> memcpy_pos_stride(dest,src,n);
>> else
>> memcpy_neg_stride(dest,src,n);
>> }
>>
>> This is expressible in C without resorting to undefined behaviour.
>Did you omit a "not" in that sentence?
No, definitely not. But I made an other mistake.
Anton Ertl suggests that that is the way to implements
Forth MOVE, and then it looks more
like
void memmove( Cell dest, Cell src, Cell n )
The Forth Cell's are unions. Manipulating the Cell's
can result in a MOVE that behaves in the Forth way.
Casting a pointer to an appropriately sized unsigned integer
is correct c, but not portable. Then it is possible to
inspect the bit pattern and have a desired effect for most
processors, and maybe even all. (In this case one expects
trouble on the transputer, and the need to have conditional
compilation.)
>Evaluating (dest<src) has undefined behavior if dest and src don't
>point into the same object (or just past the end of it).
Of course, so I don't want to do that.
>You could check for overlap (without necessarily detecting which
>pointer is "less than" the other one) using equality comparisons
>in a loop. There's no way to implement memmove() efficiently in
>portable C. I'm sympathetic to arguments that there should be,
>but there isn't.
Using C as a "portable" maybe better "highlever assembler" starts
on the premise that the code cannot be portable c.
Then one goes on and make it valid c in all cases, and truly
portable where possible.
I don't argue that the memmove should be possible portably,
and I don't argue that incrementing a signed integer doesn't
result in overflow. (I hope Anton doesn't either.)
I just want sympathy for the situation that Forth cells are
in fact a kind of union of unsigned, signed and void* .
Unless the compiler gives errors, reasonable things should
happen. The complaints Anton has that weird reasoning of the
optimiser leads to omission of wads of code. That should not
happen IMHO for valid but maybe non-portable code.
>[...]
>--
>Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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 | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-03-17 09:46 +0100 |
| Message-ID | <vkrkeb5t1ahgit95eu8ubgoc9optf7t5ne@4ax.com> |
| In reply to | #46089 |
On 15 Mar 2016 19:33:23 GMT, Albert van der Horst wrote: >Using C as a "portable" maybe better "highlever assembler" for to be one assembly language 1) C has to use at last the set of size fixed types int8_t, int16_t, int32_t, uint8_t, uint16_t, uint32_t [ok] 2) for those fixed size types all operations among them has to be definited and all the same despite the machine it runs [ok?] 3) use operation on stack as push/pop uint32_t instruction for read in the stack array so a portable use of the stack[not ok]
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-03-17 09:37 -0400 |
| Message-ID | <nceboc$5t9$1@jstuckle.eternal-september.org> |
| In reply to | #46106 |
On 3/17/2016 4:46 AM, Rosario19 wrote: > On 15 Mar 2016 19:33:23 GMT, Albert van der Horst wrote: > >> Using C as a "portable" maybe better "highlever assembler" > > for to be one assembly language > 1) C has to use at last the set of size fixed types int8_t, int16_t, > int32_t, uint8_t, uint16_t, uint32_t [ok] Why? What about machines which don't have one or more of these types? > 2) for those fixed size types all operations among them has to be > definited and all the same despite the machine it runs [ok?] And how do you do that when some machines don't support all of these types? > 3) use operation on stack as push/pop uint32_t instruction for read in > the stack array > > so a portable use of the stack[not ok] > > What about machines which don't have a stack? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-03-17 18:40 +0100 |
| Message-ID | <prqleb9m8bdbcv4p2dli6683po9enqli7l@4ax.com> |
| In reply to | #46108 |
On Thu, 17 Mar 2016 09:37:19 -0400, Jerry Stuckle wrote: >What about machines which don't have a stack? they would have many problem more the stack is the fundamental argument for informatic, cpu etc because it is how memory for cpu is good to use
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-03-17 13:53 -0400 |
| Message-ID | <nceqnr$312$1@jstuckle.eternal-september.org> |
| In reply to | #46112 |
On 3/17/2016 1:40 PM, Rosario19 wrote: > On Thu, 17 Mar 2016 09:37:19 -0400, Jerry Stuckle wrote: > >> What about machines which don't have a stack? > > they would have many problem more > the stack is the fundamental argument for informatic, cpu etc > because it is how memory for cpu is good to use > Not at all. IBM mainframes don't have a stack, for instance. And they are used by big companies and governments all over the world. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | invalid <address@is.invalid> |
|---|---|
| Date | 2016-03-17 18:00 +0000 |
| Message-ID | <ncerb5$1vf5$1@gioia.aioe.org> |
| In reply to | #46112 |
On 2016-03-17, Rosario19 <Ros@invalid.invalid> wrote: > On Thu, 17 Mar 2016 09:37:19 -0400, Jerry Stuckle wrote: > >>What about machines which don't have a stack? > > they would have many problem more No. > the stack is the fundamental argument for informatic, cpu etc No. > because it is how memory for cpu is good to use No.
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-03-17 18:37 +0100 |
| Message-ID | <soqleb1g28er6i0kbh2h0gvgl6ids4dlh0@4ax.com> |
| In reply to | #46106 |
On Thu, 17 Mar 2016 09:46:10 +0100, Rosario19 wrote: >On 15 Mar 2016 19:33:23 GMT, Albert van der Horst wrote: > >>Using C as a "portable" maybe better "highlever assembler" > >for to be one assembly language >1) C has to use at last the set of size fixed types int8_t, int16_t, >int32_t, uint8_t, uint16_t, uint32_t [ok] >2) for those fixed size types all operations among them has to be >definited and all the same despite the machine it runs [ok?] >3) use operation on stack as push/pop uint32_t instruction for read in >the stack array >so a portable use of the stack[not ok] 4) one overflow flag for the unsigned types [for implement big numbers and fixed float]
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-18 14:36 +0000 |
| Message-ID | <56ec1288$0$5883$e4fe514c@news.xs4all.nl> |
| In reply to | #46106 |
Rosario19 <Ros@invalid.invalid> writes: >On 15 Mar 2016 19:33:23 GMT, Albert van der Horst wrote: >>Using C as a "portable" maybe better "highlever assembler" >for to be one assembly language >1) C has to use at last the set of size fixed types int8_t, int16_t, >int32_t, uint8_t, uint16_t, uint32_t [ok] >2) for those fixed size types all operations among them has to be >definited and all the same despite the machine it runs [ok?] >3) use operation on stack as push/pop uint32_t instruction for read in >the stack array >so a portable use of the stack[not ok] > This is not the kind of portable assembler I've in mind. In particular, it would abstract from a computer having a 16 bit , 32 bit or 64 bit word, not trying to manipulate 64 bit times on a 16 bit computer. 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-03-14 09:17 +0100 |
| Message-ID | <nc5rs2$lkg$1@dont-email.me> |
| In reply to | #46049 |
On 14/03/16 03:59, Bernd Paysan wrote: > 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. > I expect Keith is very familiar with that particular "C is a portable assembler" expression - I expect he has heard it a good many times over the decades, and knows /exactly/ what people mean by it. And he knows that it is wrong. C is low-level, and it lets you write a lot of code in a portable language rather than system-specific assembly while retaining near maximal efficiency. That much is true. But it does /not/ operate on the same data types as machine instructions. It operates on a set of types that are in most aspects machine-independent, and in some aspects implementation-dependent. These do not necessarily match the hardware - they were designed to be a reasonable common-subset fit for a lot of the hardware in common use when the language was created. Processors - and therefore assembly languages - have many features in their instruction sets and their data types that are not directly available in C. A key example is that on a processor, signed integer overflow is typically clearly defined - in C, it is not. But equally clearly, small processors will not support data types such as 64-bit integers or floating point - but C gives you them on such devices. And modern processors are designed to have data types that fit with C, rather than the other way round. There are lots of types of programming that are possible in assembly, but completely impossible in (standard) C. You are very limited in your access to hardware, you cannot access hardware registers other than memory-mapped peripherals, you have no control over the timing of code, you have little control over the ordering (volatile accesses are ordered, but not calculations or non-volatile accesses), you cannot interact with interrupts (except in a very limited way with signals), you cannot implement multi-threading, atomic accesses, etc. (you can /use/ these features in C11, but you cannot write the underlying implementations in standard C), you cannot (at least not efficiently and conveniently) use co-routines or other types of control-flow structuring outside the limits of C. C is the language that it is - with its benefits and its disadvantages. It does not completely replace assembly, but certainly many programs that used to be written in assembly could be written more conveniently in C (or at least mostly C). In the same way, many programs that have traditionally be written in C could be written more conveniently in C++, Python, or a host of other higher level languages that have different balances between safety, ease-of-use, functionality, efficiency, etc. > 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. >
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-14 22:56 +0000 |
| Message-ID | <nc7fik$tsi$2@dont-email.me> |
| In reply to | #46054 |
Am Mon, 14 Mar 2016 09:17:00 +0100 schrieb David Brown:
> But it does /not/ operate on the same data types as machine
> instructions.
So you say, K&R are wrong? They may be wrong in the sense of that they
designed their language around the PDP-11, and in the long run pretty
much forced everybody to adopt the PDP-11-isms they used (and many of
those constraints came actually from the IBM /360, which did set a lot of
standards in a very diverse stone-age computing time).
> It operates on a set of types that are in most aspects
> machine-independent, and in some aspects implementation-dependent. These
> do not necessarily match the hardware - they were designed to be a
> reasonable common-subset fit for a lot of the hardware in common use
> when the language was created.
That is a strange view about history. In 1970, data type diversity was
much bigger than today. We had hardware which packed 10 6-bit characters
(of course, all upper case) into one 60 bit word. We had one's and two's
complement for integer, and floating point was very often BCD, or base
16. It was not easy to port C to some other processors of that time due
to the PDP-11-isms in it. ANSI C reflects that diversity by being full
of UB for things that really only diverged back then, and in the
meantime, a consensus has formed.
K&R did not make the language for all these strange hardware back then,
of which very little has survived to today, their focus was on PDP-11.
The hardware characteristics that have survived: byte addressed, two's
complement machines, unsegmented address space, IEEE-style binary
floating point, is not only shaping the C language, it is also shaped by
the C language, as you state below. This is a mutual influence; though
part of that influence was carried independently by the popularity of the
actual popular architectures that had those properties (PDP-11 and
others).
> Processors - and therefore assembly
> languages - have many features in their instruction sets and their data
> types that are not directly available in C. A key example is that on a
> processor, signed integer overflow is typically clearly defined - in C,
> it is not.
Just in *ANSI C,* it is not. E.g. GCC recently (in version 5) got
extensions for that, after they axed the access to wraparound in GCC 2.95
more than a decade ago, and added it back as a compiler switch with -
fwrapv soon due to demand of their user base.
Using -fwrapv, you can detect signed overflow just the same as unsigned
overflow (where the standard has defined mod 2^n behavior) pretty much in
the same way you can for unsigned (where b<0 is always false):
int a, b; ...
if(b<0 ? a>=a+b : a<a+b) { <addition overflow> }
This is C, it is only non-nasal-daemon-C; it is very obvious that this if
triggers only on an overflow (regardless of actual integer
representation). A compiler writer who wants to speed up real-world
programs would detect this pattern and convert it to just two
instructions: add a,b and jump on overflow.
> But equally clearly, small processors will not support data
> types such as 64-bit integers or floating point - but C gives you them
> on such devices.
I've seen Keil C on an 8051. There was neither 64 bit (or 32 bit) nor
floating point support (they later added FP support, and also cleaned up
some rough corners). There are some weird restrictions, too, but in
general, the Keil compiler provided pretty much what I think a "portable
assembler" for the 8051 should look like: all the extensions that are
needed to access the the features of the hardware, all the restrictions
that come with that underpowered CPU, and an efficient way to map the
code to that tiny processor. Once you understand the limitations, you
can write code that works on a PC and on Keil; though of course, a lot of
code written for the 8051 will be inherently non-portable (accessing
SFRs).
If you have an armel Linux or Android system, where software floating
point emulation is enabled, it's not C that provides the floating point.
The compiler just has to limit itself to those instructions of the ARM FP
ISA that is emulated. Same with x86; in the 386 days, I had my software
floating point emulator, but C compiled 80x87 instructions. The
emulation layer did cost performance, it would have been faster if the
corresponding code was called directly.
64 bit data types (register pairs) on 32 bit is used as output of
widening multiplication, also as input for shifts, and input of divisions
on most 32 bit architectures, but C makes the data type more useful, by
also providing other operations. C's support for add with carry is non-
existing, but the double-sized data type allows to express it.
> And modern processors are designed to have data types that fit with C,
> rather than the other way round.
Yes, well observed, that influence is two-way, especially due to C's
popularity. But they still have their add operation defined as if it was
fit for Forth, not for ANSI C: don't care about the sign, just wrap
around, use the same instruction for signed and unsigned addition. Can't
be influence from Forth, because Forth's popularity is much lower than
C's. Forth, of course, was also shaped by the popular 1970 architectures
like PDP-11, so it's that influence.
> There are lots of types of programming that are possible in assembly,
> but completely impossible in (standard) C. You are very limited in your
> access to hardware, you cannot access hardware registers other than
> memory-mapped peripherals, you have no control over the timing of code,
> you have little control over the ordering (volatile accesses are
> ordered, but not calculations or non-volatile accesses), you cannot
> interact with interrupts (except in a very limited way with signals),
> you cannot implement multi-threading, atomic accesses, etc. (you can
> /use/ these features in C11, but you cannot write the underlying
> implementations in standard C), you cannot (at least not efficiently and
> conveniently) use co-routines or other types of control-flow structuring
> outside the limits of C.
There are certainly some aspects of assembler where C is inadequate (even
when implemented in a friendly way), or at least requires adding a few
asm-statements. Not all of the list above is fair: The core of a low-
level language should be those features that cannot be implemented in
that language; so not being able to implement atomic operations based on
the rest of C is not a deficit, but rather suggests adding these
operations to the language standard.
> C is the language that it is - with its benefits and its disadvantages.
> It does not completely replace assembly, but certainly many programs
> that used to be written in assembly could be written more conveniently
> in C (or at least mostly C). In the same way, many programs that have
> traditionally be written in C could be written more conveniently in C++,
> Python, or a host of other higher level languages that have different
> balances between safety, ease-of-use, functionality, efficiency, etc.
Fully agreed on that. The expression "portable assembler" IMHO just
means that: while it can't fully replace assembler in all corner cases,
only very little assembler should be needed (IIRC, K&R provided some line
counts of the remaining assembler part in Unix in the first edition, was
it some hundred lines of code?), and for more high-level stuff, there are
a bunch of other languages which do a better job, depending on your
expectations (none of them do all jobs better than the others).
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-03-14 20:00 -0500 |
| Message-ID | <m2neeblg740l9kpqb4r2drlai0ii0h313o@4ax.com> |
| In reply to | #46067 |
On Mon, 14 Mar 2016 22:56:20 -0000 (UTC), Bernd Paysan
<bernd.paysan@gmx.de> wrote:
>Am Mon, 14 Mar 2016 09:17:00 +0100 schrieb David Brown:
>> But it does /not/ operate on the same data types as machine
>> instructions.
>
>So you say, K&R are wrong? They may be wrong in the sense of that they
>designed their language around the PDP-11, and in the long run pretty
>much forced everybody to adopt the PDP-11-isms they used (and many of
>those constraints came actually from the IBM /360, which did set a lot of
>standards in a very diverse stone-age computing time).
>
>> It operates on a set of types that are in most aspects
>> machine-independent, and in some aspects implementation-dependent. These
>> do not necessarily match the hardware - they were designed to be a
>> reasonable common-subset fit for a lot of the hardware in common use
>> when the language was created.
>
>That is a strange view about history. In 1970, data type diversity was
>much bigger than today. We had hardware which packed 10 6-bit characters
>(of course, all upper case) into one 60 bit word. We had one's and two's
>complement for integer, and floating point was very often BCD, or base
>16. It was not easy to port C to some other processors of that time due
>to the PDP-11-isms in it. ANSI C reflects that diversity by being full
>of UB for things that really only diverged back then, and in the
>meantime, a consensus has formed.
>
>K&R did not make the language for all these strange hardware back then,
>of which very little has survived to today, their focus was on PDP-11.
>The hardware characteristics that have survived: byte addressed, two's
>complement machines, unsegmented address space, IEEE-style binary
>floating point, is not only shaping the C language, it is also shaped by
>the C language, as you state below. This is a mutual influence; though
>part of that influence was carried independently by the popularity of the
>actual popular architectures that had those properties (PDP-11 and
>others).
While K&R were clearly focused on the PPD-11 at the time, a number of
port to "odd" machines arrived very quickly - the Honeywell 6000
(9-bit bytes) is even mentioned in K&R1.
They also mention: "It is now routine in our environment that software
developed on UNIX is transported to the local Honeywell, IBM and
Interdata systems. In fact, the C compilers and runtime support on
these four machines are much more compatible than the supposedly ANSI
standard versions of Fortran."
>> Processors - and therefore assembly
>> languages - have many features in their instruction sets and their data
>> types that are not directly available in C. A key example is that on a
>> processor, signed integer overflow is typically clearly defined - in C,
>> it is not.
>
>Just in *ANSI C,* it is not. E.g. GCC recently (in version 5) got
>extensions for that, after they axed the access to wraparound in GCC 2.95
>more than a decade ago, and added it back as a compiler switch with -
>fwrapv soon due to demand of their user base.
>
>Using -fwrapv, you can detect signed overflow just the same as unsigned
>overflow (where the standard has defined mod 2^n behavior) pretty much in
>the same way you can for unsigned (where b<0 is always false):
>
>int a, b; ...
>if(b<0 ? a>=a+b : a<a+b) { <addition overflow> }
>
>This is C, it is only non-nasal-daemon-C; it is very obvious that this if
>triggers only on an overflow (regardless of actual integer
>representation). A compiler writer who wants to speed up real-world
>programs would detect this pattern and convert it to just two
>instructions: add a,b and jump on overflow.
>
>> But equally clearly, small processors will not support data
>> types such as 64-bit integers or floating point - but C gives you them
>> on such devices.
>
>I've seen Keil C on an 8051. There was neither 64 bit (or 32 bit) nor
>floating point support (they later added FP support, and also cleaned up
>some rough corners). There are some weird restrictions, too, but in
>general, the Keil compiler provided pretty much what I think a "portable
>assembler" for the 8051 should look like: all the extensions that are
>needed to access the the features of the hardware, all the restrictions
>that come with that underpowered CPU, and an efficient way to map the
>code to that tiny processor. Once you understand the limitations, you
>can write code that works on a PC and on Keil; though of course, a lot of
>code written for the 8051 will be inherently non-portable (accessing
>SFRs).
>
>If you have an armel Linux or Android system, where software floating
>point emulation is enabled, it's not C that provides the floating point.
>The compiler just has to limit itself to those instructions of the ARM FP
>ISA that is emulated. Same with x86; in the 386 days, I had my software
>floating point emulator, but C compiled 80x87 instructions. The
>emulation layer did cost performance, it would have been faster if the
>corresponding code was called directly.
>
>64 bit data types (register pairs) on 32 bit is used as output of
>widening multiplication, also as input for shifts, and input of divisions
>on most 32 bit architectures, but C makes the data type more useful, by
>also providing other operations. C's support for add with carry is non-
>existing, but the double-sized data type allows to express it.
>
>> And modern processors are designed to have data types that fit with C,
>> rather than the other way round.
>
>Yes, well observed, that influence is two-way, especially due to C's
>popularity. But they still have their add operation defined as if it was
>fit for Forth, not for ANSI C: don't care about the sign, just wrap
>around, use the same instruction for signed and unsigned addition. Can't
>be influence from Forth, because Forth's popularity is much lower than
>C's. Forth, of course, was also shaped by the popular 1970 architectures
>like PDP-11, so it's that influence.
>
>> There are lots of types of programming that are possible in assembly,
>> but completely impossible in (standard) C. You are very limited in your
>> access to hardware, you cannot access hardware registers other than
>> memory-mapped peripherals, you have no control over the timing of code,
>> you have little control over the ordering (volatile accesses are
>> ordered, but not calculations or non-volatile accesses), you cannot
>> interact with interrupts (except in a very limited way with signals),
>> you cannot implement multi-threading, atomic accesses, etc. (you can
>> /use/ these features in C11, but you cannot write the underlying
>> implementations in standard C), you cannot (at least not efficiently and
>> conveniently) use co-routines or other types of control-flow structuring
>> outside the limits of C.
>
>There are certainly some aspects of assembler where C is inadequate (even
>when implemented in a friendly way), or at least requires adding a few
>asm-statements. Not all of the list above is fair: The core of a low-
>level language should be those features that cannot be implemented in
>that language; so not being able to implement atomic operations based on
>the rest of C is not a deficit, but rather suggests adding these
>operations to the language standard.
>
>> C is the language that it is - with its benefits and its disadvantages.
>> It does not completely replace assembly, but certainly many programs
>> that used to be written in assembly could be written more conveniently
>> in C (or at least mostly C). In the same way, many programs that have
>> traditionally be written in C could be written more conveniently in C++,
>> Python, or a host of other higher level languages that have different
>> balances between safety, ease-of-use, functionality, efficiency, etc.
>
>Fully agreed on that. The expression "portable assembler" IMHO just
>means that: while it can't fully replace assembler in all corner cases,
>only very little assembler should be needed (IIRC, K&R provided some line
>counts of the remaining assembler part in Unix in the first edition, was
>it some hundred lines of code?), and for more high-level stuff, there are
>a bunch of other languages which do a better job, depending on your
>expectations (none of them do all jobs better than the others).
From K&R1: "Of 13000 lines of system code, only about 800 lines at the
very lowest level are in assembler."
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web