Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #14720 > unrolled thread
| Started by | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| First post | 2011-12-18 20:51 -0500 |
| Last post | 2011-12-19 22:35 +0000 |
| Articles | 20 on this page of 106 — 24 participants |
Back to article view | Back to comp.lang.c
code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 20:51 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 18:29 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 21:51 -0500
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 22:24 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 19:53 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 23:32 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 20:57 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 00:01 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-18 21:13 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 16:42 -0500
Re: code snippet Keith Thompson <kst-u@mib.org> - 2011-12-18 20:14 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-18 23:27 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-19 12:33 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 16:33 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-20 00:20 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 19:46 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-20 01:14 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-20 15:51 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-21 14:11 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-21 07:03 -0800
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-21 21:41 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-21 16:35 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 01:03 +0000
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-22 03:19 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 07:11 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 16:59 +0000
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-22 18:38 +0100
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 10:40 -0800
Re: code snippet Markus Wichmann <nullplan@gmx.net> - 2011-12-22 19:12 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 03:50 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-28 17:06 +0100
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-01 20:04 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 12:38 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-02 10:14 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-03 04:56 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-03 18:26 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-04 00:09 -0800
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 21:53 +1300
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-04 16:14 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 12:28 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2012-01-02 10:18 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-03 04:56 -0800
Re: code snippet "BartC" <bc@freeuk.com> - 2011-12-22 18:05 +0000
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 18:14 +0000
Re: code snippet superpollo <superpollo@tznvy.pbz> - 2011-12-22 20:00 +0100
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 19:08 +0000
Re: code snippet superpollo <superpollo@tznvy.pbz> - 2011-12-22 22:43 +0100
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet BruceS <bruces42@hotmail.com> - 2011-12-23 16:26 -0800
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-22 19:21 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 11:33 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-23 09:10 +0100
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-23 14:43 +0000
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-23 17:14 +0000
Re: code snippet Keith Thompson <kst-u@mib.org> - 2011-12-23 12:10 -0800
Re: code snippet Walter Banks <walter@bytecraft.com> - 2012-01-03 14:24 -0500
Re: code snippet Kaz Kylheku <kaz@kylheku.com> - 2012-01-03 19:58 +0000
Re: code snippet Walter Banks <walter@bytecraft.com> - 2012-01-03 16:15 -0500
Re: code snippet blp@cs.stanford.edu (Ben Pfaff) - 2012-01-03 13:26 -0800
Re: code snippet Kaz Kylheku <kaz@kylheku.com> - 2012-01-03 22:04 +0000
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 15:44 +1300
Re: code snippet "BartC" <bc@freeuk.com> - 2012-01-04 23:34 +0000
Re: code snippet James Harris <james.harris.1@googlemail.com> - 2012-01-04 15:57 -0800
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-05 23:34 -0800
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-06 00:40 -0800
Re: code snippet Kleuske <kleuske@nowhere.net> - 2012-01-06 10:33 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-06 04:30 -0800
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 15:37 +1300
Re: code snippet Kaz Kylheku <kaz@kylheku.com> - 2012-01-04 03:37 +0000
Re: code snippet Ian Collins <ian-news@hotmail.com> - 2012-01-04 20:23 +1300
Re: code snippet jacob navia <jacob@spamsink.net> - 2011-12-22 18:26 +0100
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-22 19:34 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 11:57 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 20:18 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 12:52 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 20:37 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 13:27 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 14:09 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-23 04:01 -0800
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-22 14:24 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-22 21:57 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-01 23:06 -0800
Re: code snippet Hans Vlems <hvlems@freenet.de> - 2011-12-22 23:35 -0800
Re: code snippet "BartC" <bc@freeuk.com> - 2011-12-23 12:26 +0000
Re: code snippet jacob navia <jacob@spamsink.net> - 2011-12-23 18:32 +0100
Re: code snippet Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 04:04 -0800
Re: code snippet "io_x" <a@b.c.invalid> - 2011-12-23 09:10 +0100
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-25 11:13 -0800
Re: code snippet Seebs <usenet-nospam@seebs.net> - 2011-12-25 19:31 +0000
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-26 21:53 +0000
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-26 16:10 -0800
Re: code snippet Keith Thompson <kst-u@mib.org> - 2011-12-26 18:11 -0800
Re: code snippet 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-26 23:56 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-20 15:57 -0500
Re: code snippet Rui Maciel <rui.maciel@gmail.com> - 2011-12-21 12:39 +0000
Re: code snippet Bill Reid <hormelfree@gmail.com> - 2011-12-22 15:29 -0800
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-19 19:19 -0800
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-20 13:51 -0500
Re: code snippet Geoff <geoff@invalid.invalid> - 2011-12-20 11:08 -0800
Re: code snippet Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-19 11:37 +0000
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 16:38 -0500
Re: code snippet "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-12-19 17:02 -0500
Re: code snippet "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-19 17:21 -0500
Re: code snippet John Gordon <gordon@panix.com> - 2011-12-19 22:35 +0000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-04 15:44 +1300 |
| Message-ID | <9mhspaFpeqU6@mid.individual.net> |
| In reply to | #15389 |
On 01/ 4/12 11:04 AM, Kaz Kylheku wrote: > On 2012-01-03, Walter Banks<walter@bytecraft.com> wrote: >> >> >> Kaz Kylheku wrote: >> >>>> Very few as in some C compilers actually check that everything that can be >>>> done in asm can be done in C. >>> >>> Really? An example or two would go a long way here. >> >> http://bytecraft.com/C_versus_Assembly > > In machine language, we can, for instance, disable interrupts, flush an > instruction cache, or save the registers to a stack. To show that everything > that can be done in assembly can be done in C, you have to show how these > things are done. The paper does not show such things. > > The paper argues that in the domain of translating calculation formulas, > a compiler can select instructions as well as human programmer. (And that with > some extensions to C, like "char small @0x15;" or "registerx xreg;" we can even > coerce the selection of particular operands to match specific instances of > assembly language.) > > This has not been controversial for decades; the paper belongs more in 1966, or > maybe 1976, than in 2006. Here I do agree with you. The only (relatively) recent times I've used assembler were for the cases you mention above (in order to model an RTOS). > These days, if you're finding that you can't beat the C compiler by coding in > assembly language, chances are it's in large part because the assembly language > is designed to work well as a target language for C compilers! That has not > historically been the case. Very true. Another reason is modern compilers can optimise and analyse way more code in one pass than the programmer can. Gone are the days when optimiser performance was limited by available RAM. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-01-04 23:34 +0000 |
| Message-ID | <mn5Nq.204151$Bf.136537@newsfe17.ams2> |
| In reply to | #15386 |
"Walter Banks" <walter@bytecraft.com> wrote in message news:4F036FE2.6B947764@bytecraft.com... > > > Kaz Kylheku wrote: > >> > Very few as in some C compilers actually check that everything that can >> > be >> > done in asm can be done in C. >> >> Really? An example or two would go a long way here. > > http://bytecraft.com/C_versus_Assembly That's interesting but I don't see how you can extrapolate from that and say there's no longer any point in anyone writing assembly ever again. You have a compiler where you've made possible to directly refer to a register by name. You have a single line in C that increments the register and are surprised when it generates an increment instruction for that register! What you've really written is some inline, high-level assembly code! There's plenty of things a compiler can't optimise because it doesn't know what the programmer does, and he can't put across the knowledge in the language. And there are some things that can't be expressed in C (someone mentioned a carry flag in a related thread). You can of course add special language extensions for these, but that will end up with nearly the same portability problems as just writing a bit of assembly in the first place. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@googlemail.com> |
|---|---|
| Date | 2012-01-04 15:57 -0800 |
| Message-ID | <8c1e6e7c-23f1-4a5d-afbf-9ad199e632c4@z25g2000vbs.googlegroups.com> |
| In reply to | #15386 |
On Jan 3, 9:15 pm, Walter Banks <wal...@bytecraft.com> wrote: > Kaz Kylheku wrote: > > > Very few as in some C compilers actually check that everything that can be > > > done in asm can be done in C. > > > Really? An example or two would go a long way here. > > http://bytecraft.com/C_versus_Assembly That paper calls itself "Proof that C can match or beat assembly"! Sadly, it is nothing of the sort. It seems to compare *bad assembly* with compiler output and assume that because the compiler did better than the specific poor assembly code that they compared it with we must draw the general conclusion that C can match or beat assembly. Don't get me wrong. I'm a fan of C but it is to no-one's benefit to spread nonsense like the above. The paper includes the sentence, "After all, what is a compiler but the distilled wisdom of years of programming experience?" LOL! Cloud fairy-tale land. The sentence shows the blind faith that some people adhere to - possibly because they don't understand the details and just assume the compiler is wonderful! James
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2012-01-05 23:34 -0800 |
| Message-ID | <3541542.567.1325835288068.JavaMail.geo-discussion-forums@prlu4> |
| In reply to | #15428 |
James Harris於 2012年1月5日星期四UTC+8上午7時57分55秒寫道： > On Jan 3, 9:15 pm, Walter Banks <wal...@bytecraft.com> wrote: > > Kaz Kylheku wrote: > > > > Very few as in some C compilers actually check that everything that can be > > > > done in asm can be done in C. > > > > > Really? An example or two would go a long way here. > > > > http://bytecraft.com/C_versus_Assembly > > That paper calls itself "Proof that C can match or beat assembly"! > Sadly, it is nothing of the sort. It seems to compare *bad assembly* > with compiler output and assume that because the compiler did better > than the specific poor assembly code that they compared it with we > must draw the general conclusion that C can match or beat assembly. > > Don't get me wrong. I'm a fan of C but it is to no-one's benefit to > spread nonsense like the above. > > The paper includes the sentence, "After all, what is a compiler but > the distilled wisdom of years of programming experience?" LOL! Cloud > fairy-tale land. The sentence shows the blind faith that some people > adhere to - possibly because they don't understand the details and > just assume the compiler is wonderful! > > James We are not at the era that C was competing with Fortran and Pascal. At that kind of battles, programers supporting C just helped to spread the suspicious concepts that C was a high level language to replace Pacal, Forth and etc.. Now who's gonna clean the mess?
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-01-06 00:40 -0800 |
| Message-ID | <6da3015f-0e3a-4fea-8b10-7ac25c0e07e9@k29g2000vbl.googlegroups.com> |
| In reply to | #15483 |
On Jan 6, 7:34 am, 88888 Dihedral <dihedral88...@googlemail.com> wrote: > James Harris於 2012年1月5日星期四UTC+8上午7時57分55秒寫道： > > On Jan 3, 9:15 pm, Walter Banks <wal...@bytecraft.com> wrote: > > > Kaz Kylheku wrote: > > > > > Very few as in some C compilers actually check that everything that can be > > > > > done in asm can be done in C. > > > > > Really? An example or two would go a long way here. > > > >http://bytecraft.com/C_versus_Assembly > > > That paper calls itself "Proof that C can match or beat assembly"! > > Sadly, it is nothing of the sort. It seems to compare *bad assembly* > > with compiler output and assume that because the compiler did better > > than the specific poor assembly code that they compared it with we > > must draw the general conclusion that C can match or beat assembly. > > > Don't get me wrong. I'm a fan of C but it is to no-one's benefit to > > spread nonsense like the above. > > > The paper includes the sentence, "After all, what is a compiler but > > the distilled wisdom of years of programming experience?" LOL! Cloud > > fairy-tale land. The sentence shows the blind faith that some people > > adhere to - possibly because they don't understand the details and > > just assume the compiler is wonderful! > > We are not at the era that C was competing with Fortran and Pascal. when was that? > At that kind of battles, programers supporting C just helped to > spread the suspicious concepts that C was a high level language to > replace Pacal, Forth and etc.. well C *is* a high level langauge. I've programmed in Pascal and liked it (moving to C was quite traumatic- "what are all those strange characters?!"). But Pascal suffers from the difficulty that it needs to be heavily extended beyond its standard before its any use (proper array type, separate compilation, preset data etc.). It then becomes non-portable. Maybe modula or ada were proper grownup versions of pascal but they never really caught on. > Now who's gonna clean the mess? what mess? C ain't perfect but it's pretty good.
[toc] | [prev] | [next] | [standalone]
| From | Kleuske <kleuske@nowhere.net> |
|---|---|
| Date | 2012-01-06 10:33 +0000 |
| Message-ID | <je6il7$c4e$2@dont-email.me> |
| In reply to | #15484 |
On Fri, 06 Jan 2012 00:40:53 -0800, Nick Keighley saw fit to publish the following: <snip> >> We are not at the era that C was competing with Fortran and Pascal. > > when was that? Ages ago. Read "The Cuckoo's Egg" for a glimpse. C never competed with Pascal, though. Pascal was intended for educational purposes from the get-go and is _quite_ good at it. C is intended for post-educational purposes and is quite good in that respect. >> At that kind of battles, programers supporting C just helped to spread >> the suspicious concepts that C was a high level language to replace >> Pacal, Forth and etc.. > > well C *is* a high level langauge. I've programmed in Pascal and liked > it (moving to C was quite traumatic- "what are all those strange > characters?!"). But Pascal suffers from the difficulty that it needs to > be heavily extended beyond its standard before its any use (proper array > type, separate compilation, preset data etc.). It then becomes > non-portable. Maybe modula or ada were proper grownup versions of pascal > but they never really caught on. Oberon comes to mind, but, like you said, none of the Pascal-ish languages gained much popularity. I would not call Ada a successor to Pascal. Modula2/3 are, though. >> Now who's gonna clean the mess? > > what mess? C ain't perfect but it's pretty good. There are two types of programming languages: those everybody bitches about and those nobody uses (Stroustrup). -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2012-01-06 04:30 -0800 |
| Message-ID | <4588144.730.1325853023779.JavaMail.geo-discussion-forums@prgi2> |
| In reply to | #15484 |
Nick Keighley於 2012年1月6日星期五UTC+8下午4時40分53秒寫道： > On Jan 6, 7:34 am, 88888 Dihedral <dihedr...@googlemail.com> > wrote: > > James Harris於 2012年1月5日星期四UTC+8上午7時57分55秒寫道： > > > On Jan 3, 9:15 pm, Walter Banks <wal...@bytecraft.com> wrote: > > > > Kaz Kylheku wrote: > > > > > > > > Very few as in some C compilers actually check that everything that can be > > > > > > done in asm can be done in C. > > > > > > > Really? An example or two would go a long way here. > > > > > >http://bytecraft.com/C_versus_Assembly > > > > > That paper calls itself "Proof that C can match or beat assembly"! > > > Sadly, it is nothing of the sort. It seems to compare *bad assembly* > > > with compiler output and assume that because the compiler did better > > > than the specific poor assembly code that they compared it with we > > > must draw the general conclusion that C can match or beat assembly. > > > > > Don't get me wrong. I'm a fan of C but it is to no-one's benefit to > > > spread nonsense like the above. > > > > > The paper includes the sentence, "After all, what is a compiler but > > > the distilled wisdom of years of programming experience?" LOL! Cloud > > > fairy-tale land. The sentence shows the blind faith that some people > > > adhere to - possibly because they don't understand the details and > > > just assume the compiler is wonderful! > > > > We are not at the era that C was competing with Fortran and Pascal. > > when was that? > > > At that kind of battles, programers supporting C just helped to > > spread the suspicious concepts that C was a high level language to > > replace Pacal, Forth and etc.. > > well C *is* a high level langauge. I've programmed in Pascal and liked > it (moving to C was quite traumatic- "what are all those strange > characters?!"). But Pascal suffers from the difficulty that it needs > to be heavily extended beyond its standard before its any use (proper > array type, separate compilation, preset data etc.). It then becomes > non-portable. Maybe modula or ada were proper grownup versions of > pascal but they never really caught on. > ADA is designed for the military and the defense industry. Pascal was used in NASA before in the early 80's. There are still many object pascal programmers. I think that unix, linux and even MS windows are all written in C is the true force driving so many programmers to pick up C. > > Now who's gonna clean the mess? > > what mess? C ain't perfect but it's pretty good.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-04 15:37 +1300 |
| Message-ID | <9mhsc5FpeqU5@mid.individual.net> |
| In reply to | #15381 |
On 01/ 4/12 08:58 AM, Kaz Kylheku wrote: > On 2012-01-03, Walter Banks<walter@bytecraft.com> wrote: >> >> First there is very few things that can be done in asm that cannot be done in C. > > For instance, take garbage collection. Suppose that in some function there is > a statement "x = NULL", where x is local and there are no more uses of x in the > remaining block. An optimizing C compiler could simply not bother with this > assignment since x has no next use. But what if there is garbage collection? > The variable x could be the last reference to a large amount of memory, whose > reclamation will be prevented if the assignment is optimized away. Only for as long as x remains in scope. > The C compiler does not know that x has a kind of next use: it can be visited > "behind the scenes" by the garbage collector! C compilers are GC-unfriendly in > numerous ways, one of which is this generation of semantic garbage: keeping > values in memory or registers beyond the point at which they have become > garbage in the source semantics. In assembly we don't have this problem; > since we know what we put into every memory location and register. Again, for how long? If a value is no longer used, the optimiser will reuse the register. If a block if dynamic memory is no longer used, why keep the pointer to it in scope? It sounds like you are trying to compensate form poor design, at least in the context of gc. > We would like to be able to extend the C compiler with new rules such as > "whenever a pointer variable has no next use, generate code to overwrite it > with null", but the language doesn't give us a way to direct the translation in > such ways. I still don't see why. If the pointer is in the current scope, the work is probably unnecessary. If not, the work may be a very expensive way to fix a bad design. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-01-04 03:37 +0000 |
| Message-ID | <20120103190941.684@kylheku.com> |
| In reply to | #15392 |
On 2012-01-04, Ian Collins <ian-news@hotmail.com> wrote: > On 01/ 4/12 08:58 AM, Kaz Kylheku wrote: >> On 2012-01-03, Walter Banks<walter@bytecraft.com> wrote: >>> >>> First there is very few things that can be done in asm that cannot be done in C. >> >> For instance, take garbage collection. Suppose that in some function there is >> a statement "x = NULL", where x is local and there are no more uses of x in the >> remaining block. An optimizing C compiler could simply not bother with this >> assignment since x has no next use. But what if there is garbage collection? >> The variable x could be the last reference to a large amount of memory, whose >> reclamation will be prevented if the assignment is optimized away. > > Only for as long as x remains in scope. Yes, but that could be a long extent of computation, under which there are lots of nested computations. E.g. if x is in the scope of some upper level function, like main(), it is now prevented from gc for nearly whole lifetime of the program. >> The C compiler does not know that x has a kind of next use: it can be visited >> "behind the scenes" by the garbage collector! C compilers are GC-unfriendly in >> numerous ways, one of which is this generation of semantic garbage: keeping >> values in memory or registers beyond the point at which they have become >> garbage in the source semantics. In assembly we don't have this problem; >> since we know what we put into every memory location and register. > > Again, for how long? If a value is no longer used, the optimiser will > reuse the register. If a block if dynamic memory is no longer used, why So you would think, but it doesn't always work out that way. Sometimes the object is actually in memory. The variable is no longer live, and the C compiler does not waste any time by overwriting that variable with null just because it is no longer live, since this is of no consequence in the normal C paradigm. Your naive conservative garbage collector (the only kind you can realistically achieve under C) has to treat that memory location as a live reference, lacking the liveness info from the compiler. Sometimes a related problem can happens. A variable holds some dynamic object, and that variable is overwritten with a new value. However, the new value is held in a register, while the old value had been spilled into the underlying memory location for that variable and is persisting there. > keep the pointer to it in scope? Okay, so how do you not keep the pointer? What is the "unkeep" operation? Even clobbering the pointer with NULL doesn't do the trick, necessarily. The optimizer will see: hey, this variable is no longer live at this assignment, so just throw the assignment away. This is okay in normal C, because if you didn't need the dynamic object, you would have called free on it, right? A pointer to some dynamic object which has no next use, and which is the last reference to that object is a leak under the explicit memory management paradigm. > It sounds like you are trying to > compensate form poor design, at least in the context of gc. One "solution" is to call a dummy external function, which receives the address of the variable. This will force most compilers to spill the up-to-date register-cached value into the underlying storage, clobbering any stale value. This is not a nice thing to have to do everywhere. (I've done this as a reactive approach in response to confirmed cases of the problem.) >> We would like to be able to extend the C compiler with new rules such as >> "whenever a pointer variable has no next use, generate code to overwrite it >> with null", but the language doesn't give us a way to direct the translation in >> such ways. > > I still don't see why. If the pointer is in the current scope, the work > is probably unnecessary. Yes, it probably is unnecessary. Except for the rare situation when this crops up and bites you. > If not, the work may be a very expensive way > to fix a bad design. What is the inexpensive way to fix the design?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-04 20:23 +1300 |
| Message-ID | <9mid3eFpeqU8@mid.individual.net> |
| In reply to | #15395 |
On 01/ 4/12 04:37 PM, Kaz Kylheku wrote: > On 2012-01-04, Ian Collins<ian-news@hotmail.com> wrote: >> On 01/ 4/12 08:58 AM, Kaz Kylheku wrote: >>> On 2012-01-03, Walter Banks<walter@bytecraft.com> wrote: >>>> >>>> First there is very few things that can be done in asm that cannot be done in C. >>> >>> For instance, take garbage collection. Suppose that in some function there is >>> a statement "x = NULL", where x is local and there are no more uses of x in the >>> remaining block. An optimizing C compiler could simply not bother with this >>> assignment since x has no next use. But what if there is garbage collection? >>> The variable x could be the last reference to a large amount of memory, whose >>> reclamation will be prevented if the assignment is optimized away. >> >> Only for as long as x remains in scope. > > Yes, but that could be a long extent of computation, under which there > are lots of nested computations. E.g. if x is in the scope of some > upper level function, like main(), it is now prevented from gc for nearly whole > lifetime of the program. True, but considering gc isn't a silver bullet, you have to code with it in mind. >>> The C compiler does not know that x has a kind of next use: it can be visited >>> "behind the scenes" by the garbage collector! C compilers are GC-unfriendly in >>> numerous ways, one of which is this generation of semantic garbage: keeping >>> values in memory or registers beyond the point at which they have become >>> garbage in the source semantics. In assembly we don't have this problem; >>> since we know what we put into every memory location and register. >> >> Again, for how long? If a value is no longer used, the optimiser will >> reuse the register. If a block if dynamic memory is no longer used, why > > So you would think, but it doesn't always work out that way. Sometimes > the object is actually in memory. The variable is no longer live, and the C > compiler does not waste any time by overwriting that variable with null just > because it is no longer live, since this is of no consequence in the normal > C paradigm. > > Your naive conservative garbage collector (the only kind you can realistically > achieve under C) has to treat that memory location as a live reference, > lacking the liveness info from the compiler. > > Sometimes a related problem can happens. A variable holds some dynamic object, > and that variable is overwritten with a new value. However, the new value is > held in a register, while the old value had been spilled into the underlying > memory location for that variable and is persisting there. > >> keep the pointer to it in scope? > > Okay, so how do you not keep the pointer? What is the "unkeep" operation? Limiting the pointer's scope, typically be declaring and initialising it where it is needed and not before. >> It sounds like you are trying to >> compensate form poor design, at least in the context of gc. > > One "solution" is to call a dummy external function, which receives the address > of the variable. This will force most compilers to spill the up-to-date > register-cached value into the underlying storage, clobbering any stale > value. > > This is not a nice thing to have to do everywhere. (I've done this as a > reactive approach in response to confirmed cases of the problem.) If you had to resort to such shenanigans, was the problem one where gc was an appropriate solution? >>> We would like to be able to extend the C compiler with new rules such as >>> "whenever a pointer variable has no next use, generate code to overwrite it >>> with null", but the language doesn't give us a way to direct the translation in >>> such ways. >> >> I still don't see why. If the pointer is in the current scope, the work >> is probably unnecessary. > > Yes, it probably is unnecessary. Except for the rare situation when this > crops up and bites you. > >> If not, the work may be a very expensive way >> to fix a bad design. > > What is the inexpensive way to fix the design? Fix it before writing the code! Like any tool, you can't just throw a garbage collector at any bit of code and expect optimal performance. To get the best results, you have to write your code with garbage collection in mind. The same applies with smart pointers in C++, you can't just change any random pointer based to code to use them and expect the best results. Garbage collectors aren't part of standard C and garbage collected code isn't standard C. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-12-22 18:26 +0100 |
| Message-ID | <jcvp7r$2id$1@speranza.aioe.org> |
| In reply to | #14864 |
Le 22/12/11 16:11, 88888 Dihedral a écrit : >> The loop invariant is that the key's index (if it exists) is in [low, >> high) i.e. low<= index< high. These asymmetric bounds avoid any >> problems with unsigned indexes when length == 0. They also explain the >> different settings for low and high. >> >> -- >> Ben. > > Do you consider to convert 5 to 10 lines of C to assembly? Each time you see that you have done a mistake you go to assembly man, that's just to impress people here. Well, you are not going to do that here in general, nor with me in particular. I know enough assembly to know when to use it. That routine doesn't do anything where an assembly language program would be much better. Places where assembly shines are computations and operations that have NO equivalent in higher level languages. That is surely not the case with the small routine above
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-12-22 19:34 +0000 |
| Message-ID | <0.ceef25457ffad09d0acb.20111222193427GMT.87zkekl7ss.fsf@bsb.me.uk> |
| In reply to | #14864 |
88888 Dihedral <dihedral88888@googlemail.com> writes: <snip> > Do you consider to convert 5 to 10 lines of C to assembly? No, why do you ask? Would you? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 11:57 -0800 |
| Message-ID | <2372733.489.1324583849963.JavaMail.geo-discussion-forums@prix23> |
| In reply to | #14878 |
On Friday, December 23, 2011 3:34:27 AM UTC+8, Ben Bacarisse wrote: > 88888 Dihedral <dihedr...@googlemail.com> writes: > <snip> > > Do you consider to convert 5 to 10 lines of C to assembly? > > No, why do you ask? Would you? > > -- > Ben. I did that 20 years ago on X86 cpu. It was a piece of cake to gain the 20-40% speed required if paid well.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 20:18 +0000 |
| Message-ID | <slrnjf744e.223p.usenet-nospam@guild.seebs.net> |
| In reply to | #14881 |
On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: > I did that 20 years ago on X86 cpu. > It was a piece of cake to gain the 20-40% speed required if paid well. Yeah, uhm. Since then, CPUs have gotten a lot more complicated and compilers a lot smarter. Simple question for you: On a modern x86 (say, a Core i5), do you believe the actual computations are executing the instructions generated from assembly? Hint: The answer is "no", and has been for a long time. Nowadays, an x86 CPU consists of a nice modern core with lots of registers which is running a runtime translator from x86 machine code. It used to be instruction scheduling was something humans could do pretty well, and compilers mostly didn't try to do because it wasn't possible to do it with the resources available. Now it's something humans suck at and compilers mostly do. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 12:52 -0800 |
| Message-ID | <8093011.520.1324587134285.JavaMail.geo-discussion-forums@prlk31> |
| In reply to | #14882 |
On Friday, December 23, 2011 4:18:41 AM UTC+8, Seebs wrote: > On 2011-12-22, 88888 Dihedral <dihedr...@googlemail.com> wrote: > > I did that 20 years ago on X86 cpu. > > > It was a piece of cake to gain the 20-40% speed required if paid well. > > Yeah, uhm. Since then, CPUs have gotten a lot more complicated and > compilers a lot smarter. > > Simple question for you: On a modern x86 (say, a Core i5), do you believe > the actual computations are executing the instructions generated from > assembly? > > Hint: The answer is "no", and has been for a long time. Nowadays, an x86 > CPU consists of a nice modern core with lots of registers which is running > a runtime translator from x86 machine code. > > It used to be instruction scheduling was something humans could do pretty > well, and compilers mostly didn't try to do because it wasn't possible to > do it with the resources available. Now it's something humans suck at > and compilers mostly do. > > -s > -- I use about 20 to 26 instructions only in those various kinds of cpus I played with. Of course I check those instructions that preserve the flags also those control flow instructions with the most likely first in my assembly. If the compiler is smarter than a professional programmer, then a lot novice programmers should be fired for not producing smart and fast programs. > Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net > http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures > http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! > I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 20:37 +0000 |
| Message-ID | <slrnjf7738.23eo.usenet-nospam@guild.seebs.net> |
| In reply to | #14883 |
On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: > I use about 20 to 26 instructions only in those various kinds of > cpus I played with. That gives you another significant disadvantage compared to the compiler. > If the compiler is smarter than a professional programmer, > then a lot novice programmers should be fired for not producing > smart and fast programs. "Smarter" is a pretty broad term. >Of course I check those instructions that preserve the flags also >those control flow instructions with the most likely first in my assembly. The compiler can consider more possible sequences of instructions per second than you can per month. The compiler also has the option of using instructions that don't preserve flags, and thus gaining advantages from using the flags as intended, and can avoid flow control when it's the wrong choice. Dunno if you saw this, but a while back, someone had some PRNG code here, which included a snippet roughly to the effect of: if (z) x += y; Replacing this with: x += (y * z); dramatically improved the efficiency of the entire PRNG, because that branch had been slowing it down more than any five or ten other instructions. You are doubtless better at some *kinds* of thinking than a compiler, but you generally won't beat a modern compiler by enough to notice, and indeed, my experience has been that people who think they can beat compilers normally lose to compilers. The only people I've seen beat modern compilers are people who understand why they normally can't. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 13:27 -0800 |
| Message-ID | <9374707.578.1324589230175.JavaMail.geo-discussion-forums@prol32> |
| In reply to | #14884 |
On Friday, December 23, 2011 4:37:03 AM UTC+8, Seebs wrote: > On 2011-12-22, 88888 Dihedral <dihedr...@googlemail.com> wrote: > > I use about 20 to 26 instructions only in those various kinds of > > cpus I played with. > > That gives you another significant disadvantage compared to the compiler. > > > If the compiler is smarter than a professional programmer, > > then a lot novice programmers should be fired for not producing > > smart and fast programs. > > "Smarter" is a pretty broad term. > > >Of course I check those instructions that preserve the flags also > >those control flow instructions with the most likely first in my assembly. > > The compiler can consider more possible sequences of instructions per second > than you can per month. The compiler also has the option of using > instructions that don't preserve flags, and thus gaining advantages from > using the flags as intended, and can avoid flow control when it's the > wrong choice. > > Dunno if you saw this, but a while back, someone had some PRNG code here, > which included a snippet roughly to the effect of: > > if (z) > x += y; > > Replacing this with: > x += (y * z); > > dramatically improved the efficiency of the entire PRNG, because that branch > had been slowing it down more than any five or ten other instructions. > > You are doubtless better at some *kinds* of thinking than a compiler, but you > generally won't beat a modern compiler by enough to notice, and indeed, my > experience has been that people who think they can beat compilers normally > lose to compilers. The only people I've seen beat modern compilers are people > who understand why they normally can't. :) > > -s > -- > Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net > http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures > http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! > I am not speaking for my employer, although they do rent some of my opinions. OK, you are selling compilers. I am working on compilers in GCC and MINI C PORTABLE C and device C! If you are selling arm compilers, then I agree with you.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 21:57 +0000 |
| Message-ID | <slrnjf79nd.24nn.usenet-nospam@guild.seebs.net> |
| In reply to | #14885 |
On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: > OK, you are selling compilers. No, I'm not. > I am working on compilers in GCC and MINI C > PORTABLE C and device C! That's terrifying. > If you are selling arm compilers, then I agree with you. I'm not selling compilers at all. I'm merely aware that people who think they are smarter than the compiler are nearly always wrong. Especially given your track record of suggestions for things that you think would produce performance improvements. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-22 14:09 -0800 |
| Message-ID | <27252424.540.1324591749587.JavaMail.geo-discussion-forums@prdv33> |
| In reply to | #14887 |
On Friday, December 23, 2011 5:57:11 AM UTC+8, Seebs wrote: > On 2011-12-22, 88888 Dihedral <dihedr...@googlemail.com> wrote: > > OK, you are selling compilers. > > No, I'm not. > > > I am working on compilers in GCC and MINI C > > PORTABLE C and device C! > > That's terrifying. > > > If you are selling arm compilers, then I agree with you. > > I'm not selling compilers at all. I'm merely aware that people who think > they are smarter than the compiler are nearly always wrong. Especially given > your track record of suggestions for things that you think would produce > performance improvements. > Thanks for you appreciations. I am really bad of lousy programmers.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-12-22 21:57 +0000 |
| Message-ID | <slrnjf7bmv.25vc.usenet-nospam@guild.seebs.net> |
| In reply to | #14890 |
On 2011-12-22, 88888 Dihedral <dihedral88888@googlemail.com> wrote: > Thanks for you appreciations. I am really bad of lousy programmers. Oh, don't be so hard on yourself. I think you're about average for a lousy programmer. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web