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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-03 07:01 -0800 |
| Message-ID | <5bf5dcb7-ef8c-4d6b-aa1b-11f0522651b7@googlegroups.com> |
| In reply to | #100911 |
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.
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.
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.
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].
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.
2. Defining a means of indicating that code does not require the behavior
outside of the places using the new constructs.
3. Deprecating the use of the language that would be processed without the
header.
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.
> > 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?
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,
> > If someone is seeking to write a useful quality implementation for a
> > particular platform, I would consider the expectations of programmers who
> > are targeting that platform as being far more important than what the
> > Standard would say.
>
> Then your thinking is wrong headed. Do you understand why we have
> standards?
Tell me. I would think there should be two purposes:
1. Define a large categories of implementations and programs (call the
implementations X-compliant and the programs Y-conforming), such
that for any combination of an X-compliant implementation C and a
Y-compliant program P, something useful can be said about the effect
of feeding program P to implementation Q [e.g. while Q may reject
P outright, it will never behave in unconstrained fashion].
2. Maximize the number of combinations of programs and implementations
such that feeding a program P to implementation C will do something
useful.
While the present Standard doesn't seem to make much effort at either of the
above, I would suggest that a good standard should seek to--and largely
succeed at--doing both. The present Standard defines an absurdly-large
category of "conforming" programs, about which it says essentially nothing
(almost any text file that starts with two underscores could be described
as a "conforming C program", for example) and a category of "strictly-
conforming" programs upon which it imposes very tight requirements, but for
which it still offers no meaningful behavioral guarantees [since the
Standard would allow an implementation to require an arbitrary amount of
stack space to evaluate a literal constant like 42, and does not require
that implementations provide adequate stack for the purpose, it would be
possible, for any source text, to write a compiler which would--as far as
the Standard is concerned--be justified in blowing the stack and behaving
in arbitrary fashion].
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-03 09:01 -0800 |
| Message-ID | <ln60lwulff.fsf@kst-u.example.com> |
| In reply to | #100989 |
supercat@casperkitty.com writes:
[...]
> 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),
[...]
No, the authors of the POSIX standard actually thought of that.
For POSIX functions and other identifiers declared in C standard
headers such as <stdio.h>, you have to define a macro like
_POSIX_SOURCE before including the header to make the identifier
visible. A compiler can define such a macro implicitly in a
non-conforming mode.
(IMHO it would have been better for all POSIX-specific
identifiers to be declared only in POSIX-specific headers, but the
authors of POSIX, like the authors of the C standard, had to deal
with existing practice.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-03 12:36 -0800 |
| Message-ID | <b3b49ec1-bfd1-42fe-9da6-7529c476fa29@googlegroups.com> |
| In reply to | #101014 |
On Tuesday, January 3, 2017 at 11:01:53 AM UTC-6, Keith Thompson wrote: > supercat writes: > No, the authors of the POSIX standard actually thought of that. > For POSIX functions and other identifiers declared in C standard > headers such as <stdio.h>, you have to define a macro like > _POSIX_SOURCE before including the header to make the identifier > visible. A compiler can define such a macro implicitly in a > non-conforming mode. I was under the impression that the intention was that such a macro be set at the command line, since older POSIX source code wouldn't define it, with the effect that compilers can either be compiled in a way that pre-sets the flag and makes them behave in a way that isn't Standard compliant, or refrains from doing so and have the compiler behave in a way that isn't compliant with POSIX. In any case, I forgot to mention that many POSIX implementations deviate from the Standard in a much more important way: the Standard does not recognize the possibility that malloc(), calloc(), etc. may return a pointer which isn't null, but which might nonetheless cause a program to die if/when code tries to actually use it. It would have made sense for the Standard to the behavior of malloc(), fopen(), etc. as issuing requests to an underlying system, and returning null in the event that the system reports failure, but recognizing the the possible implementation-defined existence of side effects outside the program's control [a statement that such side-effects may exist should be sufficient definition to achieve conformance, though quality implementations should provide more detail whenever practical].
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-04 09:51 +1300 |
| Message-ID | <ed2h6nF9licU2@mid.individual.net> |
| In reply to | #101027 |
On 01/ 4/17 09:36 AM, supercat@casperkitty.com wrote: > > In any case, I forgot to mention that many POSIX implementations deviate > from the Standard in a much more important way: the Standard does not > recognize the possibility that malloc(), calloc(), etc. may return a > pointer which isn't null, but which might nonetheless cause a program to > die if/when code tries to actually use it. Neither does POSIX. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-03 13:08 -0800 |
| Message-ID | <lnwpebua07.fsf@kst-u.example.com> |
| In reply to | #101027 |
supercat@casperkitty.com writes:
[...]
> In any case, I forgot to mention that many POSIX implementations deviate
> from the Standard in a much more important way: the Standard does not
> recognize the possibility that malloc(), calloc(), etc. may return a
> pointer which isn't null, but which might nonetheless cause a program to
> die if/when code tries to actually use it.
That has nothing to do with POSIX. The POSIX requirements for malloc()
are, as far as I can tell, exactly the same as the ISO C requirements
(including the implementation-defined behavior of malloc(0)). What
you're describing is a characteristic of the Linux kernel.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-03 14:07 -0800 |
| Message-ID | <4c08dfe0-afbf-4a76-862d-784ad66dc2d6@googlegroups.com> |
| In reply to | #101035 |
On Tuesday, January 3, 2017 at 3:08:35 PM UTC-6, Keith Thompson wrote: > That has nothing to do with POSIX. The POSIX requirements for malloc() > are, as far as I can tell, exactly the same as the ISO C requirements > (including the implementation-defined behavior of malloc(0)). What > you're describing is a characteristic of the Linux kernel. 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? Even on a Linux kernel, an implementation could conform to the Standard by pre-allocating and touching a certain amount of storage before it does anything else, using that to satisfy all subsequent malloc requests, and having malloc() return null if malloc() tries to ask for more storage than was pre-allocated. While such an approach would be crude, there are certainly some situations where it would be advantageous. There may be other situations where having an implementation acquire memory after user code has started executing is more useful than having them pre-allocate it, but I would classify those as situations where an implementation that is non-conforming may--for at least some purposes--be more useful than one which is conforming.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-04 11:28 +1300 |
| Message-ID | <ed2msiFccfvU1@mid.individual.net> |
| In reply to | #101044 |
On 01/ 4/17 11:07 AM, supercat@casperkitty.com wrote: > On Tuesday, January 3, 2017 at 3:08:35 PM UTC-6, Keith Thompson wrote: >> That has nothing to do with POSIX. The POSIX requirements for malloc() >> are, as far as I can tell, exactly the same as the ISO C requirements >> (including the implementation-defined behavior of malloc(0)). What >> you're describing is a characteristic of the Linux kernel. > > 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. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-01-03 22:49 +0000 |
| Message-ID | <o4h9ou$qjg$3@news.albasani.net> |
| In reply to | #101047 |
On 2017-01-03, Ian Collins <ian-news@hotmail.com> wrote: > On 01/ 4/17 11:07 AM, supercat@casperkitty.com wrote: >> On Tuesday, January 3, 2017 at 3:08:35 PM UTC-6, Keith Thompson wrote: >>> That has nothing to do with POSIX. The POSIX requirements for malloc() >>> are, as far as I can tell, exactly the same as the ISO C requirements >>> (including the implementation-defined behavior of malloc(0)). What >>> you're describing is a characteristic of the Linux kernel. >> >> 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. > Is there any mainstream OS these days that does not do over commit? I see Solaris does not allows that but there are problems related to it... eg java can't reserve memory... overcommit is mainly usefull for GC based programs as they tend to reserve gigabytes of space... one have to use over commit, either that, or waste disk space on swap... -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-04 11:53 +1300 |
| Message-ID | <ed2oc4FccfvU2@mid.individual.net> |
| In reply to | #101050 |
On 01/ 4/17 11:49 AM, Melzzzzz wrote: > On 2017-01-03, Ian Collins <ian-news@hotmail.com> wrote: >> On 01/ 4/17 11:07 AM, supercat@casperkitty.com wrote: >>> On Tuesday, January 3, 2017 at 3:08:35 PM UTC-6, Keith Thompson wrote: >>>> That has nothing to do with POSIX. The POSIX requirements for malloc() >>>> are, as far as I can tell, exactly the same as the ISO C requirements >>>> (including the implementation-defined behavior of malloc(0)). What >>>> you're describing is a characteristic of the Linux kernel. >>> >>> 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. >> > Is there any mainstream OS these days that does not do over commit? > I see Solaris does not allows that but there are problems related to > it... eg java can't reserve memory... Badly written (spit) Java can't reserve memory, which is a good thing! Any OS that can run as a hypervisor should not over commit. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-01-03 18:39 -0600 |
| Message-ID | <0sgo6clc3g19o0fl5js47vb4e3isnigfnh@4ax.com> |
| In reply to | #101050 |
On Tue, 3 Jan 2017 22:49:02 +0000 (UTC), Melzzzzz <Melzzzzz@zzzzz.com> wrote: >On 2017-01-03, Ian Collins <ian-news@hotmail.com> wrote: >> On 01/ 4/17 11:07 AM, supercat@casperkitty.com wrote: >>> On Tuesday, January 3, 2017 at 3:08:35 PM UTC-6, Keith Thompson wrote: >>>> That has nothing to do with POSIX. The POSIX requirements for malloc() >>>> are, as far as I can tell, exactly the same as the ISO C requirements >>>> (including the implementation-defined behavior of malloc(0)). What >>>> you're describing is a characteristic of the Linux kernel. >>> >>> 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. >> >Is there any mainstream OS these days that does not do over commit? >I see Solaris does not allows that but there are problems related to >it... eg java can't reserve memory... overcommit is mainly usefull for >GC based programs as they tend to reserve gigabytes of space... >one have to use over commit, either that, or waste disk space on swap... Define "mainstream". zOS, and zVSE do not overcommit. In fact both of those allocate disk pages to almost (there are exceptions) every allocated page in each address space (IOW, if a page is paged out, it always goes to the same slot on disk).
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-01-04 00:47 +0000 |
| Message-ID | <o4hgnh$qjg$9@news.albasani.net> |
| In reply to | #101067 |
On 2017-01-04, Robert Wessel <robertwessel2@yahoo.com> wrote: > On Tue, 3 Jan 2017 22:49:02 +0000 (UTC), Melzzzzz <Melzzzzz@zzzzz.com> > wrote: > >>On 2017-01-03, Ian Collins <ian-news@hotmail.com> wrote: >>> On 01/ 4/17 11:07 AM, supercat@casperkitty.com wrote: >>>> On Tuesday, January 3, 2017 at 3:08:35 PM UTC-6, Keith Thompson wrote: >>>>> That has nothing to do with POSIX. The POSIX requirements for malloc() >>>>> are, as far as I can tell, exactly the same as the ISO C requirements >>>>> (including the implementation-defined behavior of malloc(0)). What >>>>> you're describing is a characteristic of the Linux kernel. >>>> >>>> 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. >>> >>Is there any mainstream OS these days that does not do over commit? >>I see Solaris does not allows that but there are problems related to >>it... eg java can't reserve memory... overcommit is mainly usefull for >>GC based programs as they tend to reserve gigabytes of space... >>one have to use over commit, either that, or waste disk space on swap... > > > Define "mainstream". Most popular... -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-04 09:49 +0000 |
| Message-ID | <586cbfef.256875@news.xs4all.nl> |
| In reply to | #101068 |
Melzzzzz <Melzzzzz@zzzzz.com> wrote: > On 2017-01-04, Robert Wessel <robertwessel2@yahoo.com> wrote: > > On Tue, 3 Jan 2017 22:49:02 +0000 (UTC), Melzzzzz <Melzzzzz@zzzzz.com> > > > >>Is there any mainstream OS these days that does not do over commit? > >>I see Solaris does not allows that but there are problems related to > >>it... eg java can't reserve memory... overcommit is mainly usefull for > >>GC based programs as they tend to reserve gigabytes of space... > >>one have to use over commit, either that, or waste disk space on swap... > > > > Define "mainstream". > Most popular... Define "popular"... Windows 7 is the most used, but it's only relatively highly spoken of. The second-most used is Windows 10, and that's not so much popular as a popular dictatorship: nobody likes it, but if you have it you're compelled to pretend you do. Linux, all versions added up, doesn't even have the market share of the derided Windows 8. Popular? Go away. OSX has more users than Linux (keep that in mind, fanboyz on either side!), and it's laughably popular among its addicts, but a cause of frustration for almost anyone else who has to deal with it. An OS that was actually _popular_ among those who used it? Well, it's claimed by those who were there that ITS was quite nice. I myself wouldn't know. In any case, overcommit is a tool of the devil, along with spaces in filenames and outdated documentation. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-04 15:45 +0000 |
| Message-ID | <87shoyltgi.fsf@bsb.me.uk> |
| In reply to | #101079 |
raltbos@xs4all.nl (Richard Bos) writes: > Melzzzzz <Melzzzzz@zzzzz.com> wrote: > >> On 2017-01-04, Robert Wessel <robertwessel2@yahoo.com> wrote: >> > On Tue, 3 Jan 2017 22:49:02 +0000 (UTC), Melzzzzz <Melzzzzz@zzzzz.com> >> > >> >>Is there any mainstream OS these days that does not do over commit? <snip> >> > Define "mainstream". > >> Most popular... > > Define "popular"... <snip> > Linux, all versions added up, doesn't even have the market share of the > derided Windows 8. Popular? Go away. A lot of servers run Linux as do my WiFi router, the network storage device I have, my printer, my PVR and both my phones. I think the stereo does as well but I'm not sure. There are quite a lot of those things around so if you were no counting them there may be more Linux systems that you think. I have no numbers, so I'm not saying ou are wrong, just checking that you've added in these things. In context, the real question would be whether Linux is configured to over-commit on these devices since it can do either. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-04 20:05 +0100 |
| Message-ID | <o4jgvi$a8e$1@dont-email.me> |
| In reply to | #101101 |
On 04/01/17 16:45, Ben Bacarisse wrote: > raltbos@xs4all.nl (Richard Bos) writes: > >> Melzzzzz <Melzzzzz@zzzzz.com> wrote: >> >>> On 2017-01-04, Robert Wessel <robertwessel2@yahoo.com> wrote: >>>> On Tue, 3 Jan 2017 22:49:02 +0000 (UTC), Melzzzzz <Melzzzzz@zzzzz.com> >>>> >>>>> Is there any mainstream OS these days that does not do over commit? > <snip> >>>> Define "mainstream". >> >>> Most popular... >> >> Define "popular"... > <snip> >> Linux, all versions added up, doesn't even have the market share of the >> derided Windows 8. Popular? Go away. > > A lot of servers run Linux as do my WiFi router, the network storage > device I have, my printer, my PVR and both my phones. I think the > stereo does as well but I'm not sure. There are quite a lot of those > things around so if you were no counting them there may be more Linux > systems that you think. I have no numbers, so I'm not saying ou are > wrong, just checking that you've added in these things. I believe I have 16 systems running Linux in my house, not including virtual machines, old systems that are usually off, or the couple of Raspberry Pi's in a drawer. There is one Windows system. > > In context, the real question would be whether Linux is configured to > over-commit on these devices since it can do either. > Most of the Linux systems we have around us are "devices", rather than general computers - typically they don't run programs that might be over-committing. (Android phones and pads may be an exception.) But my guess is that in almost all cases, the default over-commit mode (heuristic overcommit) will be used. From the documentation: The Linux kernel supports the following overcommit handling modes 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default. 1 - Always overcommit. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages. 2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable amount (default is 50%) of physical RAM. Depending on the amount you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate. Useful for applications that want to guarantee their memory allocations will be available in the future without having to initialize every page.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-03 15:55 -0800 |
| Message-ID | <d2a9364d-c18f-4208-aa18-b347ef692099@googlegroups.com> |
| In reply to | #101047 |
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.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-04 13:09 +1300 |
| Message-ID | <ed2sqdFccfvU3@mid.individual.net> |
| In reply to | #101057 |
On 01/ 4/17 12:55 PM, supercat@casperkitty.com wrote: > 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. Over commit is an abomination which is only of use to poorly written programs. So this is an example where standard compliance is good! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-01-04 00:12 +0000 |
| Message-ID | <o4helb$qjg$4@news.albasani.net> |
| In reply to | #101060 |
On 2017-01-04, Ian Collins <ian-news@hotmail.com> wrote: > On 01/ 4/17 12:55 PM, supercat@casperkitty.com wrote: >> 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. > > Over commit is an abomination which is only of use to poorly written > programs. So this is an example where standard compliance is good! > Well, programs that use GC, overcommit heavily... -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-04 09:50 +0000 |
| Message-ID | <586cc553.1637109@news.xs4all.nl> |
| In reply to | #101061 |
Melzzzzz <Melzzzzz@zzzzz.com> wrote: > On 2017-01-04, Ian Collins <ian-news@hotmail.com> wrote: > > On 01/ 4/17 12:55 PM, supercat@casperkitty.com wrote: > >> On Tuesday, January 3, 2017 at 4:28:44 PM UTC-6, Ian Collins wrote: > >>> 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. > > > > Over commit is an abomination which is only of use to poorly written > > programs. So this is an example where standard compliance is good! > > Well, programs that use GC, overcommit heavily... One more reason why GC makes for bad, lazy programmers. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-04 07:25 -0800 |
| Message-ID | <437a826d-3479-4b10-8474-46ef8266dc25@googlegroups.com> |
| In reply to | #101061 |
On Tuesday, January 3, 2017 at 6:12:33 PM UTC-6, Melzzzzz wrote: > Well, programs that use GC, overcommit heavily... Oh really? Some garbage collectors going back at least to the 1984 Macintosh (most likely before) have the ability to mark items as "purgeable", with the semantics that at any time when the GC is allowed to run it may cause such items to spontaneously cease to exist. Such objects need to be accessed via some form of handle, which will continue to exist whether or not the object does, and code which accesses such objects must lock them during use (to ensure that they can't be eliminated while they are being used). It would not be at all unreasonable for code on such a system to allocate a total volume of objects which exceeds a system's capacity, but doing so would not be a problem since code would be prepared to release objects which were useful, but not absolutely necessary, to free up space. Is there some other sense in which you claim GC systems overcommit?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-01-04 15:29 +0000 |
| Message-ID | <o4j4df$bbc$2@news.albasani.net> |
| In reply to | #101097 |
On 2017-01-04, supercat@casperkitty.com <supercat@casperkitty.com> wrote: > On Tuesday, January 3, 2017 at 6:12:33 PM UTC-6, Melzzzzz wrote: >> Well, programs that use GC, overcommit heavily... > > Oh really? Some garbage collectors going back at least to the 1984 Macintosh > (most likely before) have the ability to mark items as "purgeable", with the > semantics that at any time when the GC is allowed to run it may cause such > items to spontaneously cease to exist. Such objects need to be accessed via > some form of handle, which will continue to exist whether or not the object > does, and code which accesses such objects must lock them during use (to > ensure that they can't be eliminated while they are being used). It would > not be at all unreasonable for code on such a system to allocate a total > volume of objects which exceeds a system's capacity, but doing so would not > be a problem since code would be prepared to release objects which were > useful, but not absolutely necessary, to free up space. > > Is there some other sense in which you claim GC systems overcommit? 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 -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
Page 4 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