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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#84041

On Tuesday, March 15, 2016 at 11:41:35 AM UTC-5, Jerry Stuckle wrote:
> Yes, and there's the American Car Association.  Whoa - wait a sec.  It's
> the American *Automobile* Association.
> 
> We use both terms here.

A pickup truck is a type of automobile.  A car is a different type of
automobile.  A pickup truck is not a type of car.

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

#84042

On 3/15/2016 2:18 PM, supercat@casperkitty.com wrote:
> On Tuesday, March 15, 2016 at 11:41:35 AM UTC-5, Jerry Stuckle wrote:
>> Yes, and there's the American Car Association.  Whoa - wait a sec.  It's
>> the American *Automobile* Association.
>>
>> We use both terms here.
> 
> A pickup truck is a type of automobile.  A car is a different type of
> automobile.  A pickup truck is not a type of car.
> 

I have *never* heard the term automobile applied to a pickup truck!

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

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

#84043

On Tuesday, March 15, 2016 at 1:42:56 PM UTC-5, Jerry Stuckle wrote:
> I have *never* heard the term automobile applied to a pickup truck!

As an individual vehicle not typically, but someone who owned a passenger
car and a pickup truck would likely have an "automobile" insurance policy
for both.  I don't know of any other term that would encompass cars,
pickups, mini-vans, etc. but exclude commercial vehicles like semis, box
trucks, etc.

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

#84046

On 3/15/2016 2:54 PM, supercat@casperkitty.com wrote:
> On Tuesday, March 15, 2016 at 1:42:56 PM UTC-5, Jerry Stuckle wrote:
>> I have *never* heard the term automobile applied to a pickup truck!
> 
> As an individual vehicle not typically, but someone who owned a passenger
> car and a pickup truck would likely have an "automobile" insurance policy
> for both.  I don't know of any other term that would encompass cars,
> pickups, mini-vans, etc. but exclude commercial vehicles like semis, box
> trucks, etc.
> 

How about "motor vehicle" - or "non-commercial motor vehicle"?

And BTW - insurance policies also apply to commercial motor vehicles.

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

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

#84047

On 3/15/2016 2:54 PM, supercat@casperkitty.com wrote:
> On Tuesday, March 15, 2016 at 1:42:56 PM UTC-5, Jerry Stuckle wrote:
>> I have *never* heard the term automobile applied to a pickup truck!
> 
> As an individual vehicle not typically, but someone who owned a passenger
> car and a pickup truck would likely have an "automobile" insurance policy
> for both.  I don't know of any other term that would encompass cars,
> pickups, mini-vans, etc. but exclude commercial vehicles like semis, box
> trucks, etc.
> 

(Hit it too fast)

And automobiles can be commercial vehicles also, just as cargo vans may
or may not be commercial vehicles.  It's how the are used that counts -
not what they are.

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

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

#84055

On Tue, 15 Mar 2016 11:54:52 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Tuesday, March 15, 2016 at 1:42:56 PM UTC-5, Jerry Stuckle wrote:
>> I have *never* heard the term automobile applied to a pickup truck!
>
>As an individual vehicle not typically, but someone who owned a passenger
>car and a pickup truck would likely have an "automobile" insurance policy
>for both.  I don't know of any other term that would encompass cars,
>pickups, mini-vans, etc. but exclude commercial vehicles like semis, box
>trucks, etc.


Some of that is just tradition and/or inertia.  If you insure your
airplane, you buy "hull insurance" (despite the fact that most
airplane make terrible boats, although a few are merely poor boats).
And that's because the first aircraft policies were modifications of
boat policies.

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

#84049

On 15-Mar-16 13:42, Jerry Stuckle wrote:
> On 3/15/2016 2:18 PM, supercat@casperkitty.com wrote:
>> Jerry Stuckle wrote:
>>> Yes, and there's the American Car Association.  Whoa - wait a
>>> sec.  It's the American *Automobile* Association.
>>> 
>>> We use both terms here.
>> 
>> A pickup truck is a type of automobile.  A car is a different type
>> of automobile.  A pickup truck is not a type of car.

Ford boasts that the F150 is the best-selling "car" in America.

> I have *never* heard the term automobile applied to a pickup truck!

Pickup makers call themselves "automobile" manufacturers, and they are
part of the "auto industry".  The entire point of using that word,
rather than "car", is to include pickups and SUVs.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#84050

On 3/15/2016 4:37 PM, Stephen Sprunk wrote:
> On 15-Mar-16 13:42, Jerry Stuckle wrote:
>> On 3/15/2016 2:18 PM, supercat@casperkitty.com wrote:
>>> Jerry Stuckle wrote:
>>>> Yes, and there's the American Car Association.  Whoa - wait a
>>>> sec.  It's the American *Automobile* Association.
>>>>
>>>> We use both terms here.
>>>
>>> A pickup truck is a type of automobile.  A car is a different type
>>> of automobile.  A pickup truck is not a type of car.
> 
> Ford boasts that the F150 is the best-selling "car" in America.
> 
>> I have *never* heard the term automobile applied to a pickup truck!
> 
> Pickup makers call themselves "automobile" manufacturers, and they are
> part of the "auto industry".  The entire point of using that word,
> rather than "car", is to include pickups and SUVs.
> 
> S
> 

They call themselves "automobile" manufacturers because their main
product is automobiles.  Would you rather they call themselves
"automobile, pickup truck, SUV, cargo van and light truck" manufacturers?

Many companies go by their major product(s) instead of listing
everything they do.

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

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

#83968

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]

#83969

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]

#83979

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]

#83985

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]

#84007

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]

#84012

C might not be a 'portable assembler' in the same sense as a automobile 
is a horseless-carriage (that depends a bit on how limited you want to 
define assembler).

I think it does qualify in the sense of the 'Iron Horse' as a name for 
the locomotive (aka train). It may not be exactly an assembler, but it 
is close enough for many purposes that it can largely replace one.

Especially in the earlier days, a person skilled in C and assembly could 
do a pretty good translation of C code to assembly and get very close to 
what a C compiler would put out (of course the purpose of the compiler 
was so you didn't have to). It was fairly easy to write code that was 
nearly as efficient as assembly, but didn't need to be recoded for every 
different machine. (You lost some access to some of the 'trick' 
instructions that might help in special cases, and traded that for being 
portable).

Since when C was being developed there were a LOT more common 
architectures for processors, this could be a big win. Today you can get 
much large market penetration with a very small number of basic machine 
architectures (but even now, if you want to be hyper-efficient, there 
are lots a variations you might want to learn).

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

#84026

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]

#84045

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]

#84218

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]

#84245

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]

#84270

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]

#84271

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]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web