Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #384794 > unrolled thread
| Started by | David Brown <david.brown@hesbynett.no> |
|---|---|
| First post | 2024-05-22 18:55 +0200 |
| Last post | 2024-05-25 16:05 -0500 |
| Articles | 20 on this page of 542 — 23 participants |
Back to article view | Back to comp.lang.c
C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-22 18:55 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 14:42 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-22 22:11 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 17:26 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 14:17 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 09:38 -0300
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 17:08 +0000
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 16:06 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:11 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 13:21 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 14:49 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 11:03 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 14:17 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 12:45 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 17:06 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 13:19 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 21:27 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 17:46 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-25 08:33 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 16:51 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 16:34 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:05 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-25 08:19 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 17:14 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 02:09 +0100
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-06-06 15:01 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-22 15:53 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 22:21 -0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-23 13:11 +0100
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 09:43 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 16:19 +0200
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:25 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 13:06 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 15:45 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 18:29 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:11 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 15:58 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 13:09 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 12:51 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 16:18 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 16:25 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 19:35 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 19:01 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 23:26 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 22:27 +0100
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-26 19:19 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 23:06 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:49 +0000
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-26 19:54 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 11:10 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 23:59 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-26 22:52 +0100
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:20 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:48 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-27 11:05 +0300
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-26 10:12 -0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:17 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 13:42 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-27 17:33 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 13:52 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-28 13:21 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 23:37 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 10:02 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-14 14:30 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-14 23:39 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-15 19:17 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-15 20:27 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:39 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-16 00:20 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 01:16 +0000
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-16 12:31 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-17 00:03 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-16 16:54 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-16 20:00 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-17 10:49 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-17 13:18 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-15 17:58 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:37 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-16 16:55 +0200
Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-16 16:48 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-17 11:42 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 17:19 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 04:19 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 22:39 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 15:54 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:00 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-19 09:37 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-19 10:17 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-19 13:44 +0300
Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-19 11:57 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) scott@slp53.sl.home (Scott Lurndal) - 2024-06-19 13:46 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-19 18:02 +0300
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-19 07:25 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-19 10:49 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 07:13 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-21 13:06 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 22:48 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-22 13:40 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-21 10:15 -0400
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:32 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 04:19 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-17 11:41 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-17 14:57 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 18:57 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-18 08:12 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Kettlewell <invalid@invalid.invalid> - 2024-06-18 16:14 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-17 14:21 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 19:20 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-17 22:39 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Michael S <already5chosen@yahoo.com> - 2024-06-18 12:39 +0300
Re: Hex string literals (was Re: C23 thoughts and opinions) bart <bc@freeuk.com> - 2024-06-18 11:28 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:12 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 17:20 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:04 -0700
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-20 06:51 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-18 09:50 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 13:56 +0000
Re: Hex string literals (was Re: C23 thoughts and opinions) David Brown <david.brown@hesbynett.no> - 2024-06-18 17:21 +0200
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-18 19:25 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-18 19:38 +0100
Re: Hex string literals (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-21 22:49 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-28 00:20 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-27 17:59 -0700
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-28 15:42 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-28 13:44 -0700
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-28 05:36 +0100
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-28 15:53 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:44 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-27 01:55 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 02:48 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-27 14:03 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 02:45 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 11:30 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-29 04:17 +0000
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 06:00 +0100
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 13:58 +0200
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 17:20 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-30 02:32 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 11:09 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 13:43 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-01 01:45 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 14:34 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 17:08 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 15:48 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 18:03 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 13:55 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 16:19 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 16:28 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 16:48 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 15:04 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 17:34 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 19:03 +0100
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-31 18:36 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 22:15 +0100
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 01:25 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:24 +0100
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 05:17 -0700
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 15:08 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 17:22 -0700
objcopy -I binary etc... Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-06 14:56 +0300
Re: objcopy -I binary etc... Was: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-06 07:44 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-01 22:51 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:24 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 19:59 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 04:00 +0000
Re: Correct objcopy Usage (was Re: C23 thoughts and opinions) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 04:33 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-06-01 03:37 +0200
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:09 +0100
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-06-01 13:59 +0200
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 17:26 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 01:11 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-02 00:39 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 03:06 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-06 14:43 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-31 21:42 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-31 21:11 +0000
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-06 15:38 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-06 21:38 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 00:51 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 09:04 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 10:20 -0500
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 10:22 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:53 +0000
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-07 16:58 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 03:08 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-08 00:04 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-08 08:27 +0000
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-13 14:14 +0200
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-13 14:07 -0500
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 08:53 +0200
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-14 03:13 -0500
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 10:26 +0200
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-14 03:38 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-15 22:42 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-15 20:42 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-16 03:15 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-08 13:09 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 00:46 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 11:19 +0300
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-08 19:28 +0100
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-08 14:52 -0500
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 12:40 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 11:20 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 14:12 +0300
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 14:44 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 17:32 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 20:00 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 21:06 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-09 23:40 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-09 22:49 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-10 01:06 +0300
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-10 01:26 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-11 08:33 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-09 21:12 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-09 00:45 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 22:17 +0100
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-01 21:11 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 17:47 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-31 15:03 +0100
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-31 15:34 +0000
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-31 20:31 +0100
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 01:53 +0100
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:53 +0100
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 16:51 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 09:24 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 13:39 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 13:31 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 17:51 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-01 01:39 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-01 11:37 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:27 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-02 10:37 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 01:16 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 11:16 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:10 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-04 12:28 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 01:51 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-04 19:45 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-03 11:13 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:12 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-04 12:35 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 01:50 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-05 09:10 +0100
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-06-05 09:23 -0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-05 15:09 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-06 02:12 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-06 19:38 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:55 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-07 22:23 +0100
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 00:39 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-08 02:14 +0100
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-08 03:55 +0000
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-08 11:14 +0100
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-07 22:36 -0700
xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 14:41 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 15:06 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 17:42 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 18:56 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 18:14 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 19:20 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 19:57 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 23:23 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 00:45 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 01:29 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 09:21 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 12:44 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-28 23:08 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 01:24 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-30 02:35 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 00:40 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 10:40 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 14:04 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 22:31 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-31 15:20 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-30 19:47 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:15 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 08:57 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:59 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 11:02 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-03 14:41 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:07 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 14:41 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 00:54 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 10:32 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 13:08 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 14:10 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 15:27 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 15:19 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 14:38 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 15:43 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-29 14:57 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:54 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 17:27 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 19:27 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-29 14:07 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 22:59 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 22:46 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 01:18 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 02:31 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 12:23 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-30 14:40 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-30 14:21 -0700
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 16:41 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 08:31 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 00:06 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 13:31 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 15:15 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 16:09 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 08:29 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 16:50 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-05-30 16:00 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-30 18:28 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:10 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 10:01 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-30 11:33 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-30 12:13 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 14:14 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:51 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:12 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 10:57 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 12:38 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 12:23 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 15:23 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 15:16 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-29 18:32 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 18:41 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 21:31 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 07:49 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 13:01 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-29 10:18 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-28 17:34 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-05-29 22:08 +0100
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-30 15:05 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-05-30 14:20 -0400
Re: xxd -i vs DIY Was: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-30 12:27 -0700
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 09:55 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-31 13:45 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-31 13:33 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 04:19 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 13:40 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 04:16 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-03 18:39 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:07 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-04 04:46 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 03:58 +0000
Re: xxd -i vs DIY Was: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 09:52 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-04 11:01 +0300
Re: xxd -i vs DIY Was: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-04 10:34 +0200
Re: xxd -i vs DIY Was: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-03 22:46 -0400
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-28 13:54 -0700
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 01:03 +0100
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 20:32 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-22 22:23 -0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 02:59 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-22 21:08 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 04:20 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 04:47 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-22 21:30 -0700
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-23 07:29 +0100
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 14:32 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 13:37 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:31 +0200
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-23 20:23 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 16:25 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 20:31 +0300
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 14:28 -0700
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 17:10 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 15:43 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 02:49 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 16:40 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 15:36 +0300
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-22 14:24 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:35 +0200
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-23 16:05 -0700
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-23 16:17 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 16:50 +0200
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-24 11:08 -0700
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-24 11:21 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:22 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 23:51 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 03:13 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:42 +0200
Re: C23 thoughts and opinions - why so conservative? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-23 14:35 -0400
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 09:40 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-24 17:10 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 12:29 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-25 13:29 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 16:21 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 16:15 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-23 15:02 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-23 15:56 +0200
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-05-23 17:15 -0500
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 17:37 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-24 12:05 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-24 06:54 -0700
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-24 18:46 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-25 03:01 -0700
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-23 17:19 +0300
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-23 22:10 +0200
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 00:34 +0300
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 01:06 +0000
Re: C23 thoughts and opinions - why so conservative? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-24 07:47 +0100
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 00:31 +0000
Re: C23 thoughts and opinions - why so conservative? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-24 06:38 +0100
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 05:42 +0000
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 11:42 +0300
Re: C23 thoughts and opinions - why so conservative? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 18:35 -0700
Re: C23 thoughts and opinions - why so conservative? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 19:42 -0700
Re: C23 thoughts and opinions - why so conservative? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-23 20:28 -0700
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-24 17:57 +0200
Re: C23 thoughts and opinions - why so conservative? scott@slp53.sl.home (Scott Lurndal) - 2024-05-24 16:16 +0000
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-25 16:41 +0200
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 19:22 +0300
Re: C23 thoughts and opinions - why so conservative? bart <bc@freeuk.com> - 2024-05-24 19:38 +0100
Re: C23 thoughts and opinions - why so conservative? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-24 13:06 -0700
Re: C23 thoughts and opinions - why so conservative? bart <bc@freeuk.com> - 2024-05-24 21:20 +0100
Re: C23 thoughts and opinions - why so conservative? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 00:32 +0000
Re: C23 thoughts and opinions - why so conservative? David Brown <david.brown@hesbynett.no> - 2024-05-25 17:28 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 00:40 +0000
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-25 17:47 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-25 16:45 -0700
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-26 16:18 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB <cr88192@gmail.com> - 2024-05-26 09:48 -0500
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-26 18:12 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 02:48 +0000
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB <cr88192@gmail.com> - 2024-05-28 01:31 -0500
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-29 11:27 -0400
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-05-30 14:18 -0500
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) David Brown <david.brown@hesbynett.no> - 2024-05-28 13:56 +0200
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-27 20:26 -0700
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-05-26 18:59 -0400
Re: errno (was Re: C23 thoughts and opinions - why so conservative?) BGB <cr88192@gmail.com> - 2024-05-25 15:23 -0500
Re: C23 thoughts and opinions - why so conservative? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-23 14:38 -0700
Re: C23 thoughts and opinions - why so conservative? Michael S <already5chosen@yahoo.com> - 2024-05-24 00:48 +0300
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-23 21:25 +0200
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-23 16:49 -0300
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 07:36 +0200
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-24 09:32 +0200
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 18:34 +0200
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 09:13 +0200
Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-26 13:23 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:55 +0000
Re: C23 thoughts and opinions Lynn McGuire <lynnmcguire5@gmail.com> - 2024-05-31 18:34 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 01:27 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 11:02 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 14:03 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 16:29 +0300
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-02 19:23 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 21:44 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 12:00 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 18:34 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 16:50 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 21:05 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 19:38 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 22:58 +0300
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 21:22 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:17 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-04 11:23 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:25 +0200
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 13:30 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 12:48 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 19:17 +0000
Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-04 17:32 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:22 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:14 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 04:01 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:57 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 02:52 -0500
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-14 03:20 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:15 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-05 13:32 +0000
Re: C23 thoughts and opinions cross@spitfire.i.gajendra.net (Dan Cross) - 2024-06-05 13:59 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:59 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:12 +0000
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 06:55 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-02 19:15 +0000
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-02 12:46 -0700
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:21 +0000
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 14:16 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:23 -0700
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 13:46 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 19:21 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 20:44 -0500
Re: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-04 23:59 -0400
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 00:44 -0500
Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-05 13:29 +0000
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 13:49 -0500
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 21:14 +0200
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:28 +0200
Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 16:33 +0100
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:28 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-25 21:24 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 08:32 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 02:48 -0700
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 13:44 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 15:39 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 15:46 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 17:20 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 16:29 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 18:05 +0300
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 18:26 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 19:50 +0300
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 05:41 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 10:46 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 17:10 +0200
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 18:23 +0300
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 19:23 +0200
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 18:36 +0200
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 19:11 +0200
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:30 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 10:45 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 05:45 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 13:53 -0700
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 21:16 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-27 07:14 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:53 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 21:03 +0000
Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 08:44 +0200
Don't let the door hit you... (Was: C23 thoughts and opinions) gazelle@shell.xmission.com (Kenny McCormack) - 2024-05-23 19:58 +0000
Re: Don't let the door hit you... (Was: C23 thoughts and opinions) Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 18:35 +0200
Re: C23 thoughts and opinions Lynn McGuire <lynnmcguire5@gmail.com> - 2024-05-31 17:55 -0500
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:30 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:29 +0000
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-01 23:31 -0700
Re: C23 thoughts and opinions gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-02 13:24 +0000
Re: C23 thoughts and opinions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-06-02 16:51 +0000
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-02 19:52 +0000
Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 12:01 +0300
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:31 -0700
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-03 14:02 -0700
Re: C23 thoughts and opinions gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-03 21:48 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:36 +0200
Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-04 14:47 -0700
Re: C23 thoughts and opinions bart <bc@freeuk.com> - 2024-06-03 23:43 +0100
Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-03 16:23 -0700
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:47 +0200
Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 02:20 +0000
Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:47 +0200
Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:25 +0000
Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:29 -0700
Re: C23 thoughts and opinions Thiago Adams <thiago.adams@gmail.com> - 2024-05-24 21:35 -0300
Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-05-25 16:05 -0500
Page 3 of 28 — ← Prev page 1 2 [3] 4 5 … 28 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-26 16:25 +0100 |
| Message-ID | <v2vka0$3f4a2$1@dont-email.me> |
| In reply to | #385099 |
On 26/05/2024 14:18, Michael S wrote:
> On Sun, 26 May 2024 12:51:12 +0100
> bart <bc@freeuk.com> wrote:
>
>> On 26/05/2024 12:09, David Brown wrote:
>>> On 26/05/2024 00:58, Keith Thompson wrote:
>>
>>>> For a very large file, that could be a significant burden. (I
>>>> don't have any numbers on that.)
>>>
>>> I do :
>>>
>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
>>>
>>> (That's from a proposal for #embed for C and C++. Generating the
>>> numbers and parsing them is akin to using xxd.)
>>>
>>> More useful links:
>>>
>>> <https://thephd.dev/embed-the-details#results>
>>> <https://thephd.dev/implementing-embed-c-and-c++>
>>>
>>> (These are from someone who did a lot of the work for the
>>> proposals, and prototype implementations, as far as I understand
>>> it.)
>>>
>>>
>>>
>>> Note that I can't say how much of a difference this will make in
>>> real life. I don't know how often people need to include
>>> multi-megabyte files in their code. It certainly is not at a level
>>> where I would change any of my existing projects from external
>>> generator scripts to using #embed, but I might use it in future
>>> projects.
>>
>> I've just done my own quick test (not in C, using embed in my
>> language):
>>
>> []byte clangexe = binclude("f:/llvm/bin/clang.exe")
>>
>> proc main=
>> fprintln "clang.exe is # bytes", clangexe.len
>> end
>>
>>
>> This embeds the Clang C compiler which is 119MB. It took 1.3 seconds
>> to compile (note my compiler is not optimised).
>>
>> If I tried it using text: a 121M-line include file, with one number
>> per line, it took 144 seconds (I believe it used more RAM than was
>> available: each line will have occupied a 64-byte AST node, so nearly
>> 8GB, on a machine with only 6GB available RAM, much of which was
>> occupied).
>
> On my old PC that was not the cheapest box in the shop, but is more than
> 10 y.o. compilation speed for similarly organized (but much smaller)
> text files is as following:
> MSVC 18.00.31101 (VS 2013) - 1950 KB/sec
> MSVC 19.16.27032 (VS 2017) - 1180 KB/sec
> MSVC 19.20.27500 (VS 2019) - 1180 KB/sec
> clang 17.0.6 - 547 KB/sec (somewhat better with hex text)
> gcc 13.2.0 - 580 KB/sec
>
> So, MSVC compilers, esp. an old one, are somewhat faster than yours.
> But if there was swapping involved it's not comparable. How much time
> does it take for your compiler to produce 5MB byte array from text?
Are you talking about a 5MB array initialised like this:
unsigned char data[] = {
45,
67,
17,
... // 5M-3 more rows
};
The timing for 120M entries was challenging as it exceeded physical
memory. However that test I can also do with C compilers. Results for
120 million lines of data are:
DMC - Out-of-memory
Tiny C - Silently stopped after 13 second (I thought it had
finished but no)
lccwin32 - Insufficient memory
gcc 10.x.x - Out of memory after 80 seconds
mcc - (My product) Memory failure after 27 seconds
Clang - (Crashed after 5 minutes)
MM 144s (Compiler for my language)
So the compiler for my language did quite well, considering!
Back to the 5MB test:
Tiny C 1.7s 2.9MB/sec (Tcc doesn't use any IR)
mcc 3.7s 1.3MB/sec (my product; uses intermediate ASM)
DMC -- -- (Out of memory; 32-bit compiler)
lccwin32 3.9s 1.3MB/sec
gcc 10.x 10.6s 0.5MB/sec
clang 7.4s 0.7MB/sec (to object file only)
MM 1.4s 3.6MB/sec (compiler for my language)
MM 0.7 7.1MB/sec (MM optimised via C and gcc-O3)
As a reminder, when using my version of 'embed' in my language,
embedding a 120MB binary file took 1.3 seconds, about 90MB/second.
> But both are much faster than compiling through text. Even "slow"
> 40MB/3 is 6-7 times faster than the fastest of compilers in my tests.
Do you have a C compiler that supports #embed?
It's generally understood that processing text is slow, if representing
byte-at-a-time data. If byte arrays could be represented as sequences of
i64 constants, it would improve matters. That could be done in C, but
awkwardly, by aliasing a byte-array with an i64-array.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-26 19:35 +0300 |
| Message-ID | <20240526193549.000031a8@yahoo.com> |
| In reply to | #385115 |
On Sun, 26 May 2024 16:25:51 +0100
bart <bc@freeuk.com> wrote:
> On 26/05/2024 14:18, Michael S wrote:
> > On Sun, 26 May 2024 12:51:12 +0100
> > bart <bc@freeuk.com> wrote:
> >
> >> On 26/05/2024 12:09, David Brown wrote:
> >>> On 26/05/2024 00:58, Keith Thompson wrote:
> >>
> >>>> For a very large file, that could be a significant burden. (I
> >>>> don't have any numbers on that.)
> >>>
> >>> I do :
> >>>
> >>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
> >>>
> >>> (That's from a proposal for #embed for C and C++. Generating the
> >>> numbers and parsing them is akin to using xxd.)
> >>>
> >>> More useful links:
> >>>
> >>> <https://thephd.dev/embed-the-details#results>
> >>> <https://thephd.dev/implementing-embed-c-and-c++>
> >>>
> >>> (These are from someone who did a lot of the work for the
> >>> proposals, and prototype implementations, as far as I understand
> >>> it.)
> >>>
> >>>
> >>>
> >>> Note that I can't say how much of a difference this will make in
> >>> real life. I don't know how often people need to include
> >>> multi-megabyte files in their code. It certainly is not at a
> >>> level where I would change any of my existing projects from
> >>> external generator scripts to using #embed, but I might use it in
> >>> future projects.
> >>
> >> I've just done my own quick test (not in C, using embed in my
> >> language):
> >>
> >> []byte clangexe = binclude("f:/llvm/bin/clang.exe")
> >>
> >> proc main=
> >> fprintln "clang.exe is # bytes", clangexe.len
> >> end
> >>
> >>
> >> This embeds the Clang C compiler which is 119MB. It took 1.3
> >> seconds to compile (note my compiler is not optimised).
> >>
> >> If I tried it using text: a 121M-line include file, with one number
> >> per line, it took 144 seconds (I believe it used more RAM than was
> >> available: each line will have occupied a 64-byte AST node, so
> >> nearly 8GB, on a machine with only 6GB available RAM, much of
> >> which was occupied).
> >
> > On my old PC that was not the cheapest box in the shop, but is more
> > than 10 y.o. compilation speed for similarly organized (but much
> > smaller) text files is as following:
> > MSVC 18.00.31101 (VS 2013) - 1950 KB/sec
> > MSVC 19.16.27032 (VS 2017) - 1180 KB/sec
> > MSVC 19.20.27500 (VS 2019) - 1180 KB/sec
> > clang 17.0.6 - 547 KB/sec (somewhat better with hex text)
> > gcc 13.2.0 - 580 KB/sec
> >
> > So, MSVC compilers, esp. an old one, are somewhat faster than yours.
> > But if there was swapping involved it's not comparable. How much
> > time does it take for your compiler to produce 5MB byte array from
> > text?
>
> Are you talking about a 5MB array initialised like this:
>
> unsigned char data[] = {
> 45,
> 67,
> 17,
> ... // 5M-3 more rows
> };
>
Yes.
> The timing for 120M entries was challenging as it exceeded physical
> memory. However that test I can also do with C compilers. Results for
> 120 million lines of data are:
>
> DMC - Out-of-memory
>
> Tiny C - Silently stopped after 13 second (I thought it
> had finished but no)
>
> lccwin32 - Insufficient memory
>
> gcc 10.x.x - Out of memory after 80 seconds
>
> mcc - (My product) Memory failure after 27 seconds
>
> Clang - (Crashed after 5 minutes)
>
> MM 144s (Compiler for my language)
>
> So the compiler for my language did quite well, considering!
>
That's an interesting test as well, but I don't want to run it on my HW
right now. May be, at night.
>
> Back to the 5MB test:
>
> Tiny C 1.7s 2.9MB/sec (Tcc doesn't use any IR)
>
> mcc 3.7s 1.3MB/sec (my product; uses intermediate ASM)
Faster than new MSVC, but slower than old MSVC.
>
> DMC -- -- (Out of memory; 32-bit compiler)
>
> lccwin32 3.9s 1.3MB/sec
>
> gcc 10.x 10.6s 0.5MB/sec
>
> clang 7.4s 0.7MB/sec (to object file only)
>
> MM 1.4s 3.6MB/sec (compiler for my language)
>
> MM 0.7 7.1MB/sec (MM optimised via C and gcc-O3)
>
That's quite impressive.
Does it generate object files or goes directly to exe?
Even if later, it's still impressive.
> As a reminder, when using my version of 'embed' in my language,
> embedding a 120MB binary file took 1.3 seconds, about 90MB/second.
>
>
> > But both are much faster than compiling through text. Even "slow"
> > 40MB/3 is 6-7 times faster than the fastest of compilers in my
> > tests.
>
> Do you have a C compiler that supports #embed?
>
No, I just blindly believe the paper.
But it probably would be available in clang this year and in gcc around
start of the next year. At least I hope so.
> It's generally understood that processing text is slow, if
> representing byte-at-a-time data. If byte arrays could be represented
> as sequences of i64 constants, it would improve matters. That could
> be done in C, but awkwardly, by aliasing a byte-array with an
> i64-array.
>
I don't think that conversion from text to binary is a significant
bottleneck here. In order to get a feeling of the things, I wrote a
tiny program that converts comma-separated list of integers to a binary
file. Something quite similar to 'xxd -r' but with input format that
is more fit to our requirements. Not identical to full requirements, of
course. My utility can't handle comments and probably few other things
that are allowed in C sources, but conversion part is pretty much the
same.
It runs at 6.700 MB/s with decimal input and at 9.1 MB/s with hex input.
That with SATA SSD of sort that went out of fashion before 2020.
So, it seems that at least in case gcc a conversion part constitutes
less than 10% of the total run time.
If you want to play with it yourself, here is my source:
-- list_to_bin.c
-- takes textual input from standard input
-- writes output to binary file
-- Usage:
-- list_to_bin oufile.bin < inp_file.txt
--
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
int main(int argz, char** argv)
{
if (argz > 1) {
FILE* fp = fopen(argv[1], "wb");
if (fp) {
char buf[2048];
_Bool look_for_comma = 0;
for (;;) {
if (fgets(buf, sizeof(buf), stdin) != buf)
break;
char* p = buf;
for (;;) {
char c = *p;
if (isgraph(c)) {
if (look_for_comma) {
if (c == ',') {
look_for_comma = 0;
++p;
} else {
goto done;
}
} else {
char* endp;
long val = strtol(p, &endp, 0);
if (endp==p) // not a number
goto done;
fputc((unsigned char)val, fp);
p = endp;
look_for_comma = 1;
}
} else {
if (c == 0)
break; // end of line
++p; // skip space or control character
}
}
}
done:
fclose(fp);
} else {
perror(argv[1]);
return 1;
}
}
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-26 19:01 +0100 |
| Message-ID | <v2vtdi$3gnl6$1@dont-email.me> |
| In reply to | #385126 |
On 26/05/2024 17:35, Michael S wrote:
> On Sun, 26 May 2024 16:25:51 +0100
> bart <bc@freeuk.com> wrote:
>
>> On 26/05/2024 14:18, Michael S wrote:
>> Are you talking about a 5MB array initialised like this:
>>
>> unsigned char data[] = {
>> 45,
>> 67,
>> 17,
>> ... // 5M-3 more rows
>> };
>>
>
> Yes.
>
>> The timing for 120M entries was challenging as it exceeded physical
>> memory. However that test I can also do with C compilers. Results for
>> 120 million lines of data are:
>>
>> DMC - Out-of-memory
>>
>> Tiny C - Silently stopped after 13 second (I thought it
>> had finished but no)
>>
>> lccwin32 - Insufficient memory
>>
>> gcc 10.x.x - Out of memory after 80 seconds
>>
>> mcc - (My product) Memory failure after 27 seconds
>>
>> Clang - (Crashed after 5 minutes)
>>
>> MM 144s (Compiler for my language)
>>
>> So the compiler for my language did quite well, considering!
>>
>
> That's an interesting test as well, but I don't want to run it on my HW
> right now. May be, at night.
>
>>
>> Back to the 5MB test:
>>
>> Tiny C 1.7s 2.9MB/sec (Tcc doesn't use any IR)
>>
>> mcc 3.7s 1.3MB/sec (my product; uses intermediate ASM)
>
> Faster than new MSVC, but slower than old MSVC.
My mcc is never going to be fast, because it uses ASM, which itself will
generate a text file several times larger than the C (so the line "123,"
in C ends up as " db 123" in the ASM file).
However I've looked at a possible way of speeding this up in general,
see below.
>>
>> DMC -- -- (Out of memory; 32-bit compiler)
>>
>> lccwin32 3.9s 1.3MB/sec
>>
>> gcc 10.x 10.6s 0.5MB/sec
>>
>> clang 7.4s 0.7MB/sec (to object file only)
>>
>> MM 1.4s 3.6MB/sec (compiler for my language)
>>
>> MM 0.7 7.1MB/sec (MM optimised via C and gcc-O3)
>>
>
> That's quite impressive.
> Does it generate object files or goes directly to exe?
All produce EXE files, via linkers if necessary, except Clang (its hefty
LLVM installation doesn't come with standard C headers, nor a linker; it
depends on MS tools, but never manages to sync with them).
My MM product directly generates EXE files with no intermediate OBJ files.
> Even if later, it's still impressive.
So, it's more impressive if it first generates an OBJ file then invokes
a linker? I'd have thought that eliminating that pointless intermediate
step would be more impressive!
Anyway, I thought of a way of speeding up initialisation of byte-arrays
which is, instead of parsing each value into its own AST node, to
directly parse successive numeric values into a special data-string
object (similar to normal strings, and identical to the data-strings
used for embedded data).
Then there is only one AST node containing one 'string' value, instead
of 5M or 120M nodes.
This produced a timing, for 5M lines, of 0.34s (0.28s optimised), a
throughput of 15-18MB/sec.
When I applied this to the 120M line data (which is a 0.6GB source
file), it finished in 6.5 seconds (5.5 optimised), or 18-21MB/sec.
Previously that took 144 seconds.
However I can't keep that experimental code, since if it turns out not
all values are constant expressions, it has to revert to normal
processing, which is tricky to do; it may already have read 1M numbers
and needs to backtrack). This was just to see how fast it could be.
Processing 120MB as binary rather than text is still faster; that works
at up to 110MB/sec with an optimised compiler.
>> As a reminder, when using my version of 'embed' in my language,
>> embedding a 120MB binary file took 1.3 seconds, about 90MB/second.
>>
>>
>>> But both are much faster than compiling through text. Even "slow"
>>> 40MB/3 is 6-7 times faster than the fastest of compilers in my
>>> tests.
>>
>> Do you have a C compiler that supports #embed?
>>
>
> No, I just blindly believe the paper.
Funny that no one else has access to an implementation! Those figures
have been around for a while.
> But it probably would be available in clang this year and in gcc around
> start of the next year. At least I hope so.
>
>> It's generally understood that processing text is slow, if
>> representing byte-at-a-time data. If byte arrays could be represented
>> as sequences of i64 constants, it would improve matters. That could
>> be done in C, but awkwardly, by aliasing a byte-array with an
>> i64-array.
>>
>
> I don't think that conversion from text to binary is a significant
> bottleneck here.
That's not quite what I meant. That conversion is the lexical part of
processing source code, it can be very fast.
It is parsing, and especially constructing a list of 5M or 120M AST
nodes, each containing one expression, and the subsequent type-checking
and code generation that takes the time.
However your benchmark looks intriguing and I'll have a closer look later.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-26 23:26 +0300 |
| Message-ID | <20240526232651.00002d2e@yahoo.com> |
| In reply to | #385138 |
On Sun, 26 May 2024 19:01:21 +0100 bart <bc@freeuk.com> wrote: > On 26/05/2024 17:35, Michael S wrote: > > On Sun, 26 May 2024 16:25:51 +0100 > > bart <bc@freeuk.com> wrote: > > > > > >> > >> Back to the 5MB test: > >> > >> Tiny C 1.7s 2.9MB/sec (Tcc doesn't use any IR) > >> > >> mcc 3.7s 1.3MB/sec (my product; uses intermediate > >> ASM) > > > > Faster than new MSVC, but slower than old MSVC. > > My mcc is never going to be fast, because it uses ASM, which itself > will generate a text file several times larger than the C (so the > line "123," in C ends up as " db 123" in the ASM file). > Generation of asm at 7-8 MB/s sounds feasible even on slow computer. And once you have asm in right format, 'gnu as' processes it quite fast. On faster computer I had seen ~30 MB/s. I'd guess the slower one should be able to do it at 15 MB/s. So, generation+assembling together could run at ~5 MB/s. The trick here is to use format that 'gnu as' was optimized for. To know what it is, look at the output of gcc -S.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-26 22:27 +0100 |
| Message-ID | <v309fk$3jrtv$1@dont-email.me> |
| In reply to | #385145 |
On 26/05/2024 21:26, Michael S wrote: > On Sun, 26 May 2024 19:01:21 +0100 > bart <bc@freeuk.com> wrote: > >> On 26/05/2024 17:35, Michael S wrote: >>> On Sun, 26 May 2024 16:25:51 +0100 >>> bart <bc@freeuk.com> wrote: >>> >>> >>>> >>>> Back to the 5MB test: >>>> >>>> Tiny C 1.7s 2.9MB/sec (Tcc doesn't use any IR) >>>> >>>> mcc 3.7s 1.3MB/sec (my product; uses intermediate >>>> ASM) >>> >>> Faster than new MSVC, but slower than old MSVC. >> >> My mcc is never going to be fast, because it uses ASM, which itself >> will generate a text file several times larger than the C (so the >> line "123," in C ends up as " db 123" in the ASM file). >> > > Generation of asm at 7-8 MB/s sounds feasible even on slow computer. > And once you have asm in right format, If I take the 5M-line data file, and use `gcc -S` on it, produces an ASM file where the bytes are combined into strings. Is that the 'trick'? Then processing that ASM file can be faster. However my ASM o/p doesn't create strings like that, and the ASM file is therefore five times the size. Still, my assembler can turn my 72MB ASM file into a 5MB executable in 0.74 seconds (which is 100MB/sec). 'as' can turn its much smaller 15MB ASM (.s) file into an executable in 0.56 seconds (27MB/sec). > 'gnu as' processes it quite fast. Given the same input (ie. same set of instructions), my assembler is faster than 'as'. See this survey of assembler speeds here: https://www.reddit.com/r/Compilers/comments/1c41y6d/assembler_survey/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button Mine is the 'AA' assembler. The bottleneck here is writing the ASM file. But I don't care about that, since 'mcc' is not my primary compiler. My primary one doesn't use ASM. But even with that bottleneck, mcc compiles this data file to EXE three times as fast as gcc. My MM compiler can do so 17 times as fast as gcc. And with the optimisation I mentioned in a previous post (similar to as's trick), it could do so 35-40 times faster than gcc.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-05-26 19:19 +0100 |
| Message-ID | <v2vugh$3gso8$1@dont-email.me> |
| In reply to | #385126 |
On 26/05/2024 17:35, Michael S wrote:
> On Sun, 26 May 2024 16:25:51 +0100
> bart <bc@freeuk.com> wrote:
>
>> On 26/05/2024 14:18, Michael S wrote:
>>> On Sun, 26 May 2024 12:51:12 +0100
>>> bart <bc@freeuk.com> wrote:
>>>
>>>> On 26/05/2024 12:09, David Brown wrote:
>>>>> On 26/05/2024 00:58, Keith Thompson wrote:
>>>>
>>>>>> For a very large file, that could be a significant burden. (I
>>>>>> don't have any numbers on that.)
>>>>>
>>>>> I do :
>>>>>
>>>>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
>>>>>
>>>>> (That's from a proposal for #embed for C and C++. Generating the
>>>>> numbers and parsing them is akin to using xxd.)
>>>>>
>>>>> More useful links:
>>>>>
>>>>> <https://thephd.dev/embed-the-details#results>
>>>>> <https://thephd.dev/implementing-embed-c-and-c++>
>>>>>
>>>>> (These are from someone who did a lot of the work for the
>>>>> proposals, and prototype implementations, as far as I understand
>>>>> it.)
>>>>>
>>>>>
>>>>>
>>>>> Note that I can't say how much of a difference this will make in
>>>>> real life. I don't know how often people need to include
>>>>> multi-megabyte files in their code. It certainly is not at a
>>>>> level where I would change any of my existing projects from
>>>>> external generator scripts to using #embed, but I might use it in
>>>>> future projects.
>>>>
>>>> I've just done my own quick test (not in C, using embed in my
>>>> language):
>>>>
>>>> []byte clangexe = binclude("f:/llvm/bin/clang.exe")
>>>>
>>>> proc main=
>>>> fprintln "clang.exe is # bytes", clangexe.len
>>>> end
>>>>
>>>>
>>>> This embeds the Clang C compiler which is 119MB. It took 1.3
>>>> seconds to compile (note my compiler is not optimised).
>>>>
>>>> If I tried it using text: a 121M-line include file, with one number
>>>> per line, it took 144 seconds (I believe it used more RAM than was
>>>> available: each line will have occupied a 64-byte AST node, so
>>>> nearly 8GB, on a machine with only 6GB available RAM, much of
>>>> which was occupied).
>>>
>>> On my old PC that was not the cheapest box in the shop, but is more
>>> than 10 y.o. compilation speed for similarly organized (but much
>>> smaller) text files is as following:
>>> MSVC 18.00.31101 (VS 2013) - 1950 KB/sec
>>> MSVC 19.16.27032 (VS 2017) - 1180 KB/sec
>>> MSVC 19.20.27500 (VS 2019) - 1180 KB/sec
>>> clang 17.0.6 - 547 KB/sec (somewhat better with hex text)
>>> gcc 13.2.0 - 580 KB/sec
>>>
>>> So, MSVC compilers, esp. an old one, are somewhat faster than yours.
>>> But if there was swapping involved it's not comparable. How much
>>> time does it take for your compiler to produce 5MB byte array from
>>> text?
>>
>> Are you talking about a 5MB array initialised like this:
>>
>> unsigned char data[] = {
>> 45,
>> 67,
>> 17,
>> ... // 5M-3 more rows
>> };
>>
>
> Yes.
>
>> The timing for 120M entries was challenging as it exceeded physical
>> memory. However that test I can also do with C compilers. Results for
>> 120 million lines of data are:
>>
>> DMC - Out-of-memory
>>
>> Tiny C - Silently stopped after 13 second (I thought it
>> had finished but no)
>>
>> lccwin32 - Insufficient memory
>>
>> gcc 10.x.x - Out of memory after 80 seconds
>>
>> mcc - (My product) Memory failure after 27 seconds
>>
>> Clang - (Crashed after 5 minutes)
>>
>> MM 144s (Compiler for my language)
>>
>> So the compiler for my language did quite well, considering!
>>
>
> That's an interesting test as well, but I don't want to run it on my HW
> right now. May be, at night.
>
>>
>> Back to the 5MB test:
>>
>> Tiny C 1.7s 2.9MB/sec (Tcc doesn't use any IR)
>>
>> mcc 3.7s 1.3MB/sec (my product; uses intermediate ASM)
>
> Faster than new MSVC, but slower than old MSVC.
>
>>
>> DMC -- -- (Out of memory; 32-bit compiler)
>>
>> lccwin32 3.9s 1.3MB/sec
>>
>> gcc 10.x 10.6s 0.5MB/sec
>>
>> clang 7.4s 0.7MB/sec (to object file only)
>>
>> MM 1.4s 3.6MB/sec (compiler for my language)
>>
>> MM 0.7 7.1MB/sec (MM optimised via C and gcc-O3)
>>
>
> That's quite impressive.
> Does it generate object files or goes directly to exe?
> Even if later, it's still impressive.
>
>> As a reminder, when using my version of 'embed' in my language,
>> embedding a 120MB binary file took 1.3 seconds, about 90MB/second.
>>
>>
>>> But both are much faster than compiling through text. Even "slow"
>>> 40MB/3 is 6-7 times faster than the fastest of compilers in my
>>> tests.
>>
>> Do you have a C compiler that supports #embed?
>>
>
> No, I just blindly believe the paper.
> But it probably would be available in clang this year and in gcc around
> start of the next year. At least I hope so.
>
>> It's generally understood that processing text is slow, if
>> representing byte-at-a-time data. If byte arrays could be represented
>> as sequences of i64 constants, it would improve matters. That could
>> be done in C, but awkwardly, by aliasing a byte-array with an
>> i64-array.
>>
>
> I don't think that conversion from text to binary is a significant
> bottleneck here. In order to get a feeling of the things, I wrote a
> tiny program that converts comma-separated list of integers to a binary
> file. Something quite similar to 'xxd -r' but with input format that
> is more fit to our requirements. Not identical to full requirements, of
> course. My utility can't handle comments and probably few other things
> that are allowed in C sources, but conversion part is pretty much the
> same.
> It runs at 6.700 MB/s with decimal input and at 9.1 MB/s with hex input.
> That with SATA SSD of sort that went out of fashion before 2020.
>
> So, it seems that at least in case gcc a conversion part constitutes
> less than 10% of the total run time.
>
> If you want to play with it yourself, here is my source:
>
> -- list_to_bin.c
> -- takes textual input from standard input
> -- writes output to binary file
> -- Usage:
> -- list_to_bin oufile.bin < inp_file.txt
> --
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
>
> int main(int argz, char** argv)
> {
> if (argz > 1) {
> FILE* fp = fopen(argv[1], "wb");
> if (fp) {
> char buf[2048];
> _Bool look_for_comma = 0;
> for (;;) {
> if (fgets(buf, sizeof(buf), stdin) != buf)
> break;
>
> char* p = buf;
> for (;;) {
> char c = *p;
> if (isgraph(c)) {
> if (look_for_comma) {
> if (c == ',') {
> look_for_comma = 0;
> ++p;
> } else {
> goto done;
> }
> } else {
> char* endp;
> long val = strtol(p, &endp, 0);
> if (endp==p) // not a number
> goto done;
> fputc((unsigned char)val, fp);
> p = endp;
> look_for_comma = 1;
> }
> } else {
> if (c == 0)
> break; // end of line
> ++p; // skip space or control character
> }
> }
> }
> done:
> fclose(fp);
> } else {
> perror(argv[1]);
> return 1;
> }
> }
> return 0;
> }
>
The Baby X resource compiler has a 'binary' tag to embed binary data.
The biggest file in my documents folder was a 33 mb boost zipped image.
And the resouce compiler, built in debug mode, took five seconds to
convert that to a C source file with an array of unsigned chars.
It then took gcc about 20 seconds to compile it to an object file.
The output file was 218 mb. It goes straight in the bin.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-26 23:06 +0300 |
| Message-ID | <20240526230028.00003635@yahoo.com> |
| In reply to | #385140 |
On Sun, 26 May 2024 19:19:59 +0100 Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > The Baby X resource compiler has a 'binary' tag to embed binary data. > The biggest file in my documents folder was a 33 mb boost zipped > image. And the resouce compiler, built in debug mode, took five > seconds to convert that to a C source file with an array of unsigned > chars. > > It then took gcc about 20 seconds to compile it to an object file. > If '33 mb' means 33 MB and 'about 20 seconds' means 20 seconds then your gcc compiles at 1.65 MB/s. That's 2.8x faster than gcc on my old test machine and 1.7 times faster than gcc 13.2.0 on much faster machine with quite good PCIe-attached SSD. Sounds interesting. What are your HW, OS and environment? Can you show us an example of your output format? > The output file was 218 mb. It goes straight in the bin. >
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-27 00:49 +0000 |
| Message-ID | <v30lak$3mcj6$3@dont-email.me> |
| In reply to | #385144 |
On Sun, 26 May 2024 23:06:47 +0300, Michael S wrote: > On Sun, 26 May 2024 19:19:59 +0100 Malcolm McLean > <malcolm.arthur.mclean@gmail.com> wrote: > >> ... was a 33 mb boost zipped image. >> > If '33 mb' means 33 MB ... Yeah, I wondered about that. Never saw anybody measure things in “millibits” before ...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-05-26 19:54 -0700 |
| Message-ID | <v30sl1$3rl7g$1@dont-email.me> |
| In reply to | #385159 |
On 5/26/2024 5:49 PM, Lawrence D'Oliveiro wrote: > On Sun, 26 May 2024 23:06:47 +0300, Michael S wrote: > >> On Sun, 26 May 2024 19:19:59 +0100 Malcolm McLean >> <malcolm.arthur.mclean@gmail.com> wrote: >> >>> ... was a 33 mb boost zipped image. >>> >> If '33 mb' means 33 MB ... > > Yeah, I wondered about that. Never saw anybody measure things in > “millibits” before ... 33 MB at 33 millibars... ;^)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-27 11:10 +0200 |
| Message-ID | <v31ilu$3v3ff$3@dont-email.me> |
| In reply to | #385159 |
On 27/05/2024 02:49, Lawrence D'Oliveiro wrote: > On Sun, 26 May 2024 23:06:47 +0300, Michael S wrote: > >> On Sun, 26 May 2024 19:19:59 +0100 Malcolm McLean >> <malcolm.arthur.mclean@gmail.com> wrote: >> >>> ... was a 33 mb boost zipped image. >>> >> If '33 mb' means 33 MB ... > > Yeah, I wondered about that. Never saw anybody measure things in > “millibits” before ... I've seen communication systems that had transfer speeds measured in mbps - millibits per second.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-26 23:59 +0300 |
| Message-ID | <20240526235955.000059ee@yahoo.com> |
| In reply to | #385126 |
On Sun, 26 May 2024 19:35:49 +0300 Michael S <already5chosen@yahoo.com> wrote: > On Sun, 26 May 2024 16:25:51 +0100 > bart <bc@freeuk.com> wrote: > > > On 26/05/2024 14:18, Michael S wrote: > > > The timing for 120M entries was challenging as it exceeded physical > > memory. However that test I can also do with C compilers. Results > > for 120 million lines of data are: > > > > DMC - Out-of-memory > > > > Tiny C - Silently stopped after 13 second (I thought it > > had finished but no) > > > > lccwin32 - Insufficient memory > > > > gcc 10.x.x - Out of memory after 80 seconds > > > > mcc - (My product) Memory failure after 27 seconds > > > > Clang - (Crashed after 5 minutes) > > > > MM 144s (Compiler for my language) > > > > So the compiler for my language did quite well, considering! > > > > That's an interesting test as well, but I don't want to run it on my > HW right now. May be, at night. > Done. On bigger gear it was not as bad as I expected. Input file: 155,488,672 bytes C source (decimal, one number per line): 641,236,315 bytes gcc compilation time: 3m54.635s peak memory consumption by compiler: ~27 GB 0.66 MB/s, only 25-30% slower rate than 5 MB input on the same HW That is, slow, but not sky is falling sort of slow.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-26 22:52 +0100 |
| Message-ID | <v30auq$3kcu9$1@dont-email.me> |
| In reply to | #385126 |
On 26/05/2024 17:35, Michael S wrote:
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
>
> int main(int argz, char** argv)
> {
> if (argz > 1) {
> FILE* fp = fopen(argv[1], "wb");
> if (fp) {
> char buf[2048];
> _Bool look_for_comma = 0;
> for (;;) {
> if (fgets(buf, sizeof(buf), stdin) != buf)
> break;
>
> char* p = buf;
> for (;;) {
> char c = *p;
> if (isgraph(c)) {
> if (look_for_comma) {
> if (c == ',') {
> look_for_comma = 0;
> ++p;
> } else {
> goto done;
> }
> } else {
> char* endp;
> long val = strtol(p, &endp, 0);
> if (endp==p) // not a number
> goto done;
> fputc((unsigned char)val, fp);
> p = endp;
> look_for_comma = 1;
> }
> } else {
> if (c == 0)
> break; // end of line
> ++p; // skip space or control character
> }
> }
> }
> done:
> fclose(fp);
> } else {
> perror(argv[1]);
> return 1;
> }
> }
> return 0;
> }
I tried this on my 600MB data like this:
C:\c>c fred.exe <data
C:\c>fred --version
clang version 18.1.0rc
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\c
Since those bytes represent the contents of the clang compiler, I was
able to run it afterwards.
All versions across compilers/optimise levels seemed to give a constant
time of 17-18 seconds. This is good compared with my initial 144 seconds
(most compilers failed; you reported a similar test took several minutes).
However, what's involved with a compiler is much elaborate than such a
program. There's syntax, type-checking, code-generation...
Still, I reported earlier an experimental change to my non-C compiler,
which translated this same input to a program with that embedded binary
(not just the binary itself) in under 6 seconds.
That's three times as fast as the above result:
C:\mapps>tm \mx2\mm -ext test2 # tm is timing tool
Compiling test2.m to test2.exe
TM: 5.86 # (timings vary)
C:\mapps>test2
data is 119571969 bytes
C:\mapps>type test2.m
[]byte data = (
include "data"
0)
proc main=
fprintln "data is # bytes", data.len
end
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-26 16:20 -0700 |
| Message-ID | <87le3wyxcl.fsf@nosuchdomain.example.com> |
| In reply to | #385126 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> If you want to play with it yourself, here is my source:
>
> -- list_to_bin.c
> -- takes textual input from standard input
> -- writes output to binary file
> -- Usage:
> -- list_to_bin oufile.bin < inp_file.txt
> --
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
[...]
FYI, my newsreader interpreted everything following the "-- " line as a
signature. (It displayed it in italics, which isn't much of a problem.)
--
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-27 00:48 +0000 |
| Message-ID | <v30l85$3mcj6$2@dont-email.me> |
| In reply to | #385126 |
On Sun, 26 May 2024 19:35:49 +0300, Michael S wrote: > Faster than new MSVC, but slower than old MSVC. New MSVC is slower than old MSVC?!? Say it isn’t so!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-27 11:05 +0300 |
| Message-ID | <20240527110547.00006d07@yahoo.com> |
| In reply to | #385158 |
On Mon, 27 May 2024 00:48:05 -0000 (UTC) Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Sun, 26 May 2024 19:35:49 +0300, Michael S wrote: > > > Faster than new MSVC, but slower than old MSVC. > > New MSVC is slower than old MSVC?!? Say it isn’t so! Is not it a case for just about any compiler that has a long history of development? Compilers become slower over time. In return they support newer dialects of input language and generate better diagnostics. They also try to produce faster code, with very varying levels of success. This trend was most easily seen during first decade of LLVM/clang.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-05-26 10:12 -0300 |
| Message-ID | <a4d1a54e-5380-4ef9-b61e-d455ee344c71@gmail.com> |
| In reply to | #385092 |
Em 5/26/2024 8:09 AM, David Brown escreveu:
>
> That's the idea. In theory, C pre-processors and C compilers are
> independent programs with a standardised format between them - in
> practice, they are often part of the same binary, and almost invariably
> come from the same developers. The "cpp" program may have to generate
> standard preprocessed output, and the "cc" program may have to accept
> standard preprocessed output, but there is nothing to stop the pair of
> programs supporting extended formats that are more efficient.
I will never stop saying, preprocessor and compiler should be integrated
in a way programmers will a most not notice.
The way preprocessor sends information to the compiler is using special
tokens . For instance when pragma is used.
But how to send information to latter phases like static analysis that
uses AST? One solution is to use existing parts of AST and attaching
some extra information carried by these especial tokens. But this is
very confusing. What is the rule what is the grammar? What parts of the
AST will have pragma tokens ?
The solution I adopt in cake is to make pragma part of the grammar and
then participating on AST. So pragma survives the preprocessor arriving
at compiler as an especial token, and compiler includes the pragma
inside the AST as if it was part of the grammar. (I put pragma into the
grammar similarly of static_assert, it can be extended to other usages
if necessary)
I don´t know how GCC works, but I suspect it is doing something similar
because I checked with this sample
void f(int
#warning message
i)
{}
void f2(int
#pragma GCC diagnostic push /*FAIL*/
i)
{}
In this sample we have this error
<source>:7:9: error: expected ';', ',' or ')' before '#pragma'
7 | #pragma GCC diagnostic push
https://godbolt.org/z/WEEK8desq
Then this, in my view, is telling that GCC is using something similar of
what I did.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-26 16:17 -0700 |
| Message-ID | <87plt8yxgn.fsf@nosuchdomain.example.com> |
| In reply to | #385092 |
David Brown <david.brown@hesbynett.no> writes:
> On 26/05/2024 00:58, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 25/05/2024 03:29, Keith Thompson wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 23/05/2024 14:11, bart wrote:
>>>>> [...]
>>>>>>> 'embed' was discussed a few months ago. I disagreed with the poor
>>>>>>> way it was to be implemented: 'embed' notionally generates a list of
>>>>>>> comma-separated numbers as tokens, where you have to take care of
>>>>>>> any trailing zero yourself if needed. It would also be hopelessly
>>>>>>> inefficient if actually implemented like that.
>>>>>>
>>>>>> Fortunately, it is /not/ actually implemented like that - it is only
>>>>>> implemented "as if" it were like that. Real prototype implementations
>>>>>> (for gcc and clang - I don't know about other tools) are extremely
>>>>>> efficient at handling #embed. And the comma-separated numbers can be
>>>>>> more flexible in less common use-cases.
>>>>> [...]
>>>>>
>>>>> I'm aware of a proposed implementation for clang:
>>>>>
>>>>> https://github.com/llvm/llvm-project/pull/68620
>>>>> https://github.com/ThePhD/llvm-project
>>>>>
>>>>> I'm currently cloning the git repo, with the aim of building it so I can
>>>>> try it out and test some corner cases. It will take a while.
>>>>>
>>>>> I'm not aware of any prototype implementation for gcc. If you are, I'd
>>>>> be very interested in trying it out.
>>>>>
>>>>> (And thanks for starting this thread!)
>>>> I've built this from source, and it mostly works. I haven't seen it
>>>> do
>>>> any optimization; the `#embed` directive expands to a sequence of
>>>> comma-separated integer constants.
>>>> Which means that this:
>>>> #include <stdio.h>
>>>> int main(void) {
>>>> struct foo {
>>>> unsigned char a;
>>>> unsigned short b;
>>>> unsigned int c;
>>>> double d;
>>>> };
>>>> struct foo obj = {
>>>> #embed "foo.dat"
>>>> };
>>>> printf("a=%d b=%d c=%d d=%f\n", obj.a, obj.b, obj.c, obj.d);
>>>> }
>>>> given "foo.dat" containing bytes with values 1, 2, 3, and 4,
>>>> produces
>>>> this output:
>>>> a=1 b=2 c=3 d=4.000000
>>>
>>> That is what you would expect by the way #embed is specified. You
>>> would not expect to see any "optimisation", since optimisations should
>>> not change the results (apparent from choosing between alternative
>>> valid results).
>>>
>>> Where you will see the optimisation difference is between :
>>>
>>> const int xs[] = {
>>> #embed "x.dat"
>>> };
>>>
>>> and
>>>
>>> const int xs[] = {
>>> #include "x.csv"
>>> };
>>>
>>>
>>> where "x.dat" is a large binary file, and "x.csv" is the same data as
>>> comma-separated values. The #embed version will compile very much
>>> faster, using far less memory. /That/ is the optimisation.
>> Why would it compile faster? #embed expands to something similar to
>> CSV, which still has to be parsed.
>
> No, it does /not/. That's the /whole/ point of #embed, and the main
> motivation for its existence. People have always managed to embed
> binary source files into their binary output files - using linker
> tricks, or using xxd or other tools (common or specialised) to turn
> binary files into initialisers for constant arrays (or structs). I've
> done so myself on many projects, all integrated together in makefiles.
>
> #embed has two purposes. One is to save you from using external tools
> for that kind of thing. The other is to do it more efficiently for
> big files.
>
> There are two ways this is done for examples like this. One is that
> is that the compiler does /not/ turn each byte into a series of ASCII
> digits for the number, then parse that number to get back to a byte.
> It jumps straight from byte in to byte out, possibly after expanding
> to a bigger type size if necessary. Secondly, compilers typically
> track lots more information about each initialiser - such as the file,
> line and column number so that it can give you helpful messages if
> there is a value out of range, or too many or too few initialisers.
> With #embed, the compiler doesn't have to do any of that.
>
> The compiler will generate results /as if/ it had expanded the file to
> a list of numbers and parsed them. But it will not do that in
> practice. (At least, not for more serious implementations - simple
> solutions might do so to get support implemented quickly.)
I'll start by acknowledging that the prototype information apparently
*does* optimize #embed when it can. I was mistaken on that point.
#embed *must* expand to the standard-defined comma-delimited sequence in
*some* cases.
Which means that the piece of the compiler that implements #embed has to
recognize when it must generate that sequence, and when it can do
something more efficient.
>> Reference:
>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf>
>> 6.10.4.
>> The first one will probably initialize each int element of xs to a
>> single byte value extracted from x.dat. Is that what you intended?
>
> Yes, if that's what the programmer wrote - though I agree that
> character types will be more common and will be the prime target for
> optimisation.
>
>> #embed works best with arrays of unsigned char.
>
> Sure, that will be a very common use.
>
>> If you mean that the #embed will expand to something other than the
>> sequence of integer constants, how does it know to do that in this
>> context?
>
> It knows because the compiler writers are actually quite smart. The C
> standards may describe the translation process in a series of distinct
> and independent phases, but that's not how it is done in practice.
> The key point is that the compiler knows how the sequence of integers
> is going to be used before it gets that far in the preprocessing.
>
> I'd expect implementations to have extremely fast implementations for
> initialising arrays of character types, and probably also for other
> arrays of scaler types. More complicated examples - such as
> parameters in a macro or function call - would probably use a
> fall-back of generating naïve lists of integer constants.
My problem is not just with how the compiler can figure out when it can
optimize, but how programmers are supposed to understand whatever rules
it uses. Can I rely on the optimization being performed if I use a
typedef for unsigned char, or if I use an enumeration type whose
underlying type is unsigned char, or if I have initialization elements
befor and after the #embed directive?
Effective use of #embed requires too much "magic" for my taste --
particularly having the preprocessor rely on information from later
phases. The semantics of #embed don't rely on that information, but
efficient use for large files does.
>> If you have a binary file containing a sequence of int values, you
>> can
>> use #embed to initialize an unsigned char array that's aliased with or
>> copied to the int array.
>> The *embed element width* is typically going to be CHAR_BIT bits by
>> default. It can only be changed by an *implementation-defined* embed
>> parameter. It seems odd that there's no standard way to specify the
>> element width.
>> It seems even more odd that the embed element width is
>> implementation defined and not set to CHAR_BIT by default.
>
> I agree. But it may be left flexible for situations where the host
> and target have different ideas about CHAR_BIT. (Targets with
> CHAR_BIT other than 8 are very rare, hosts with CHAR_BIT other than 8
> are non-existent, but C remains flexible.)
I would think that you'd want the element width to match CHAR_BIT *on
the target* (which is the only CHAR_BIT that's relevant or available).
If you're cross-compiling, you'd probably want to embed a file that
could have been used on the target system.
And if I'm not doing that kind of exotic cross-compiling, I can't rely
on the element width being CHAR_BIT *or* on any standard way to specify
that I want it to be CHAR_BIT.
Requiring the default width to be CHAR_BIT would, I'm guessing, solve
99% of cases. Allowing it to be specified by a parameter would solve
the remaing 1%. And I expect it *will* be CHAR_BIT in most or all
implementations, and programmers will rely on that assumption. I think
the standard should guarantee that.
>> A conforming implementation could set the embed element width to,
>> say, 4*CHAR_BIT and then not provide an implementation-defined embed
>> parameter to specify a different width, making #embed unusable for
>> unsigned char arrays. (N3220 is a draft, not the final C23 standard,
>> but I haven't heard about any changes in this area.)
>> The kind of optimization I was thinking about was having #embed, in
>> some
>> cases, expand to something other than the specified sequence of
>> comma-separated integer constants. Such an optimization would be
>> intended to improve compile-time speed and memory usage, not run-time
>> performance.
>> With a straightforward implementation, the preprocessor has to
>> generate
>> a sequence of integer constants as text, and then later compiler phases
>> have to parse that text sequence and generate the corresponding code.
>> Given:
>> const unsigned char data[4] = {
>> #embed "four_bytes.dat"
>> }
>> That 4 byte data file is translated to something like "1, 2, 3,
>> 4", then
>> converted into a stream of tokens, then those tokens are parsed, then,
>> given the context, the original 4-byte sequence is written into the
>> generated object file.
>> For a very large file, that could be a significant burden. (I don't
>> have any numbers on that.)
>
> I do :
>
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics>
>
> (That's from a proposal for #embed for C and C++. Generating the
> numbers and parsing them is akin to using xxd.)
>
> More useful links:
>
> <https://thephd.dev/embed-the-details#results>
> <https://thephd.dev/implementing-embed-c-and-c++>
>
> (These are from someone who did a lot of the work for the proposals,
> and prototype implementations, as far as I understand it.)
That second link does have a lot of good information. I think I had
seen it before, but I hadn't read it thoroughly. It refers to prototype
implementations for both gcc and clang. I've built the prototype on my
system, and godbolt.org has it, but the gcc prototype (for which the
article provides good performance data) doesn't seem to be available
anywhere.
My experiments with the clang prototype have been a bit confusing. I
assumed that `clang -E` would give me meaningful results, but it always
produces the comma-delimited sequence of integer constants, and even
that output is inconsistent. It looks like "-E" synthesizes naive and
not entirely correct output. Feeding that output to clang produces
warnings that I don't get without "-E". Some of this might be the
result of user error on my part.
I did some tests with 100MB file, both with #embed and with #include
using the output of "xxd". #embed *is* much faster.
According to <https://thephd.dev/implementing-embed-c-and-c++>, it
internally generates __builtin_pp_embed, which takes as arguments the
expected type (always unsigned char for now), the filename as a string
literal, and the data encoded as a base64 string literal. That's not
going to be as fast as a hypothetical pure binary blob, but apparently
it's still much faster than parsing a comma-delimited sequence.
I haven't been able to get "clang -E" in the prototype to generate
__builtin_pp_embed, or to get clang to recognize it. There are internal
things going on that I don't understand.
The author points out that using binary blobs would break tools that
work with -E preprocessed source files. If you could assume that the
preprocessed output will be processed only by the same compiler, that
wouldn't be an issue, but apparently that's not a safe assumption.
The author acknowedges that the prototype implementation doesn't handle
all cases correctly.
> Note that I can't say how much of a difference this will make in real
> life. I don't know how often people need to include multi-megabyte
> files in their code. It certainly is not at a level where I would
> change any of my existing projects from external generator scripts to
> using #embed, but I might use it in future projects.
>
>
>> An optimized version might have the preprocessor generate some
>> compiler-specific binary output, say something like "@rawdata N"
>> followed by N bytes of raw data. Later compiler phases recognize the
>> "@rawdata" construct and directly dump the data into the object file in
>> the right place. Making #embed generate @rawdata is only part of the
>> solution; the compiler has to implement @rawdata in a way that allows it
>> to be used inside an initializer, or perhaps in any other appropriate
>> context.
>
> That's the idea. In theory, C pre-processors and C compilers are
> independent programs with a standardised format between them - in
> practice, they are often part of the same binary, and almost
> invariably come from the same developers. The "cpp" program may have
> to generate standard preprocessed output, and the "cc" program may
> have to accept standard preprocessed output, but there is nothing to
> stop the pair of programs supporting extended formats that are more
> efficient.
>
>> This could be substantially more efficient for something like:
>> static const unsigned char data[] = {
>> #embed "bigfile.dat"
>> };
>> Of course it wouldn't handle my test case above. But #embed can
>> take
>> parameters, so it could generate the standard sequence by default and
>> "@rawdata" if you ask for it.
>> I don't know whether this kind of optimization is worthwhile, i.e.,
>> whether the straightforward implementation really imposes significant
>> commpile-time performance penalties that @rawdata or equivalent can
>> solve. I also don't know whether existing implementations will
>> implement this kind of optimization (so far they haven't implemented
>> #embed at all).
>
> Prototypes have been made, and they do have such optimisations. How
> things end up in real tools remains to be seen, of course.
Here's how I personally would have preferred for #embed to be specified:
- As in current C23 drafts, #embed with no parameters must operate *as
if* it expanded to a comma-delimited list of integer constant
expressions.
- With no parameters, both the common cases (initializing an array of
characters) and odd cases (e.g., initializing a struct object with
varying types and sizes of members) must work as specified.
- A standard-defined parameter allows control over optimization.
The parameter can be "optimize(true)" or "optimize(false)".
"optimize(false)" has no formal effect, but the compiler *should*
generate the canonical sequence of constants.
"optimize(true)" causes undefined behavior if #embed is used in a
context other than the initialization of an array of character type.
A naive compiler can quietly ignore the optimize() parameter and always
generate the comma-delimited sequence. An exceedingly clever compiler
could ignore it and always make a correct decision about whether to
optimize #embed.
Without the optimize parameter, typical compilers are expected to
optimize #embed depending on the context in which it's used, and should
produce the correct results in all cases. The parameter can be used to
override the compiler's judgement.
Another possibility might have been to specify that #embed can *only* be
used to initialize an array of character type, and any other use either
has undefined behavior or is a constraint violation. That would avoid
all the complication of determining from context whether it can be
optimized, and would probably cover 99% of cases. But it's probably too
late for that.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-27 13:42 +0200 |
| Message-ID | <v31rj5$o20$1@dont-email.me> |
| In reply to | #385154 |
On 27/05/2024 01:17, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 26/05/2024 00:58, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 25/05/2024 03:29, Keith Thompson wrote: >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>>> On 23/05/2024 14:11, bart wrote: >>>>>> [...] >> >> The compiler will generate results /as if/ it had expanded the file to >> a list of numbers and parsed them. But it will not do that in >> practice. (At least, not for more serious implementations - simple >> solutions might do so to get support implemented quickly.) > > I'll start by acknowledging that the prototype information apparently > *does* optimize #embed when it can. I was mistaken on that point. > > #embed *must* expand to the standard-defined comma-delimited sequence in > *some* cases. > > Which means that the piece of the compiler that implements #embed has to > recognize when it must generate that sequence, and when it can do > something more efficient. Yes, exactly. >> I'd expect implementations to have extremely fast implementations for >> initialising arrays of character types, and probably also for other >> arrays of scaler types. More complicated examples - such as >> parameters in a macro or function call - would probably use a >> fall-back of generating naïve lists of integer constants. > > My problem is not just with how the compiler can figure out when it can > optimize, but how programmers are supposed to understand whatever rules > it uses. Can I rely on the optimization being performed if I use a > typedef for unsigned char, or if I use an enumeration type whose > underlying type is unsigned char, or if I have initialization elements > befor and after the #embed directive? I don't know if that is something the programmer should need to consider, at least for most cases. Generally as a programmer you don't consider the compilation speed when writing code. You simply expect that compiler writers try to make their tools as fast as reasonably possible without sacrificing features. Sometimes there can be particular use-cases where the programmer has to look at the compiler manuals and adapt the code or build procedures to suit. I think that will be the case here too - compiler manuals should document what types of #embed usage they optimise. But I think it is unlikely that people writing portable code will do anything other than initialising a const (or constexpr) array of unsigned char if they have big enough files for optimisation to be relevant. Any compiler that does any #embed optimisation will handle this case. And even simple #embed implementations will likely be better than any alternatives (such as using xxd). > > Effective use of #embed requires too much "magic" for my taste -- > particularly having the preprocessor rely on information from later > phases. The semantics of #embed don't rely on that information, but > efficient use for large files does. > It is a violation of the neat layered (or pipeline) view of C compilation. But you could argue that this has been broken for decades - you have _Pragma that is syntactically an operator but duplicates preprocessor work, you have compiler pragmas that duplicate command-line flags (and command-line flags that duplicate preprocessor defines), you have pre-compiled headers, you have LTO that passes data multiple times through different parts of the pipeline. >>> If you have a binary file containing a sequence of int values, you >>> can >>> use #embed to initialize an unsigned char array that's aliased with or >>> copied to the int array. >>> The *embed element width* is typically going to be CHAR_BIT bits by >>> default. It can only be changed by an *implementation-defined* embed >>> parameter. It seems odd that there's no standard way to specify the >>> element width. >>> It seems even more odd that the embed element width is >>> implementation defined and not set to CHAR_BIT by default. >> >> I agree. But it may be left flexible for situations where the host >> and target have different ideas about CHAR_BIT. (Targets with >> CHAR_BIT other than 8 are very rare, hosts with CHAR_BIT other than 8 >> are non-existent, but C remains flexible.) > > I would think that you'd want the element width to match CHAR_BIT *on > the target* (which is the only CHAR_BIT that's relevant or available). > If you're cross-compiling, you'd probably want to embed a file that > could have been used on the target system. Yes, I think so. > > And if I'm not doing that kind of exotic cross-compiling, I can't rely > on the element width being CHAR_BIT *or* on any standard way to specify > that I want it to be CHAR_BIT. > > Requiring the default width to be CHAR_BIT would, I'm guessing, solve > 99% of cases. Allowing it to be specified by a parameter would solve > the remaing 1%. And I expect it *will* be CHAR_BIT in most or all > implementations, and programmers will rely on that assumption. I think > the standard should guarantee that. > I agree with you. I'm just trying to think of why the standards might not make that guarantee. >>> For a very large file, that could be a significant burden. (I don't >>> have any numbers on that.) >> >> I do : >> >> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-efficiency-metrics> >> >> (That's from a proposal for #embed for C and C++. Generating the >> numbers and parsing them is akin to using xxd.) >> >> More useful links: >> >> <https://thephd.dev/embed-the-details#results> >> <https://thephd.dev/implementing-embed-c-and-c++> >> >> (These are from someone who did a lot of the work for the proposals, >> and prototype implementations, as far as I understand it.) > > That second link does have a lot of good information. I think I had > seen it before, but I hadn't read it thoroughly. It refers to prototype > implementations for both gcc and clang. I've built the prototype on my > system, and godbolt.org has it, but the gcc prototype (for which the > article provides good performance data) doesn't seem to be available > anywhere. > You are putting a lot more effort into this testing than I have. For my work, I am generally dependent on "official" toolchain builds - provided by the manufacturers of the microcontrollers we use, or at least by the manufacturers of the cpu cores. I like to keep track of what's coming - future versions of C or C++, future versions of compilers, etc. But details such as implementation efficiency (rather than features) don't matter much to me until they are available as part of these pre-built toolchains. (Sometimes it's fun to try things earlier, and I enjoy playing with newer compilers on godbolt.org, but I don't see testing the speed of #embed to be /so/ much fun that I'd bother building a compiler for it!) But it's nice to see you've done some independent testing. I have no particular reason to double "thephd.dev", but no particular reason to consider it authoritative either. > My experiments with the clang prototype have been a bit confusing. I > assumed that `clang -E` would give me meaningful results, but it always > produces the comma-delimited sequence of integer constants, and even > that output is inconsistent. It looks like "-E" synthesizes naive and > not entirely correct output. Feeding that output to clang produces > warnings that I don't get without "-E". Some of this might be the > result of user error on my part. > > I did some tests with 100MB file, both with #embed and with #include > using the output of "xxd". #embed *is* much faster. > > According to <https://thephd.dev/implementing-embed-c-and-c++>, it > internally generates __builtin_pp_embed, which takes as arguments the > expected type (always unsigned char for now), the filename as a string > literal, and the data encoded as a base64 string literal. That's not > going to be as fast as a hypothetical pure binary blob, but apparently > it's still much faster than parsing a comma-delimited sequence. > > I haven't been able to get "clang -E" in the prototype to generate > __builtin_pp_embed, or to get clang to recognize it. There are internal > things going on that I don't understand. > > The author points out that using binary blobs would break tools that > work with -E preprocessed source files. If you could assume that the > preprocessed output will be processed only by the same compiler, that > wouldn't be an issue, but apparently that's not a safe assumption. > > The author acknowedges that the prototype implementation doesn't handle > all cases correctly. That's all good testing results - thanks for reporting them. >> >> Prototypes have been made, and they do have such optimisations. How >> things end up in real tools remains to be seen, of course. > > Here's how I personally would have preferred for #embed to be specified: > > - As in current C23 drafts, #embed with no parameters must operate *as > if* it expanded to a comma-delimited list of integer constant > expressions. > - With no parameters, both the common cases (initializing an array of > characters) and odd cases (e.g., initializing a struct object with > varying types and sizes of members) must work as specified. > - A standard-defined parameter allows control over optimization. > > The parameter can be "optimize(true)" or "optimize(false)". > > "optimize(false)" has no formal effect, but the compiler *should* > generate the canonical sequence of constants. > > "optimize(true)" causes undefined behavior if #embed is used in a > context other than the initialization of an array of character type. > I disagree here. I want the compiler to generate the "as if" results regardless of any optimisation, working as currently specified. And /if/ the compiler is able to optimise the #embed, then I want it to do so automatically - I see no situation in which I would ever want "optimize(false)". What would be nice is an optional warning if the #embed size is over a certain limit and it is unable to optimise it - a message telling the user that an array of "unsigned char" would be faster than an array of "signed char", or whatever, would be helpful. But that kind of thing is definitely implementation-specific. I'd also like a pre-processor command-line option (again this is clearly implementation-specific) to force non-optimised output from #embed, for use with "gcc -E" (or "clang -E") and third-party tools. > A naive compiler can quietly ignore the optimize() parameter and always > generate the comma-delimited sequence. An exceedingly clever compiler > could ignore it and always make a correct decision about whether to > optimize #embed. > > Without the optimize parameter, typical compilers are expected to > optimize #embed depending on the context in which it's used, and should > produce the correct results in all cases. The parameter can be used to > override the compiler's judgement. > > Another possibility might have been to specify that #embed can *only* be > used to initialize an array of character type, and any other use either > has undefined behavior or is a constraint violation. That would avoid > all the complication of determining from context whether it can be > optimized, and would probably cover 99% of cases. But it's probably too > late for that. > Agreed. As it is, #embed is complicated because it covers more than the simple case of initialising a const array of unsigned char. But it can't cover anything like all cases of embedding external data in C programs. (I have programs with internal web servers - they need to embed all files in a directory, and create an indexing structure. This is currently all automated by a python script called from the makefile - switching to #embed only would involve manual source changes when files are added or removed.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-05-27 17:33 -0700 |
| Message-ID | <87cyp6zsen.fsf@nosuchdomain.example.com> |
| In reply to | #385178 |
David Brown <david.brown@hesbynett.no> writes:
> On 27/05/2024 01:17, Keith Thompson wrote:
[...]
>> Here's how I personally would have preferred for #embed to be
>> specified:
>> - As in current C23 drafts, #embed with no parameters must operate
>> *as
>> if* it expanded to a comma-delimited list of integer constant
>> expressions.
>> - With no parameters, both the common cases (initializing an array of
>> characters) and odd cases (e.g., initializing a struct object with
>> varying types and sizes of members) must work as specified.
>> - A standard-defined parameter allows control over optimization.
>> The parameter can be "optimize(true)" or "optimize(false)".
>> "optimize(false)" has no formal effect, but the compiler *should*
>> generate the canonical sequence of constants.
>> "optimize(true)" causes undefined behavior if #embed is used in a
>> context other than the initialization of an array of character type.
>
> I disagree here. I want the compiler to generate the "as if" results
> regardless of any optimisation, working as currently specified. And
> /if/ the compiler is able to optimise the #embed, then I want it to do
> so automatically - I see no situation in which I would ever want
> "optimize(false)".
The issue I'm trying to address (very prematurely, no doubt) is
that the decision of whether to optimize #embed vs. generating the
naive comma-separated sequence is difficult to formalize, and easy
to get wrong in corner cases. "restrict" is another performance
hint whose only formal effect is to introduce undefined behavior
if you use it incorrectly.
Let's say I define an array of a 1-byte enumeration type, initialized
with #embed for a very large binary file. Maybe one compiler recognizes
this as a case where it can perform the optimization, and another
doesn't. If I can tell the compiler "trust me, I'm using this to
initialize raw byte data, and I'll take responsibility if I get it
wrong", I can see that being useful.
And maybe "optimize" isn't the best name. Perhaps "raw_bytes"?
Without some kind of programmer control, I'm concerned that the rules
for defining an array so #embed will be correctly optimized will be
spread as lore rather than being specified anywhere.
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-28 13:52 +0200 |
| Message-ID | <v34gi3$j385$1@dont-email.me> |
| In reply to | #385185 |
On 28/05/2024 02:33, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 27/05/2024 01:17, Keith Thompson wrote: > [...] >>> Here's how I personally would have preferred for #embed to be >>> specified: >>> - As in current C23 drafts, #embed with no parameters must operate >>> *as >>> if* it expanded to a comma-delimited list of integer constant >>> expressions. >>> - With no parameters, both the common cases (initializing an array of >>> characters) and odd cases (e.g., initializing a struct object with >>> varying types and sizes of members) must work as specified. >>> - A standard-defined parameter allows control over optimization. >>> The parameter can be "optimize(true)" or "optimize(false)". >>> "optimize(false)" has no formal effect, but the compiler *should* >>> generate the canonical sequence of constants. >>> "optimize(true)" causes undefined behavior if #embed is used in a >>> context other than the initialization of an array of character type. >> >> I disagree here. I want the compiler to generate the "as if" results >> regardless of any optimisation, working as currently specified. And >> /if/ the compiler is able to optimise the #embed, then I want it to do >> so automatically - I see no situation in which I would ever want >> "optimize(false)". > > The issue I'm trying to address (very prematurely, no doubt) is > that the decision of whether to optimize #embed vs. generating the > naive comma-separated sequence is difficult to formalize, and easy > to get wrong in corner cases. That's probably true. I would expect compiler implementations to optimise #embed only in cases where it is very clear (and at the very least, initialising a const array of char will fall into that category), and only when the preprocessor and compiler can coordinate it. Fallback will be using integer literal constants. I can't see any reason why that fallback should be slower than using xxd (or similar) and #include, so #embed should always be no slower than existing methods but sometimes very much faster. If optimisation was controlled or specified by something in the standard (such as your suggested "optimize()" parameter), then it would have to be formalized - leaving it to the implementation, which can document it as "best effort", entirely avoids the difficulty of specifying it. The only formalization needed is to say that it will always act "as if" it generated a comma-separated sequence. > "restrict" is another performance > hint whose only formal effect is to introduce undefined behavior > if you use it incorrectly. Yes, it is. (And I believe C23 has re-written some of the description of "restrict" - not to change its behaviour, but to make it clearer. I have not looked at that bit as yet.) But again, I can't see how any discussion of optimisation of #embed affects the behaviour and therefore any UB. The result is /always/ the same - it's just the compile time that may differ. > > Let's say I define an array of a 1-byte enumeration type, initialized > with #embed for a very large binary file. Maybe one compiler recognizes > this as a case where it can perform the optimization, and another > doesn't. Yes, that may be the case. > If I can tell the compiler "trust me, I'm using this to > initialize raw byte data, and I'll take responsibility if I get it > wrong", I can see that being useful. What do you mean by "wrong" here? Both compilers will give identical results. The only difference is that one will do so faster than the other. > > And maybe "optimize" isn't the best name. Perhaps "raw_bytes"? "raw_bytes" makes no sense to me. I can see that "optimize" might be confusing - normally the word refers to the speed (and/or memory usage) of the generated code, while here it refers to the speed (and/or memory usage) of the compilation. > > Without some kind of programmer control, I'm concerned that the rules > for defining an array so #embed will be correctly optimized will be > spread as lore rather than being specified anywhere. > They might, but I really do not think that is so important, since they will not affect the generated results.
[toc] | [prev] | [next] | [standalone]
Page 3 of 28 — ← Prev page 1 2 [3] 4 5 … 28 Next page →
Back to top | Article view | comp.lang.c
csiph-web