Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #83771 > unrolled thread

Re: OT: One of Anton's papers makes Hacker News

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-15 03:06 -0700
                            Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-15 08:47 -0700
                              Re: OT: One of Anton's papers makes Hacker News Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-15 11:59 -0400
                                Re: OT: One of Anton's papers makes Hacker News Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-15 09:34 -0700
                                Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-15 11:17 -0700
                            Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-15 12:41 -0400
                              Re: OT: One of Anton's papers makes Hacker News Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-15 10:54 -0700
                              Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-15 11:18 -0700
                                Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-15 14:42 -0400
                                  Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-15 11:54 -0700
                                    Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-15 16:11 -0400
                                    Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-15 16:13 -0400
                                    Re: OT: One of Anton's papers makes Hacker News Robert Wessel <robertwessel2@yahoo.com> - 2016-03-15 16:18 -0500
                                  Re: OT: One of Anton's papers makes Hacker News Stephen Sprunk <stephen@sprunk.org> - 2016-03-15 15:37 -0500
                                    Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-15 16:42 -0400
                        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 Richard Damon <Richard@Damon-Family.org> - 2016-03-15 08:19 -0400
                            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 supercat@casperkitty.com - 2016-03-17 11:53 -0700
                                      Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-17 19:58 -0400
                                  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 Tim Rentsch <txr@alumni.caltech.edu> - 2016-03-18 08:14 -0700
                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 supercat@casperkitty.com - 2016-03-14 14:14 -0700
                    Re: OT: One of Anton's papers makes Hacker News Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 14:26 -0700
                      Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-14 14:46 -0700
                        Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-15 10:39 +0100
                    Re: OT: One of Anton's papers makes Hacker News David Brown <david.brown@hesbynett.no> - 2016-03-15 10:38 +0100
                      Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-15 07:47 -0700
                  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 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 00:43 -0700
                Re: OT: One of Anton's papers makes Hacker News Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 08:06 +0000
              Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-14 14:01 -0700
                Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 14:55 -0700
                  Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-14 15:17 -0700
                    Re: OT: One of Anton's papers makes Hacker News raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:40 +0000
                      Re: OT: One of Anton's papers makes Hacker News Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-14 20:12 -0400
                    Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-14 16:17 -0700
                      Re: OT: One of Anton's papers makes Hacker News supercat@casperkitty.com - 2016-03-14 23:28 -0700
                        Re: OT: One of Anton's papers makes Hacker News Keith Thompson <kst-u@mib.org> - 2016-03-15 00:05 -0700
                        Re: OT: One of Anton's papers makes Hacker News Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:29 +0000
            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 fir <profesor.fir@gmail.com> - 2016-03-15 09:24 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#83771 — Re: OT: One of Anton's papers makes Hacker News

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] | [next] | [standalone]

#83775

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]

#83802

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]

#83806

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]

#83811

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]

#83833

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]

#83837

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]

#83841

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]

#83842

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]

#83955

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]

#83961

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]

#83964

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]

#83967

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]

#84006

On Tuesday, March 15, 2016 at 12:19:44 AM UTC, Keith Thompson wrote:
> Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>
> 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.
> 
In the States, no.
This side of the pond, we call them "cars" rather than automobiles.
An automobile is specifically a horseless carriage, a "car" usually also
means a horseless carriage, but can also mean one pulled by a 
locomotive ("the dining car"), or by a horse, though that's now rare.

[toc] | [prev] | [next] | [standalone]

#84024

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, March 15, 2016 at 12:19:44 AM UTC, Keith Thompson wrote:
>> Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>>
>> 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.
>> 
> In the States, no.
> This side of the pond, we call them "cars" rather than automobiles.

So do we.  "Automobile" and "car" are both used.  "Car" is perhaps
slightly less formal.  (This is, of course, irrelevant.)

> An automobile is specifically a horseless carriage, a "car" usually also
> means a horseless carriage, but can also mean one pulled by a 
> locomotive ("the dining car"), or by a horse, though that's now rare.

The term "dining car" is also commonly used in the US.
dictionary.com gives "a railway passenger coach" as a meaning of
"carriage", and says it's British.  (Again, this is all irrelevant.)

A car/automobile is a horseless carriage.  It is not a horse,
even though it largely replaces horses.  (We could, I suppose,
have changed the meaning of the word "horse" to include cars,
but that didn't happen.)

C is not an assembler.  I see a very stark distinction between
assembly languages (which specify, perhaps not with 100% fidelity,
sequences of CPU instructions) and higher-level languages (that say
nothing about CPU instructions).  C is clearly on the higher-level
side of that divide.  It's a relatively low-level language as
compared to, say, Python or Ada.  But since we already have the
phrase "low-level language", I see no need to warp the meaning of
"assembler" to cover C.

-- 
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]

#84028

On 3/15/2016 11:47 AM, Keith Thompson wrote:
> [...]
> C is not an assembler.[...]

     Further to this point: When has anyone encountered an assembler
that will eliminate common sub-expressions?  Reduce operator strength?
Unroll loops?  Add pre-fetch instructions to mask data latencies?

     No such optimizations are required of a C implementation, yet
nearly all implementations do these and more as a matter of course.
When has anyone encountered an optimizing assembler?

     (Answer: I did, in about 1978, but the optimization was trivial.
The machine had self-relative branch instructions that could jump to
nearby targets, and longer/slower branches that could jump to distant
addresses.  The assembler supported a pseudo-op that turned into a
short branch if the destination was near or a long branch if it was
remote.  Backward branches were figured out in the initial pass, but
there was a separate pass to decide which kind of instruction to use
for forward branches.  That's the *only* assembler I ever ran into that
performed any kind of optimization at all.  In C-land, by contrast,
sophisticated optimization is routine.)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#84034

On Tuesday, March 15, 2016 at 3:59:28 PM UTC, Eric Sosman wrote:
> On 3/15/2016 11:47 AM, Keith Thompson wrote:
> 
>      Further to this point: When has anyone encountered an assembler
> that will eliminate common sub-expressions?  Reduce operator strength?
> Unroll loops?  Add pre-fetch instructions to mask data latencies?
> 
>      No such optimizations are required of a C implementation, yet
> nearly all implementations do these and more as a matter of course.
> When has anyone encountered an optimizing assembler?
> 
>      (Answer: I did, in about 1978, but the optimization was trivial.
> The machine had self-relative branch instructions that could jump to
> nearby targets, and longer/slower branches that could jump to distant
> addresses.  The assembler supported a pseudo-op that turned into a
> short branch if the destination was near or a long branch if it was
> remote.  Backward branches were figured out in the initial pass, but
> there was a separate pass to decide which kind of instruction to use
> for forward branches.  That's the *only* assembler I ever ran into that
> performed any kind of optimization at all.  In C-land, by contrast,
> sophisticated optimization is routine.)
> 
My last significant assembly language work was years ago, for a RISC
processor used in the Nintendo 64. The assembler had lots of features
so that the assembly instructions didn't necessarily match the machine 
code. However mainly it was to make code easier to write. If I remember 
rightly, branches were tightly restricted to a few instructions in length, so 
to execute a big conditional jump, you had to branch to a "trampoline"
which would then do the jump for you. But the assembler hid that, you
could just type bz r1 label (branch to "label" if register 1 is zero) and 
it would fix up out of range labels.

[toc] | [prev] | [next] | [standalone]

#84040

On Tuesday, March 15, 2016 at 10:59:28 AM UTC-5, Eric Sosman wrote:
> > C is not an assembler.[...]
> 
>      Further to this point: When has anyone encountered an assembler
> that will eliminate common sub-expressions?  Reduce operator strength?
> Unroll loops?  Add pre-fetch instructions to mask data latencies?

To borrow the analogy given above, when did one last encounter anything
referred to as any kind of horse that consumed coal?

I would suggest that most microprocessor C dialects have a common core set
of operations whose canonical behavior may be defined as an abstract machine
which has an arbitrary number of non-addressable registers in each execution
context plus a quantity of addressable storage.  Given

    struct short_pair {short x,y; }
    extern short_pair *foo;

a statement "foo->x += 25;" would be performed as [numbering temporary value
holders arbitrarily]

    load p539 from pointer in memory at global label "foo"
    add 2 to p539
    load i389 from two bytes in memory at p539
    add 25 to i389, yielding at least 16 valid bits
    store int i389 to two bytes in memory at p539

Each of those lines may take multiple machine instructions, or multiple
lines might be consolidated into one machine instruction, or anything
in-between.  The key point is that every program may be described in terms
of instructions for an abstract machine that knows nothing about any
non-primitive types, and such description defines a "canonical" behavior for
that program.  Further, while different abstract machines might have
different behavior in case of things like arithmetic overflow, most machines
would have a well-defined natural behavior, though sometimes with some
uncertainties (e.g. registers holding signed integers may arbitrarily hold
or discard excess precision) and in many cases that natural behavior may be
useful.

I would suggest that rather than having compiler writers assume that there
is no need to let the program specify behavior in any circumstances other
than those in which they think behavior should be defined, it would be more
helpful to recognize the existence of a canonical meaning which would be
yielded by straightforward compilation, and then allow programmers to
indicate the extent to which they can tolerate deviations from that meaning.

In some application fields there are many situations where the natural
canonical meaning of code on a given platform would coincide with
application requirements in circumstances not recognized by the Standard.
If a function needs to compute x*y+l in cases where x and y are both in the
range +/- 127 and l is in the range -LONG_MAX/2 to +LONG_MAX/2 or yield any
value in cases where x, y, or l is outside the given range, the natural
canonical behavior of x*y+l on most microcomputer platforms would fit the
requirements perfectly.  Given that most programming languages evolve in
the direction of allowing things to be expressed more concisely, it would
seem a shame for modern compilers to require something much more complicated
to yield behavior that could be achieved easily on an older one.  Even if
a compiler can be made sophisticated enough to turn some complicated
expression into the same code that an old compiler would have naturally
yielded in the first place, I would think such efforts would be more usefully
directed toward providing ways for programmers to simply say what they want
the compiler to do in the same kind of low-level terms as older compilers
did.

Optimization opportunities are optimized when a compiler can implement
semantics which are as loose as possible *while still meeting application
requirements*.  For a compiler to loosen semantics beyond that point,
however, is counter-productive.  Either the application will end up having
to include code which forces stronger semantics than it really needs, or
else the application will sometimes unpredictably fail to meet requirements.
Neither outcome seems desirable.

[toc] | [prev] | [next] | [standalone]

#84035

On 3/15/2016 6:06 AM, Malcolm McLean wrote:
> On Tuesday, March 15, 2016 at 12:19:44 AM UTC, Keith Thompson wrote:
>> Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>>
>> 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.
>>
> In the States, no.
> This side of the pond, we call them "cars" rather than automobiles.
> An automobile is specifically a horseless carriage, a "car" usually also
> means a horseless carriage, but can also mean one pulled by a 
> locomotive ("the dining car"), or by a horse, though that's now rare.
> 

Yes, and there's the American Car Association.  Whoa - wait a sec.  It's
the American *Automobile* Association.

We use both terms here.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#84038

On Tuesday, March 15, 2016 at 4:41:35 PM UTC, Jerry Stuckle wrote:
> On 3/15/2016 6:06 AM, Malcolm McLean wrote:
>
> Yes, and there's the American Car Association.  Whoa - wait a sec.  It's
> the American *Automobile* Association.
> 
> We use both terms here.
> 
Automobile is used occasionally in Britain, but usually in trade names
"Auto Superdeals" and so on. It's very rare to hear the term in speech
other than as part of such a term.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web