Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67230 > unrolled thread
| Started by | fl <rxjwg98@gmail.com> |
|---|---|
| First post | 2015-08-12 15:28 -0700 |
| Last post | 2015-08-14 09:03 -0700 |
| Articles | 20 on this page of 164 — 27 participants |
Back to article view | Back to comp.lang.c
How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 15:28 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 23:52 +0100
Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:13 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 00:33 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:06 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-13 20:50 +0000
Re: How to read a data file whose size is unknown in C? Stephen Sprunk <stephen@sprunk.org> - 2015-08-17 13:38 -0500
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-17 14:48 -0400
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-18 11:10 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 15:01 +0100
Re: How to read a data file whose size is unknown in C? gordonb.8n5lc@burditt.org (Gordon Burditt) - 2015-08-14 02:33 -0500
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-14 10:06 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 09:14 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-14 21:27 +0000
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:52 +0200
Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-15 01:17 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 10:27 +0200
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-15 18:09 +0000
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:05 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 13:50 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 21:37 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:33 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 22:58 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 00:08 +0200
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 00:40 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:23 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:37 -0700
Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:35 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 10:31 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:21 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:31 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 03:38 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:29 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:46 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:03 -0700
Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-16 03:23 +0100
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 00:56 -0700
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 01:08 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-17 10:20 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:01 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 11:31 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 14:01 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 22:28 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:29 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-16 10:50 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:40 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-16 20:22 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 21:27 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:31 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:25 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 16:29 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 23:43 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 18:20 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-17 19:10 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-18 05:26 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:23 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-18 04:23 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:39 -0700
Re: How to read a data file whose size is unknown in C? Ike Naar <ike@iceland.freeshell.org> - 2015-08-18 16:49 +0000
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:42 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-18 19:57 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-19 16:12 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-19 18:04 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-20 16:52 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-20 18:18 -0700
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-21 20:39 +0000
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-21 17:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-21 19:35 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:28 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-22 22:43 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 00:07 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:59 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:22 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-23 19:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-23 21:35 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 16:59 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-24 17:57 -0700
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-25 01:09 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-25 19:03 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-25 22:16 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-26 14:29 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-26 18:28 -0400
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 19:25 -0700
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-27 10:07 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 09:18 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 18:04 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 11:15 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 21:10 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 15:54 -0700
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:28 +0200
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-27 13:12 -0600
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:35 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-25 04:28 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:19 -0400
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-24 00:31 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:06 -0700
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:25 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 10:45 -0400
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-21 17:40 -0400
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 00:40 -0400
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-19 05:38 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 10:20 -0400
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:22 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:21 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-14 08:48 -0400
Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:21 -0700
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-12 19:44 -0600
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-12 22:04 -0400
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 00:44 +0100
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 01:04 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 11:31 +0100
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 11:51 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 08:49 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 17:45 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:11 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:34 +0100
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 12:21 -0500
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 19:07 +0100
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 16:08 -0500
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:51 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-15 12:36 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:26 +0200
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:26 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 08:11 -0700
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-16 00:05 -0500
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-16 09:08 -0400
Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:22 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:28 -0700
Re: How to read a data file whose size is unknown in C? Tonton Th <tTh@nowhere.invalid> - 2015-08-14 11:06 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:28 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 18:56 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 13:39 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 00:21 +0100
Re: How to read a data file whose size is unknown in C? Ian Collins <ian-news@hotmail.com> - 2015-08-14 12:26 +1200
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:00 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:30 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 12:31 +0100
Re: How to read a data file whose size is unknown in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 04:51 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:21 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:23 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-14 16:57 -0700
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-15 14:49 -0600
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:31 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 00:35 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 08:57 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 17:28 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:12 +0000
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 07:03 +0200
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 12:38 +0200
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 13:32 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 14:49 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 14:05 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 14:50 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:14 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:42 -0400
Re: How to read a data file whose size is unknown in C? Ken Brody <kenbrody@spamcop.net> - 2015-08-13 10:56 -0400
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:16 -0700
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-08-13 18:12 +0200
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:50 -0400
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 20:07 +0200
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 14:38 -0400
Re: How to read a data file whose size is unknown in C? John Bode <jfbode1029@gmail.com> - 2015-08-13 09:30 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-14 09:03 -0700
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-25 22:16 -0400 |
| Message-ID | <mrj7e0$3s2$1@dont-email.me> |
| In reply to | #68361 |
On 08/25/2015 10:03 PM, David Kleinecke wrote: ... > ... I want C to be the universal high order assembler While C has sometimes been described as "portable high-level assembler", it isn't and was never intended to be. C code describes the desired behavior, not the desired sequence of machine language instructions. You've got essentially no chance of ever convincing the C committee of changing it in that fashion. I'd recommend trying to develop your own C-like language, rather then trying to change C itself. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-26 14:29 -0700 |
| Message-ID | <6c28b77b-4577-49af-b6ac-4fa1f3ed65ee@googlegroups.com> |
| In reply to | #68363 |
On Tuesday, August 25, 2015 at 7:16:21 PM UTC-7, James Kuyper wrote: > On 08/25/2015 10:03 PM, David Kleinecke wrote: > ... > > ... I want C to be the universal high order assembler > > While C has sometimes been described as "portable high-level assembler", > it isn't and was never intended to be. C code describes the desired > behavior, not the desired sequence of machine language instructions. > You've got essentially no chance of ever convincing the C committee of > changing it in that fashion. I'd recommend trying to develop your own > C-like language, rather then trying to change C itself. Hum - and all over the world people thought that C was the "portable high-level assembler" and used it as a portable high-level assembler. That's all I intend - what people are already doing. Is there some specific reason why you object to that description of C?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-26 18:28 -0400 |
| Message-ID | <55DE3D7B.7060706@verizon.net> |
| In reply to | #68453 |
On 08/26/2015 05:29 PM, David Kleinecke wrote: > On Tuesday, August 25, 2015 at 7:16:21 PM UTC-7, James Kuyper wrote: >> On 08/25/2015 10:03 PM, David Kleinecke wrote: ... >>> ... I want C to be the universal high order assembler >> >> While C has sometimes been described as "portable high-level >> assembler", it isn't and was never intended to be. C code describes >> the desired behavior, not the desired sequence of machine language >> instructions. You've got essentially no chance of ever convincing >> the C committee of changing it in that fashion. I'd recommend >> trying to develop your own C-like language, rather then trying to >> change C itself. > > Hum - and all over the world people thought that C was the "portable > high-level assembler" and used it as a portable high-level > assembler. That's all I intend - what people are already doing. > > Is there some specific reason why you object to that description of > C? Just because many people believe that nonsense doesn't make it true. Many people (Rick Hodgins being the most recent and egregious example I can think of) have posted complaints here about not being able to convince their C compilers to generate exactly the sequence of machine language instructions they want it to. If C were, in fact, a "portable high-level assembler", those objections would be entirely justified. And if it were true, the C language would have to have a very different structure. It doesn't provide any mechanism for specifying requirements that tight. The C standard goes out of it's way to make it very clear what is and is not required of a conforming compiler when translating and executing any particular piece of C code - your key complaints have been about how much it fails to require. Simplifying slightly, almost the only thing actually required of a strictly conforming C program is that it produce a particular sequence of output; an implementation has a great deal of freedom in how it achieves that result. For code that is merely correct, and not strictly conforming, the requirements are even looser: the program might have different permitted outputs depending upon which choice the implementation made for each instance of unspecified behavior. Even for strictly conforming code, the required output can vary depending upon the locale, and how it varies with locale is, at best, implementation-defined. In particular, the glyphs that are so important to you are generally locale dependent, the C standard imposes no requirements on them of any kind - it only imposes requirements on the characters represented by those glyphs. In general, different glyphs will be displayed depending upon where the output from a C program is directed, and depending upon how the display device is currently configured, things which which are completely outside the scope of the C standard. As it currently stands, it's not uncommon, given even a small chunk of C code, for there to be, for example, 20 different ways to generate machine code for a given platform which meets all of the requirements imposed by the C standard on a that piece of C code. Not only does C give implementors complete freedom in choosing which of those 20 ways to choose, it provides, at best, only very limited means for developers to provide hints indicating which of the 20 ways they'd prefer (register, inline, restrict). This gives C implementors the freedom to optimize the code according to their own understanding of the target platform, freeing the developer from needing to have a corresponding understanding of it. That's what makes C portable - but it's also what makes it NOT an assembler. The corresponding disadvantage is that if the developer does have a strong understanding of a particular platform, and code that doesn't need to be portable to other platforms, the developer may get upset that C provides no way of forcing the implementation to generate the desired machine code. That's not the kind of language C is intended to be, and a developer who wants it to be that should instead be programming using an actual assembly language.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-26 19:25 -0700 |
| Message-ID | <fc6d3b41-071d-43a6-88e4-ecf0a95d86d6@googlegroups.com> |
| In reply to | #68457 |
On Wednesday, August 26, 2015 at 11:28:28 PM UTC+1, James Kuyper wrote: > On 08/26/2015 05:29 PM, David Kleinecke wrote: > > > Hum - and all over the world people thought that C was the "portable > > high-level assembler" and used it as a portable high-level > > assembler. That's all I intend - what people are already doing. > > > > Is there some specific reason why you object to that description of > > C? > > Just because many people believe that nonsense doesn't make it true. > Many people (Rick Hodgins being the most recent and egregious example I > can think of) have posted complaints here about not being able to > convince their C compilers to generate exactly the sequence of machine > language instructions they want it to. If C were, in fact, a "portable > high-level assembler", those objections would be entirely justified. And > if it were true, the C language would have to have a very different > structure. It doesn't provide any mechanism for specifying requirements > that tight. > In fact it does. There's an asm keyword. Some compilers also allow you to name variables, specify them "register", and force the named register to be the resister assigned to that variable. However it's inherently non-portable. There's no obvious way of demanding certain machine code instructions, whilst also being portable to CPUs without those instructions in the instruction set, without writing an emulator for the second CPU, which wouldn't be efficient. > > This gives C implementors the freedom to optimize the code according to > their own understanding of the target platform, freeing the developer > from needing to have a corresponding understanding of it. That's what > makes C portable - but it's also what makes it NOT an assembler. > Once upon a time i++ would generate "Increment i" and i += 1 would generate "load x register with one, add x register to i". Those days are long gone. However there's still a basic mapping from C constructs to assembler constructs. The careful programmer has a pretty good idea what code he'll generate. What really matters is the call interface. Now here, C is usually a portable assembler. The standard doesn't actually require it, but virtually every C compiler has a "calling convention" which allows you to link with modules written in assembler. Typically it's something like "first four parameters in registers, rest on stack" (Clever programmers are careful to pass fewer than four parameters in time critical code, for this reason). So you can write a module in assembler, and call a routine in C. You can then write it in C for clarity (Heathfield's law). Once it's right, you can replace all the C variables with assembler register names. You can take out the for loops and put in gotos. You can gradually bring it to a state where the C instructions match one for one the assembly instructions, all the time testing it against the clear version to make sure you haven't introduced a mistake. Then it goes into assembler itself, often simply wrapping with asm. So C is a portable assembler. That's the entire point and strength of the language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-27 10:07 +0200 |
| Message-ID | <mrmgct$mdl$1@dont-email.me> |
| In reply to | #68464 |
On 27/08/15 04:25, Malcolm McLean wrote: > On Wednesday, August 26, 2015 at 11:28:28 PM UTC+1, James Kuyper wrote: >> On 08/26/2015 05:29 PM, David Kleinecke wrote: >> >>> Hum - and all over the world people thought that C was the "portable >>> high-level assembler" and used it as a portable high-level >>> assembler. That's all I intend - what people are already doing. I don't think many C programmers think that way - but there are always some. >>> >>> Is there some specific reason why you object to that description of >>> C? The clearest reason must surely be that it is completely wrong. Next on the list would be that the phrase is oxymoronic (like "amusing ringtone", or "secure windows"). Assembly is nothing more nor less than a human-readable syntax for a target's machine code. By definition it is as low-level as one can get (being directly equivalent to the machine code) - "high level assembler" makes no sense. And also by definition, assembly is tightly matched with the target - "portable assembler" also makes no sense. C was never intended to be a "portable high-level assembler" - it was intended to be a low-level systems language. Some aspects of the language (the increment operator being a prime example) were picked with a view to being convenient and easy for an implementation to convert to fast assembly - but that does not make C a high-level assembler. There was a time, long ago, when C compilers were simple enough, and cpus were simple enough, that you could make a reasonable guess as to the code that would be generated for much of your C code. That time is long gone, as compilers have become far more powerful, the C language has gained features, processors have got more complex, and programs have grown in size and complexity. (It still applies to some extent with small embedded systems.) >> >> Just because many people believe that nonsense doesn't make it true. >> Many people (Rick Hodgins being the most recent and egregious example I >> can think of) have posted complaints here about not being able to >> convince their C compilers to generate exactly the sequence of machine >> language instructions they want it to. If C were, in fact, a "portable >> high-level assembler", those objections would be entirely justified. And >> if it were true, the C language would have to have a very different >> structure. It doesn't provide any mechanism for specifying requirements >> that tight. >> > In fact it does. There's an asm keyword. Some compilers also allow you > to name variables, specify them "register", and force the named > register to be the resister assigned to that variable. Yes, but that's all non-portable - it is highly dependent on the compiler and the target, and often involves compiler extensions. (And many people find that when using gcc's inline assembly, they still have trouble getting the expected assembly generation...). There is no doubt that such features can be useful at times, but it covers a tiny proportion of C code. > > However it's inherently non-portable. There's no obvious way of demanding > certain machine code instructions, whilst also being portable to CPUs > without those instructions in the instruction set, without writing > an emulator for the second CPU, which wouldn't be efficient. Exactly. >> >> This gives C implementors the freedom to optimize the code according to >> their own understanding of the target platform, freeing the developer >> from needing to have a corresponding understanding of it. That's what >> makes C portable - but it's also what makes it NOT an assembler. >> > Once upon a time i++ would generate "Increment i" and i += 1 would > generate "load x register with one, add x register to i". One some processors that is the case - on other processors, it would do something different. On some processors, the code would be "subtract 0xff from i directly in memory", as that is the simplest equivalent instruction. So while K&R worked with cpus that had such "increment" assembly codes, even these simple cases of direct C-to-assembly "translation" disappeared once C was ported to different targets. > Those days > are long gone. However there's still a basic mapping from C constructs > to assembler constructs. The careful programmer has a pretty good idea > what code he'll generate. There is certainly a rough connection - and if you want to generate particularly small and/or fast code, then it is useful to know the structure of your cpu and write C code in a manner that fits well. This is almost exclusively the realm of small embedded systems - if you know your cpu has no floating point hardware, or only single-precision hardware, then you avoid using doubles or floats. If it is an 8-bit or 16-bit cpu, you make sure you use small integer types when possible. If it has poor or limited pointer registers, then you limit your pointer usage. But even when I am working with small and limited processors, whose cpu and assembly I know well, and with compilers that I know well, it is a long time since I could reliably predict assembly sequences. It used to be possible, with simpler and more limited compilers, but not now. I can still have some idea of the type of code that will be generated, but not the details. > What really matters is the call interface. Now here, C is usually a > portable assembler. The standard doesn't actually require it, but > virtually every C compiler has a "calling convention" which allows > you to link with modules written in assembler. Typically it's > something like "first four parameters in registers, rest on stack" > (Clever programmers are careful to pass fewer than four parameters > in time critical code, for this reason). Details vary from compiler to compiler, and cpu to cpu. They can even vary across OS's on the same target, and some compilers support multiple calling conventions. Nothing is ever simple! (But I agree that if you are looking for optimal code, you might want to consider such details in the structure of your code - with the understanding that it might be sub-optimal on other targets or compilers.) > So you can write a module in assembler, and call a routine in C. > You can then write it in C for clarity (Heathfield's law). Once > it's right, you can replace all the C variables with assembler > register names. You can take out the for loops and put in gotos. > You can gradually bring it to a state where the C instructions > match one for one the assembly instructions, all the time testing > it against the clear version to make sure you haven't introduced > a mistake. Then it goes into assembler itself, often simply > wrapping with asm. All you will do with a process like that is produce something non-portable, hard to understand, unmaintainable, and almost certainly slower than the original C. Unless you are able to do something that is basically impossible in C, such as taking advantage of SIMD or other odd cpu hardware, you are very unlikely to beat the compiler by assembly, especially if you try to copy the original C code structure. > > So C is a portable assembler. That's the entire point and strength > of the language. > No, it is nothing like a portable assembler (and most of your post shows exactly that). And /that/ is the entire point and strength of the language - it is a portable low-level language that saves you from having to think or work in assembly.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-27 09:18 -0700 |
| Message-ID | <lnegiowvr3.fsf@kst-u.example.com> |
| In reply to | #68464 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, August 26, 2015 at 11:28:28 PM UTC+1, James Kuyper wrote:
>> On 08/26/2015 05:29 PM, David Kleinecke wrote:
>> > Hum - and all over the world people thought that C was the "portable
>> > high-level assembler" and used it as a portable high-level
>> > assembler. That's all I intend - what people are already doing.
>> >
>> > Is there some specific reason why you object to that description of
>> > C?
>>
>> Just because many people believe that nonsense doesn't make it true.
>> Many people (Rick Hodgins being the most recent and egregious example I
>> can think of) have posted complaints here about not being able to
>> convince their C compilers to generate exactly the sequence of machine
>> language instructions they want it to. If C were, in fact, a "portable
>> high-level assembler", those objections would be entirely justified. And
>> if it were true, the C language would have to have a very different
>> structure. It doesn't provide any mechanism for specifying requirements
>> that tight.
>>
> In fact it does. There's an asm keyword.
Not in standard C, though the standard does mention it as a common
extension.
> Some compilers also allow you
> to name variables, specify them "register", and force the named
> register to be the resister assigned to that variable.
Again, that's an extension, not part of C itself.
[...]
> Once upon a time i++ would generate "Increment i" and i += 1 would
> generate "load x register with one, add x register to i".
Do you have a citation for that? I wouldn't be surprised if that's
correct for some early C compilers, but I also wouldn't be surprised if
even the earliest compilers were able to generate the same code for
`i++` and `i += 1`.
> Those days
> are long gone. However there's still a basic mapping from C constructs
> to assembler constructs. The careful programmer has a pretty good idea
> what code he'll generate.
I consider myself a careful programmer, and 99% of the time I
have no clue what CPU instructions will be generated for the C
code I write. I don't always know which CPU it's going to run on.
On rare occasions I might need to examine an assembly listing to
track down a bug.
> What really matters is the call interface. Now here, C is usually a
> portable assembler. The standard doesn't actually require it, but
> virtually every C compiler has a "calling convention" which allows
> you to link with modules written in assembler. Typically it's
> something like "first four parameters in registers, rest on stack"
> (Clever programmers are careful to pass fewer than four parameters
> in time critical code, for this reason).
The existence of a common call interface used for C and assembly
language doesn't imply that C is some kind of assembly language, any
more than it implies that assembly language is really a dialect of C.
> So you can write a module in assembler, and call a routine in C.
> You can then write it in C for clarity (Heathfield's law). Once
> it's right, you can replace all the C variables with assembler
> register names. You can take out the for loops and put in gotos.
> You can gradually bring it to a state where the C instructions
> match one for one the assembly instructions, all the time testing
> it against the clear version to make sure you haven't introduced
> a mistake. Then it goes into assembler itself, often simply
> wrapping with asm.
>
> So C is a portable assembler. That's the entire point and strength
> of the language.
There is a very stark difference between an assembly language
and a non-assembly language. Assembly language programs specify
CPU instructions. C programs specify run-time behavior (with
a few extensions that let you exercise more control in limited
circumstances).
Certainly C is lower level than some other languages. C is
semantically closer to assembly language than, say, Python is.
But C and Python share the important characteristic that source
code specifies behavior.
I can imagine an actual "portable assembly language", in which you
could write code that would specify instruction sequences while still
being usable on multiple target systems. It would be difficult to
specify the mapping, and the result would not look much like C.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-27 18:04 +0000 |
| Message-ID | <mrnjen$fva$1@speranza.aioe.org> |
| In reply to | #68493 |
Keith Thompson <kst-u@mib.org> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: (snip) >> Those days >> are long gone. However there's still a basic mapping from C constructs >> to assembler constructs. The careful programmer has a pretty good idea >> what code he'll generate. > I consider myself a careful programmer, and 99% of the time I > have no clue what CPU instructions will be generated for the C > code I write. I don't always know which CPU it's going to run on. > On rare occasions I might need to examine an assembly listing to > track down a bug. OK, but one can usually rely on C compilers to generate code approximately proportional to the size of the C code. That is not true for most other high-level languages. There are some that one can hope for, but never really know. One that I have wondered is which compilers recognize a / and % usign the same operands, and do one divide instruction that returns both quotient and remainder. (As hardware often does.) (snip on call interface) (snip on calling assembler code) >> So C is a portable assembler. That's the entire point and strength >> of the language. > There is a very stark difference between an assembly language > and a non-assembly language. Assembly language programs specify > CPU instructions. C programs specify run-time behavior (with > a few extensions that let you exercise more control in limited > circumstances). C is low enough that many tasks that previously required assembler can now be done in C. > Certainly C is lower level than some other languages. C is > semantically closer to assembly language than, say, Python is. > But C and Python share the important characteristic that source > code specifies behavior. But even more, many C operands correspond to operations on the usual processors. As one example, Fortran has the ISHFT function to perform bit shifting, which shifts left for a positive shift amount, right for a negative amount. Sometimes convenient, but not directly supported by most processors. ISHFT also allows the shift amount to equal the bit width of the operand, again requiring extra tests. So, yes, C isn't an assembler, but often enough it doesn't promiss more than the hardware provides. > I can imagine an actual "portable assembly language", in which you > could write code that would specify instruction sequences while still > being usable on multiple target systems. It would be difficult to > specify the mapping, and the result would not look much like C. For another view, consider PL/360. PL/360 is a high-level (looking) language that directly maps to S/360 instructions. This becomes obvious in some example cases: R1 := R1+R1+R1; quadruples the value in R1 (register 1). Specifically: LR R1,R1 AR R1,R1 AR R1,R1 changes to registers take effect immediately, unlike changes to C variables. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-27 11:15 -0700 |
| Message-ID | <755c899c-c2aa-4af8-b41e-c1523ea6a983@googlegroups.com> |
| In reply to | #68501 |
On Thursday, August 27, 2015 at 7:04:22 PM UTC+1, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: > > > Certainly C is lower level than some other languages. C is > > semantically closer to assembly language than, say, Python is. > > But C and Python share the important characteristic that source > > code specifies behavior. > > But even more, many C operands correspond to operations on > the usual processors. > > As one example, Fortran has the ISHFT function to perform bit > shifting, which shifts left for a positive shift amount, right > for a negative amount. Sometimes convenient, but not directly > supported by most processors. ISHFT also allows the shift amount > to equal the bit width of the operand, again requiring extra tests. > Yes. Shifting left or right by a negative, or more than the width of type, is undefined in C. It would be easy enough to define a behaviour, and in fact the UB is a bit of a nuisance sometimes. But the reason is obvious. A shift equals a "rotate register" assembly instruction. On virtually every processor, of course you can't cater for every conceivable processor.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-27 21:10 +0000 |
| Message-ID | <mrnubn$bmg$1@speranza.aioe.org> |
| In reply to | #68503 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip regarding C and portable assemblers) (then I wrote) >> But even more, many C operands correspond to operations on >> the usual processors. >> As one example, Fortran has the ISHFT function to perform bit >> shifting, which shifts left for a positive shift amount, right >> for a negative amount. Sometimes convenient, but not directly >> supported by most processors. ISHFT also allows the shift amount >> to equal the bit width of the operand, again requiring extra tests. > Yes. Shifting left or right by a negative, or more than the width of type, > is undefined in C. It would be easy enough to define a behaviour, and in > fact the UB is a bit of a nuisance sometimes. But the reason is obvious. > A shift equals a "rotate register" assembly instruction. On virtually every > processor, of course you can't cater for every conceivable processor. Most processors now have a multiple bit shift instruction, and rarely rotate. Most have a restriction on the number of bits shifted, with modulo bit width being a common case. Some smaller processors have one bit shift and rotate instructions. Rotate through carry allows one to shift between registers through a series of such rotate instructions. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-27 15:54 -0700 |
| Message-ID | <lntwrkuyuj.fsf@kst-u.example.com> |
| In reply to | #68501 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
>>> So C is a portable assembler. That's the entire point and strength
>>> of the language.
>
>> There is a very stark difference between an assembly language
>> and a non-assembly language. Assembly language programs specify
>> CPU instructions. C programs specify run-time behavior (with
>> a few extensions that let you exercise more control in limited
>> circumstances).
>
> C is low enough that many tasks that previously required
> assembler can now be done in C.
True. In other words, many tasks that previously required an
assembler can now be done using something that is *not* an assembler.
Cars replaced horses; that doesn't mean it's reasonable to say that
cars *are* horses. (Yes, I'm oversimplifying.)
>> Certainly C is lower level than some other languages. C is
>> semantically closer to assembly language than, say, Python is.
>> But C and Python share the important characteristic that source
>> code specifies behavior.
>
> But even more, many C operands correspond to operations on
> the usual processors.
C requires floating-point even on systems that don't have hardware
support. A simple "+" operator might compile to a function call.
Likewise for 64-bit integers (since C99). Likewise for complex
numbers and struct assignment.
Yes, C is designed to make it possible to generate efficient code. Most
built-in operations are designed to map to relatively simple machine
code (with some notable exceptions). But C is *not* designed to
generate code for any specific processor.
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-28 09:28 +0200 |
| Message-ID | <mrp2et$be3$1@dont-email.me> |
| In reply to | #68501 |
On 27/08/15 20:04, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > (snip) > >>> Those days >>> are long gone. However there's still a basic mapping from C constructs >>> to assembler constructs. The careful programmer has a pretty good idea >>> what code he'll generate. > >> I consider myself a careful programmer, and 99% of the time I >> have no clue what CPU instructions will be generated for the C >> code I write. I don't always know which CPU it's going to run on. >> On rare occasions I might need to examine an assembly listing to >> track down a bug. > > OK, but one can usually rely on C compilers to generate code > approximately proportional to the size of the C code. That is > not true for most other high-level languages. Certainly with C (at least in your own code - it's harder once you call a library function) one usually has an idea of what you will get in terms of speed and size (even though, as Keith says, you might have no idea of the details of the instructions generated). But there is a huge gap between having a good idea of the sort of size, speed and structures that will be generated, and being a "portable assembler". To be anything remotely like an assembler, you have to have an almost perfect prediction about exactly what instructions will be generated - perhaps allowing for flexibility of register choices. C is nowhere near that, and never has been. > > There are some that one can hope for, but never really know. > > One that I have wondered is which compilers recognize a / and % > usign the same operands, and do one divide instruction that returns > both quotient and remainder. (As hardware often does.) Personally, I am glad that my compiler recognizes such symbols and if possible turns them into something completely different (such as shifts and masks if possible, or multiplication of the reciprocal if it can). It's just an optimisation - a good compiler will do it well, a poor compiler (or one with optimisations disabled or limited) will do it badly. > > (snip on call interface) > > (snip on calling assembler code) > >>> So C is a portable assembler. That's the entire point and strength >>> of the language. > >> There is a very stark difference between an assembly language >> and a non-assembly language. Assembly language programs specify >> CPU instructions. C programs specify run-time behavior (with >> a few extensions that let you exercise more control in limited >> circumstances). > > C is low enough that many tasks that previously required > assembler can now be done in C. Now /that/ is undoubtedly true. But that does not mean, in any way, that C is a "portable assembler". When someone writes a simple mail client in assembler (I've seen it done - madness!) which could be written in 10,000 lines of C or 100 lines of Python, you do not call assembler a "low-level Python" or "target-dependent C". > >> Certainly C is lower level than some other languages. C is >> semantically closer to assembly language than, say, Python is. >> But C and Python share the important characteristic that source >> code specifies behavior. > > But even more, many C operands correspond to operations on > the usual processors. Many of the choices about the behaviour of C features were made with a view to easy and efficient implementation on real systems. The undefined behaviour of C's shift operators outside the range 0 to 31 (or whatever, depending on the size of the other operand) are based on that principle. But while that was done to allow more code that previously was the domain of assembly to now be written in C, it again does not make C an assembler. > > As one example, Fortran has the ISHFT function to perform bit > shifting, which shifts left for a positive shift amount, right > for a negative amount. Sometimes convenient, but not directly > supported by most processors. ISHFT also allows the shift amount > to equal the bit width of the operand, again requiring extra tests. > > So, yes, C isn't an assembler, but often enough it doesn't promiss > more than the hardware provides. In my experience (mostly smaller systems), C provides a great deal more than the hardware. When I work on an 8-bit cpu, I can write code for shifting a 32-bit integer by multiple steps - knowing the compiler will build the loops and library calls needed to make it work. C is not different in principle from any other programming language. All you are saying is that it is a fairly low-level language, which is true. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-08-27 13:12 -0600 |
| Message-ID | <1b4mjkzgso.fsf@pfeifferfamily.net> |
| In reply to | #68493 |
Keith Thompson <kst-u@mib.org> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> Some compilers also allow you
>> to name variables, specify them "register", and force the named
>> register to be the resister assigned to that variable.
>
> Again, that's an extension, not part of C itself.
Well, the "register" keyword itself is part of C, and its intent is
described as
A declaration of an identifier for an object with storage-class
specifier register suggests that access to the object be as fast as
possible. The extent to which such suggestions are effective is
implementation-defined.101)
Actually forcing as many as possible to physical registers would be an
implementation's definition.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-28 09:35 +0200 |
| Message-ID | <mrp2t0$ct9$1@dont-email.me> |
| In reply to | #68504 |
On 27/08/15 21:12, Joe Pfeiffer wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> Some compilers also allow you >>> to name variables, specify them "register", and force the named >>> register to be the resister assigned to that variable. >> >> Again, that's an extension, not part of C itself. > > Well, the "register" keyword itself is part of C, and its intent is > described as > > A declaration of an identifier for an object with storage-class > specifier register suggests that access to the object be as fast as > possible. The extent to which such suggestions are effective is > implementation-defined.101) > > Actually forcing as many as possible to physical registers would be an > implementation's definition. > The "register" keyword has never been anything more than a hint to the compiler (and a restriction that you cannot take the address of the variable). Most compilers ignore it, except for the restriction on taking its address. (For example, gcc ignores it unless optimisations are disabled.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-25 04:28 -0700 |
| Message-ID | <348df68d-e0e1-4870-9eae-0558ea41a03d@googlegroups.com> |
| In reply to | #68282 |
On Tuesday, August 25, 2015 at 1:54:23 AM UTC+1, Keith Thompson wrote: > > You can certainly define a data structure representing a glyph or a > collection of glyphs and manipulate it in C. If I understand you > correctly, you might look into how fonts are represented (there are > several standards, and I'm not familiar with any of them). Rendering > those glyphs on an output device is another matter. That's beyond the > scope of the C standard -- but of course that doesn't mean you can't do > it in C. > The emerging standard is TTF (true type fonts). Essentially a true type glyph consists of a unicode character id, a series of quadratic Beziers defining the outline, and "hints" which tell the renderer how to place pixels when the font gets small. Virtually no font will have glyphs for more than a small subset of Unicode, and there's an "unknown" glyph which should consist of an empty rectangle. So it's easy enough to convert your character from whatever representation you're using to Unicode, and look it up. But then the problems start. Considering only Latin-like alphabets, converting from Bezier form to a fill is a medium-difficulty task, getting a nicely anti-aliased fill and supporting the hints is high difficulty. Fortunately freetype does most of the work for you. But with non-Latin like languages the text might be cursive, it might be right-left or up down, it might have various dots and squiggles not represented as the character. Supporting a large range of languages is a big task.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-24 00:19 -0400 |
| Message-ID | <mre5u4$6h7$1@dont-email.me> |
| In reply to | #68178 |
On 08/23/2015 10:17 PM, David Kleinecke wrote: > On Saturday, August 22, 2015 at 8:22:29 PM UTC-7, James Kuyper wrote: ... >> There are two character sets that a C program can know about - the basic >> execution character set and the extended execution character set. Both >> can be encoded in char arrays. The latter may require multi-byte >> encoding. C standard library provide routines for dealing with such >> encodings. >> In 1994, wchar_t was added, in 2011, char16_t and char32_t were added. >> Any complaints you have about the lack of character support in C90 >> should be re-evaluated in light of the changes that were made to >> character support in later versions. ... > Come on - you know I have no use for any standard more recent than > C90 and not much use for the standard library. Yes, and I was implicitly pointing one of the many ridiculous consequences of that stance. > wchar_t is in the C90 standard. I apologize - you're correct. But while wchar_t was present in C90, it was only a very primitive concept. Meaningful support for wide characters was not added until Amendment I, which created C95. > I would like to see how to do decent glyph manipulation and stay within > C90 standard. I think it can be done but I don't see my way clear yet. The C standard only talks about characters, it cares nothing about glyphs. You should be able to do whatever you want to do about glyphs without worrying in the least about what the C standard says about anything else. > C knows about other character stes. The first thing that happens > (5.1.1.2) is "Physical source file characters are mapped to the source > character set ... " You were talking specifically about the a C program. The only character sets a C program can work with are the execution character sets. The source character sets are what the program itself is written in - which might be the same as or entirely different from the execution character sets. The C implementation is what has to deal with the source character sets. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-24 00:31 -0700 |
| Message-ID | <e2fa0cf3-8c54-45e4-97c2-fef2cf504e26@googlegroups.com> |
| In reply to | #68178 |
On Monday, August 24, 2015 at 3:17:38 AM UTC+1, David Kleinecke wrote: > On Saturday, August 22, 2015 at 8:22:29 PM UTC-7, James Kuyper wrote: > > > There are two character sets that a C program can know about - the basic > > execution character set and the extended execution character set. Both > > can be encoded in char arrays. The latter may require multi-byte > > encoding. C standard library provide routines for dealing with such > > encodings. > > In 1994, wchar_t was added, in 2011, char16_t and char32_t were added. > > Any complaints you have about the lack of character support in C90 > > should be re-evaluated in light of the changes that were made to > > character support in later versions. > > -- > > James Kuyper > > Come on - you know I have no use for any standard more recent than > C90 and not much use for the standard library. > > wchar_t is in the C90 standard. > > I would like to see how to do decent glyph manipulation and stay within > C90 standard. I think it can be done but I don't see my way clear yet. > > C knows about other character stes. The first thing that happens > (5.1.1.2) is "Physical source file characters are mapped to the source > character set ... " > Pass strings about as UTF-8. Call them char * for clarity, and have a low-level utf interface layer that casts to unsigned char * to get the high bits and do the UTF-8 to index calculations. When you need a glyph rather than a string, call ut8toindex() or whatever your low-level conversion routine is called. If you need belt and braces, the index can be a long, although it would be an unusual machine capable of handling glyphs above the size of its own int. That gives you a Unicode value. You might want to pass about arrays of them in scratch code, but don't in your public interfaces, to keep them clean. This system will work with any dialect of C, it's also very easy to mix and match with unicode-naive code - if they pass you ascii, that's a subset of UTF8. If you pass them UTF8, as long as they don't need glyphs, string copying and comparisons will work fine. The nuisance is embedding non-Latin characters in C code. But a real answer is very difficult. You can provide a few characters using an encoding of some type, but if you're writing a hieroglyphics heavy program, you'll need to be able to read the hieroglyphics. Which means having an editor which displays them, and there's no standard for that.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-24 17:06 -0700 |
| Message-ID | <f0cf8970-2c55-4d0b-ab32-7225afd5dfed@googlegroups.com> |
| In reply to | #68199 |
On Monday, August 24, 2015 at 12:31:58 AM UTC-7, Malcolm McLean wrote: > On Monday, August 24, 2015 at 3:17:38 AM UTC+1, David Kleinecke wrote: > > On Saturday, August 22, 2015 at 8:22:29 PM UTC-7, James Kuyper wrote: > > > > > There are two character sets that a C program can know about - the basic > > > execution character set and the extended execution character set. Both > > > can be encoded in char arrays. The latter may require multi-byte > > > encoding. C standard library provide routines for dealing with such > > > encodings. > > > In 1994, wchar_t was added, in 2011, char16_t and char32_t were added. > > > Any complaints you have about the lack of character support in C90 > > > should be re-evaluated in light of the changes that were made to > > > character support in later versions. > > > -- > > > James Kuyper > > > > Come on - you know I have no use for any standard more recent than > > C90 and not much use for the standard library. > > > > wchar_t is in the C90 standard. > > > > I would like to see how to do decent glyph manipulation and stay within > > C90 standard. I think it can be done but I don't see my way clear yet. > > > > C knows about other character stes. The first thing that happens > > (5.1.1.2) is "Physical source file characters are mapped to the source > > character set ... " > > > Pass strings about as UTF-8. Call them char * for clarity, and have a > low-level utf interface layer that casts to unsigned char * to get the > high bits and do the UTF-8 to index calculations. > > When you need a glyph rather than a string, call ut8toindex() or whatever > your low-level conversion routine is called. If you need belt and braces, > the index can be a long, although it would be an unusual machine capable > of handling glyphs above the size of its own int. That gives you a > Unicode value. You might want to pass about arrays of them in scratch > code, but don't in your public interfaces, to keep them clean. > > This system will work with any dialect of C, it's also very easy to > mix and match with unicode-naive code - if they pass you ascii, that's > a subset of UTF8. If you pass them UTF8, as long as they don't need glyphs, > string copying and comparisons will work fine. > > The nuisance is embedding non-Latin characters in C code. But a real > answer is very difficult. You can provide a few characters using an > encoding of some type, but if you're writing a hieroglyphics heavy > program, you'll need to be able to read the hieroglyphics. Which > means having an editor which displays them, and there's no standard > for that. It's even worse when the text quotes several different scripts. A work on the ancient Near East might need Arabic, Hebrew, Aramaic, Greek Coptic and Geez all mixed up together. With the new Unicode extensions hieroglyphs and cuneiform might be demanded. Not to mention the sheer chauvinism of thinking nothing but English exists.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:25 +0000 |
| Message-ID | <55d885d3.20409718@news.xs4all.nl> |
| In reply to | #67970 |
David Kleinecke <dkleinecke@gmail.com> wrote:
> On Friday, August 21, 2015 at 1:39:57 PM UTC-7, Richard Bos wrote:
> > David Kleinecke <dkleinecke@gmail.com> wrote:
> > > On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote:
> >
> > > > The word "alphabet" is perhaps not the best choice for what you're
> > > > trying to say. The word often refers to just letters; see for example,
> > > > the isalpha() function.
> > >
> > > Alphabet is the usual word for whatever character ste a text is using.
> >
> > '.' and '(' are in your alphabet?
>
> Be careful here "text" includes a lot of things like Chinese writing
> and Sumerian and Egyptian (see Unicode - they may even include the
> figures on an Easter Island taking biard by now).
All the more reason _not_ to call it an "alphabet", but to read the
Standard for a chance and, in discussions on C, use the term it defines
for this purpose.
> My question was - is there a generally agree-upon name for these 92
> glyphs (incuding the blank glyph)?
Yes, but you've already rejected it because it is from the C Standard
and therefore eeeeevil: printable characters.
Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-22 10:45 -0400 |
| Message-ID | <mra1qo$vm2$1@dont-email.me> |
| In reply to | #67970 |
On 08/21/2015 08:17 PM, David Kleinecke wrote: ... > The crucial attribute of a text is that it is a sequence of glyphs - > written in a book, carved on a rock, you name it). If presented with > a text I haven't seen before I count the different glyphs (not always > easy). The set of all different glyphs is the alphabet of the text. > The alphabet the C standard is thinking of contains the 91 glyphs > listed in 5.2.1 plus the space character. These 92 glyphs are encoded > as byte values in a way the standard leaves us to guess is what is > called the ANSII character set. The standard adds some byte values that > that are encoded by glyph pairs. > > My question was - is there a generally agree-upon name for these 92 > glyphs (incuding the blank glyph)? By the way, those 92 characters correspond to 92,092 glyphs on my desktop system (I've got 1001 different fonts installed, so each glyph has 1000 allographs). That number might give you a hint about why the standard talks primarily about the characters, rather than concentrating on the corresponding glyphs the way that you do. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-21 17:40 -0400 |
| Message-ID | <55D79AE8.60008@verizon.net> |
| In reply to | #67918 |
On 08/20/2015 07:52 PM, David Kleinecke wrote: > On Wednesday, August 19, 2015 at 5:13:07 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >>> On Tuesday, August 18, 2015 at 7:14:06 PM UTC-7, Keith Thompson wrote: >>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>>> On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote: >>>>>> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote: >>>>>>> Alternativly I could some other non-ASCII character (CTRL-Z, for example >>>>>>> for soft EOL. >>>>>> >>>>>> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)). >>>>> >>>>> As elsewhere - a bag of tells. What's your name for the letters we >>>>> actually use (hint: not printable)? ... >>> I was thinking in terms of a text. A text is written in an alphabet. The >>> alphabets I am contemplating use some of the 256 different bytes. The >>> most familiar one in the C alphabet which would be the 5.2.1 or perhaps >>> also the 5.2.2 set. I don't care. I don't mcuh care which character is >>> used for which purpose so long as the map one-to-one. On implementations which support ASCII (which is not required by the C standard), SUB would have to be supported as an extended character, as described in 5.2.1p1, because it doesn't match any of the characters in the basic character set described in 5.2.1p3. The extended character set includes both the basic character set and the extended characters. The standard says a number of important things about the basic character set, that it doesn't say about the extended character set, but for most purposes in a C context, it's the extended character set that's relevant, and its that character set which I would have to identify with your term "the C alphabet". >> The word "alphabet" is perhaps not the best choice for what you're >> trying to say. The word often refers to just letters; see for example, >> the isalpha() function. > > Alphabet is the usual word for whatever character ste a text is using. That meaning listed as the third definition at <https://en.wiktionary.org/wiki/alphabet>. It's an obscure usage; in my experience meanings 1 and 2 are overwhelming the most common, but meaning 3 is a reasonable one in a CS context. SUB is in the ASCII character set, so it if you wish to use "alphabet" in that sense, SUB is in the alphabet on any system that supports ASCII. Cntl-Z is a key sequence, not a character, but in the appropriate contexts, it's a key sequence that can be used to generate that character. So, with that context in mind, what is the significance of your obscure comment which appears as the third paragraph of quoted text above? I'd normally guess that "bag of tells" was either a misspelling of "bagatelle", or a punning phrase meant to invoke that term - except that I can't figure out why you would be using that term in this context. Alternatively, the 2nd and 3rd noun meanings for "tell" listed at <https://en.wiktionary.org/wiki/tell> refer to things that, if stored in physical form such as printed text or a computer disk, could in fact be put in a bag, but I can't figure out what that could have to do with anything in this context, either.
[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