Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100060 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2016-12-22 22:47 -0500 |
| Last post | 2017-01-07 18:51 -0500 |
| Articles | 20 on this page of 161 — 27 participants |
Back to article view | Back to comp.lang.c
How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2016-12-22 22:47 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ike Naar <ike@iceland.freeshell.org> - 2016-12-23 06:56 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 11:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 11:26 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 12:09 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 12:34 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 12:56 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 20:58 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 21:09 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-23 13:36 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-23 12:39 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-24 16:46 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 13:04 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-25 09:43 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 22:01 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-24 15:21 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? luser droog <luser.droog@gmail.com> - 2016-12-24 15:29 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-25 16:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-25 13:13 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-27 09:42 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Manfred <noname@invalid.add> - 2017-02-03 20:40 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:47 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-29 14:33 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:04 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2017-01-01 11:38 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 13:49 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:17 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-03 13:26 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2016-12-26 17:29 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-27 10:10 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 08:33 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2016-12-27 20:22 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 10:18 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-27 13:28 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 15:55 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:01 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 16:40 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:34 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-29 06:27 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:47 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:45 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 15:26 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? asetofsymbols@gmail.com - 2017-01-01 13:03 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 03:04 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-03 08:27 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-02 12:37 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-03 10:42 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 21:24 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-14 11:15 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-16 00:31 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-18 21:45 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 18:24 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:49 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-10 01:57 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-10 10:32 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-13 08:44 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-02 10:42 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-02 13:06 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-03 10:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 07:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-03 09:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 12:36 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 09:51 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-03 13:08 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 14:07 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 11:28 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-03 22:49 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 11:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-03 18:39 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-04 00:47 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-04 09:49 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:45 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? David Brown <david.brown@hesbynett.no> - 2017-01-04 20:05 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 15:55 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 13:09 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-04 00:12 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-04 09:50 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-04 07:25 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-04 15:29 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-04 10:29 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 16:34 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? antispam@math.uni.wroc.pl - 2017-01-07 18:59 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-07 15:59 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? antispam@math.uni.wroc.pl - 2017-01-08 03:27 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-07 21:56 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-03 16:22 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 07:05 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:09 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-13 15:40 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-13 15:56 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 15:58 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-14 09:29 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:14 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-31 10:57 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 08:07 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-02-03 08:43 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 08:43 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-18 21:46 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-18 09:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-27 14:37 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-23 12:33 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 17:21 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 13:08 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 22:33 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-23 14:55 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 15:12 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 01:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-24 04:12 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 15:12 +0000
Re: Inadvertent trolls Noob <root@127.0.0.1> - 2016-12-24 11:34 +0100
Re: Inadvertent trolls BartC <bc@freeuk.com> - 2016-12-24 12:47 +0000
Typo or freudian slip? (Was: Inadvertent trolls) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-24 13:13 +0000
Re: Typo or freudian slip? (Was: Inadvertent trolls) BartC <bc@freeuk.com> - 2016-12-24 14:02 +0000
Re: Inadvertent trolls Keith Thompson <kst-u@mib.org> - 2016-12-24 12:36 -0800
Re: Inadvertent trolls Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-24 13:59 -0800
Re: Inadvertent trolls Gareth Owen <gwowen@gmail.com> - 2016-12-26 18:38 +0000
Re: C interpreter Noob <root@127.0.0.1> - 2016-12-24 23:39 +0100
Re: C interpreter BartC <bc@freeuk.com> - 2016-12-25 00:32 +0000
Re: Inadvertent trolls jacobnavia <jacob@jacob.remcomp.fr> - 2017-01-01 11:10 +0100
Re: Inadvertent trolls BartC <bc@freeuk.com> - 2017-01-01 11:54 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 09:52 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-04 23:38 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-05 17:49 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? David Brown <david.brown@hesbynett.no> - 2017-01-05 09:57 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Noob <root@127.0.0.1> - 2017-01-05 09:50 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 11:16 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-23 04:36 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 13:24 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 01:35 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:06 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-28 18:33 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:13 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-02 02:53 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:09 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-13 08:51 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:28 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-13 10:00 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-13 10:34 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:00 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:17 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-14 13:52 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-16 00:18 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-28 18:40 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:48 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 17:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-29 01:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 01:27 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 01:59 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-23 13:01 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 14:08 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-05 00:05 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2017-01-05 12:08 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-05 10:41 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2017-01-05 18:08 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2017-01-05 17:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2017-01-05 12:02 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? James Kuyper <jameskuyper@verizon.net> - 2017-01-05 14:36 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? antispam@math.uni.wroc.pl - 2017-01-07 20:20 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-07 12:55 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-07 18:51 -0500
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-04 10:29 -0800 |
| Message-ID | <2a99e34f-ca08-40d5-ae0f-39ea79b005b0@googlegroups.com> |
| In reply to | #101098 |
On Wednesday, January 4, 2017 at 9:29:59 AM UTC-6, Melzzzzz wrote: > I said wrongly, GC tend to preallocate, that is they reserve space for > future use. eg java -version does reserve gigabytes of RAM. I seen > Haskell map_noreserve terabyte of RAM, and D around 500MB There's nothing wrong with pre-allocating space, nor with having systems postpone physical mapping of space which has been allocated but not yet used, provided that the system keeps track of how much space has been reserved but not mapped, and ensures that storage will always be available when needed. Such a scheme may be quite useful in systems which have a means of marking memory as purgeable (even if such marking is done on a per-process basis, so the system responds to low-memory conditions by killing off some background processes). If the amount of memory that programs need to have available significantly exceeds the amount that they are likely to use, such an approach would allow background processes to benefit from the otherwise-unused memory unless or until it was needed for more important purposes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-03 16:34 -0800 |
| Message-ID | <cc38cf3d-e662-45f1-8312-b54896a082e8@googlegroups.com> |
| In reply to | #101060 |
On Tuesday, January 3, 2017 at 6:10:01 PM UTC-6, Ian Collins wrote:
> Over commit is an abomination which is only of use to poorly written
> programs. So this is an example where standard compliance is good!
If one is stuck using a platform which for whatever reason cannot provide
assurance that allocation requests will either succeed or fail cleanly,
but which is expected to have far more memory than a program will need,
an implementation which violates the Standard may be more useful than one
which is compliant but requires that all memory be pre-allocated.
Similarly, if one is stuck using a platform which behaves very badly if an
attempt is made to open a file for writing when a write-protected disk is
inserted, and which provides no clean way for testing whether a disk is
write-protected without trying to write it, an implementation where
fopen("somefile", "wb"); will attempt to open a file for writing, with
whatever consequences befall, may be more useful than one where that call
would unconditionally return NULL regardless of whether a writable disk
was inserted. Whether or not a platform should have such limitations, some
historical platforms (e.g. MS-DOS 1.1) did, and the question of whether an implementation on such a platform should be willing to attempt operations
which could fail in ways beyond those described by the Standard should be
left to the implementer's judgment.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-01-07 18:59 +0000 |
| Message-ID | <o4rdqm$na3$1@z-news.wcss.wroc.pl> |
| In reply to | #101060 |
Ian Collins <ian-news@hotmail.com> wrote:
> On 01/ 4/17 12:55 PM, supercat@casperkitty.com wrote:
>
> Over commit is an abomination which is only of use to poorly written
> programs. So this is an example where standard compliance is good!
Actually there are two issues:
- One is programs which have large potentially writable areas.
That inculdes all programs which dynamically load code,
debugging and to some degree normal dynamic linking.
Big example is programs using fork to create several
almost identical copies. Either one allocates all potentially
writable memory at the start, effectively wasting it because
it is normally not written and shared copy will do,
or one faces possibility of crash when there is unexpected
write activity.
- Second are programs which want to do their own advanced
memory management. Such programs really need a way to
allocate address space, but AFAICS all that Linux offers
is memory allocation with overcommit. Docs on the net
indicate that Windows has special function for allocating
address space but I am not aware of equivalent functionality
on Linux.
So really there are deeper issues here. In particular, if
guaranted worst case behaviour is better than systems that
frequently work well but sometimes fail. For critical
systems guaranted worst case is better, but it is hard
to argue that it is always better.
Concerning standards compliance: failure due to memory
overcommit is in the same category as hardware failure
or user switching the system off during computation.
While never failing hardware would be good standard
has can not mandate this. And trying to remove power
switch is silly.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-07 15:59 -0800 |
| Message-ID | <a0b653b8-ec74-400e-adf1-f51c8af09fd9@googlegroups.com> |
| In reply to | #101236 |
On Saturday, January 7, 2017 at 12:59:41 PM UTC-6, anti...@math.uni.wroc.pl wrote: > Concerning standards compliance: failure due to memory > overcommit is in the same category as hardware failure > or user switching the system off during computation. > While never failing hardware would be good standard > has can not mandate this. And trying to remove power > switch is silly. I disagree with that analogy, in that even on most systems that overcommit memory it would be possible for a C implementation to guard against the associated hazards by allocating a pool of memory and touching every location therein before running any user code, and then using that pool to satisfy all malloc() requests. If an implementation opts to have malloc() return pointers to storage whose availability was not confirmed before starting user code, that should be viewed as a deliberate decision to put practical considerations ahead of standards compliance (which should not necessarily be viewed as a bad thing, depending upon the considerations involved). If the Standard recognized the existence of an execution platform as a component which may be separate from the implementation, it could have described a number of actions as requests to the underlying platform and recognized the possibility that a platform may introduce side-effects beyond an implementation's control. As it is, however, the Standard would make no distinction between an implementation where an attempt to use a malloc'ed pointer could fail because of an overcommit, and one where it could fail because malloc simply returned a random address.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-01-08 03:27 +0000 |
| Message-ID | <o4sbiv$a4f$1@z-news.wcss.wroc.pl> |
| In reply to | #101269 |
supercat@casperkitty.com wrote:
> On Saturday, January 7, 2017 at 12:59:41 PM UTC-6, anti...@math.uni.wroc.pl wrote:
> > Concerning standards compliance: failure due to memory
> > overcommit is in the same category as hardware failure
> > or user switching the system off during computation.
> > While never failing hardware would be good standard
> > has can not mandate this. And trying to remove power
> > switch is silly.
>
> I disagree with that analogy, in that even on most systems that overcommit
> memory it would be possible for a C implementation to guard against the
> associated hazards by allocating a pool of memory and touching every location
> therein before running any user code, and then using that pool to satisfy
> all malloc() requests. If an implementation opts to have malloc() return
> pointers to storage whose availability was not confirmed before starting
> user code, that should be viewed as a deliberate decision to put practical
> considerations ahead of standards compliance (which should not necessarily
> be viewed as a bad thing, depending upon the considerations involved).
I am not sure about current situation, but in the past your
tactic would not work: when running out of memory kernel
heuristically looked for victim. So it could kill not the
process doing allocation but an unrelated process. Having
large area of excusive use memory increased chance of
beeing a victim. Also, once kernel decided to kill your
process malloc had no way to return null. So you (maybe)
decrease chance of getting pointer that will fail, but
instead malloc fails (while it should return something).
Also, Linux on clusters have active memory deduplication:
if you fill memory with say "0xdeadbeef" kernel will
use notice that data is duplicated and allocate only
single page.
Finally, memory overcommit is settable by system owner.
Should malloc fight with with owners decision to
have noncompliant behaviour?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-07 21:56 -0800 |
| Message-ID | <3b965a78-9916-413b-96c7-219d9064813b@googlegroups.com> |
| In reply to | #101275 |
On Saturday, January 7, 2017 at 9:27:36 PM UTC-6, anti...@math.uni.wroc.pl wrote: > supercat wrote: > > I disagree with that analogy, in that even on most systems that overcommit > > memory it would be possible for a C implementation to guard against the > > associated hazards by allocating a pool of memory and touching every location > > therein before running any user code, and then using that pool to satisfy > > all malloc() requests. If an implementation opts to have malloc() return > > pointers to storage whose availability was not confirmed before starting > > user code, that should be viewed as a deliberate decision to put practical > > considerations ahead of standards compliance (which should not necessarily > > be viewed as a bad thing, depending upon the considerations involved). > > I am not sure about current situation, but in the past your > tactic would not work: when running out of memory kernel > heuristically looked for victim. So it could kill not the > process doing allocation but an unrelated process. Having > large area of excusive use memory increased chance of > beeing a victim. Also, once kernel decided to kill your > process malloc had no way to return null. So you (maybe) > decrease chance of getting pointer that will fail, but > instead malloc fails (while it should return something). If all of the memory gets touched before user code starts executing, then it's possible that a program might fail to start, but once the program starts it should be able to run. > Also, Linux on clusters have active memory deduplication: > if you fill memory with say "0xdeadbeef" kernel will > use notice that data is duplicated and allocate only > single page. That could be a problem, but nobody promised that a conforming implemntation would be possible on every platform in the universe. > Finally, memory overcommit is settable by system owner. > Should malloc fight with with owners decision to > have noncompliant behaviour? The Standard merely classifies implementations as conforming or non- conforming. If someone would benefit from having a behavior which is contrary to the Standard, they should use a non-conforming implementation. While it would be helpful to have a Standard that recognized that quality implementations for different platforms and purposes should offer different guarantees, the present one doesn't, meaning that practicality may compel the use of non-conforming implementations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-03 16:22 -0800 |
| Message-ID | <lnbmvnu11q.fsf@kst-u.example.com> |
| In reply to | #101057 |
supercat@casperkitty.com writes:
> On Tuesday, January 3, 2017 at 4:28:44 PM UTC-6, Ian Collins wrote:
>> On 01/ 4/17 11:07 AM, supercat wrote:
>> > What in the Standard would exempt any implementation, even one for which
>> > the underlying platform is annoying, from a guarantee that malloc() will
>> > never do anything other than yield null or yield a usable pointer, with
>> > no other side-effects?
>>
>> Nothing. Linux with over commit enabled isn't POSIX compliant.
>
> Fair point, though it would remain an example of a platform where compliance
> would require forgoing some platform features that would in some cases be
> more useful than Standard compliance.
>
> Returning to my earlier point, earlier point that many implementations are
> designed to either be invoked with a command-line option which predefines
> a macro which makes them non-compliant with the C Standard, or without that
> option which would prevent them from running some POSIX code without
> modification (it would be pointless to have C files use #define to enable
> POSIX features rather than #include <posix.h>, but for whatever reason C
> compilers almost always include command-line options to predefine macros but
> seldom include command-line options to include the contents of a given file
> before each C file, so pre-defining the macro that enables POSIX features
> before including standard headers is equivalent to including a <posix.h>
> file.)
Dude, sentences!
There is no <posix.h> header. POSIX-specific functions are declared in
several different headers, some of them ISO C headers (like <stdio.h>),
some of them POSIX-specific (like <unistd.h>).
Because POSIX declares some non-ISO-C functions in ISO C standard
headers, it's necessary to define a macro such as _POSIX_C_SOURCE (which
supersedes the older _POSIX_SOURCE) or _XOPEN_SOURCE before including
the relevant headers. (The details are a bit complicated.)
It's perfectly reasonable to write something like:
#define _POSIX_C_SOURCE some_value
#include <stdio.h>
if you want to use the POSIX functions that are declared in
<stdio.h>. If you want to define the macro in some other way,
that's fine too -- but other approaches have the drawback that
some of the information required to compile the source file is not
contained in the source file itself.
--
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 | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-01-04 07:05 +0000 |
| Message-ID | <slrno6p7m8.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #101062 |
On Wed, 2017-01-04, Keith Thompson wrote:
...
> It's perfectly reasonable to write something like:
>
> #define _POSIX_C_SOURCE some_value
> #include <stdio.h>
>
> if you want to use the POSIX functions that are declared in
> <stdio.h>. If you want to define the macro in some other way,
> that's fine too -- but other approaches have the drawback that
> some of the information required to compile the source file is not
> contained in the source file itself.
A long time ago I decided that this drawback is a fact of life, and
that the Makefile (in my case) is as much a part of the source code as
my C sources.
For this case, I tend to have lines similar to:
foo.o: CPPFLAGS+=-D_POSIX_SOURCE
so that I only enable it for the parts of the program which cannot be
standard C.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 15:09 -0800 |
| Message-ID | <kfntw92pnfz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100989 |
supercat@casperkitty.com writes: > [...] My point is that the C Standard is not, *in and of itself*, > sufficient to write useful programs; [...] Hogwash. The set of such programs may not be as large as some people would like, but it certainly is larger than the empty set.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-13 15:40 -0800 |
| Message-ID | <5d426729-992a-4edc-ae91-725fa2420ea5@googlegroups.com> |
| In reply to | #101678 |
On Friday, January 13, 2017 at 5:09:10 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > > [...] My point is that the C Standard is not, *in and of itself*, > > sufficient to write useful programs; [...] > > Hogwash. The set of such programs may not be as large as > some people would like, but it certainly is larger than > the empty set. True or false: The Standard allows conforming implementations to behave in arbitrary fashion if certain implementation limits--most notably runtime stack depth--are exceeded. True or false: The Standard requires that each implementation be capable of processing at least one program which nominally exercises certain implementation limits, but would not forbid an implementation from meeting that requirement through the use of special optimizations which are applied only to that one exact program. Can you offer up any source text which would be guaranteed not to exceed any implementation limits, in such fashion as to invoke Undefined Behavior, on any conforming implementation?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 15:56 -0800 |
| Message-ID | <ln60lildjz.fsf@kst-u.example.com> |
| In reply to | #101687 |
supercat@casperkitty.com writes:
> On Friday, January 13, 2017 at 5:09:10 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>> > [...] My point is that the C Standard is not, *in and of itself*,
>> > sufficient to write useful programs; [...]
>>
>> Hogwash. The set of such programs may not be as large as
>> some people would like, but it certainly is larger than
>> the empty set.
>
> True or false: The Standard allows conforming implementations to
> behave in arbitrary fashion if certain implementation limits--most
> notably runtime stack depth--are exceeded.
>
> True or false: The Standard requires that each implementation be
> capable of processing at least one program which nominally exercises
> certain implementation limits, but would not forbid an implementation
> from meeting that requirement through the use of special optimizations
> which are applied only to that one exact program.
>
> Can you offer up any source text which would be guaranteed not to exceed
> any implementation limits, in such fashion as to invoke Undefined Behavior,
> on any conforming implementation?
True, true, and no, respectively, but hardly relevant.
Nevertheless, one can write useful C programs using only information
provided by the C standard. There needn't be a 100% binding guarantee
that a program works as expected on all possible conforming
implementations for that program to be useful.
Just as an optimization, perhaps consider leaving the goal posts
where they are.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-13 15:58 -0800 |
| Message-ID | <8d849f2f-1e06-4139-84f3-4e10e9806e12@googlegroups.com> |
| In reply to | #101687 |
On Friday, January 13, 2017 at 11:40:17 PM UTC, supe...@casperkitty.com wrote: > > True or false: The Standard requires that each implementation be > capable of processing at least one program which nominally exercises > certain implementation limits, but would not forbid an implementation > from meeting that requirement through the use of special optimizations > which are applied only to that one exact program. > The standard isn't written for language lawyers. If you want to create a perverse implementation you can do so. The "at least one program" qualification gives the C programmer some idea about the block depth and so on he can rely on, without imposing the impossible requirement that every program with depth of less than 127 blocks functions be accepted unless it breaks some other limit somewhere. Our compiler can have a stack for the active block, and it can have 128 entries, and everything will be fine.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-14 09:29 -0800 |
| Message-ID | <24e63198-e5f5-47fb-a110-373a52e412d1@googlegroups.com> |
| In reply to | #101692 |
On Friday, January 13, 2017 at 5:58:09 PM UTC-6, Malcolm McLean wrote:
> On Friday, January 13, 2017 at 11:40:17 PM UTC, supercat wrote:
> > True or false: The Standard requires that each implementation be
> > capable of processing at least one program which nominally exercises
> > certain implementation limits, but would not forbid an implementation
> > from meeting that requirement through the use of special optimizations
> > which are applied only to that one exact program.
> >
> The standard isn't written for language lawyers. If you want to create
> a perverse implementation you can do so.
My point is precisely that the Standard wasn't written for language
lawyers, and the authors of the Standard saw no need to try to make
it "lawyer-proof". They saw no need to describe every useful feature
or guarantee that quality implementations should provide, especially
those which an implementation would have to go out if its way not to
provide, since they expected compiler writers to share the prevailing
views of common sense.
That having been said, I do think the Standard writers could have made
the Standard failed to define any useful category of C programs. Some
slight changes to the Standard would allow it to define a new category of
programs about which the Standard would offer strong guarantees. I
would call the new category "Selectively Conforming" programs, subject
to the following definition:
- A program is Selectively Conforming if any conforming implementation
would be required to either process it without Undefined Behavior or
else indicate via Implementation-Defined means that it is unable to
do so.
Adding such a definition would clear the way for the Standard to add
features which could be supported by some, but not all, implementations
and allow programs that need such features to have their behavior covered
by the Standard.
All that would be necessary to make such a definition workable would be
for the Standard to add two provisos:
1. In the absence of a directive waiving the guarantee (which would
make a program not Selectively Conforming), an implementation
must guarantee that in any circumstance where it cannot continue
processing the program in defined fashion, it will trap in an
Implementation-Defined manner whose default behavior will
terminate execution.
2. In the absence of directives to the contrary, an implementation
may trap in aforementioned fashion at any time when it would
otherwise be unable to guarantee defined execution; it may also
refuse compilation of any program which might cause such a trap
at runtime. The ability to run useful programs is a Quality of
Implementation issue, and not required for conformance, provided
behavior remains defined in all cases that are under the
implementation's control.
Adding those provisions to the Standard would greatly increase the set
of programs about which the Standard can say something meaningful, and
also make it practical to expand the set of behaviors and guarantees
programmers could safely exploit on platforms that can cheaply support
them without imposing any burden on platforms that can't.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-31 08:14 -0800 |
| Message-ID | <kfny3xrdx6d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101687 |
supercat@casperkitty.com writes: > On Friday, January 13, 2017 at 5:09:10 PM UTC-6, Tim Rentsch wrote: >> supercat writes: >> >>> [...] My point is that the C Standard is not, *in and of itself*, >>> sufficient to write useful programs; [...] >> >> Hogwash. The set of such programs may not be as large as >> some people would like, but it certainly is larger than >> the empty set. > > True or false: The Standard allows conforming implementations to > behave in arbitrary fashion if certain implementation limits--most > notably runtime stack depth--are exceeded. Stack depth is not an implementation limit, as the Standard uses the term. > True or false: The Standard requires that each implementation be > capable of processing at least one program which nominally exercises > certain implementation limits, but would not forbid an implementation > from meeting that requirement through the use of special optimizations > which are applied only to that one exact program. If there is a point to this statement I don't know what it is. The Standard explicitly avoids considering any question regarding optimization (excluding volatile), as I am sure you must know. > Can you offer up any source text which would be guaranteed not to exceed > any implementation limits, in such fashion as to invoke Undefined Behavior, > on any conforming implementation? I think you're asking a deliberately fuzzy question. In any case though the question is irrelevant - lots of people find programs useful if in practice they work, regardless of whether there are any absolute guarantees about their behavior. Maybe you should use the term "supercat-useful" to indicate the distinction. It may very well be that the Standard does not suffice to write supercat-useful programs. I can't speak to that issue since I don't know what "supercat-useful" means.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-31 10:57 -0800 |
| Message-ID | <881ea0a9-55a6-46e8-842b-bdd22d54b3fb@googlegroups.com> |
| In reply to | #102842 |
On Tuesday, January 31, 2017 at 10:14:10 AM UTC-6, Tim Rentsch wrote: > supercat writes: > > True or false: The Standard allows conforming implementations to > > behave in arbitrary fashion if certain implementation limits--most > > notably runtime stack depth--are exceeded. > > Stack depth is not an implementation limit, as the Standard > uses the term. What behavioral requirements, if any, would the standard apply to a program that nests recursive calls a billion levels deep? Is there any N, such that it applies any more requirements to a program which never nests function calls more than N deep? While the authors of the Standard don't explicitly list function nesting depth as an Implementation Limit, that's probably because it would be impractical for many implementations to document how deeply function calls can be nested. I can think of no other means of justifying the behavior of implementations which jump the rails when processing billion-deep recursive calls. > > True or false: The Standard requires that each implementation be > > capable of processing at least one program which nominally exercises > > certain implementation limits, but would not forbid an implementation > > from meeting that requirement through the use of special optimizations > > which are applied only to that one exact program. > > If there is a point to this statement I don't know what it is. > The Standard explicitly avoids considering any question regarding > optimization (excluding volatile), as I am sure you must know. Would the Standard allow a conforming compiler's code generator to say "If given a certain precise source file, output a hard-coded executable which runs it properly, and when given any other source file generate an executable that unconditionally bombs the stack?" If such behavior would not make a compiler non-conforming, would that not imply that there are no programs whose behavior is defined on all conforming implementations? > > Can you offer up any source text which would be guaranteed not to exceed > > any implementation limits, in such fashion as to invoke Undefined Behavior, > > on any conforming implementation? > > I think you're asking a deliberately fuzzy question. In any case > though the question is irrelevant - lots of people find programs > useful if in practice they work, regardless of whether there are > any absolute guarantees about their behavior. I believe you were objecting to my claim that it is impossible to write any program whose behavior is defined on all implementations. If stack overflow is not UB, what is it? If there are times when stack overflow would be guaranteed not to occur, other than when running an implementation's One Program, what are they?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-03 08:07 -0800 |
| Message-ID | <kfny3xn9s12.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102856 |
supercat@casperkitty.com writes: > On Tuesday, January 31, 2017 at 10:14:10 AM UTC-6, Tim Rentsch wrote: >> supercat writes: >>> True or false: The Standard allows conforming implementations to >>> behave in arbitrary fashion if certain implementation limits--most >>> notably runtime stack depth--are exceeded. >> >> Stack depth is not an implementation limit, as the Standard >> uses the term. > > What behavioral requirements, if any, would the standard apply to a program > that nests recursive calls a billion levels deep? > > Is there any N, such that it applies any more requirements to a program > which never nests function calls more than N deep? How much stack is available is determined by things like how much RAM the machine has and how much memory the operating system allows, which are not part of the implementation but elements of "a data-processing system capable of supporting a conforming implementation". As such they are explicitly outside the domain of what the Standard addresses. > While the authors of the Standard don't explicitly list function nesting > depth as an Implementation Limit, that's probably because it would be > impractical for many implementations to document how deeply function calls > can be nested. [...] No, they didn't list such things because they deliberately chose to exclude such things from any consideration because they are not included in what makes up an implementation. >>> True or false: The Standard requires that each implementation be >>> capable of processing at least one program which nominally exercises >>> certain implementation limits, but would not forbid an implementation >>> from meeting that requirement through the use of special optimizations >>> which are applied only to that one exact program. >> >> If there is a point to this statement I don't know what it is. >> The Standard explicitly avoids considering any question regarding >> optimization (excluding volatile), as I am sure you must know. > > Would the Standard allow a conforming compiler's code generator to say > "If given a certain precise source file, output a hard-coded executable > which runs it properly, and when given any other source file generate > an executable that unconditionally bombs the stack?" That sounds like a rhetorical question. I am sure you know that the Standard requires implementations to produce a working executable for only one program. > If such behavior would not make a compiler non-conforming, would that not > imply that there are no programs whose behavior is defined on all conforming > implementations? You are confusing the questions of behavior being defined and running a program being guaranteed to work. The behavior of all strictly conforming C programs is defined, even those programs that could not possibly execute on any machine in our physical universe. But there is no power on earth that can guarantee that running ANY program is going to work, because any computer in the real world is subject to the laws of physics, quantum mechanics, etc. >>> Can you offer up any source text which would be guaranteed not to exceed >>> any implementation limits, in such fashion as to invoke Undefined Behavior, >>> on any conforming implementation? >> >> I think you're asking a deliberately fuzzy question. In any case >> though the question is irrelevant - lots of people find programs >> useful if in practice they work, regardless of whether there are >> any absolute guarantees about their behavior. > > I believe you were objecting to my claim that it is impossible to write > any program whose behavior is defined on all implementations. If stack > overflow is not UB, what is it? If there are times when stack overflow > would be guaranteed not to occur, other than when running an > implementation's One Program, what are they? Again you are confusing behavior being defined and what the results of running a program will be. They are not the same thing.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-03 08:43 -0800 |
| Message-ID | <de298604-d918-4916-975d-00effddc7c7f@googlegroups.com> |
| In reply to | #103040 |
On Friday, February 3, 2017 at 10:08:00 AM UTC-6, Tim Rentsch wrote:
> You are confusing the questions of behavior being defined and
> running a program being guaranteed to work. The behavior of all
> strictly conforming C programs is defined, even those programs
> that could not possibly execute on any machine in our physical
> universe. But there is no power on earth that can guarantee
> that running ANY program is going to work, because any computer
> in the real world is subject to the laws of physics, quantum
> mechanics, etc.
It would be possible for an implementation to guarantee that it would
behave in defined fashion under all circumstances *provided that the
platform meets certain requirements*. In most cases, an implementation's
requirements would include things like continuous power, but it would
be possible for a special-purpose implementation to include check-pointing
to a non-volatile store, along with a means of restarting from an earlier
checkpoint after power loss. If an implementation isn't going to include
hardware, I would suggest that it should include a list of requirements
which, if met, would guarantee correct operation.
Further, given that most execution platforms provide a means by which an
executing program can ascertain how much stack will be available, I would
suggest that it would be both practical and useful to recognize a categories
of implementations and programs which, when combined, would never invoke
Undefined Behavior as a consequence of stack overflow. This could be
handled using at least two approaches individually or in combination:
1. An implementation could define the consequences of stack overflow
in sufficient detail to allow a programmer to prevent nasal demons.
2. An implementation could define an intrinsic __ample_stack() with the
semantics that it will false *unless* it can guarantee that execution
will either terminate (via means other than stack overflow) or reach
another invocation of __ample_stack() without a stack overflow
occurring first, and will refuse linkage if it cannot guarantee that
ample stack will exist on all paths where __ample_stack() returns
false.
The level of sophistication required for a linker to support __ample_stack()
would not be appreciably greater than the level present in some embedded
development tools which already perform static stack analysis. On a typical
platform, the compiler would need to record for each function a list of all
the functions it calls and the worst-case amount of content that would be
pushed on the stack before each such call if the __ample_stack() intrinsic
unconditionally returned false. The linker could then compute for each such
function the worst-case stack requirement for the "__ample_stack false" path.
In order to determine the minimum amount of stack for which __ample_stack()
should return true, the compiler would need to examine all the function
calls made on the "true" path and add the amount of stack content each call
required to the amount of data it pushed on the stack between the evaluation
of __ample_stack() and that call, determine the maximum stack requirement
for all possible paths, and compare the remaining stack to any value that was
at least that size but not unreasonably huge (quality implementations should
have __ample_stack() return true when practical, but practicality may
suggest that a compiler should have some tests require enough memory to
allow other tests to be skipped).
>Again you are confusing behavior being defined and what the
>results of running a program will be. They are not the same
>thing.
Implementations are generally in complete control over how much stack they
use, and most platforms can guarantee that a certain amount of stack is
available. Based on those two facts, there should be a standard way by
which implementations could statically guarantee that stack overflows will
not result in Undefined Behavior.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-09 08:43 -0800 |
| Message-ID | <kfn4m035n7g.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103044 |
supercat@casperkitty.com writes: > [...] > > In order to determine the minimum amount of stack for which __ample_stack() > should return true, the compiler would need to examine all the function > calls made on the "true" path and add the amount of stack content each call > required to the amount of data it pushed on the stack between the evaluation > of __ample_stack() and that call, determine the maximum stack requirement > for all possible paths, and compare the remaining stack to any value that was > at least that size but not unreasonably huge (quality implementations should > have __ample_stack() return true when practical, but practicality may > suggest that a compiler should have some tests require enough memory to > allow other tests to be skipped). You must learn to write more simply. There is no way I am going to wade through this sort of verbal toxic waste.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 21:46 +1300 |
| Message-ID | <ee8oaqF2vaqU6@mid.individual.net> |
| In reply to | #100989 |
On 01/ 4/17 04:01 AM, supercat@casperkitty.com wrote: > On Monday, January 2, 2017 at 3:53:13 PM UTC-6, Ian Collins wrote: >> On 01/ 3/17 07:42 AM, supercat wrote: >>> The C89 Standard wasn't written to describe a new language, but rather a >>> family of languages that were already in wide use. There would have been >>> no way to write a single set of requirements, or even two sets of >>> requirements, such that all useful implementations could comply with at >>> least one set, and at least one set would be sufficient to meet the needs >>> of all useful programs. >> >> Well all Unix implementations manged quite well, didn't they? The POISX >> standard extends, defining the undefined, but does not contradict the C >> standard it is based upon. > > I think there are one or two places where Posix contradicts the C Standard > (e.g. by having standard headers define macros or identifiers that don't > start with an underscore and aren't listed by the Standard), but if your > point is that many implementations are useful because they define things > beyond what the C Standard requires, I agree with you. It is. > My point is that the C Standard is not, *in and of itself*, sufficient to > write useful programs; since different platforms are generally used to run > different kinds of programs, which in turn need different features and > guarantees, it would make sense that the features and guarantees which are > available to a programmer should depend upon the platform upon which the > program is running. I don't thank anyone has ever claimed otherwise. We all know that work is required to get an application from a POSIX environment to run on windows. What the standard provides is a common core library shared on all conforming implementations. > Given the state of 1980s compiler technology, it was possible for many implementations to offer useful features and guarantees beyond what the > Standard required at zero cost or near cost, and the popularity of the > language stemmed from the fact that in many cases it was obvious what > features and guarantees would naturally be available on which platforms. The popularity of C in the 80s largely came form it being better than assembler for non-trivial applications. On the projects I was working on at the time, portability was never really considered. Each compiler had it's own set of what would now be called non-portable extensions for the target platform. Don't forget that there wasn't a standard in the 80s other than K&R. > My point is that whether or not any Committee chose to recognize them, > languages like "C for MS-DOS platforms", "C for the Macintosh", etc. > were necessary to accomplish many useful tasks on various platforms, and > compiler manufacturers regarded as them as standards that were just as > important as anything the Committee wrote [the fact that many MS-DOS > programs required compilers to support the "near" and "far" qualifiers, > for example, was far more important to compiler manufacturers than the > fact that the Standard forbids compilers from adding reserved words that > don't start with underscores]. Extensions that predate the first standard could hardly be removed, could that? There would have been no sense in standardising platform specific features. > Over the years, the costs of commonplace features and guarantees have > increased to the point that from a performance standpoint it would make > far more sense to have compilers provide them on an as-needed basis rather > than by default. Such issues arise in many fields; C is hardly unique. > When they arise in other languages or protocols, they can be handled > without breaking things by: > > 1. Defining new constructs to narrowly request the formerly-cheap behavior > in those specific places where it actually needed. You keep citing "formerly-cheap behavior" without qualifying it in anything other than contrived snippets. > 2. Defining a means of indicating that code does not require the behavior > outside of the places using the new constructs. I'm sure what you are referring to here, but don't compilers invariably provide options and macros to select the language version to use? > 3. Deprecating the use of the language that would be processed without the > header. Unable to parse. > That approach is the way standards are supposed to work. While the need to > explicitly specify language versions [e.g. by starting Javascrpt files with > the string literal "use strict";] can be a slight nuisance, it allows > languages and protocols to shed historical baggage far more easily, and with > far less disruption to existing systems and code, than would otherwise be > possible. Just like options and macros to select the language version to use? >>> Consequently, I don't think the C Standard can sensibly be viewed as "just >>> another requirements document", as much as some people would try to view >>> it that way. Such a view would simultaneously prevent the Standard from >>> saying anything at all useful about low-end implementations for which >>> meeting some of the requirements in the spec would be impractical, but >>> also subject even programmers targeting high-end systems to the limitations >>> of low-end systems upon which their programs would never be run anyway. >> >> Utter tripe. We are discussing the libraries section of the standard >> and libraries provide a common interface for both high and low end >> systems, which enables us to develop software on the former for the >> latter. It does not say anything about systems that are not intended to >> conform to it. > > If the Standard refrains from mandating useful features so as to be usable > on as many machines as possible, does it make sense for it to disqualify > machines because they can't support features that only a minority of programs > need? Or would it make more sense to recognize concepts of "sub-baseline" > implementations which would be below the quality one would expect in the > absence of resource constraints, but which could nonetheless be useful for > many purposes? That would be a language almost but not entirely unlike C. Making more features optional isn't a bat thing and C11 has made some progress in that direction. > While some people might turn down their nose at the kinds of programs that > can run on a machine which have enough memory to hold 256 instructions and > 24 bytes of data, even tiny machines like that are probably programmed as > often in C as in assembly languages. It's not possible to write a standards- > compliant program on such a platform, but compilers for such platforms may > be able to guarantee that any program will either fit within the platform's > resource constraints or refuse compilation altogether--a situation which is > in fact better than on some conforming implementations where a program that > barely fits in memory might load successfully but immediately jump the > rails because of a stack overflow, Which is something they already do. They don't claim to be compliant C implementations. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-18 09:01 -0800 |
| Message-ID | <9bff9192-e563-4e6d-ab3a-d0f89848861d@googlegroups.com> |
| In reply to | #102104 |
On Wednesday, January 18, 2017 at 2:46:25 AM UTC-6, Ian Collins wrote:
> On 01/ 4/17 04:01 AM, supercat wrote:
> > Given the state of 1980s compiler technology, it was possible for many implementations to offer useful features and guarantees beyond what the
> > Standard required at zero cost or near cost, and the popularity of the
> > language stemmed from the fact that in many cases it was obvious what
> > features and guarantees would naturally be available on which platforms.
>
> The popularity of C in the 80s largely came form it being better than
> assembler for non-trivial applications. On the projects I was working
> on at the time, portability was never really considered. Each compiler
> had it's own set of what would now be called non-portable extensions for
> the target platform. Don't forget that there wasn't a standard in the
> 80s other than K&R.
Compilers for microcomputers also had many other features in common with
the original C for the PDP-11:
1. Pointers would be stored and hardware addresses, and casts between
pointers and matching-size integer types were representation-
preserving.
2. Casts between signed and unsigned integers are representation-
preserving.
3. The representations of pointers to objects would be unaffected by the
types of objects identified thereby.
4. The common-initial-sequence rule was extended to extended not just
to members with the same type, but also to those with the same size
and alignment requirements.
5. Even though object accesses which weren't made through pointers could
use register-cached values in the absence of any use or casting of
pointers of alias-compatible types, accesses through suitably-aligned
pointers would behave as accesses to the bytes of the underlying
storage.
6. As noted in the C89 Rationale for making short unsigned values promote
to signed, most operators would behave identically with signed and
unsigned values in *all* cases except where *BOTH* of the following
conditions applied:
a. The MSB of the result was set *AND*
b. The result was used in a way that would treat signed and unsigned
types differently (the rationale lists those ways).
7. Except on 16-bit x86, operations on char* had the same semantics as
operations in integers. On that platform, operations on char* would
either act as operations on the 32-bit representation or the low 16
bits thereof (depending upon the operation and, for relational
operators, the compiler and/or settings).
8. Given char *p,*q; p+(q-p) would yield q even in cases where the
difference between q and p exceeded the range of ptrdiff_t [e.g. on
a 16-bit system, if p is the start of a 40960-byte object and q points
just past it, q-p would yield -24576, but p-24576 would yield q]. The
Standard allows SIZE_MAX to exceed the range of ptrdiff_t, but leaves
behavior undefined if pointers that differ by more than the maximum
value of ptrdiff_t are subtracted.
Given the state of compiler technology of the time, it cost compilers
essentially nothing to support such guarantees; are you aware of any
microcomputer compilers that didn't support all of them?
> > My point is that whether or not any Committee chose to recognize them,
> > languages like "C for MS-DOS platforms", "C for the Macintosh", etc.
> > were necessary to accomplish many useful tasks on various platforms, and
> > compiler manufacturers regarded as them as standards that were just as
> > important as anything the Committee wrote [the fact that many MS-DOS
> > programs required compilers to support the "near" and "far" qualifiers,
> > for example, was far more important to compiler manufacturers than the
> > fact that the Standard forbids compilers from adding reserved words that
> > don't start with underscores].
>
> Extensions that predate the first standard could hardly be removed,
> could that? There would have been no sense in standardising platform
> specific features.
Features like the above were not universal to every platform in existence,
but were common to the vast majority. Having compilers for similar platforms
behave in similar fashion certainly makes sense; the only reason not to
standardize such things would be if compilers for such platforms would
behave in similar fashion even without official standardization.
> > Over the years, the costs of commonplace features and guarantees have
> > increased to the point that from a performance standpoint it would make
> > far more sense to have compilers provide them on an as-needed basis rather
> > than by default. Such issues arise in many fields; C is hardly unique.
> > When they arise in other languages or protocols, they can be handled
> > without breaking things by:
> >
> > 1. Defining new constructs to narrowly request the formerly-cheap behavior
> > in those specific places where it actually needed.
>
> You keep citing "formerly-cheap behavior" without qualifying it in
> anything other than contrived snippets.
See above. You may call them contrived, but they can allow useful tasks to
be performed more easily and/or efficiently than would otherwise be possible.
> > 2. Defining a means of indicating that code does not require the behavior
> > outside of the places using the new constructs.
>
> I'm sure what you are referring to here, but don't compilers invariably
> provide options and macros to select the language version to use?
The Standard does not define any such thing. What I mean by #2 would be
saying that if code includes
#pragma STDC_ALIAS_MODE=3
then compilers would be allowed to make certain aliasing optimizations
(possibly including some optimizations which are not presently allowed,
such as assuming that things won't generally be aliased by char*) but
forbidden from making others (such as assuming code which casts a float*
to a uint32_t* and uses it to access a uint32_t without any intervening
accesses to that type won't alias an object of type uint32_t).
> > 3. Deprecating the use of the language that would be processed without the
> > header.
>
> Unable to parse.
Maybe fleshed-out example would clarify. As Javascript was originally
designed, the "var" statement will create a new variable in the present
scope, but an attempt to assign a variable which has not been declared
will create a or modify a variable in the caller's scope. Some code
relies upon this, but the semantics are generally recognized as really
icky and best avoided.
If a Javascript file starts with "use strict"; [including the quotes] then
the Javascript interpreter will regard the use of a variable which is not
declared in the present scope as a fatal error. Since code which relies
upon the old behavior would be unlikely to start with that string literal,
adding the new behavior to the Javascript interpreter will not break old
code. On the other hand, use of the old mode is largely deprecated, and
people writing Javascript are strongly encouraged to use "use strict"; in
all new projects whenever practical.
Likewise, the Standard could specify that new programs should, whenever
practical, contain directives (either directly, or within an #include
file) to indicate what compiler features or modes require. Code which
is willing to apply "hope for the best" semantics would not be required
to contain such directives, and compilers would have great freedom to
process such code lacking such directives as they see fit, but code which
lacks such directives would not qualify as anything other than "barely
conforming".
> > That approach is the way standards are supposed to work. While the need to
> > explicitly specify language versions [e.g. by starting Javascrpt files with
> > the string literal "use strict";] can be a slight nuisance, it allows
> > languages and protocols to shed historical baggage far more easily, and with
> > far less disruption to existing systems and code, than would otherwise be
> > possible.
>
> Just like options and macros to select the language version to use?
Somewhat, but standardized.
> > If the Standard refrains from mandating useful features so as to be usable
> > on as many machines as possible, does it make sense for it to disqualify
> > machines because they can't support features that only a minority of programs
> > need? Or would it make more sense to recognize concepts of "sub-baseline"
> > implementations which would be below the quality one would expect in the
> > absence of resource constraints, but which could nonetheless be useful for
> > many purposes?
>
> That would be a language almost but not entirely unlike C. Making more
> features optional isn't a bat thing and C11 has made some progress in
> that direction.
You mean "bad" thing?
As I see it, a C Standard is going to partition programs into four classes:
1. Programs which all implementations must accept and process in defined
fashion for all inputs they will receive.
2. Programs which all implementations must either accept and process in
at-least-loosely defined fashion for all inputs they will receive, or
else reject altogether.
3. Programs which all implementations must reject.
4. Programs which all implementations must accept, but which may behave
in arbitrary fashion for some inputs they will receive.
5. Programs which implementations may treat in arbitrary fashion,
including rejection.
Would you agree with that classification? I would suggest that a good
standard should seek to maximize the number of implementations that can
support the language for purposes of doing at least some tasks, and
maximize the number of tasks that can be performed by programs in category
#1 or #2. If a program is in category #2, there might be only a few
implementations that can run it, but it will still have a standard-define
meaning, and it would be possible for someone to design an implementation
for other platforms that would be capable of executing it--even if not
very efficiently--with that meaning. For example, if the Standard were to
specify a means of declaring a 48-bit floating-point value stored in the
format used by Borland's Turbo Pascal and for some reason there was a
demand for such a format, any compiler that wanted to support it could add
support. Operations on such type may be far less efficient than operations
on native types, but might still be much more amenable to optimizations than
C code which tries to process such things as a sequence of bytes.
> > While some people might turn down their nose at the kinds of programs that
> > can run on a machine which have enough memory to hold 256 instructions and
> > 24 bytes of data, even tiny machines like that are probably programmed as
> > often in C as in assembly languages. It's not possible to write a standards-
> > compliant program on such a platform, but compilers for such platforms may
> > be able to guarantee that any program will either fit within the platform's
> > resource constraints or refuse compilation altogether--a situation which is
> > in fact better than on some conforming implementations where a program that
> > barely fits in memory might load successfully but immediately jump the
> > rails because of a stack overflow,
>
> Which is something they already do. They don't claim to be compliant C
> implementations.
True, but I would suggest that a Standard should try to maximize the range
of platforms about which it can say something useful.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web