Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #397525 > unrolled thread
| Started by | wij <wyniijj5@gmail.com> |
|---|---|
| First post | 2026-04-14 22:47 +0800 |
| Last post | 2026-04-18 11:33 +0200 |
| Articles | 20 on this page of 365 — 21 participants |
Back to article view | Back to comp.lang.c
A thought of C wij <wyniijj5@gmail.com> - 2026-04-14 22:47 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-14 18:45 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 02:41 +0800
Re: A thought of C Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-14 15:56 -0400
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-14 22:41 +0100
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-15 00:20 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 00:33 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 09:57 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:43 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:10 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:12 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:12 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:20 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-16 06:28 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-16 14:03 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-16 22:13 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-16 14:33 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-16 20:26 -0400
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-17 12:27 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-17 14:37 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-17 16:37 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-17 15:54 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-17 14:49 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-17 16:45 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-17 17:42 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 10:22 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-18 03:41 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-18 15:37 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-18 16:08 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 17:35 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 13:44 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-19 16:06 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 17:35 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-18 18:29 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 12:17 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 12:50 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 14:17 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 15:28 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 17:47 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 18:47 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-19 21:32 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 00:36 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 08:25 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 12:45 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 15:02 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 15:32 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 18:04 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 10:50 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 20:50 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 14:30 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 23:09 +0100
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 05:01 +0200
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 04:53 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 10:48 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 21:13 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-20 20:27 +0000
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 15:04 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 09:00 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 14:59 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 23:36 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 18:22 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 11:01 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 13:44 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 13:48 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 15:43 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 16:01 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 18:03 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 09:19 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 18:51 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 13:16 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 01:01 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 19:53 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 09:40 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 13:01 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 14:23 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 00:52 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 19:26 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 11:30 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 13:12 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 15:12 +0300
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:18 +0000
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 17:35 +0300
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 10:32 -0400
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 17:45 +0300
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 13:43 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 16:40 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 17:42 +0100
Re: A thought of C DFS <nospam@dfs.com> - 2026-04-25 10:38 -0400
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:16 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 13:50 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 04:43 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 13:33 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:22 +0000
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 17:39 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:02 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 14:40 +0200
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:17 +0000
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-23 19:42 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 22:04 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-23 23:15 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-24 01:06 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:57 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-24 08:27 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 01:33 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-24 11:27 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-24 13:11 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-24 14:55 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-24 14:05 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-24 17:26 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 10:09 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 10:14 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-23 16:10 +0200
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 08:25 +0200
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-23 17:41 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 20:19 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-25 23:04 +0000
time measurements (Re: A thought of C) Michael S <already5chosen@yahoo.com> - 2026-04-26 12:34 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 09:03 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 08:58 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 12:40 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 22:56 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 15:07 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:28 +0200
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:13 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-21 11:51 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 22:13 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-22 14:28 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-22 14:29 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 09:22 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 02:03 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 02:07 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 11:30 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 14:06 -0700
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-21 00:39 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 02:34 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-21 23:41 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 12:49 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:01 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 12:12 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 13:57 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-21 15:55 +0300
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 14:49 +0100
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-21 18:44 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 18:06 +0200
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:24 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 13:02 +0300
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 08:07 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:12 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 12:48 +0300
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 04:36 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 20:13 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 15:14 +0100
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 17:56 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 17:12 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 18:21 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 17:57 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 19:16 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 21:42 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 14:33 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 00:22 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 18:59 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-23 11:07 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 09:47 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-22 23:16 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 10:58 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 03:43 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 12:48 +0200
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 10:42 -0400
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 16:30 +0100
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 09:21 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 17:27 +0100
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 14:19 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:25 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 21:17 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 14:08 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-23 23:18 +0100
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 01:31 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 17:51 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:19 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-23 21:34 -0400
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 04:26 +0200
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-24 20:26 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:21 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:21 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:20 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:23 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 18:27 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 18:57 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:26 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 23:03 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 23:50 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-25 12:04 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-25 12:00 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-25 21:24 +0100
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 13:52 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-25 22:27 +0100
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-26 00:48 +0300
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:49 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-26 02:24 +0300
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-25 20:07 -0400
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 17:14 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 04:34 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-25 18:08 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 17:20 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 01:47 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 18:40 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 19:58 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:39 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 00:53 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 18:27 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 02:41 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 19:03 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 19:08 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 05:04 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 12:32 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-26 15:13 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-26 16:27 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-26 17:19 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-26 15:34 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 19:30 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-26 12:14 +0100
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-26 15:23 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-26 20:02 -0400
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 04:24 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 20:05 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 05:16 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 21:26 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 17:51 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:31 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-25 20:19 -0400
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-25 18:11 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 18:34 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-26 20:58 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 18:44 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:24 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-24 23:01 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 23:49 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:26 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 09:42 +0200
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-20 13:49 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 18:34 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-20 22:57 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 23:03 +0100
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 10:53 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-21 02:56 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-21 14:10 +0200
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:04 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 08:28 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 11:31 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 14:27 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 15:38 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 15:38 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-21 17:55 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 17:28 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 11:13 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-21 19:11 +0300
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-21 21:09 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-22 15:16 +0100
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-22 15:13 +0000
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 18:26 +0300
Re: A thought of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-04-22 16:09 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 08:18 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-23 01:56 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 02:29 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 18:18 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 03:57 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 19:11 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 09:14 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-22 17:27 +0200
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-22 18:52 +0300
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-22 20:39 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-23 13:15 +0300
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-23 12:50 +0200
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 08:46 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 02:40 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 18:31 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-22 20:37 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 02:37 -0700
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 06:46 -0700
Re: A thought of C Michael S <already5chosen@yahoo.com> - 2026-04-19 16:54 +0300
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-19 16:02 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-20 00:49 +0000
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-20 17:17 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-26 22:57 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 02:55 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-27 02:06 +0100
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-29 02:00 +0100
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-29 04:31 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-19 15:36 +0200
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-17 10:25 -0700
Re: A thought of C James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-17 16:30 -0400
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 12:20 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 11:21 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 19:52 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 14:24 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 00:40 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-14 15:31 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 12:15 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-14 21:46 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 14:05 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 10:24 +0200
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 11:46 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 20:21 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-15 20:26 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 15:38 +0200
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 00:58 +0800
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-15 22:11 +0200
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 05:38 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:48 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:31 -0700
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:13 +0200
Re: A thought of C antispam@fricas.org (Waldek Hebisch) - 2026-04-16 04:43 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:23 +0200
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 14:38 +0000
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 17:05 +0200
Re: A thought of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-04-16 15:11 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 17:43 +0200
Re: A thought of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-04-16 16:23 +0000
Re: A thought of C cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-16 19:48 +0000
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 19:04 +0000
Re: A thought of C scott@slp53.sl.home (Scott Lurndal) - 2026-04-16 19:01 +0000
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:34 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:29 -0700
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 15:06 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 05:12 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-15 23:52 +0100
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 07:30 +0800
Re: A thought of C Bart <bc@freeuk.com> - 2026-04-16 00:50 +0100
Re: A thought of C Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-15 20:17 -0400
Re: A thought of C David Brown <david.brown@hesbynett.no> - 2026-04-16 09:35 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:37 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:40 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:47 -0700
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 13:19 +0200
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-16 14:28 -0700
Re: A thought of C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 23:34 -0700
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 15:12 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 07:22 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 16:52 -0700
[meta] signature quote (was Re: A thought of C) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 03:13 +0200
Re: A thought of C 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-15 07:00 +0200
Re: A thought of C makendo <makendo@makendo.invalid> - 2026-04-15 21:40 +0800
Re: A thought of C Jonathan Lamothe <jonathan@jlamothe.net> - 2026-04-15 10:51 -0400
Re: A thought of C makendo <makendo@makendo.invalid> - 2026-04-16 12:44 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 01:11 +0800
Re: A thought of C 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-15 20:23 +0200
Re: A thought of C "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-15 21:01 +0100
Re: A thought of C 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-15 22:40 +0200
Re: A thought of C "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-16 11:38 +0100
Re: A thought of C "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-30 11:31 +0100
Re: A thought of C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-19 07:41 +0000
Re: A thought of C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-15 17:14 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 09:27 +0800
Re: A thought of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-15 19:04 -0700
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 18:42 +0800
Re: A thought of C gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-16 13:10 +0000
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 22:21 +0800
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 17:03 +0200
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-16 22:14 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-18 22:17 +0800
Re: A thought of C wij <wyniijj5@gmail.com> - 2026-04-21 06:29 +0800
Re: A thought of C Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-24 02:27 +0000
Re: A thought of C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-16 04:05 +0200
Re: A thought of C cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-16 11:24 +0000
Re: A thought of C Rosario19 <Ros@invalid.invalid> - 2026-04-18 11:33 +0200
Page 16 of 19 — ← Prev page 1 … 14 15 [16] 17 18 19 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-15 10:24 +0200 |
| Message-ID | <10rni04$mk8l$2@dont-email.me> |
| In reply to | #397538 |
On 15/04/2026 08:05, wij wrote:
> On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:
>> wij <wyniijj5@gmail.com> writes:
>>> On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:
>>>> wij <wyniijj5@gmail.com> writes:
>>>>> In attempting writting a simple language, I had a thought of what language is
>>>>> to share. Because I saw many people are stuck in thinking C/C++ (or other
>>>>> high level language) can be so abstract, unlimited 'high level' to mysteriously
>>>>> solve various human description of idea.
>>>>>
>>>>> C and assembly are essentially the same, maybe better call it 'portable assembly'.
>>>>
>>>> No, C is not any kind of assembly. Assembly language and C are
>>>> fundamentally different.
>>>>
>>>> An assembly language program specifies a sequence of CPU instructions.
>>>
>>> [Repeat] 'Assembly' can also be like C:
>>> // This is 'assembly'
>>> def int=32bit; // Choose right bits for your platform, or leave it for
>>> def char= 8bit; // compiler to decide.
>>
>> Compiler? You said this was assembly.
>>
>>> int a;
>>> char b;
>>> a=b; // allow auto promotion
>>>
>>> while(a<b) {
>>> a+=1;
>>> }
>>
>> You've claimed that that's assembly language. What assembler?
>> For what CPU?
>>
>> Is it even for a real assembler?
>
> I think you realize the example above is just an example to demo my idea.
In other words, it is imaginary. Hitchen's razor - "What can be
asserted without evidence can also be dismissed without evidence". All
you have shown is that your understanding of what "assembly language"
really is, is questionable.
>
>>> Yes, the C-like example above specifies exactly a sequence of CPU instructions
>>> (well, small deviation is allowed, and assembly can also have function, macro)
>>>
>>>> A C program specifies run-time behavior. (A compiler generates CPU
>>>> instructions behind the scenes to implement that behavior.)
>>>
>>> Being 'portable', it should specify 'run-time behavior', no exact instructions.
>>
>> Yes, that's what I said. And that's the fundamental difference between
>> assembly and C.
>
> How/what do you specify 'run-time behavior'? Not based on CPU?
Correct.
From the C standard:
"The semantic descriptions in this International Standard describe the
behaviour of an abstract machine"
Some aspects of C are given as "implementation-defined behaviour", and
the choice of the details of the behaviour will come primarily from the
target processor and/or OS (if any), within the range allowed in the C
standard.
>
> E.g. in C, int types are fixed-size, have range, wrap-around, alignment
> and 'atomic','overlapping' properties, you cannot really understand or hide it and
> program C/C++ correctly from the high-level concept of 'integer'.
Signed integer types in C do not have wrapping behaviour on overflow -
arithmetic overflow is undefined behaviour. Unsigned integer types have
modulo behaviour, and thus do not overflow.
And yes, you absolutely /can/ program in C and C++ with a high-level
concept of "integer". Pick integer types that are big enough for the
task in hand, and use them without concern for size, alignment, overflow
behaviour (because you are not overflowing them), or other behaviours.
If you need atomic access, use atomic types. Occasionally your code
needs to be so low-level, or you are so concerned about maximal
efficiency, that it is helpful to know the details. Usually, however,
you can concentrate on writing correct code. If you have used an
appropriate type, it will be as efficient as practical.
Understanding the underlying hardware can certainly help you write more
efficient code, or at least avoid some inefficiencies. But you don't
need more than a rough idea for most kinds of C and C++ programming.
>
> The point is that C has NO WAY get rid of these (hard-ware) features, no matter
> how high-level one thinks C is or expect C would be.
A great many real-world programming languages have limitations or
features that exist because of real-world hardware. They often have
some kind of "integer" type that is implemented as 32-bit or 64-bit,
because that efficiently matches hardware. (For example, Haskell is
undoubtedly a high-level language by any standards - it's "Int" type is
typically 64-bits (though only guaranteed to hold a range of 30 bits)
and is used far more often than unlimited range "Integer".)
C has more "implementation-defined" behaviours than many high-level
languages. It can be considered as a relatively low-level high-level
language. But the language's definition is primarily in terms of an
abstract machine and behavioural semantics, not in terms of hardware or
implementation, and thus it is a high-level language and not in any
sense an assembler language.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-15 11:46 +0100 |
| Message-ID | <10rnq9g$qgv9$2@dont-email.me> |
| In reply to | #397538 |
On 15/04/2026 07:05, wij wrote:
> On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:
>>> int a;
>>> char b;
>>> a=b; // allow auto promotion
>>>
>>> while(a<b) {
>>> a+=1;
>>> }
>>
>> You've claimed that that's assembly language. What assembler?
>> For what CPU?
>>
>> Is it even for a real assembler?
>
> I think you realize the example above is just an example to demo my idea.
So you've invented an 'assembly' syntax that looks exactly like C, in
order to support your notion that C and assembly are really the same thing!
Real assembly generally uses explicit instructions and labels rather
than the implicit ones used here. It would also have limits on the
complexity of expressions. If your pseudo-assembler supports:
a = b+c*f(x,y);
then you've invented a HLL.
>>> Yes, the C-like example above specifies exactly a sequence of CPU instructions
>>> (well, small deviation is allowed, and assembly can also have function, macro)
>>>
>>>> A C program specifies run-time behavior. (A compiler generates CPU
>>>> instructions behind the scenes to implement that behavior.)
>>>
>>> Being 'portable', it should specify 'run-time behavior', no exact instructions.
>>
>> Yes, that's what I said. And that's the fundamental difference between
>> assembly and C.
>
> How/what do you specify 'run-time behavior'? Not based on CPU?
>
> E.g. in C, int types are fixed-size, have range, wrap-around, alignment
> and 'atomic','overlapping' properties, you cannot really understand or hide it and
> program C/C++ correctly from the high-level concept of 'integer'.
>
> The point is that C has NO WAY get rid of these (hard-ware) features, no matter
> how high-level one thinks C is or expect C would be.
There are a dozen or more HLLs that have exactly such a set of integer
types. Actually, those have fixed-width integers with fixed ranges,
wrap-around behaviour, twos complement format and so on, even more so
than C.
So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even
more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)
Would you claim that those are also essentially assembly? If not, why not?
>> I had a similar discussion here some time ago. As I recall, the
>> other participant repeatedly claimed that sophisticated assemblers
>> that don't generate specified sequences of CPU instructions are
>> common, but never provided an example. (I haven't been able to
>> track down the discussion.)
>
> When I heard 'sophisticated assemblers', I would think something like my idea of
> 'portable' assembly, but maybe different.
> One my point should be clear as stated in the above int example "... C has NO WAY
> get rid of these (hard-ware) features, no matter how high-level one thinks C is or
> expect C would be."
Starting with C23, C has _BitInt, where you can define a 1000000-bit
integer type if you want. (There may be limits as to how big.)
Or a 37-bit type.
While I don't agree with such a feature for this language (partly
/because/ it is a big departure from machine types), it is a
counter-example to your point.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-15 20:21 +0800 |
| Message-ID | <7da922d007ccbdda1d0727e31578f8cee04e7a30.camel@gmail.com> |
| In reply to | #397542 |
On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:
> On 15/04/2026 07:05, wij wrote:
> > On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:
>
> > > > int a;
> > > > char b;
> > > > a=b; // allow auto promotion
> > > >
> > > > while(a<b) {
> > > > a+=1;
> > > > }
> > >
> > > You've claimed that that's assembly language. What assembler?
> > > For what CPU?
> > >
> > > Is it even for a real assembler?
> >
> > I think you realize the example above is just an example to demo my idea.
>
> So you've invented an 'assembly' syntax that looks exactly like C, in
> order to support your notion that C and assembly are really the same thing!
Exactly. But not really 'invented'. I feagured if anyone wants to implement
a 'portable assembly', he would find it not much different from C (from the
example shown, 'structured C'). So, in a sense, not worthy to implement.
> Real assembly generally uses explicit instructions and labels rather
> than the implicit ones used here. It would also have limits on the
> complexity of expressions. If your pseudo-assembler supports:
>
> a = b+c*f(x,y);
>
> then you've invented a HLL.
You may say that.
>
> > > > Yes, the C-like example above specifies exactly a sequence of CPU instructions
> > > > (well, small deviation is allowed, and assembly can also have function, macro)
> > > >
> > > > > A C program specifies run-time behavior. (A compiler generates CPU
> > > > > instructions behind the scenes to implement that behavior.)
> > > >
> > > > Being 'portable', it should specify 'run-time behavior', no exact instructions.
> > >
> > > Yes, that's what I said. And that's the fundamental difference between
> > > assembly and C.
> >
> > How/what do you specify 'run-time behavior'? Not based on CPU?
> >
> > E.g. in C, int types are fixed-size, have range, wrap-around, alignment
> > and 'atomic','overlapping' properties, you cannot really understand or hide it and
> > program C/C++ correctly from the high-level concept of 'integer'.
> >
> > The point is that C has NO WAY get rid of these (hard-ware) features, no matter
> > how high-level one thinks C is or expect C would be.
>
> There are a dozen or more HLLs that have exactly such a set of integer
> types. Actually, those have fixed-width integers with fixed ranges,
> wrap-around behaviour, twos complement format and so on, even more so
> than C.
>
> So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even
> more closely tied to the machine than C is. (In C, built-in types are
> not sized, but have mininum widths, and until C23, integer
> representation was not specified.)
>
> Would you claim that those are also essentially assembly? If not, why not?
I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation
is difficult) 'portable assembly' is because C (subset) could map to 'assembly'
and in a sense have to. E.g.
int p2; // p2 is connected to extern hardware
p2=0;
p2=0; // significant (hard-ware knows the second 'touch' triggers different
// action (or for delay purpose).
And, in union, I don't how 'high-level' can explain the way read/write part
of float object officially.
union {
char carr[sizeof(uint64_t)]; // C++ guarantees sizeof(char)==1
float f;
}
> > > I had a similar discussion here some time ago. As I recall, the
> > > other participant repeatedly claimed that sophisticated assemblers
> > > that don't generate specified sequences of CPU instructions are
> > > common, but never provided an example. (I haven't been able to
> > > track down the discussion.)
> >
> > When I heard 'sophisticated assemblers', I would think something like my idea of
> > 'portable' assembly, but maybe different.
> > One my point should be clear as stated in the above int example "... C has NO WAY
> > get rid of these (hard-ware) features, no matter how high-level one thinks C is or
> > expect C would be."
>
> Starting with C23, C has _BitInt, where you can define a 1000000-bit
> integer type if you want. (There may be limits as to how big.)
>
> Or a 37-bit type.
>
> While I don't agree with such a feature for this language (partly
> /because/ it is a big departure from machine types), it is a
> counter-example to your point.
Thanks for the example. I did not stress 'C is assembly', maybe it is
because I saw too many Bonita-type of programming concept to stress 'portable
assembly' (also I think it may be helpful to others).
My understand of C is that the development of C is simply from practical needs
(i.e. rare of C is from 'theoretical imagination'). Maybe _BitInt is the same but
I don't know.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-15 20:26 +0800 |
| Message-ID | <ea9831dbd3e07976185b30f6101456489014c146.camel@gmail.com> |
| In reply to | #397544 |
On Wed, 2026-04-15 at 20:21 +0800, wij wrote:
> On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:
> > On 15/04/2026 07:05, wij wrote:
> > > On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:
> >
> > > > > int a;
> > > > > char b;
> > > > > a=b; // allow auto promotion
> > > > >
> > > > > while(a<b) {
> > > > > a+=1;
> > > > > }
> > > >
> > > > You've claimed that that's assembly language. What assembler?
> > > > For what CPU?
> > > >
> > > > Is it even for a real assembler?
> > >
> > > I think you realize the example above is just an example to demo my idea.
> >
> > So you've invented an 'assembly' syntax that looks exactly like C, in
> > order to support your notion that C and assembly are really the same thing!
>
> Exactly. But not really 'invented'. I feagured if anyone wants to implement
> a 'portable assembly', he would find it not much different from C (from the
> example shown, 'structured C'). So, in a sense, not worthy to implement.
Typo: 'structured assembly'
> > Real assembly generally uses explicit instructions and labels rather
> > than the implicit ones used here. It would also have limits on the
> > complexity of expressions. If your pseudo-assembler supports:
> >
> > a = b+c*f(x,y);
> >
> > then you've invented a HLL.
>
> You may say that.
>
> >
> > > > > Yes, the C-like example above specifies exactly a sequence of CPU instructions
> > > > > (well, small deviation is allowed, and assembly can also have function, macro)
> > > > >
> > > > > > A C program specifies run-time behavior. (A compiler generates CPU
> > > > > > instructions behind the scenes to implement that behavior.)
> > > > >
> > > > > Being 'portable', it should specify 'run-time behavior', no exact instructions.
> > > >
> > > > Yes, that's what I said. And that's the fundamental difference between
> > > > assembly and C.
> > >
> > > How/what do you specify 'run-time behavior'? Not based on CPU?
> > >
> > > E.g. in C, int types are fixed-size, have range, wrap-around, alignment
> > > and 'atomic','overlapping' properties, you cannot really understand or hide it and
> > > program C/C++ correctly from the high-level concept of 'integer'.
> > >
> > > The point is that C has NO WAY get rid of these (hard-ware) features, no matter
> > > how high-level one thinks C is or expect C would be.
> >
> > There are a dozen or more HLLs that have exactly such a set of integer
> > types. Actually, those have fixed-width integers with fixed ranges,
> > wrap-around behaviour, twos complement format and so on, even more so
> > than C.
> >
> > So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even
> > more closely tied to the machine than C is. (In C, built-in types are
> > not sized, but have mininum widths, and until C23, integer
> > representation was not specified.)
> >
> > Would you claim that those are also essentially assembly? If not, why not?
>
> I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation
> is difficult) 'portable assembly' is because C (subset) could map to 'assembly'
> and in a sense have to. E.g.
>
> int p2; // p2 is connected to extern hardware
>
> p2=0;
> p2=0; // significant (hard-ware knows the second 'touch' triggers different
> // action (or for delay purpose).
>
> And, in union, I don't how 'high-level' can explain the way read/write part
> of float object officially.
> union {
> char carr[sizeof(uint64_t)]; // C++ guarantees sizeof(char)==1
> float f;
> }
Typo: char carr[sizeof(float)];
> > > > I had a similar discussion here some time ago. As I recall, the
> > > > other participant repeatedly claimed that sophisticated assemblers
> > > > that don't generate specified sequences of CPU instructions are
> > > > common, but never provided an example. (I haven't been able to
> > > > track down the discussion.)
> > >
> > > When I heard 'sophisticated assemblers', I would think something like my idea of
> > > 'portable' assembly, but maybe different.
> > > One my point should be clear as stated in the above int example "... C has NO WAY
> > > get rid of these (hard-ware) features, no matter how high-level one thinks C is or
> > > expect C would be."
> >
> > Starting with C23, C has _BitInt, where you can define a 1000000-bit
> > integer type if you want. (There may be limits as to how big.)
> >
> > Or a 37-bit type.
> >
> > While I don't agree with such a feature for this language (partly
> > /because/ it is a big departure from machine types), it is a
> > counter-example to your point.
>
> Thanks for the example. I did not stress 'C is assembly', maybe it is
> because I saw too many Bonita-type of programming concept to stress 'portable
> assembly' (also I think it may be helpful to others).
>
> My understand of C is that the development of C is simply from practical needs
> (i.e. rare of C is from 'theoretical imagination'). Maybe _BitInt is the same but
> I don't know.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-15 15:38 +0200 |
| Message-ID | <10ro4c9$qsu2$1@dont-email.me> |
| In reply to | #397544 |
On 15/04/2026 14:21, wij wrote: > On Wed, 2026-04-15 at 11:46 +0100, Bart wrote: >> >> There are a dozen or more HLLs that have exactly such a set of integer >> types. Actually, those have fixed-width integers with fixed ranges, >> wrap-around behaviour, twos complement format and so on, even more so >> than C. >> >> So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even >> more closely tied to the machine than C is. (In C, built-in types are >> not sized, but have mininum widths, and until C23, integer >> representation was not specified.) >> >> Would you claim that those are also essentially assembly? If not, why not? > > I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation > is difficult) 'portable assembly' is because C (subset) could map to 'assembly' > and in a sense have to. E.g. > > int p2; // p2 is connected to extern hardware > > p2=0; > p2=0; // significant (hard-ware knows the second 'touch' triggers different > // action (or for delay purpose). > You are not making any sense. I don't think you understand what C is, how the language is defined, or how typical C implementations work. In C, when you write the code above there is /nothing/ to suggest that there should be two actions. C compilers can - and many will - combine the two "p2 = 0;" statements. This is critical to understanding why C is not in any sense an "assembler". In assembly languages, if you write the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice. In C, the language do not require an operation for the statement "p2 = 0;". They require that after that statement, any observable behaviour produced by the program will be as if the value 0 had been assigned to the object "p2". Repeating that same requirement does not change it - the compiler does not have to have implement "p2 = 0;" twice. (It is free to do so twice - or two hundred times if it likes. And if the value of p2 is not used, it can be completely eliminated.) Have you actually done any C programming at all?
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-16 00:58 +0800 |
| Message-ID | <d678a2ad4064ef26f491324a1081e139e6ebed8d.camel@gmail.com> |
| In reply to | #397547 |
On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote: > On 15/04/2026 14:21, wij wrote: > > On Wed, 2026-04-15 at 11:46 +0100, Bart wrote: > > > > > > There are a dozen or more HLLs that have exactly such a set of integer > > > types. Actually, those have fixed-width integers with fixed ranges, > > > wrap-around behaviour, twos complement format and so on, even more so > > > than C. > > > > > > So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even > > > more closely tied to the machine than C is. (In C, built-in types are > > > not sized, but have mininum widths, and until C23, integer > > > representation was not specified.) > > > > > > Would you claim that those are also essentially assembly? If not, why not? > > > > I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation > > is difficult) 'portable assembly' is because C (subset) could map to 'assembly' > > and in a sense have to. E.g. > > > > int p2; // p2 is connected to extern hardware > > > > p2=0; > > p2=0; // significant (hard-ware knows the second 'touch' triggers different > > // action (or for delay purpose). > > > You are not making any sense. I don't think you understand what C is, > how the language is defined, or how typical C implementations work. I switched from C to C++ 30 years ago. But that is 'theoretical', I see things from real world side. I think you approach 'C' from standard documents, that is not the way of understanding. You cannot understand the world by/from reading the bible. > In C, when you write the code above there is /nothing/ to suggest that > there should be two actions. As I know, 'old-time' C has no optimization. > C compilers can - and many will - combine > the two "p2 = 0;" statements. This is critical to understanding why C > is not in any sense an "assembler". Not a valid reason. > In assembly languages, if you write > the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice. Assembly compiler (or language) can also do the same optimization. > In C, the language do not require an operation for the statement "p2 = > 0;". They require that after that statement, any observable behaviour > produced by the program will be as if the value 0 had been assigned to > the object "p2". You need a model now by saying so. > Repeating that same requirement does not change it - > the compiler does not have to have implement "p2 = 0;" twice. (It is > free to do so twice - or two hundred times if it likes. And if the > value of p2 is not used, it can be completely eliminated.) > > Have you actually done any C programming at all? Nope, I quit C (but I keep watching C, since part of C++ is C)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-15 22:11 +0200 |
| Message-ID | <10rordp$16j1j$3@dont-email.me> |
| In reply to | #397552 |
On 15/04/2026 18:58, wij wrote: > On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote: >> On 15/04/2026 14:21, wij wrote: >>> On Wed, 2026-04-15 at 11:46 +0100, Bart wrote: >>>> >>>> There are a dozen or more HLLs that have exactly such a set of integer >>>> types. Actually, those have fixed-width integers with fixed ranges, >>>> wrap-around behaviour, twos complement format and so on, even more so >>>> than C. >>>> >>>> So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even >>>> more closely tied to the machine than C is. (In C, built-in types are >>>> not sized, but have mininum widths, and until C23, integer >>>> representation was not specified.) >>>> >>>> Would you claim that those are also essentially assembly? If not, why not? >>> >>> I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation >>> is difficult) 'portable assembly' is because C (subset) could map to 'assembly' >>> and in a sense have to. E.g. >>> >>> int p2; // p2 is connected to extern hardware >>> >>> p2=0; >>> p2=0; // significant (hard-ware knows the second 'touch' triggers different >>> // action (or for delay purpose). >>> >> You are not making any sense. I don't think you understand what C is, >> how the language is defined, or how typical C implementations work. > > I switched from C to C++ 30 years ago. I don't think you understand C++ either. In the context of this discussion, it is not different from C. > But that is 'theoretical', I see things > from real world side. I think you approach 'C' from standard documents, that is > not the way of understanding. You cannot understand the world by/from reading > the bible. No, I understand C and C++ from using them in real-world code - as well as knowing what the code means and what is guaranteed by the language. Practical experience tells you what works well in practice - but theoretical knowledge tells you what you can expect so that you are not just programming by luck and "it worked for me when I tried it". > >> In C, when you write the code above there is /nothing/ to suggest that >> there should be two actions. > > As I know, 'old-time' C has no optimization. > Nonsense. Modern C compilers often do more optimisation than older ones, but there was never a "pre-optimisation" world. Things like eliminating dead code, or optimising based on knowing that signed integer overflow never occurs in a correct program, have been around from early tools. I have used heavily optimising compilers for 30 years. >> C compilers can - and many will - combine >> the two "p2 = 0;" statements. This is critical to understanding why C >> is not in any sense an "assembler". > > Not a valid reason. > What do you mean by that? It's a fact, not a "reason". >> In assembly languages, if you write >> the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice. > > Assembly compiler (or language) can also do the same optimization. > No, assemblers cannot do that - if they did, they would not be assemblers. An assembler directly translates your instructions from mnemonic codes (assembly instructions) to binary opcodes. Some assemblers might have pseudo-instructions that translate to more than one binary opcode, but always in a specific defined pattern. >> In C, the language do not require an operation for the statement "p2 = >> 0;". They require that after that statement, any observable behaviour >> produced by the program will be as if the value 0 had been assigned to >> the object "p2". > > You need a model now by saying so. Again, I don't know what you are trying to say. > >> Repeating that same requirement does not change it - >> the compiler does not have to have implement "p2 = 0;" twice. (It is >> free to do so twice - or two hundred times if it likes. And if the >> value of p2 is not used, it can be completely eliminated.) >> >> Have you actually done any C programming at all? > > Nope, I quit C (but I keep watching C, since part of C++ is C) > Okay, have you ever actually done any C++ programming? The languages share the same philosophy here.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-16 05:38 +0800 |
| Message-ID | <2b51e35df2a286ae002f71c7c571f52209d17e1c.camel@gmail.com> |
| In reply to | #397556 |
On Wed, 2026-04-15 at 22:11 +0200, David Brown wrote: > On 15/04/2026 18:58, wij wrote: > > On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote: > > > On 15/04/2026 14:21, wij wrote: > > > > On Wed, 2026-04-15 at 11:46 +0100, Bart wrote: > > > > > > > > > > There are a dozen or more HLLs that have exactly such a set of integer > > > > > types. Actually, those have fixed-width integers with fixed ranges, > > > > > wrap-around behaviour, twos complement format and so on, even more so > > > > > than C. > > > > > > > > > > So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even > > > > > more closely tied to the machine than C is. (In C, built-in types are > > > > > not sized, but have mininum widths, and until C23, integer > > > > > representation was not specified.) > > > > > > > > > > Would you claim that those are also essentially assembly? If not, why not? > > > > > > > > I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation > > > > is difficult) 'portable assembly' is because C (subset) could map to 'assembly' > > > > and in a sense have to. E.g. > > > > > > > > int p2; // p2 is connected to extern hardware > > > > > > > > p2=0; > > > > p2=0; // significant (hard-ware knows the second 'touch' triggers different > > > > // action (or for delay purpose). > > > > > > > You are not making any sense. I don't think you understand what C is, > > > how the language is defined, or how typical C implementations work. > > > > I switched from C to C++ 30 years ago. > > I don't think you understand C++ either. In the context of this > discussion, it is not different from C. > > > But that is 'theoretical', I see things > > from real world side. I think you approach 'C' from standard documents, that is > > not the way of understanding. You cannot understand the world by/from reading > > the bible. > > No, I understand C and C++ from using them in real-world code - as well > as knowing what the code means and what is guaranteed by the language. > Practical experience tells you what works well in practice - but > theoretical knowledge tells you what you can expect so that you are not > just programming by luck and "it worked for me when I tried it". > > > > > > In C, when you write the code above there is /nothing/ to suggest that > > > there should be two actions. > > > > As I know, 'old-time' C has no optimization. > > > > Nonsense. > > Modern C compilers often do more optimisation than older ones, but there > was never a "pre-optimisation" world. Things like eliminating dead > code, or optimising based on knowing that signed integer overflow never > occurs in a correct program, have been around from early tools. I have > used heavily optimising compilers for 30 years. > > > > C compilers can - and many will - combine > > > the two "p2 = 0;" statements. This is critical to understanding why C > > > is not in any sense an "assembler". > > > > Not a valid reason. > > > > What do you mean by that? It's a fact, not a "reason". > > > > In assembly languages, if you write > > > the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice. > > > > Assembly compiler (or language) can also do the same optimization. > > > > No, assemblers cannot do that - if they did, they would not be > assemblers. An assembler directly translates your instructions from > mnemonic codes (assembly instructions) to binary opcodes. Some > assemblers might have pseudo-instructions that translate to more than > one binary opcode, but always in a specific defined pattern. > > > > In C, the language do not require an operation for the statement "p2 = > > > 0;". They require that after that statement, any observable behaviour > > > produced by the program will be as if the value 0 had been assigned to > > > the object "p2". > > > > You need a model now by saying so. > > Again, I don't know what you are trying to say. > > > > > > Repeating that same requirement does not change it - > > > the compiler does not have to have implement "p2 = 0;" twice. (It is > > > free to do so twice - or two hundred times if it likes. And if the > > > value of p2 is not used, it can be completely eliminated.) > > > > > > Have you actually done any C programming at all? > > > > Nope, I quit C (but I keep watching C, since part of C++ is C) > > > > Okay, have you ever actually done any C++ programming? The languages > share the same philosophy here. You are really a sick person. Looser of the real world. You just don't know yourself. I have a gold medal, an aluminum medal and a bronze commemorative plaque (for solving a riddle of Northrop Coorp.). What you have? Well... a paper (paid for) and still making false memory everyday for yourself. I retired at 37, can you? Ah, recently, you also failed to verify a simple program that proves 3x+1 problem. Fact is not made by mouth (like DJT?), looser.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-15 15:48 -0700 |
| Message-ID | <87jyu7vnza.fsf@example.invalid> |
| In reply to | #397559 |
wij <wyniijj5@gmail.com> writes:
> On Wed, 2026-04-15 at 22:11 +0200, David Brown wrote:
[...]
>> Okay, have you ever actually done any C++ programming? The languages
>> share the same philosophy here.
>
> You are really a sick person. Looser of the real world. You just don't know
> yourself.
> I have a gold medal, an aluminum medal and a bronze commemorative plaque (for
> solving a riddle of Northrop Coorp.). What you have? Well... a paper (paid for)
> and still making false memory everyday for yourself.
> I retired at 37, can you?
>
> Ah, recently, you also failed to verify a simple program that proves
> 3x+1 problem. Fact is not made by mouth (like DJT?), looser.
Keep the personal abuse to yourself.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-15 23:31 -0700 |
| Message-ID | <10rpvoj$1g5qo$3@dont-email.me> |
| In reply to | #397563 |
On 4/15/2026 3:48 PM, Keith Thompson wrote: > wij <wyniijj5@gmail.com> writes: >> On Wed, 2026-04-15 at 22:11 +0200, David Brown wrote: > [...] >>> Okay, have you ever actually done any C++ programming? The languages >>> share the same philosophy here. >> >> You are really a sick person. Looser of the real world. You just don't know >> yourself. >> I have a gold medal, an aluminum medal and a bronze commemorative plaque (for >> solving a riddle of Northrop Coorp.). What you have? Well... a paper (paid for) >> and still making false memory everyday for yourself. >> I retired at 37, can you? >> >> Ah, recently, you also failed to verify a simple program that proves >> 3x+1 problem. Fact is not made by mouth (like DJT?), looser. > > Keep the personal abuse to yourself. > YIKES! ;^o
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-16 09:13 +0200 |
| Message-ID | <10rq274$1fhtc$2@dont-email.me> |
| In reply to | #397559 |
On 15/04/2026 23:38, wij wrote: <skip drivel> I don't think there is anything more to be said. You apparently know everything already.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-04-16 04:43 +0000 |
| Message-ID | <10rppd0$1cumn$2@paganini.bofh.team> |
| In reply to | #397556 |
David Brown <david.brown@hesbynett.no> wrote:
> On 15/04/2026 18:58, wij wrote:
>>
>> Assembly compiler (or language) can also do the same optimization.
>>
>
> No, assemblers cannot do that - if they did, they would not be
> assemblers. An assembler directly translates your instructions from
> mnemonic codes (assembly instructions) to binary opcodes. Some
> assemblers might have pseudo-instructions that translate to more than
> one binary opcode, but always in a specific defined pattern.
Well, as a program assembler is not a compiler. But people talk
about "assembly language" and you can have a compiler that
takes assembly language as an input. This was done by DEC
for VAX assembly. A guy created compilers for 360 assembly,
one targeting 386, another one targetimg Java. Such compilers
to be useful should do same optimization.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-16 09:23 +0200 |
| Message-ID | <10rq2p1$1fhtc$3@dont-email.me> |
| In reply to | #397575 |
On 16/04/2026 06:43, Waldek Hebisch wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 15/04/2026 18:58, wij wrote: >>> >>> Assembly compiler (or language) can also do the same optimization. >>> >> >> No, assemblers cannot do that - if they did, they would not be >> assemblers. An assembler directly translates your instructions from >> mnemonic codes (assembly instructions) to binary opcodes. Some >> assemblers might have pseudo-instructions that translate to more than >> one binary opcode, but always in a specific defined pattern. > > Well, as a program assembler is not a compiler. But people talk > about "assembly language" and you can have a compiler that > takes assembly language as an input. This was done by DEC > for VAX assembly. A guy created compilers for 360 assembly, > one targeting 386, another one targetimg Java. Such compilers > to be useful should do same optimization. > You can indeed do that kind of thing. I once used (briefly) a setup where the assembly output of a simple 8086 C compiler was piped into a converter to turn that into assembly for an 8-bit microcontroller. The results were not particularly efficient, but it was a path from C to assembly for that microcontroller. (Other more normal C compilers for that microcontroller were terrible in other ways.) I have also seen some assembly "post-processors" that aim to clean up or otherwise optimise assembly - typically the output of C compilers that generate particularly inefficient patterns. "Assembly language" is a symbolic form of a processor's (real or virtual) instruction code, combined with helpful features like labels, address calculations, and other directives. An "assembler" is a program that translates this into machine code. But assembly language can be used for plenty of other things - these days I mostly use it to see what the compiler has generated.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-16 14:38 +0000 |
| Message-ID | <iv6ER.2006$bfif.333@fx39.iad> |
| In reply to | #397575 |
antispam@fricas.org (Waldek Hebisch) writes:
>David Brown <david.brown@hesbynett.no> wrote:
>> On 15/04/2026 18:58, wij wrote:
>>>
>>> Assembly compiler (or language) can also do the same optimization.
>>>
>>
>> No, assemblers cannot do that - if they did, they would not be
>> assemblers. An assembler directly translates your instructions from
>> mnemonic codes (assembly instructions) to binary opcodes. Some
>> assemblers might have pseudo-instructions that translate to more than
>> one binary opcode, but always in a specific defined pattern.
>
>Well, as a program assembler is not a compiler. But people talk
>about "assembly language" and you can have a compiler that
>takes assembly language as an input. This was done by DEC
>for VAX assembly. A guy created compilers for 360 assembly,
>one targeting 386, another one targetimg Java. Such compilers
>to be useful should do same optimization.
The C compiler in the GNU Compiler Collection provides
a mechanism to 'take assembly language as an input'
in the form of in-line assembler fragments. It's
useful in some limited cases (machine-level software like
kernels, boot loaders and the like).
The Burroughs Large systems (B5500 and descendents) has
never had an assembler; all code is written in a flavor
of Algol (with special syntax extensions required for
the MCP and other privileged applications).
The Burroughs Medium systems COBOL68 compiler supported
the 'ENTER SYMBOLIC' statement, which was followed by
in-line assembler until the LEAVE SYMBOLIC statement.
That functionality was not present in COBOL74 and
COBOL85 compilers. The Burroughs Programming Language
(BPL) compiler had the STORE verb which allowed
arbitrary values to be stored into the instruction
stream and was often used insert instructions
into the code stream.
For example:
GetMixInfo(a,b,c)= BEGIN UNSEGMENTED 00032000
BCT 0214; 00033000
BeginBCTParms 00034000
STORE(08) := @000000DB@; 00035000
STORE(06) := [a.NO]; 00036000
STORE(06) := [b.NO]; 00037000
STORE(06) := [c.NO]; 00038000
EndBCTParms; 00039000
END;#; 00040000
Stored the parameters for a branch communicate (trap to MCP) instruction.
DEFINE SPIO(iocb) = STORE(6) := @940000@;
STORE := [iocb.UN];#;
DEFINE HBR(label) = STORE(2) := @29@;
STORE := [label.NO];#;
DEFINE SST(area) = STORE(6) := @990001@;
STORE := [area.UA];#;
DEFINE WHR(bf, field) = STORE(4) := @6500@;
STORE(2) := bf;
STORE := [field.UN];#;
Defines macros to generate specific instructions (SPIO is Start Physical
I/O, HBR is Halt Branch, SST is System Status, WHR is Write Hardware Register).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-16 17:05 +0200 |
| Message-ID | <10rqtsf$1nbrp$2@dont-email.me> |
| In reply to | #397600 |
On 16/04/2026 16:38, Scott Lurndal wrote: > antispam@fricas.org (Waldek Hebisch) writes: >> David Brown <david.brown@hesbynett.no> wrote: >>> On 15/04/2026 18:58, wij wrote: >>>> >>>> Assembly compiler (or language) can also do the same optimization. >>>> >>> >>> No, assemblers cannot do that - if they did, they would not be >>> assemblers. An assembler directly translates your instructions from >>> mnemonic codes (assembly instructions) to binary opcodes. Some >>> assemblers might have pseudo-instructions that translate to more than >>> one binary opcode, but always in a specific defined pattern. >> >> Well, as a program assembler is not a compiler. But people talk >> about "assembly language" and you can have a compiler that >> takes assembly language as an input. This was done by DEC >> for VAX assembly. A guy created compilers for 360 assembly, >> one targeting 386, another one targetimg Java. Such compilers >> to be useful should do same optimization. > > The C compiler in the GNU Compiler Collection provides > a mechanism to 'take assembly language as an input' > in the form of in-line assembler fragments. It's > useful in some limited cases (machine-level software like > kernels, boot loaders and the like). > Not really, no. gcc "asm" statements accept a kind of template language and fills in certain types of parameters (used to pass register names, symbolic addresses, etc. to the assembly) then passes the rest of the template string directly on to the generated assembly file. It does not interpret the assembly in any way, or do any kind of checking. gcc does not take assembly language as an input any more than a typical printf statement takes English language as an input. But gcc inline assembly is definitely useful at times - you are right there!
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-04-16 15:11 +0000 |
| Message-ID | <10rqu7g$1mmnk$1@dont-email.me> |
| In reply to | #397600 |
On Thu, 16 Apr 2026 14:38:06 +0000, Scott Lurndal wrote: > antispam@fricas.org (Waldek Hebisch) writes: >>David Brown <david.brown@hesbynett.no> wrote: >>> On 15/04/2026 18:58, wij wrote: >>>> >>>> Assembly compiler (or language) can also do the same optimization. >>>> >>> >>> No, assemblers cannot do that - if they did, they would not be >>> assemblers. An assembler directly translates your instructions from >>> mnemonic codes (assembly instructions) to binary opcodes. Some >>> assemblers might have pseudo-instructions that translate to more than >>> one binary opcode, but always in a specific defined pattern. >> >>Well, as a program assembler is not a compiler. But people talk >>about "assembly language" and you can have a compiler that >>takes assembly language as an input. This was done by DEC >>for VAX assembly. A guy created compilers for 360 assembly, >>one targeting 386, another one targetimg Java. Such compilers >>to be useful should do same optimization. > > The C compiler in the GNU Compiler Collection provides > a mechanism to 'take assembly language as an input' > in the form of in-line assembler fragments. It's > useful in some limited cases (machine-level software like > kernels, boot loaders and the like). I believe that the authors of GNU C latched on to an (at the time) useful extension of the C language, originally implemented in Ron Cain's "Small C Compiler for the 8080's" (Dr. Dobbs Journal # 45, 1980) as the #asm/#endasm preprocessor directives. Ron's K&R C subset compiler didn't compile to machine code; instead, it compiled to CP/M 8080 assembler (CP/M came with an 8080 assembler as it's only language tool), and so an sourcecode assembly "passthrough" was easily implemented. > The Burroughs Large systems (B5500 and descendents) has > never had an assembler; all code is written in a flavor > of Algol (with special syntax extensions required for > the MCP and other privileged applications). > > The Burroughs Medium systems COBOL68 compiler supported > the 'ENTER SYMBOLIC' statement, which was followed by > in-line assembler until the LEAVE SYMBOLIC statement. The IBM language environments that I worked in all supported static (and later, dynamic) linkage, and my employer could afford a suite of IBM language tools. IBMs language tools shared a common object interface, so it was (relatively) easy to write the Assembly parts in Assembler, and the HLL parts in the appropriate HLL (ususally, for us, COBOL), and link them together for execution. Consequently, none of the high-level languages supported an "assembly" escape (although COBOL provided extensions for IBM DB2 relational database interaction). [snip] FWIW, I believe that the origins of C had much the same philosophy: write parts in suitable languages, and link them together prior to execution. K&R C had no reason to support inline assembly (and, as far as I have read) the authors studiously avoided that capability. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-16 17:43 +0200 |
| Message-ID | <10rr02n$v391$7@dont-email.me> |
| In reply to | #397603 |
On 2026-04-16 17:11, Lew Pitcher wrote: > [snip] > > FWIW, I believe that the origins of C had much the same > philosophy: write parts in suitable languages, and link > them together prior to execution. But was that an outcome of the C-language design, or of the UNIX operating system concepts with its languages, toolbox, and linking-editor? There also seems to have been an asymmetry here with "C", at least evolving later... From what I observed, "C" had reached a status to not be "inter pares". As a comparably low-level language it had been often used for other languages as the compile-output to be then handled by any C-compiler. Also HLLs supported interfaces to access (primarily) "C" modules because of their (much better) performance and the typically easier access to system resources. > K&R C had no reason > to support inline assembly (and, as far as I have read) > the authors studiously avoided that capability. Nonetheless it supported the reserved word 'asm' (as I can read in my old translation of K&R). (Not exactly what I'd call "studiously avoided".) Janis
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-04-16 16:23 +0000 |
| Message-ID | <10rr2ea$1mmnk$2@dont-email.me> |
| In reply to | #397605 |
On Thu, 16 Apr 2026 17:43:19 +0200, Janis Papanagnou wrote:
> On 2026-04-16 17:11, Lew Pitcher wrote:
>> [snip]
>>
>> FWIW, I believe that the origins of C had much the same
>> philosophy: write parts in suitable languages, and link
>> them together prior to execution.
>
> But was that an outcome of the C-language design, or of
> the UNIX operating system concepts with its languages,
> toolbox, and linking-editor?
All of the above.
Linkage editors were (and still are) common technology,
as was separation of languages (assembler vs high level
language). Originally, Unix was written in assembler, and
(according to the histories) C was designed (with the existent
language tools in mind) to allow the Unix developers to use
a high-level language in their development. Remember, Bell
Labs wrote more than just Unix in C; C became the lingua-franca
for all the tools and applications, including the text management
tools (TROFF, EQN, SED, AWK, etc) and games (CHESS/CHECKERS/
BACKGAMMON)
I recall reading (but cannot find the reference now) that
Unix (V7 perhaps?) consisted of thousands of lines of C code,
and a few hundred lines of assembly for device drivers.
> There also seems to have been an asymmetry here with "C",
> at least evolving later...
>
> From what I observed, "C" had reached a status to not be
> "inter pares". As a comparably low-level language it had
> been often used for other languages as the compile-output
> to be then handled by any C-compiler. Also HLLs supported
> interfaces to access (primarily) "C" modules because of
> their (much better) performance and the typically easier
> access to system resources.
>> K&R C had no reason
>> to support inline assembly (and, as far as I have read)
>> the authors studiously avoided that capability.
>
> Nonetheless it supported the reserved word 'asm' (as I can
> read in my old translation of K&R). (Not exactly what I'd
> call "studiously avoided".)
To quote K&R ("The C Programming Language" 1978)
from Appendix A ("C Reference Manual") section 2.3 ("Keywords")
"The 'entry' keyword is not currently implemented by
any compiler, but is reserved for future use. Some
implementations also reserve the words 'fortran' and 'asm'."
I note that, according to that appendix, C had been ported to
PDP 11, Honeywell 6000, IBM 360/370, and Interdata 8/32 systems
at that time, none of them running Unix, to my knowledge. As
such, the language (at that time in a bit of a plastic state,
being supplied as source code to AT&T customers and educators
alike) may have been altered on a site-by-site basis to suit
the needs of each particular client. As the context of these
keywords was never explained, I find it easier to believe that
the intent for these keywords was as a storage modifier, and
not an inline language change. Something like
extern fortran int F1(); /* use fortran calling convention */
extern asm char *F2(); /* use assembly calling convention */
> Janis
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-16 19:48 +0000 |
| Message-ID | <10rref3$dnm$1@reader1.panix.com> |
| In reply to | #397606 |
In article <10rr2ea$1mmnk$2@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Thu, 16 Apr 2026 17:43:19 +0200, Janis Papanagnou wrote:
>
>> On 2026-04-16 17:11, Lew Pitcher wrote:
>>> [snip]
>>>
>>> FWIW, I believe that the origins of C had much the same
>>> philosophy: write parts in suitable languages, and link
>>> them together prior to execution.
>>
>> But was that an outcome of the C-language design, or of
>> the UNIX operating system concepts with its languages,
>> toolbox, and linking-editor?
>
>All of the above.
>
>Linkage editors were (and still are) common technology,
>as was separation of languages (assembler vs high level
>language). Originally, Unix was written in assembler, and
>(according to the histories) C was designed (with the existent
>language tools in mind) to allow the Unix developers to use
>a high-level language in their development. Remember, Bell
>Labs wrote more than just Unix in C; C became the lingua-franca
>for all the tools and applications, including the text management
>tools (TROFF, EQN, SED, AWK, etc) and games (CHESS/CHECKERS/
>BACKGAMMON)
>
>I recall reading (but cannot find the reference now) that
>Unix (V7 perhaps?) consisted of thousands of lines of C code,
>and a few hundred lines of assembly for device drivers.
>
>> There also seems to have been an asymmetry here with "C",
>> at least evolving later...
>>
>> From what I observed, "C" had reached a status to not be
>> "inter pares". As a comparably low-level language it had
>> been often used for other languages as the compile-output
>> to be then handled by any C-compiler. Also HLLs supported
>> interfaces to access (primarily) "C" modules because of
>> their (much better) performance and the typically easier
>> access to system resources.
>
>
>
>>> K&R C had no reason
>>> to support inline assembly (and, as far as I have read)
>>> the authors studiously avoided that capability.
>>
>> Nonetheless it supported the reserved word 'asm' (as I can
>> read in my old translation of K&R). (Not exactly what I'd
>> call "studiously avoided".)
>
>To quote K&R ("The C Programming Language" 1978)
>from Appendix A ("C Reference Manual") section 2.3 ("Keywords")
> "The 'entry' keyword is not currently implemented by
> any compiler, but is reserved for future use. Some
> implementations also reserve the words 'fortran' and 'asm'."
>
>I note that, according to that appendix, C had been ported to
>PDP 11, Honeywell 6000, IBM 360/370, and Interdata 8/32 systems
>at that time, none of them running Unix, to my knowledge.
By 1978, all of those save the Honeywell machine were running
Unix, either at Bell Labs or elsehwere.
I am aware of at least two independent ports: Tom Lyon and other
students did a port at Princeton starting 1976. A Bell system
port was done to support the development of telephone switching
software for the 5ESS; in both cases, unix booted under VM/370.
The Interdata 8/32 work was done explicitly as an exercise in
portability for the Unix system itself, and was the source of
the infamous "You are not expected to understand this" comment
in the context switching code. Unknown to the Bell Labs folks
at the time, a paralel effort in Australia was porting to the
Interdata 7/32 machine; that effort actually reached the summit
of a working port first.
The PDP-11, of course, was the primary development environment
for Unix throughout most of the 1970s, until they got ahold of
VAX-11 machines at the end of the decade.
The H6000 machine was the outlier, and that probably grew out of
a much older port to the GE-635 machine.
>As
>such, the language (at that time in a bit of a plastic state,
>being supplied as source code to AT&T customers and educators
>alike) may have been altered on a site-by-site basis to suit
>the needs of each particular client. As the context of these
>keywords was never explained, I find it easier to believe that
>the intent for these keywords was as a storage modifier, and
>not an inline language change. Something like
> extern fortran int F1(); /* use fortran calling convention */
> extern asm char *F2(); /* use assembly calling convention */
By '78 and the publication of the first version of "The C
Programming Language", the version that became known as "K&R C"
was actually what Unix folks called, "typesetter C". This was
the language, as extended to support a version of `roff` with
support for a phototypesetting machine that had been acquired by
Bell Labs. It was pretty well solidified by then, though some
folks made changes; `asm` was available in the compiler used to
build Comer's "Xinu" system for the LSI-11, for example. Work
shifted from Dennis Ritchie's original PDP-11 compiler to the
Johnson's "Portable C Compiler" (PCC), which was available in
7th Edition Unix, and became the basis for the compiler used by
many in the growing minicomputer and later workstation markets.
The next major change came with the ANSI standard in 1988, of
course.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-16 19:04 +0000 |
| Message-ID | <dpaER.1513$r_k6.677@fx38.iad> |
| In reply to | #397605 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-04-16 17:11, Lew Pitcher wrote: >> [snip] >> >> FWIW, I believe that the origins of C had much the same >> philosophy: write parts in suitable languages, and link >> them together prior to execution. > >But was that an outcome of the C-language design, or of >the UNIX operating system concepts with its languages, >toolbox, and linking-editor? I expect that it was driven by the extremely limited memory of the day. V6 C had four executables: cc Driver c0 Preprocessor c1 Parser/Code Generator c2 Optimizer (optimized the asm output of c1) then to generate an a.out, cc would invoke both as Assembler ld Linker
[toc] | [prev] | [next] | [standalone]
Page 16 of 19 — ← Prev page 1 … 14 15 [16] 17 18 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web