Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #83771 > unrolled thread
| Started by | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| First post | 2016-03-13 12:27 +0000 |
| Last post | 2016-03-15 09:24 -0700 |
| Articles | 9 on this page of 69 — 19 participants |
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.
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-03-14 22:40 +0000 |
| Message-ID | <56e73d97.3723109@news.xs4all.nl> |
| In reply to | #83945 |
supercat@casperkitty.com wrote: > On Monday, March 14, 2016 at 4:56:01 PM UTC-5, Keith Thompson wrote: > > I disagree. If I'm writing a C program (even if I were writing it in > > the 1980s), 99% of the time I *do not care* what sequence of loads, > > stores, and arithmetic operations the compiler generates. I care only > > that the resulting code does what I specified. (The 1% of the time that > > I do care, it's because I'm debugging the behavior of the code on a > > lower level than is usually necessary.) > > Programmers wouldn't generally have cared about the order in which the > operations physically took place in situations where it wasn't observable, > but would have expected that the program should behave as though the > operations took place in the order indicated Wrong. And that statement really doesn't warrant any more debunking than a flat statement that it wasn't true, so you're not getting any. Richard
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-03-14 20:12 -0400 |
| Message-ID | <nc7jql$h04$1@jstuckle.eternal-september.org> |
| In reply to | #83953 |
On 3/14/2016 6:40 PM, Richard Bos wrote: > supercat@casperkitty.com wrote: > >> On Monday, March 14, 2016 at 4:56:01 PM UTC-5, Keith Thompson wrote: >>> I disagree. If I'm writing a C program (even if I were writing it in >>> the 1980s), 99% of the time I *do not care* what sequence of loads, >>> stores, and arithmetic operations the compiler generates. I care only >>> that the resulting code does what I specified. (The 1% of the time that >>> I do care, it's because I'm debugging the behavior of the code on a >>> lower level than is usually necessary.) >> >> Programmers wouldn't generally have cared about the order in which the >> operations physically took place in situations where it wasn't observable, >> but would have expected that the program should behave as though the >> operations took place in the order indicated > > Wrong. > No, he is correct. The actual order of operations within a block of code is immaterial, as long as the results is as expected. > And that statement really doesn't warrant any more debunking than a flat > statement that it wasn't true, so you're not getting any. > > Richard > Your statement is pure bunk. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-14 16:17 -0700 |
| Message-ID | <ln37rsk5td.fsf@kst-u.example.com> |
| In reply to | #83945 |
supercat@casperkitty.com writes:
> On Monday, March 14, 2016 at 4:56:01 PM UTC-5, Keith Thompson wrote:
>> I disagree. If I'm writing a C program (even if I were writing it in
>> the 1980s), 99% of the time I *do not care* what sequence of loads,
>> stores, and arithmetic operations the compiler generates. I care only
>> that the resulting code does what I specified. (The 1% of the time that
>> I do care, it's because I'm debugging the behavior of the code on a
>> lower level than is usually necessary.)
>
> Programmers wouldn't generally have cared about the order in which the
> operations physically took place in situations where it wasn't observable,
> but would have expected that the program should behave as though the
> operations took place in the order indicated except in cases where the
> compiler might document otherwise (typically as a consequence of enabling
> optimizations).
[...]
I'm not talking about reordering. I mean that I don't care about the
CPU instructions generated for a given piece of C code, any more than
I care whether the CPU is built using silicon or gallium arsenide.
C code specifies behavior; CPU instructions are merely a way to
implement that behavior.
Your concerns about aliasing are a different issue. If C were
specified in exactly the way you want it to be, it would still
specify the behavior of a C program. The operations you're talking
about aren't CPU instructions (though they may or may not be
straightforwardly implemented that way).
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-03-14 23:28 -0700 |
| Message-ID | <9161b518-daaf-43c1-8935-9b0ebe1ee935@googlegroups.com> |
| In reply to | #83960 |
On Monday, March 14, 2016 at 6:17:41 PM UTC-5, Keith Thompson wrote: > I'm not talking about reordering. I mean that I don't care about the > CPU instructions generated for a given piece of C code, any more than > I care whether the CPU is built using silicon or gallium arsenide. > C code specifies behavior; CPU instructions are merely a way to > implement that behavior. If a variable is loaded twice consecutively, without any intervening writes being made to it, the second load can be omitted if the result of the first load is available in a register. If a variable is stored and then loaded without any intervening writes, the load can be omitted if the value stored is still available in a register. If a variable is stored twice without any intervening loads, the first store can be omitted. All these are straightforward optimizations if a compiler is allowed to treat the appropriate loads and stores as consecutive. If a compiler performs such optimizations in the presence of other unexpected accesses to the same location, the effect will be that the compiler will effectively change the order in which the operations occur. For example, given x++; *p = *q; x++; if p aliases x but the compiler doesn't realize that, the effect may be equivalent to that of moving the second load of x before the store to *p [in case the compiler includes the first store] or moving the first store of x after the store to *p. If q aliases x, the effect may be equivalent to moving the first store past the load of *q. > Your concerns about aliasing are a different issue. If C were > specified in exactly the way you want it to be, it would still > specify the behavior of a C program. The operations you're talking > about aren't CPU instructions (though they may or may not be > straightforwardly implemented that way). As C was originally designed (per that early reference manual), members of a structure had a type and an offset, but no other semantic significance. If member m of type T was at offset 8 of structure s, the syntax s->m would have been equivalent to *(T*)(((char*)m)+8), and either expression would be valid in the same situations as the other. I would posit that in the 1980s and 1990s it was perfectly common to expect that the -> operator will behave in that way in all cases where there is an object of the appropriate member type in the appropriate place, regardless of the type of the surrounding structure; in cases where the layout of a data structure created by outside code was known, creating a structure and casting a pointer to it was considered cleaner than using a lot of manual address computation to extract fields.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-15 00:05 -0700 |
| Message-ID | <lnegbci5le.fsf@kst-u.example.com> |
| In reply to | #83982 |
supercat@casperkitty.com writes:
> On Monday, March 14, 2016 at 6:17:41 PM UTC-5, Keith Thompson wrote:
>> I'm not talking about reordering. I mean that I don't care about the
>> CPU instructions generated for a given piece of C code, any more than
>> I care whether the CPU is built using silicon or gallium arsenide.
>> C code specifies behavior; CPU instructions are merely a way to
>> implement that behavior.
>
> If a variable is loaded twice consecutively, without any intervening
> writes being made to it, the second load can be omitted if the result
> of the first load is available in a register.
[big snip]
Again, I'm talking about whether there's a direct mapping from C source
code to CPU instructions. (There isn't.) Neither C as it's defined by
the ISO standard, nor C as it's implemented, nor C as you'd like it to
be defined and implemented, is an assembler.
Please stop bringing up the same arguments in every thread. We heard
you the 20th time.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-03-15 08:29 +0000 |
| Message-ID | <nc8gve$p63$1@dont-email.me> |
| In reply to | #83982 |
On 15/03/16 06:28, supercat@casperkitty.com wrote: > On Monday, March 14, 2016 at 6:17:41 PM UTC-5, Keith Thompson wrote: >> I'm not talking about reordering. I mean that I don't care about the >> CPU instructions generated for a given piece of C code, any more than >> I care whether the CPU is built using silicon or gallium arsenide. >> C code specifies behavior; CPU instructions are merely a way to >> implement that behavior. > > If a variable is loaded twice consecutively, without any intervening > writes being made to it, the second load can be omitted if the result > of the first load is available in a register. How can that possibly be relevant to me as a C programmer? The whole point of C is that it lets me write programs that will work on this machine, that machine, and the other machine over there, not forgetting the machine lying under all those cobwebs in the corner and that machine with the shiny new laser eyes that they've just brought in. They all have different ways of doing things, different ways of ordering instructions, but C works on all of them. If I find myself caring about the underlying object code, I suddenly have to worry about all these different machine architectures. C insulates me from that. I'm not saying that we never have to worry about such things, but the moment we do is the moment we put down C for a while and pick up assembly language instead. > x++; > *p = *q; > x++; > > if p aliases x but the compiler doesn't realize that, the effect may be > equivalent to that of moving the second load of x before the store to *p > [in case the compiler includes the first store] or moving the first store > of x after the store to *p. If q aliases x, the effect may be equivalent > to moving the first store past the load of *q. You know, the great thing about C is that you don't have to care about this sort of stuff. I realise that, /if/ you're nailed to one platform, it might be quite relaxing and enjoyable to care about this sort of stuff. In fact, if I were nailed to one platform, I don't think I'd bother with C at all, because I'd be so engrossed in the low-level details that it would be difficult to pry me away from assembly language. But if we want to get anything done on multiple platforms this side of Christmas, it's good to be able to write code without having to worry about whether the compiler is going to load this and store that or store this and load that. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-03-14 22:38 +0000 |
| Message-ID | <56e73caa.3486218@news.xs4all.nl> |
| In reply to | #83833 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > 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 ..." All of which proves that C is a programming language which can be used to _not_ program in assembly language, rather than a portable version of assembly language itself. > The next thing you probably refute is that K&R developed the programming > language C. I should bloody well hope so! Dennis Ritchie developed C, Brian Kernighan "only" wrote the book, _not_ the language. > There's a lot of nonsense in the discussion above, of people who studied > C "the hard, academic way You know fuck-all about me, yet you think you know everything. What a surprise from a FORTH-head... getting things backwards _does_ become a habit, doesn't it? Richard
[toc] | [prev] | [next] | [standalone]
| From | Randy Howard <rhoward.mx@EverybodyUsesIt.com> |
|---|---|
| Date | 2016-03-14 01:40 -0500 |
| Message-ID | <nc5mc1$1o2c$1@gioia.aioe.org> |
| In reply to | #83802 |
On 3/13/16 2:52 PM, Albert van der Horst wrote: > 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. Not sure where you are getting this mythology from, but you may want to double-check your sources. -- Randy Howard (replace the obvious text in the obvious way if you wish to contact me directly)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-03-15 09:24 -0700 |
| Message-ID | <27d35038-8899-459c-a626-d9050ba07242@googlegroups.com> |
| In reply to | #83775 |
W dniu niedziela, 13 marca 2016 14:51:03 UTC+1 użytkownik Richard Bos napisał: > 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. > why? i rather agree with that, i even think that assembly is a part of c (c coder is expected to know asm imo)
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web