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 17 of 19 — ← Prev page 1 … 15 16 [17] 18 19 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-16 19:01 +0000 |
| Message-ID | <qmaER.1512$r_k6.281@fx38.iad> |
| In reply to | #397603 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >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. Burroughs had the same thing (independently compiled modules (ICMs) bound together by the BINDER). Although that arrived in the 70's, which is why COBOL74 and COBOL85 no longer supported inline assembler but COBOL68 did. > >Consequently, none of the high-level languages supported >an "assembly" escape (although COBOL provided extensions >for IBM DB2 relational database interaction). >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-15 15:34 -0700 |
| Message-ID | <87se8vvoo0.fsf@example.invalid> |
| In reply to | #397552 |
wij <wyniijj5@gmail.com> writes:
> On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote:
[...]
>> 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.
I'm not sure that's even meaningful. A C compiler translates C
source code to assembly or machine code. That's a non-trivial
transformation. I'm not sure you can even say that such a
transformation doesn't optimize anything.
But ok, given `n = 0; n = 0;` a C compiler *may or may not* generate
two stores to n. If it generates just one, that's an optimization.
But the point is that that kind of optimization is not specified
by the language. For every assembler I've encoutered, such
optimizations are simply not implemented.
[...]
>> 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.
Oh? Name a real-world assembler (not from your imagination) that does
that kind of optimization. I'd like to read its manual.
[...]
--
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:29 -0700 |
| Message-ID | <10rpvkn$1g5qo$2@dont-email.me> |
| In reply to | #397552 |
On 4/15/2026 9:58 AM, wij wrote: [...] > Nope, I quit C (but I keep watching C, since part of C++ is C) > > C is nice on several levels...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-15 15:06 +0100 |
| Message-ID | <10ro60s$100pr$1@dont-email.me> |
| In reply to | #397544 |
On 15/04/2026 13:21, 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.
>
>> 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.
It sounds like you don't understand the difference between a low-level
language and a high-level one.
These days C might be considered mid-level (I call it a lower-level HLL,
because so many HLLs are much higher level and more abstract).
Compiling a HLL involves lowering it to a different representation, say
from language A to language B.
But just because that translation happens to be routine, doesn't mean
and A is essentially B.
>
>>
>>>>> 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).
That won't work in C. 'p2' is likely to be in a register; that extra
write may be elided.
You'd have to use 'volatile' to guard against that. But you still can't
control where p2 is put into memory. C /is/ used for this stuff, but all
sorts of special extensions, or compiler specifics, may be employed.
In assembly it's much easier.
>
> And, in union, I don't how 'high-level' can explain the way read/write part
> of float object officially.
> union {
> char carr[sizeof(float)]; // C++ guarantees sizeof(char)==1
> float f;
> }
(Fixed that sizeof.)
I normally use my own systems language. That one is aligned much more
directly to hardware than C is, even though it is marginally higher level.
This is because C is intended to work on possible hardware, while mine
was created to work with one target as a time.
Also, when I started on mine (c. 1982 rather than 1972), hardware was
already standardising on 8-bit bytes, byte-addressed, power-of-two word
sizes, and twos-complement integers.
I don't however consider my language to be a form of assembly for lots
of reasons already mentioned.
Its compilers use 3 internal representations before it gets to native code:
HLL source -> AST -> IL -> MCL -> Native
'MCL' is the internal representation of the native code. If I need ASM
output, then MCL can be dumped into a suitable syntax (I support 4
different ASM syntaxes for x64).
This MCL/ASM itself has abstractions, so the same 'MOV' mnemonic is used
for a dozens of different move instructions that each have different
binary opcodes.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-16 05:12 +0800 |
| Message-ID | <86d4fb57b775c75bcd77df4088961d76c59f1ea5.camel@gmail.com> |
| In reply to | #397549 |
On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:
> On 15/04/2026 13:21, 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.
> >
> > > 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.
>
> It sounds like you don't understand the difference between a low-level
> language and a high-level one.
>
> These days C might be considered mid-level (I call it a lower-level HLL,
> because so many HLLs are much higher level and more abstract).
>
> Compiling a HLL involves lowering it to a different representation, say
> from language A to language B.
>
> But just because that translation happens to be routine, doesn't mean
> and A is essentially B.
>
> >
> > >
> > > > > > 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).
>
> That won't work in C. 'p2' is likely to be in a register; that extra
> write may be elided.
>
> You'd have to use 'volatile' to guard against that. But you still can't
> control where p2 is put into memory. C /is/ used for this stuff, but all
> sorts of special extensions, or compiler specifics, may be employed.
>
> In assembly it's much easier.
>
>
> >
> > And, in union, I don't how 'high-level' can explain the way read/write part
> > of float object officially.
> > union {
> > char carr[sizeof(float)]; // C++ guarantees sizeof(char)==1
> > float f;
> > }
>
> (Fixed that sizeof.)
>
> I normally use my own systems language. That one is aligned much more
> directly to hardware than C is, even though it is marginally higher level.
>
> This is because C is intended to work on possible hardware, while mine
> was created to work with one target as a time.
>
> Also, when I started on mine (c. 1982 rather than 1972), hardware was
> already standardising on 8-bit bytes, byte-addressed, power-of-two word
> sizes, and twos-complement integers.
>
> I don't however consider my language to be a form of assembly for lots
> of reasons already mentioned.
>
> Its compilers use 3 internal representations before it gets to native code:
>
> HLL source -> AST -> IL -> MCL -> Native
>
> 'MCL' is the internal representation of the native code. If I need ASM
> output, then MCL can be dumped into a suitable syntax (I support 4
> different ASM syntaxes for x64).
>
> This MCL/ASM itself has abstractions, so the same 'MOV' mnemonic is used
> for a dozens of different move instructions that each have different
> binary opcodes.
I have a Soft-CPU class you might be insterested suitable for various kind of
script languages. The idea should not be too difficult to implement in C.
-------------------------------------------------------------------------------
Wy.Sct.Spu(3wy) Wy.Sct.Spu(3wy)
NAME
Spu - Class of general purpose Soft-CPU
SYNOPSIS
Except POD types, C structures, all types are declared in namespace Wy.
#include <CSCall/SctBase.h>
Spu is an object oriented model (class) of Turing Machine that acts like
a general purpose CPU-based computing machine to provide semantics for
computing languages (for programming or for program communication). Ap‐
plications are both theoretical and practical.
The main differences of Spu and general purpose CPU (or TM) is that Spu
has no ´register´ nor ´flag´ (which, along with others, can be simu‐
lated), Spu has only a tape and a stack. The tape is initially empty.
Every object (referred to as tape variable or cell) in the tape is allo‐
cated via instruction Alloc and identified by a continuous index number.
Tape variable can be any C++ type, including Spu.
The instructions of Spu are application definable because they are
wildly varying from different purposes. Except necessary few, about >30
instructions are defined for convenience for common usage, see manpage
Wy.Sct(3wy).
[cut] ....
-------------------------------
The boundary of assembly and HLL is not clear to me.
I had wrote a killer-grade commercial assembly program, it may still be running
today after >30 years. My experience is that assembly is not that scary as commonly
thought, just don't think in low level.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-15 23:52 +0100 |
| Message-ID | <10rp4qv$19qr9$1@dont-email.me> |
| In reply to | #397558 |
On 15/04/2026 22:12, wij wrote: > On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: > The boundary of assembly and HLL is not clear to me. That seems to be obvious. > I had wrote a killer-grade commercial assembly program, it may still be running > today after >30 years. My experience is that assembly is not that scary as commonly > thought, just don't think in low level. It's not that scary. Just unergonomic to code in it, taking longer, being more error prone, much harder to understand, harder to maintain, much less portable ...
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-16 07:30 +0800 |
| Message-ID | <11e453027190767d7b69b8f7ec4a9d26861a1283.camel@gmail.com> |
| In reply to | #397564 |
On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: > On 15/04/2026 22:12, wij wrote: > > On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: > > > The boundary of assembly and HLL is not clear to me. > > That seems to be obvious. > > > I had wrote a killer-grade commercial assembly program, it may still be running > > today after >30 years. My experience is that assembly is not that scary as commonly > > thought, just don't think in low level. > > It's not that scary. Just unergonomic to code in it, taking longer, > being more error prone, much harder to understand, harder to maintain, > much less portable ... > Skill. Treat assembly as a chunk. Well document.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-16 00:50 +0100 |
| Message-ID | <10rp87o$1amnn$1@dont-email.me> |
| In reply to | #397566 |
On 16/04/2026 00:30, wij wrote: > On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: >> On 15/04/2026 22:12, wij wrote: >>> On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: >> >>> The boundary of assembly and HLL is not clear to me. >> >> That seems to be obvious. >> >>> I had wrote a killer-grade commercial assembly program, it may still be running >>> today after >30 years. My experience is that assembly is not that scary as commonly >>> thought, just don't think in low level. >> >> It's not that scary. Just unergonomic to code in it, taking longer, >> being more error prone, much harder to understand, harder to maintain, >> much less portable ... >> > > Skill. Treat assembly as a chunk. Well document. You're not making sense. It's like saying I should walk everywhere instead of using my car. But I don't want to spend two extra hours a day walking and carrying shopping etc. What exactly is the benefit of using assembly over a HLL when both can tackle the task? When I first started with microprocessors, I first had to build the hardware, which was programmed in binary. I wrote a hex editor so I could use a keyboard. Then used that to write an assembler. Then used the assembler to write a compiler for a simple HLL. The HLL allowed me to be far more productive than otherwise. Everybody seems to understand that, except you. But I have a counter-proposal: why don't you also program in binary machine code (I'll let you use hex!) instead of assembly? After all it's just a skill.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Lamothe <jonathan@jlamothe.net> |
|---|---|
| Date | 2026-04-15 20:17 -0400 |
| Message-ID | <874ilbiwsc.fsf@posteo.de> |
| In reply to | #397567 |
Bart <bc@freeuk.com> writes: > On 16/04/2026 00:30, wij wrote: >> On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: >>> On 15/04/2026 22:12, wij wrote: >>>> On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: >>> >>>> The boundary of assembly and HLL is not clear to me. >>> >>> That seems to be obvious. >>> >>>> I had wrote a killer-grade commercial assembly program, it may still be running >>>> today after >30 years. My experience is that assembly is not that scary as commonly >>>> thought, just don't think in low level. >>> >>> It's not that scary. Just unergonomic to code in it, taking longer, >>> being more error prone, much harder to understand, harder to maintain, >>> much less portable ... >>> >> Skill. Treat assembly as a chunk. Well document. > > > You're not making sense. It's like saying I should walk everywhere > instead of using my car. > > But I don't want to spend two extra hours a day walking and carrying > shopping etc. > > What exactly is the benefit of using assembly over a HLL when both can > tackle the task? > > When I first started with microprocessors, I first had to build the > hardware, which was programmed in binary. I wrote a hex editor so I > could use a keyboard. Then used that to write an assembler. Then used > the assembler to write a compiler for a simple HLL. > > The HLL allowed me to be far more productive than otherwise. Everybody > seems to understand that, except you. > > But I have a counter-proposal: why don't you also program in binary > machine code (I'll let you use hex!) instead of assembly? After all > it's just a skill. > Assembly is a great thing to know. It makes it easier to know what's going on under the hood of higher level languages, and can even help in trouboeshooting and reasoning about how to make your code more efficiet. Do I think that learning assembly is an asset? Absolutely. Do I think it's something that a project should be written in directly? In most cases, absolutely not. -- Regards, Jonathan Lamothe https://jlamothe.net
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-16 09:35 +0200 |
| Message-ID | <10rq3g8$1fhtd$1@dont-email.me> |
| In reply to | #397570 |
On 16/04/2026 02:17, Jonathan Lamothe wrote: > Bart <bc@freeuk.com> writes: > >> On 16/04/2026 00:30, wij wrote: >>> On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: >>>> On 15/04/2026 22:12, wij wrote: >>>>> On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: >>>> >>>>> The boundary of assembly and HLL is not clear to me. >>>> >>>> That seems to be obvious. >>>> >>>>> I had wrote a killer-grade commercial assembly program, it may still be running >>>>> today after >30 years. My experience is that assembly is not that scary as commonly >>>>> thought, just don't think in low level. >>>> >>>> It's not that scary. Just unergonomic to code in it, taking longer, >>>> being more error prone, much harder to understand, harder to maintain, >>>> much less portable ... >>>> >>> Skill. Treat assembly as a chunk. Well document. >> >> >> You're not making sense. It's like saying I should walk everywhere >> instead of using my car. >> >> But I don't want to spend two extra hours a day walking and carrying >> shopping etc. >> >> What exactly is the benefit of using assembly over a HLL when both can >> tackle the task? >> >> When I first started with microprocessors, I first had to build the >> hardware, which was programmed in binary. I wrote a hex editor so I >> could use a keyboard. Then used that to write an assembler. Then used >> the assembler to write a compiler for a simple HLL. >> >> The HLL allowed me to be far more productive than otherwise. Everybody >> seems to understand that, except you. >> >> But I have a counter-proposal: why don't you also program in binary >> machine code (I'll let you use hex!) instead of assembly? After all >> it's just a skill. >> > > Assembly is a great thing to know. It makes it easier to know what's > going on under the hood of higher level languages, and can even help in > trouboeshooting and reasoning about how to make your code more efficiet. > > Do I think that learning assembly is an asset? Absolutely. > > Do I think it's something that a project should be written in directly? > In most cases, absolutely not. > I agree entirely. I work in the field of small-systems embedded programming (these days, that means mostly 32-bit ARM devices programmed in C or C++). I see it as an advantage for programmers in the field to have done some assembly programming - they have a better understanding of what is going on, and avoid unnecessary pessimisations. People coming to this field from the world of PC programming often misunderstand how to write efficient code. (I once had someone ask me for help to improve the speed of their code on an 8-bit microcontroller. It turned out they had needed to half the value of an integer variable, and had done it by "x = x * 0.5;".) It is even an advantage, I think, for programmers to have worked with some digital electronics design. In electronics, you quickly learn that you can connect one output to two inputs, but you cannot connect two outputs to one input without additional electronics (a multiplexer, a logic gate, etc.). In programming, you often have resources (variables or something more complicated) with wide scopes - when you think of it like electronics, you get an immediate understanding of why it is a bad idea to set or change these resources in different parts of the code without some kind of coordination.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-15 23:37 -0700 |
| Message-ID | <10rq03m$1gc3i$2@dont-email.me> |
| In reply to | #397566 |
On 4/15/2026 4:30 PM, wij wrote: > On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: >> On 15/04/2026 22:12, wij wrote: >>> On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: >> >>> The boundary of assembly and HLL is not clear to me. >> >> That seems to be obvious. >> >>> I had wrote a killer-grade commercial assembly program, it may still be running >>> today after >30 years. My experience is that assembly is not that scary as commonly >>> thought, just don't think in low level. >> >> It's not that scary. Just unergonomic to code in it, taking longer, >> being more error prone, much harder to understand, harder to maintain, >> much less portable ... >> > > Skill. Treat assembly as a chunk. Well document. > > > Well crafted asm is not bad. Only used when needed! simple... :^) I found some of my old asm on the way back machine: https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-15 23:40 -0700 |
| Message-ID | <10rq094$1gc3i$3@dont-email.me> |
| In reply to | #397583 |
On 4/15/2026 11:37 PM, Chris M. Thomasson wrote: > On 4/15/2026 4:30 PM, wij wrote: >> On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: >>> On 15/04/2026 22:12, wij wrote: >>>> On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: >>> >>>> The boundary of assembly and HLL is not clear to me. >>> >>> That seems to be obvious. >>> >>>> I had wrote a killer-grade commercial assembly program, it may still >>>> be running >>>> today after >30 years. My experience is that assembly is not that >>>> scary as commonly >>>> thought, just don't think in low level. >>> >>> It's not that scary. Just unergonomic to code in it, taking longer, >>> being more error prone, much harder to understand, harder to maintain, >>> much less portable ... >>> >> >> Skill. Treat assembly as a chunk. Well document. >> >> >> > > Well crafted asm is not bad. Only used when needed! simple... :^) > > I found some of my old asm on the way back machine: > > https://web.archive.org/web/20060214112345/http:// > appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html 2005, damn time goes on bye, bye... ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-15 23:47 -0700 |
| Message-ID | <10rq0l9$1gimi$1@dont-email.me> |
| In reply to | #397584 |
On 4/15/2026 11:40 PM, Chris M. Thomasson wrote: > On 4/15/2026 11:37 PM, Chris M. Thomasson wrote: >> On 4/15/2026 4:30 PM, wij wrote: >>> On Wed, 2026-04-15 at 23:52 +0100, Bart wrote: >>>> On 15/04/2026 22:12, wij wrote: >>>>> On Wed, 2026-04-15 at 15:06 +0100, Bart wrote: >>>> >>>>> The boundary of assembly and HLL is not clear to me. >>>> >>>> That seems to be obvious. >>>> >>>>> I had wrote a killer-grade commercial assembly program, it may >>>>> still be running >>>>> today after >30 years. My experience is that assembly is not that >>>>> scary as commonly >>>>> thought, just don't think in low level. >>>> >>>> It's not that scary. Just unergonomic to code in it, taking longer, >>>> being more error prone, much harder to understand, harder to maintain, >>>> much less portable ... >>>> >>> >>> Skill. Treat assembly as a chunk. Well document. >>> >>> >>> >> >> Well crafted asm is not bad. Only used when needed! simple... :^) >> >> I found some of my old asm on the way back machine: >> >> https://web.archive.org/web/20060214112345/http:// >> appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html > > 2005, damn time goes on bye, bye... ;^o A song for using lang a to gen code for other langs: Operatique (Internal Struggle Version) https://youtu.be/A3Qc-2j-6Gc?list=RDGMEMYH9CUrFO7CfLJpaD7UR85w&t=50 ;^)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-16 13:19 +0200 |
| Message-ID | <10rqgkr$v392$7@dont-email.me> |
| In reply to | #397583 |
On 2026-04-16 08:37, Chris M. Thomasson wrote: > > Well crafted asm is not bad. Only used when needed! simple... :^) And in practice a throwaway-product once you change platform. (I'm shuddering thinking about porting my decades old DSP asm code to some other platform/CPU architecture.) But I've ported or re-used old "C" code without much effort. This is a crucial differences, especially in the light of the thread-theses. Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-16 14:28 -0700 |
| Message-ID | <10rrkap$20en1$1@dont-email.me> |
| In reply to | #397595 |
On 4/16/2026 4:19 AM, Janis Papanagnou wrote: > On 2026-04-16 08:37, Chris M. Thomasson wrote: >> >> Well crafted asm is not bad. Only used when needed! simple... :^) > > And in practice a throwaway-product once you change platform. Well, yeah, but its still there... Well, I am glad that the wayback machine still has my old code! :^) > (I'm shuddering thinking about porting my decades old DSP asm > code to some other platform/CPU architecture.) But I've ported > or re-used old "C" code without much effort. This is a crucial > differences, especially in the light of the thread-theses. Indeed. Bitch and a half, well, sometimes.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-15 23:34 -0700 |
| Message-ID | <10rpvtb$1gc3i$1@dont-email.me> |
| In reply to | #397549 |
On 4/15/2026 7:06 AM, Bart wrote:
> On 15/04/2026 13:21, 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.
>>
>>> 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.
>
> It sounds like you don't understand the difference between a low-level
> language and a high-level one.
A high level lang can dump code for a lower level one and vise versa.
Some code of mine created all in C++:
100 REM ct_vfield_applesoft_basic
110 HOME
120 HGR: HCOLOR = 3: VTAB 22
130 PRINT "ct_vfield_applesoft_basic"
140 GOSUB 1000
150 GOSUB 3000
160 SP = 0
170 RS(SP, 0) = 0
180 RS(SP, 1) = -1
190 RS(SP, 2) = 0
200 RS(SP, 3) = 1
210 RS(SP, 4) = 0
220 GOSUB 8000
230 V1(1) = 0: V1(2) = 0: V1(3) = 1: V1(4) = 128
240 GOSUB 6000
245 PRINT "Chris Thomasson's Koch Complete!"
250 END
1000 REM ct_init
1010 PRINT "ct_init"
1020 DIM A0(6)
1030 DIM V0(4)
1040 DIM V1(4)
1050 DIM V2(4)
1060 DIM V3(4)
1070 DIM V4(4)
1080 DIM V5(4)
1090 RN = 3
1100 DIM RS(RN, 16)
1110 GOSUB 2000
1120 RETURN
2000 REM ct_init_plane
2010 PRINT "ct_init_plane"
2020 A0(1) = 279: REM m_plane.m_width
2030 A0(2) = 191: REM m_plane.m_height
2040 A0(3) = 0.0126106: REM m_plane.m_xstep
2050 A0(4) = 0.0126316: REM m_plane.m_ystep
2060 A0(5) = -1.75288: REM m_plane.m_axes.m_xmin
2070 A0(6) = 1.2: REM m_plane.m_axes.m_ymax
2080 RETURN
3000 REM ct_display_plane
3010 PRINT "ct_display_plane"
3020 FOR I0 = 1 TO 6
3030 PRINT "A0("; I0; ") = " A0(I0)
3040 NEXT I0
3050 RETURN
4000 REM ct_project_point
4010 REM PRINT "ct_project_point"
4020 V0(3) = (V0(1) - A0(5)) / A0(3)
4030 V0(4) = (A0(6) - V0(2)) / A0(4)
4040 IF V0(3) < 0 THEN V0(3) = INT(V0(3) - .5)
4050 IF V0(3) >= 0 THEN V0(3) = INT(V0(3) + .5)
4060 IF V0(4) < 0 THEN V0(4) = INT(V0(4) - .5)
4070 IF V0(4) >= 0 THEN V0(4) = INT(V0(4) + .5)
4080 RETURN
5000 REM ct_plot_point
5010 REM PRINT "ct_plot_point"
5020 GOSUB 4000
5030 IF V0(3) > -1 AND V0(3) <= A0(1) AND V0(4) > -1 AND V0(4) <=
A0(2) THEN HPLOT V0(3), V0(4)
5040 RETURN
6000 REM ct_plot_circle
6010 PRINT "ct_plot_circle"
6020 AB = 6.28318 / V1(4)
6030 FOR I1 = 0 TO 6.28318 STEP AB
6040 V0(1) = V1(1) + COS(I1) * V1(3)
6050 V0(2) = V1(2) + SIN(I1) * V1(3)
6060 GOSUB 5000
6070 NEXT I1
6080 RETURN
7000 REM ct_plot_line
7010 PRINT "ct_plot_line"
7020 V0(1) = V5(1): V0(2) = V5(2)
7030 GOSUB 4000
7040 IF V0(3) < 0 THEN V0(3) = 0
7050 IF V0(3) > A0(1) THEN V0(3) = A0(1)
7060 IF V0(4) < 0 THEN V0(4) = 0
7070 IF V0(4) > A0(2) THEN V0(4) = A0(2)
7080 HPLOT V0(3), V0(4)
7090 V0(1) = V5(3): V0(2) = V5(4)
7100 GOSUB 4000
7110 IF V0(3) < 0 THEN V0(3) = 0
7120 IF V0(3) > A0(1) THEN V0(3) = A0(1)
7130 IF V0(4) < 0 THEN V0(4) = 0
7140 IF V0(4) > A0(2) THEN V0(4) = A0(2)
7150 HPLOT TO V0(3), V0(4)
7160 RETURN
8000 REM ct_koch
8010 IF RS(SP, 0) >= RN THEN RETURN
8020 PRINT "ct_koch = "; RS(SP, 0); " "; RS(SP, 1); " "; RS(SP, 2);
" "; RS(SP, 3); " "; RS(SP, 4)"
8030 RS(SP, 5) = RS(SP, 3) - RS(SP, 1) : REM difx
8040 RS(SP, 6) = RS(SP, 4) - RS(SP, 2) : REM dify
8050 RS(SP, 7) = RS(SP, 1) + RS(SP, 5) / 2 : REM dify
8060 RS(SP, 8) = RS(SP, 2) + RS(SP, 6) / 2 : REM dify
8070 RS(SP, 9) = -RS(SP, 6) : REM perpx
8080 RS(SP, 10) = RS(SP, 5) : REM perpy
8090 RS(SP, 11) = RS(SP, 7) + RS(SP, 9) / 3 : REM tipx
8100 RS(SP, 12) = RS(SP, 8) + RS(SP, 10) / 3 : REM tipy
8110 RS(SP, 13) = RS(SP, 1) + RS(SP, 5) / 3 : REM k0x
8120 RS(SP, 14) = RS(SP, 2) + RS(SP, 6) / 3 : REM k0y
8130 RS(SP, 15) = RS(SP, 3) - RS(SP, 5) / 3 : REM k1x
8140 RS(SP, 16) = RS(SP, 4) - RS(SP, 6) / 3 : REM k1y
8145 IF RS(SP, 0) < RN - 1 GOTO 8230
8150 V5(1) = RS(SP, 1): V5(2) = RS(SP, 2): V5(3) = RS(SP, 13): V5(4)
= RS(SP, 14)
8160 GOSUB 7000
8170 V5(1) = RS(SP, 13): V5(2) = RS(SP, 14): V5(3) = RS(SP, 11):
V5(4) = RS(SP, 12)
8180 GOSUB 7000
8190 V5(1) = RS(SP, 11): V5(2) = RS(SP, 12): V5(3) = RS(SP, 15):
V5(4) = RS(SP, 16)
8200 GOSUB 7000
8210 V5(1) = RS(SP, 15): V5(2) = RS(SP, 16): V5(3) = RS(SP, 3):
V5(4) = RS(SP, 4)
8220 GOSUB 7000
8230 REM line 0
8240 SP = SP + 1
8250 RS(SP, 0) = RS(SP - 1, 0) + 1
8260 RS(SP, 1) = RS(SP - 1, 1)
8270 RS(SP, 2) = RS(SP - 1, 2)
8280 RS(SP, 3) = RS(SP - 1, 13)
8290 RS(SP, 4) = RS(SP - 1, 14)
8300 GOSUB 8000
8310 SP = SP - 1
8320 REM line 1
8330 SP = SP + 1
8340 RS(SP, 0) = RS(SP - 1, 0) + 1
8350 RS(SP, 1) = RS(SP - 1, 13)
8360 RS(SP, 2) = RS(SP - 1, 14)
8370 RS(SP, 3) = RS(SP - 1, 11)
8380 RS(SP, 4) = RS(SP - 1, 12)
8390 GOSUB 8000
8400 SP = SP - 1
8410 REM line 2
8420 SP = SP + 1
8430 RS(SP, 0) = RS(SP - 1, 0) + 1
8440 RS(SP, 1) = RS(SP - 1, 11)
8450 RS(SP, 2) = RS(SP - 1, 12)
8460 RS(SP, 3) = RS(SP - 1, 15)
8470 RS(SP, 4) = RS(SP - 1, 16)
8480 GOSUB 8000
8490 SP = SP - 1
8500 REM line 3
8510 SP = SP + 1
8520 RS(SP, 0) = RS(SP - 1, 0) + 1
8530 RS(SP, 1) = RS(SP - 1, 15)
8540 RS(SP, 2) = RS(SP - 1, 16)
8550 RS(SP, 3) = RS(SP - 1, 3)
8560 RS(SP, 4) = RS(SP - 1, 4)
8570 GOSUB 8000
8580 SP = SP - 1
8590 RETURN
Guess the lang?
[...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-15 15:12 -0700 |
| Message-ID | <87zf33vpnh.fsf@example.invalid> |
| In reply to | #397538 |
wij <wyniijj5@gmail.com> writes:
> 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.
I hadn't. I realize it now that you've admitted it.
In other words, you made it up.
I don't believe there is any real-world assembler that accepts
that syntax. Your example is meaningless.
For every assembler I've used, the assembly language input
unambiguously specifies the sequence of CPU instructions in the
generated object file. Support for macros do not change that;
it just means the mapping is slightly more complicated.
Cite an example of an existing real-world assembler that does not
behave that way, and we might have something interesting to discuss.
>> > 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?
The C standard defines "behavior" as "external appearance or action",
which is admittedly vague. Run-time behavior is what happens when the
program is running on the target system. It includes things like input
and output, either to a console or to files.
The C standard specifies the behavior of this program:
#include <stdio.h>
int main(void) { puts("hello, world"); }
It does so without reference to any CPU. (Of course some CPU will be
used to implement that behavior.)
> 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.
Right, C doesn't directly support abstract mathematical integers.
Of course I agree that C is a lower level language than many others.
Python, for example, has reasonably transparent support for integers
of arbitrary width. Python is a higher level language than C.
(Notably, the Python interpreter is written in C).
That doesn't make C an assembly language.
[...]
> 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."
Again, yes, C is a relatively low-level language. And again,
C is not an assembly language.
And again, if you can cite a real-world example of the kind of
"sophisticated assembler" you're talking about, that would be an
interesting data point.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-16 07:22 +0800 |
| Message-ID | <f038b671454ee8d208b64ec645b17399ac2a4a8d.camel@gmail.com> |
| In reply to | #397560 |
On Wed, 2026-04-15 at 15:12 -0700, Keith Thompson wrote:
> wij <wyniijj5@gmail.com> writes:
> > 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.
>
> I hadn't. I realize it now that you've admitted it.
>
> In other words, you made it up.
>
> I don't believe there is any real-world assembler that accepts
> that syntax. Your example is meaningless.
>
> For every assembler I've used, the assembly language input
> unambiguously specifies the sequence of CPU instructions in the
> generated object file. Support for macros do not change that;
> it just means the mapping is slightly more complicated.
>
> Cite an example of an existing real-world assembler that does not
> behave that way, and we might have something interesting to discuss.
>
> > > > 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?
>
> The C standard defines "behavior" as "external appearance or action",
> which is admittedly vague. Run-time behavior is what happens when the
> program is running on the target system. It includes things like input
> and output, either to a console or to files.
>
> The C standard specifies the behavior of this program:
>
> #include <stdio.h>
> int main(void) { puts("hello, world"); }
>
> It does so without reference to any CPU. (Of course some CPU will be
> used to implement that behavior.)
>
> > 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.
>
> Right, C doesn't directly support abstract mathematical integers.
> Of course I agree that C is a lower level language than many others.
> Python, for example, has reasonably transparent support for integers
> of arbitrary width. Python is a higher level language than C.
> (Notably, the Python interpreter is written in C).
>
> That doesn't make C an assembly language.
>
> [...]
>
> > 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."
>
> Again, yes, C is a relatively low-level language. And again,
> C is not an assembly language.
>
> And again, if you can cite a real-world example of the kind of
> "sophisticated assembler" you're talking about, that would be an
> interesting data point.
>
> --
> Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
> void Void(void) { Void(); } /* The recursive call of the void */
I had thought questions like yours might have been due to the English problem.
I did not mean C is (equal to) assembly, but C is-a assembly (logic course 101).
And I hope the following code could explain some confusion.
----------------- file s_tut2.cpp
/* Copyright is licensed by GNU LGPL, see file COPYING. by I.J.Wang 2025
Spu program: 'instruction' is a C++ function:
"Mov a,b" performs the function of C++ expression "a=b"
"Add a,b" performs the function of C++ expression "a+=b"
"Add a,b,c" performs the function of C++ expression "c=a+b"
Build: g++ s_tut2.cpp -lwy
*/
#include <Wy.stdio.h>
#include "CSCall/Sct.h"
using namespace Wy;
using namespace Wy::Sct;
void t0() {
Errno r;
Spu spu;
// Note: In general, program.reserve(...) is needed if non-memcpy_able variable
// (String) is used. Because this spu program is simple and no error is
// thrown, we save the trouble.
/* 0 */ spu.add_instr( new Alloc<float>()); // 0 (alloc 3 float)
/* 1 */ spu.add_instr( new Alloc<float>()); // 1
/* 2 */ spu.add_instr( new Alloc<float>()); // 2
/* 3 */ spu.add_instr( new Alloc<String>()); // 3 (alloc 3 String)
/* 4 */ spu.add_instr( new Alloc<String>()); // 4
/* 5 */ spu.add_instr( new Alloc<String>()); // 5
/* 6 */ spu.add_instr( new Mov<float,float>(TpVar(0),1.32)); // init. var.
/* 7 */ spu.add_instr( new Mov<float,float>(TpVar(1),3.2));
/* 8 */ spu.add_instr( new Add<float,float>(TpVar(0),TpVar(1),TpVar(2)));
/* 9 */ spu.add_instr( new Dump<float>(TpVar(2))); // print resut of v(0)+v(1)
/* 10 */ spu.add_instr( new Dump<char>('\n'));
/* 11 */ spu.add_instr( new Mov<String,const char*>(TpVar(3),"hello "));
/* 12 */ spu.add_instr( new Mov<String,const char*>(TpVar(4),"world\n"));
/* 13 */ spu.add_instr( new Add<String,String>(TpVar(3),TpVar(4)));
/* 14 */ spu.add_instr( new Dump<String>(TpVar(3))); // print result of v(3)+v(4)
/* 15 */ spu.add_instr( new Free<String>()); // free 3 non-memcpy-able objects
/* 16 */ spu.add_instr( new Free<String>());
/* 17 */ spu.add_instr( new Free<String>());
/* 18 */ spu.add_instr( new Fin(0));
// Note: If implemented, 'the real assembly' would look much better
if((r=spu.tape.reserve(256))!=Ok) { // reserve enough capacity of tape for
WY_THROW(r); // non-copy_able object
}
if((r=spu.run( InstrIdx(0) ))!=Ok) { // run the program from InstrIdx(0)
WY_THROW(r);
}
};
int main(int argc, const char* argv[])
try {
t0();
cout << "OK" WY_ENDL;
return 0;
}
catch(const Errno& e) {
cerr << wrd(e) << WY_ENDL;
return -1; // e.c_errno();
}
catch(...) {
cerr << "main() caught(...)" WY_ENDL;
throw;
};
--------------
The intended 'assembly' of the above should look cleaner:
alloc<float> // float var. at index 0, no name
alloc<float> // float var. at index 1, no name
alloc<float> // ..
alloc<String> // String var. at index 3
alloc<String>
alloc<String>
mov [0], 1.32
mov [1], 3.2
add [0],[1],[2] // [2]= [0]+[1]
dump [2]
dump '\n'
mov [3], "hello " // [3]="hello "
mov [4], "world\n" // [4]="world\n"
add [3], [4] // [3]+=[4]
dump [3] // dump "helo world\n"
free // free allocated var.
free
free
fin // finish
--------
$make s_tut2
$./s_tut2
4.520000
hello world
OK
-----------------------------------
The 'assembly' could be 'structured assembly', but then I felt the
result should not be much different from C...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-15 16:52 -0700 |
| Message-ID | <87fr4vvl26.fsf@example.invalid> |
| In reply to | #397565 |
wij <wyniijj5@gmail.com> writes:
[104 lines deleted]
>> Again, yes, C is a relatively low-level language. And again,
>> C is not an assembly language.
>>
>> And again, if you can cite a real-world example of the kind of
>> "sophisticated assembler" you're talking about, that would be an
>> interesting data point.
[signature snipped]
When you post a followup, please trim quoted text that's not relevant to
your reply. And in particular, don't quote signatures.
> I had thought questions like yours might have been due to the English problem.
> I did not mean C is (equal to) assembly, but C is-a assembly (logic course 101).
No I don't think there's an English language issue. I understand what
you're saying.
There are a number of programming languages. C is one of them. There
are a number of assembly languages, which are a subset of the set of
programming languages.
You claim that C is an assembly language.
You're wrong. C is not an assembly language.
The meaning of "assembly language" is, I believe, reasonably
and consistently well understood. An assembly language program
specifies a particular sequence of CPU instructions as its output,
typically stored in an object file. C is not that.
> And I hope the following code could explain some confusion.
[code and 'assembly' snipped]
No, not at all.
[...]
> The 'assembly' could be 'structured assembly', but then I felt the
> result should not be much different from C...
One last try. I'm going to make a few statements, all of which
I believe to be true. For each one, please indicate whether you
agree or disagree. Feel free to elaborate, but I'm looking for a
yes/no for each.
1. An assembly language program specifies a sequence of CPU
instructions. The mapping might not be simple (e.g., macros),
but it is unambiguous.
2. A C program does not specify a sequence of CPU instructions.
(I'm ignoring inline assembly, which is a non-standard feature and
not what we're talking about.)
3. A C program specifies behavior, without reference to any particular
CPU instructions. (For example, I can write a "hello, world" C
program and compile and execute it on an x86_64 system and an ARM
system. It behaves as specified on both. The two executables have
no CPU instructions in common.)
5. C is a relatively low-level language (compared to Python,
for example).
6. The fact that C is a relatively low-level language does not imply
that C is an assembly language.
7. C is not an assembly language.
If you still think that C is an assembly language, please provide a
definition of the phrase "assembly language".
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-16 03:13 +0200 |
| Subject | [meta] signature quote (was Re: A thought of C) |
| Message-ID | <10rpd3u$v391$6@dont-email.me> |
| In reply to | #397568 |
On 2026-04-16 01:52, Keith Thompson wrote: > wij <wyniijj5@gmail.com> writes: > > [...] > > [signature snipped] > > When you post a followup, please trim quoted text that's not relevant to > your reply. And in particular, don't quote signatures. The latter was actually (partly) your fault; usually your signatures are separated by '-- ', but your recent post had '-- ' and was thus not seen as signature. Of course it could have been manually trimmed (like the other irrelevant text, as you suggested). :-) Janis
[toc] | [prev] | [next] | [standalone]
Page 17 of 19 — ← Prev page 1 … 15 16 [17] 18 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web