Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #386767 > unrolled thread
| Started by | aotto1968 <aotto1968@t-online.de> |
|---|---|
| First post | 2024-07-04 17:16 +0200 |
| Last post | 2024-07-07 20:29 +0200 |
| Articles | 20 on this page of 312 — 23 participants |
Back to article view | Back to comp.lang.c
technology discussion → does the world need a "new" C ? aotto1968 <aotto1968@t-online.de> - 2024-07-04 17:16 +0200
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-05 01:05 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 02:30 -0500
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-05 07:52 +0000
Re: technology discussion → does the world need a "new" C ? yeti <yeti@tilde.institute> - 2024-07-05 09:12 +0042
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-05 01:09 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-05 08:25 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 04:19 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-05 12:20 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 08:28 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-05 23:40 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 22:30 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-06 19:01 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 13:47 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:41 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:42 -0700
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:04 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 23:28 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-07 12:35 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-07 14:57 -0500
Re: technology discussion → does the world need a "new" C ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-06 11:23 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 13:46 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-06 20:15 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 17:01 -0500
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 02:24 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 01:39 -0500
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-05 11:46 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 07:23 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 03:51 -0500
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 04:23 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 14:26 -0400
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 14:33 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 16:37 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-09 18:54 +0300
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 20:03 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 13:23 -0500
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:38 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-06 23:55 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-07 10:03 -0400
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-07 15:10 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-07 19:22 -0400
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-08 00:02 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-08 12:39 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 16:31 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-09 15:54 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 16:58 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-09 17:29 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 18:22 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 14:14 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 00:15 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 19:08 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-09 21:28 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 14:23 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 00:35 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 13:51 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:32 +0100
Re: technology discussion → does the world need a "new" C ? Thiago Adams <thiago.adams@gmail.com> - 2024-07-10 11:26 -0300
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 15:49 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 17:09 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 08:48 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-10 20:14 +0300
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 21:28 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 11:13 +0300
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-11 08:41 +0000
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 12:15 +0300
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-11 10:02 +0000
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 11:17 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 12:20 +0200
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 11:56 +0100
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 22:49 +0000
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 07:02 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-11 15:19 -0500
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 14:29 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-11 16:42 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 18:30 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-10 21:39 +0300
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 20:04 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 11:31 +0300
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 04:49 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 14:00 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 06:26 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 15:04 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 11:53 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 20:56 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 13:29 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 21:36 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 07:53 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 12:03 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:51 +0200
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 14:36 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:13 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:32 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-13 11:46 +0200
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-13 11:37 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-17 14:42 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-17 19:31 +0200
Re: Re: technology discussion → does the world need a "new" C ? scott@slp53.sl.home (Scott Lurndal) - 2024-07-17 18:49 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 08:46 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 12:46 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:39 +0100
Re: Re: technology discussion → does the world need a "new" C ? scott@slp53.sl.home (Scott Lurndal) - 2024-07-12 14:17 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-12 13:50 -0500
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 21:37 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 14:00 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 07:54 +0200
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:44 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 14:59 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:39 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 21:04 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 11:46 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 18:44 -0700
Re: technology discussion → does the world need a "new" C ? Thiago Adams <thiago.adams@gmail.com> - 2024-07-12 08:51 -0300
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 13:26 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 18:29 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 04:28 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 11:54 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 17:48 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 00:01 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 01:21 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 02:29 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 18:36 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 11:54 +0300
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 11:04 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-11 13:25 +0300
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 12:41 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 12:22 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 17:58 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 18:25 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-11 11:27 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-12 08:00 +0200
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:12 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 12:21 +0100
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 12:14 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 09:54 -0700
Re: technology discussion ? does the world need a "new" C ? dave_thompson_2@comcast.net - 2024-08-25 17:16 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 18:09 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-01 19:01 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-09-02 12:10 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-02 15:18 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 06:04 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-15 23:56 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-16 03:37 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-16 18:15 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 06:15 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-17 19:07 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-17 12:52 -0700
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-26 09:37 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-26 21:28 -0700
Wording discussion (was Re: technology discussion) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-27 14:21 +0200
Re: Wording discussion (was Re: technology discussion) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 14:09 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 14:03 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 00:26 +0200
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 06:43 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-29 08:07 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-09-16 22:41 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 15:22 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 08:58 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 19:33 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 13:38 -0700
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 16:42 -0700
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 11:52 +0000
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-12 15:35 +0300
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-12 15:42 +0300
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 15:07 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-12 16:31 +0300
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:49 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-12 15:44 +0100
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 12:13 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 02:01 -0700
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-13 04:39 -0500
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 12:35 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 14:43 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-17 12:38 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-17 16:34 +0300
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-17 16:56 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-15 01:43 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-15 13:48 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-15 15:33 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-15 17:08 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-16 01:08 +0100
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-08-16 12:10 +0300
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-16 02:18 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-08-16 12:38 +0300
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 12:28 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-16 11:40 -0700
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-16 11:17 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 11:42 +0200
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-16 11:00 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 16:31 +0200
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 00:54 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 18:03 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-19 09:26 +0200
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-08-19 12:22 +0300
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 14:14 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-19 21:18 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-16 10:56 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-17 12:26 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-17 11:38 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 15:19 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-17 07:41 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-17 18:07 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-17 18:22 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-18 12:35 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 01:01 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-19 01:57 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-19 02:30 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-19 12:29 +0100
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-20 00:33 +0100
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-20 12:42 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 10:04 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 12:45 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-08-16 16:51 +0200
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-15 14:36 -0700
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-15 23:22 +0100
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-15 23:29 +0000
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 01:46 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-15 18:21 -0700
Re: technology discussion → does the world need a "new" C ? tTh <tth@none.invalid> - 2024-08-16 03:37 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-08-16 12:14 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-15 14:52 -0700
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-17 19:07 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-17 12:53 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-18 09:46 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-18 05:05 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-18 14:41 +0200
Re: technology discussion → does the world need a "new" C ? Bart <bc@freeuk.com> - 2024-07-18 14:00 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-18 18:01 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-18 14:25 -0500
Re: technology discussion → does the world need a "new" C ? vallor <vallor@cultnix.org> - 2024-07-18 22:23 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-18 12:40 -0500
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-13 13:35 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 01:09 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 07:34 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-11 04:35 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 16:54 +0200
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 16:40 +0100
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 21:46 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 13:47 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 22:40 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 16:00 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 13:38 +0200
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 22:32 +0000
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 00:04 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 16:50 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 01:38 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 18:18 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 11:12 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 13:05 -0700
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 03:19 +0000
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-09 18:31 +0200
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 13:05 -0700
Re: technology discussion → does the world need a "new" C ? Michael S <already5chosen@yahoo.com> - 2024-07-09 18:39 +0300
Re: technology discussion → does the world need a "new" C ? scott@slp53.sl.home (Scott Lurndal) - 2024-07-09 16:20 +0000
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 13:55 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-09 16:22 -0400
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-09 16:43 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 09:41 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-10 12:59 -0500
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-10 21:52 +0200
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-07 22:10 -0500
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-08 00:28 -0400
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 10:53 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 19:01 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 04:29 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-09 21:56 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 01:22 -0400
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 06:05 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 14:28 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-06 19:53 +0100
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 04:27 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 02:38 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-10 10:58 +0100
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 15:36 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:45 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:18 -0400
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 18:35 -0700
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:23 -0700
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 05:55 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 03:07 -0400
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 02:52 -0700
Re: technology discussion → does the world need a "new" C ? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-10 11:27 +0000
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:23 +0100
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 05:42 +0000
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-05 14:31 +0100
Re: technology discussion → does the world need a "new" C ? BGB <cr88192@gmail.com> - 2024-07-05 10:48 -0500
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 01:38 +0000
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-05 19:00 -0700
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 04:36 +0200
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-06 07:25 +0000
Re: technology discussion → does the world need a "new" C ? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:24 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 15:55 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:34 -0400
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-10 00:57 +0000
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 03:16 -0400
Re: technology discussion → does the world need a "new" C ? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:51 +0000
Re: technology discussion → does the world need a "new" C ? David Brown <david.brown@hesbynett.no> - 2024-07-11 12:46 +0200
Re: technology discussion → does the world need a "new" C ? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-11 13:57 +0100
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-11 14:50 +0100
Re: technology discussion → does the world need a "new" C ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-11 12:44 -0700
Re: technology discussion → does the world need a "new" C ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-12 12:17 -0700
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-11 12:09 -0400
Re: technology discussion → does the world need a "new" C ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:15 -0700
Re: technology discussion ? does the world need a "new" C ? dave_thompson_2@comcast.net - 2024-08-25 16:59 -0400
Re: technology discussion → does the world need a "new" C ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 04:29 +0200
Re: technology discussion → does the world need a "new" C ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 01:46 -0400
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-06 10:21 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:04 -0700
Re: technology discussion → does the world need a "new" C ? bart <bc@freeuk.com> - 2024-07-07 01:36 +0100
Re: technology discussion → does the world need a "new" C ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 18:39 -0700
Re: technology discussion → does the world need a "new" C ? lexi hale <lexi@hale.su> - 2024-07-05 21:54 +0200
Re: technology discussion → does the world need a "new" C ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-07 06:35 +0200
Re: technology discussion → does the world need a "new" C ? aotto1968 <aotto1968@t-online.de> - 2024-07-07 20:29 +0200
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-10 11:27 +0000 |
| Message-ID | <20240710042117.423@kylheku.com> |
| In reply to | #386980 |
On 2024-07-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 06 Jul 2024 15:23:47 -0700, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Fri, 05 Jul 2024 11:46:38 -0700, Keith Thompson wrote:
>>>
>>>> No, arrays are not pointers.
>>>
>>> Except array indexing is designed to be indistinguishable from pointer
>>> arithmetic.
>>
>> No, arrays are not pointers.
>
> Can you point out any situation where this construct
>
> &a[b]
>
> might be valid, but this
>
> (a + b)
>
> (with the same declarations of “a” and “b”) might not?
Miller Genuine Daft at work again.
a[b] /means/ *(a + (b)) so your reasoning is circular.
Arrays are not pointers. Given arrays a and b of equal size:
- sizeof a is not sizeof &[0] other than by coincidence
- &a is not &a[0] -- different type
- a = b is invalid -- arrays are not modifiable lvalues
- arrays cannot be passed to functions nor returned;
pointers can.
- int (f[3])(void) { }, function returning array of 3 int,
is a constraint violation.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-10 14:23 +0100 |
| Message-ID | <8734ohpeid.fsf@bsb.me.uk> |
| In reply to | #386989 |
Kaz Kylheku <643-408-1753@kylheku.com> writes:
> - int (f[3])(void) { }, function returning array of 3 int,
> is a constraint violation.
Nit: this is an array of three functions. Also a constraint violation
and a syntax error as array declarations can't be followed by {}s. The
impossible declaration you want would be written
int F(void)[3] {}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-06 05:42 +0000 |
| Message-ID | <v6alfr$3mmmc$1@dont-email.me> |
| In reply to | #386771 |
On Fri, 05 Jul 2024 01:09:37 -0700, Keith Thompson wrote: > (Ada, for example, has both arrays of arrays and multidimensional arrays > as distinct language features, using a(i)(j) to index the former and > a(i,j) to index the latter.) And also the option for a lower bound other than zero.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-05 14:31 +0100 |
| Message-ID | <v68sjv$3a7lb$1@dont-email.me> |
| In reply to | #386769 |
On 05/07/2024 08:30, BGB wrote:
> On 7/4/2024 8:05 PM, Lawrence D'Oliveiro wrote:
>> It’s called “Rust”.
>
>
> If anything, I suspect may make sense to go a different direction:
> Not to a bigger language, but to a more narrowly defined language.
>
> Basically, to try to distill what C does well, keeping its core essence
> intact.
That would just be rearranging the deck chairs I think.
Whatever the failings of C, it is so entrenched everywhere that it is
almost impossible to dislodge. Especially if you take out all the the
features that people apparently find indispensible.
There are anyway plenty of big-name contenders which change a LOT more,
and are full of modern, higher-level features that people seem to want.
C also is the only language that is supposed to work on any kind of
processor; most of the others require a machine which has 8/16/32/64-bit
types and have little interest in unusual targets.
(Actually, the nearest language to C that I have seen, is mine. It stays
at about that level, but it has modern conveniences such as a module
scheme and proper name-spaces. However, it is a private language, and
also 1-based, case-insensitive and with non-brace syntax! It is not a
contender.)
> *1: While not exactly that rare, and can be useful, it is debatable if
> they add enough to really justify their complexity and relative semantic
> fragility.
C only has 1D arrays, but array elements can themselves be array types.
The only complication, a big one, is that modern C allows a variable
length for those array elements (so not known at a compile-time). This
is tied in with VLAs and 'variable modified types' or whatever the
feature is called.
This applies when the multi-array data is a single block of memory.
> If using pointers, one almost invariably needs to fall back
> to doing "arr[y*N+x]"
I've never had to do that, even if N was a variable. If using Iliffe
vectors then C allows you do regular indexing even with runtime bounds.
> Note that multidimensional indexing via multiple levels of pointer
> indirection would not be effected by this.
These are Iliffe vectors.
> Similarly, structs may not be declared at the point of use, but only as
> types.
This is how it works on my language; they must be a named user-type.
It's crazy how C allows them just anywhere, even in useless declarations
like this:
struct {int x,y;};
> Though, would want to do a few things differently from my current IR to
> be able to reduce memory footprint; as my current IR was designed in
> such a way that it is effectively necessary to load in the whole program
> before code-generation can be done. Ideally one would want the compiler
> to be able to read-in the IR as-needed and discard the parts it is
> already done with (but, existing efforts to redesign the IR stage here
> have tended to fizzle; would effectively need to redesign the compiler
> backend to be able to make effective use of it).
>
> For a new compiler, could make sense to try to "do it right this time"
> (though, not too much of an issue if running the compiler on a modern
> PC, as they are "not exactly RAM constrained" in this area; so reading
> in and decoding the IR and symbol tables for an entire executable image
> at the same time, is not too much of an issue).
It's not an issue at all. My main compiler is a whole-program one; the
entire source code for my biggest program occupies 1/8000th of the
memory of my PC. That would be like building an 8-byte source file on my
first computer.
Presumably you are running on some restricted hardware of your own?
> If pulled of well, such a module system could be both faster and require
> less memory use in the compiler if compared with headers
Headers are a bottleneck in C. 50 modules all including the same huge
header (say the 1000 #includes involved with #include <gtk<>, which is
for GTK2), would involve repeating all that work 50 times.
> Even with unity builds, build times can still get annoying for bigger
> programs. And here, I am talking like 20 seconds to rebuild a 250kLOC
> program.
In my language, a 250Kloc app would take about half a second to build
into an executable.
My C compiler is slower since it uses a discrete ASM stage.
(It will build sql.c which is actually 250Kloc including headers, in
half a second, generating a 1MB EXE, however that program is 40%
comments, and big chunks are conditional blocks. Preprocessing it
generates 85Kloc.)
> Granted, even if parsing is fast, this still leaves the
> challenge of fast/efficient machine-code generation.
Unoptimised code in my case (for the way I write code, for my language,
and for my apps) is about 50% slower than when passed through C and gcc-O3.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-05 10:48 -0500 |
| Message-ID | <v694mr$3bhbs$1@dont-email.me> |
| In reply to | #386777 |
On 7/5/2024 8:31 AM, bart wrote:
> On 05/07/2024 08:30, BGB wrote:
>> On 7/4/2024 8:05 PM, Lawrence D'Oliveiro wrote:
>>> It’s called “Rust”.
>>
>>
>> If anything, I suspect may make sense to go a different direction:
>> Not to a bigger language, but to a more narrowly defined language.
>>
>> Basically, to try to distill what C does well, keeping its core
>> essence intact.
>
> That would just be rearranging the deck chairs I think.
>
> Whatever the failings of C, it is so entrenched everywhere that it is
> almost impossible to dislodge. Especially if you take out all the the
> features that people apparently find indispensible.
>
> There are anyway plenty of big-name contenders which change a LOT more,
> and are full of modern, higher-level features that people seem to want.
>
For what I want, at this point, is not a whole lot of high-level features.
> C also is the only language that is supposed to work on any kind of
> processor; most of the others require a machine which has 8/16/32/64-bit
> types and have little interest in unusual targets.
>
Yeah.
In this case, I would assume limiting it to 32 and 64 bit machines.
My hobby ISA on FPGAs is 64-bit, albeit can use 32 or 64 bit pointers.
I mostly settled on using 64-bit pointers with 48-bit address space and
16-bits for tag metadata (implicitly, the high 16 bits is ignored by
normal Load/Store operations).
Though, the use of pointer-tagging is not entirely invisible to C,
though, unless bounds-checking is enabled, the high 16 bits are
typically zeroed for C data pointers (they are used for function
pointers and link-register values though, to encode the intended
operating mode for the CPU and similar).
> (Actually, the nearest language to C that I have seen, is mine. It stays
> at about that level, but it has modern conveniences such as a module
> scheme and proper name-spaces. However, it is a private language, and
> also 1-based, case-insensitive and with non-brace syntax! It is not a
> contender.)
>
I would assume something that wouldn't be a massive pain for copy/paste
translation.
>
>> *1: While not exactly that rare, and can be useful, it is debatable if
>> they add enough to really justify their complexity and relative
>> semantic fragility.
>
> C only has 1D arrays, but array elements can themselves be array types.
>
> The only complication, a big one, is that modern C allows a variable
> length for those array elements (so not known at a compile-time). This
> is tied in with VLAs and 'variable modified types' or whatever the
> feature is called.
>
> This applies when the multi-array data is a single block of memory.
>
At least one major C compiler has rejected VLAs entirely last I heard.
I added them experimentally, but it doesn't fully work.
I also made my compiler fall back to using them for arrays which are too
big (over 16K, for sake of a 128K default stack size).
In this case, they are turned into heap allocations with automatic
freeing on function return, but seemingly it is buggy and is currently
prone to data corruption and memory leaks.
My attempt to port Quake3 ran into issues here as it regularly tried to
use arrays over the size limit (though, some comments in the code
implied that OSX did something similar, albeit with a 32K size limit;
some functions though tried to use 64K or 128K local arrays, which isn't
really going to fly short of boosting the stack size to 512K or 1MB).
Choice of stack size being:
32K: Generally only small programs will fit;
64K: Many programs fit, but some don't.
Say, Doom can fit onto a 64K stack, Quake not so much.
128K: Stuff generally fits (*1).
*1: Though, GLQuake and Quake3 required moving a lot of former stack
arrays onto the heap.
Using larger stacks is undesirable though if one wants to support NOMMU
operation, since if a program allocates 1MB and only uses 90K or so,
then the remaining 934K are entirely wasted.
Generally, recursion and register save/restore by itself isn't enough to
threaten a 128K stack, but large structs and arrays will do so readily.
Luckily, an ABI based around pass-by-reference has little issue with
internally turning large structs into heap allocations.
Though, having a compiler which turns large arrays or large structs into
a compiler error (vs giving a warning and turning them into heap
allocs), probably wouldn't fly to well.
Though, in the attempted Quake3 port, did end up turning some large
global structs into heap allocations as well, mostly as they caused the
".bss" section to become so large that the PE loading was failing (at
the moment stuff appears to break if the total size of the PE image goes
over 8MB).
Then again, there is a limit at present (in my compiler) that the
handling of relocs (in the PE export code) can't express sections larger
than 8MB (the remaining bits of a 32-bit value are used to encode the
reloc type and section number). It is possible I was hitting this limit
(it was a TODO feature to expand this part of the code to use a 64-bit
format for intermediate reloc handling).
>> If using pointers, one almost invariably needs to fall back to doing
>> "arr[y*N+x]"
>
> I've never had to do that, even if N was a variable. If using Iliffe
> vectors then C allows you do regular indexing even with runtime bounds.
>
>> Note that multidimensional indexing via multiple levels of pointer
>> indirection would not be effected by this.
>
> These are Iliffe vectors.
>
Pros/cons.
For many uses, one still wants a contiguous buffer.
For some uses (typically limited to square power-of-2 arrays), I have
used Morton order, but I also ended up adding special CPU instructions
to deal with Morton order arrays.
>
>> Similarly, structs may not be declared at the point of use, but only
>> as types.
>
> This is how it works on my language; they must be a named user-type.
> It's crazy how C allows them just anywhere, even in useless declarations
> like this:
>
> struct {int x,y;};
>
Yeah.
As-is the parser needs to lift them out and put them in their own
special part of the AST.
Ideally, one doesn't want this.
Ideally also one doesn't want to need to parse a crapton of prototypes
and structs/typedefs/etc for every translation unit either.
>> Though, would want to do a few things differently from my current IR
>> to be able to reduce memory footprint; as my current IR was designed
>> in such a way that it is effectively necessary to load in the whole
>> program before code-generation can be done. Ideally one would want the
>> compiler to be able to read-in the IR as-needed and discard the parts
>> it is already done with (but, existing efforts to redesign the IR
>> stage here have tended to fizzle; would effectively need to redesign
>> the compiler backend to be able to make effective use of it).
>>
>> For a new compiler, could make sense to try to "do it right this time"
>> (though, not too much of an issue if running the compiler on a modern
>> PC, as they are "not exactly RAM constrained" in this area; so reading
>> in and decoding the IR and symbol tables for an entire executable
>> image at the same time, is not too much of an issue).
>
> It's not an issue at all. My main compiler is a whole-program one; the
> entire source code for my biggest program occupies 1/8000th of the
> memory of my PC. That would be like building an 8-byte source file on my
> first computer.
>
> Presumably you are running on some restricted hardware of your own?
>
Ideally, I would want a compiler that I could run on my ISA, without
needing to provide like 512MB or 1GB of swap space to do so...
One of the main FPGA boards I am targeting has 128MB of RAM, and can
generally manage a CPU core running at 50MHz.
>> If pulled of well, such a module system could be both faster and
>> require less memory use in the compiler if compared with headers
>
> Headers are a bottleneck in C. 50 modules all including the same huge
> header (say the 1000 #includes involved with #include <gtk<>, which is
> for GTK2), would involve repeating all that work 50 times.
>
Hence, unity builds...
The performance gains of compiling, say, 50-100 KLOC all in one
translation unit without needing to duplicate a bunch of header parsing,
more than makes up for any loss due to inability to run compiler
instances in parallel (and if one does have multiple compiler instances,
a decent sized program can still be reduced down to a matter of seconds
of build time).
>> Even with unity builds, build times can still get annoying for bigger
>> programs. And here, I am talking like 20 seconds to rebuild a 250kLOC
>> program.
>
> In my language, a 250Kloc app would take about half a second to build
> into an executable.
>
> My C compiler is slower since it uses a discrete ASM stage.
>
> (It will build sql.c which is actually 250Kloc including headers, in
> half a second, generating a 1MB EXE, however that program is 40%
> comments, and big chunks are conditional blocks. Preprocessing it
> generates 85Kloc.)
>
>
>> Granted, even if parsing is fast, this still leaves the challenge of
>> fast/efficient machine-code generation.
>
> Unoptimised code in my case (for the way I write code, for my language,
> and for my apps) is about 50% slower than when passed through C and gcc-O3.
>
On my ISA, it is slower.
Though, ironically, despite my compiler's general level of suck in these
areas (vs GCC), in terms of performance it is beating out "GCC -O3"
targeting RISC-V.
It was pretty close with static-linked non-relocatable images in RV64G.
Though, with PIE images, it has turned into "no contest" (PIC/PIE seems
to kinda ruin both code density and performance for RISC-V).
Where, I have a CPU design that can run both my own ISA and RV64G
(technically, at the same time; such as a kernel in my own ISA but
programs compiled as RV64G)
This is despite also my compiler using an ABI designed around the
assumption of NOMMU operation (similar to FDPIC in this sense). Where,
essentially, function calling generally involves a magic ritual to
reload the Global Pointer to make sure it points to the correct location
for whichever image is currently executing code.
Though, I suspect much of this is because RISC-V takes a fairly steep
hit to performance due to a few issues:
Lack of register-indexed memory addressing;
No good way to deal with constant/immediate values larger than 12 bits.
Say, a 32-bit constant typically requires a 2-instruction sequence to
load it into a register (though, GCC seems to prefer turning all of
these constants into memory loads rather than use LUI+ADD or similar);
and 64 bit always gets turned into a memory load.
There are a lot of other ISA differences, but I suspect these are likely
the big ones.
...
Technically, could have tried porting Quake3 to build for RV64G instead
of my own ISA, but then I would need to go implement loader support for
ELF Shared-Objects in my "OS", which I don't want to deal with at the
moment.
Though, I am using a software OpenGL rasterizer, and past attempts to
build the OpenGL rasterizer in RISC-V mode resulted in performance that
could best be described as "glacial" on a 50MHz CPU (32 GPRs, no SIMD,
and no RGB helper instructions, really hurt at this part).
Though, this testing was generally with GLQuake (but, wouldn't expect
Quake3Arena to be much different here). Though, I still kinda have
doubts that Quake3 is going to give particularly playable performance on
a 50MHz CPU with software rasterized OpenGL (if/when I get it fully
working).
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-06 01:38 +0000 |
| Message-ID | <v6a76q$3gqkm$6@dont-email.me> |
| In reply to | #386777 |
On Fri, 5 Jul 2024 14:31:44 +0100, bart wrote: > C also is the only language that is supposed to work on any kind of > processor ... I don’t think there is anything innate in the design of C to ensure that. It was simply its popularity that meant it was usually the first language implemented on a new processor. For example, C assumes byte addressability. So that causes awkwardness on architectures like the PDP-10, for example. It just so happened such architectures became extinct at about the time the rise of 8-bit microprocessors (and their more advanced successors) made byte- addressability essentially universal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-05 19:00 -0700 |
| Message-ID | <87plrruvmt.fsf@nosuchdomain.example.com> |
| In reply to | #386783 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 5 Jul 2024 14:31:44 +0100, bart wrote:
>
>> C also is the only language that is supposed to work on any kind of
>> processor ...
>
> I don’t think there is anything innate in the design of C to ensure that.
> It was simply its popularity that meant it was usually the first language
> implemented on a new processor.
>
> For example, C assumes byte addressability. So that causes awkwardness on
> architectures like the PDP-10, for example. It just so happened such
> architectures became extinct at about the time the rise of 8-bit
> microprocessors (and their more advanced successors) made byte-
> addressability essentially universal.
C assumes byte addressibility, but it doesn't assume that bytes are 8
bits.
The PDP-10 had 36-bit words and could operate on bit fields of any size
from 1 to 36 bits. A conforming PDP-10 C compiler might have
CHAR_BIT==9, for example. But yes, it would be awkward to deal with
arrays of 6-bit quantities.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-06 04:36 +0200 |
| Message-ID | <v6aak5$3l7dn$1@dont-email.me> |
| In reply to | #386784 |
On 06.07.2024 04:00, Keith Thompson wrote: > > The PDP-10 had 36-bit words and could operate on bit fields of any size > from 1 to 36 bits. A conforming PDP-10 C compiler might have > CHAR_BIT==9, for example. But yes, it would be awkward to deal with > arrays of 6-bit quantities. ISTR that the old CDCs 175/176 (with NOS) had 60 bit words and stored 6-bit based Pascal character strings (with array length 10) in a word. Don't recall how it had handled other data types from other languages or longer strings (if these were possible [in their Pascal dialect]). Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-06 07:25 +0000 |
| Message-ID | <v6argi$3ngh6$5@dont-email.me> |
| In reply to | #386784 |
On Fri, 05 Jul 2024 19:00:58 -0700, Keith Thompson wrote: > C assumes byte addressibility, but it doesn't assume that bytes are 8 > bits. > > The PDP-10 had 36-bit words and could operate on bit fields of any size > from 1 to 36 bits. But it couldn’t address them.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-06 23:24 +0100 |
| Message-ID | <871q46upke.fsf@bsb.me.uk> |
| In reply to | #386792 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Fri, 05 Jul 2024 19:00:58 -0700, Keith Thompson wrote: > >> C assumes byte addressibility, but it doesn't assume that bytes are 8 >> bits. >> >> The PDP-10 had 36-bit words and could operate on bit fields of any size >> from 1 to 36 bits. > > But it couldn’t address them. And C does not assume that the hardware can address bytes. On word addressed machines, some pointer conversions generate code. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-06 15:55 -0700 |
| Message-ID | <878qyeuo4i.fsf@nosuchdomain.example.com> |
| In reply to | #386792 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 05 Jul 2024 19:00:58 -0700, Keith Thompson wrote:
>> C assumes byte addressibility, but it doesn't assume that bytes are 8
>> bits.
>>
>> The PDP-10 had 36-bit words and could operate on bit fields of any size
>> from 1 to 36 bits.
>
> But it couldn’t address them.
There was a project to add PDP-10 support to GCC. It had CHAR_BIT==9.
I don't know any of the details.
http://pdp10.nocrew.org/gcc/
Cray vector systems like the T90 have (had?) 64-bit words as the
smallest addressible unit. The C compilers emulated 8-bit byte
addressing in software.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-07-06 21:34 -0400 |
| Message-ID | <v6crb5$1gpa$1@dont-email.me> |
| In reply to | #386792 |
On 7/6/24 03:25, Lawrence D'Oliveiro wrote: > On Fri, 05 Jul 2024 19:00:58 -0700, Keith Thompson wrote: > >> C assumes byte addressibility, but it doesn't assume that bytes are 8 >> bits. >> >> The PDP-10 had 36-bit words and could operate on bit fields of any size >> from 1 to 36 bits. > > But it couldn’t address them. It doesn't matter whether there's hardware support for addressing bytes - byte addressing can be emulated in software on any platform sufficiently powerful to implement C's bitwise operators. To read a byte on a word-addressed machine where the word size is multiple bytes, just read in the word, then extract the bits that represent that particular byte. To write a byte on such a machine, read in the current contents of that word, replace the bits that represent that byte with their new values, and write the entire word back to memory. On many platforms, if _Alignof(type) is less than the word size, then a C pointer to that type is implemented as the combination of the machine address of the correct word, combined with an offset within that word of the first byte of that object. The existence of real world implementations that did this is the main reason that the C standard does not require that all pointers have the same representation. This may be inefficient, maybe sufficiently so to be a reason for avoiding using C on such a platform, but it doesn't (and hasn't) prevent the existence of a fully conforming implementation of C on that platform.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-10 00:57 +0000 |
| Message-ID | <v6kma1$1jcln$7@dont-email.me> |
| In reply to | #386840 |
On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: > On many platforms, if _Alignof(type) is less than the word size, then a > C pointer to that type is implemented as the combination of the machine > address of the correct word, combined with an offset within that word of > the first byte of that object. Which is a terrific idea, except it cannot be carried to its logical conclusion (addressing of arbitrarily-aligned dynamically-defined bitfields) because of the requirement in the C spec that the size of a “byte” be at least 8 bits.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-07-10 03:16 -0400 |
| Message-ID | <v6lcg3$1qhmn$1@dont-email.me> |
| In reply to | #386973 |
On 7/9/24 20:57, Lawrence D'Oliveiro wrote: > On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: > >> On many platforms, if _Alignof(type) is less than the word size, then a >> C pointer to that type is implemented as the combination of the machine >> address of the correct word, combined with an offset within that word of >> the first byte of that object. > > Which is a terrific idea, except it cannot be carried to its logical > conclusion (addressing of arbitrarily-aligned dynamically-defined > bitfields) because of the requirement in the C spec that the size of a > “byte” be at least 8 bits. I will grant you that I failed to mention the fact that this is a feasible way of implementing C only on platforms with a word size of 16 bits or longer. I assumed that would be obvious - I apologize for not anticipating that it might not be. On platforms where the word size is smaller than 8 bits, the opposite strategy applies: instead of storing multiple bytes in a word, an implementation would have to use multiple words to store a byte. I know that there's a fair number of implementations that use the first approach, I have no idea whether there are any that use the second approach. It should be feasible, but it would probably be more trouble than it's worth. The key point is that the addressable unit in C can be emulated - it needn't bear any particularly close relationship to the hardware addressable unit.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-11 02:51 +0000 |
| Message-ID | <v6nhbr$29e0c$3@dont-email.me> |
| In reply to | #386984 |
On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote: > On 7/9/24 20:57, Lawrence D'Oliveiro wrote: > >> On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: >> >>> On many platforms, if _Alignof(type) is less than the word size, then >>> a C pointer to that type is implemented as the combination of the >>> machine address of the correct word, combined with an offset within >>> that word of the first byte of that object. >> >> Which is a terrific idea, except it cannot be carried to its logical >> conclusion (addressing of arbitrarily-aligned dynamically-defined >> bitfields) because of the requirement in the C spec that the size of a >> “byte” be at least 8 bits. > > I will grant you that I failed to mention the fact that this is a > feasible way of implementing C only on platforms with a word size of 16 > bits or longer. Don’t you think C needs a better way of handling bitfields than shift-and- mask? Many architectures have bitfield instructions, but C cannot easily make use of them without the ability to have arbitrarily-bit-aligned pointers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-07-11 12:46 +0200 |
| Message-ID | <v6od5q$2djgq$3@dont-email.me> |
| In reply to | #387038 |
On 11/07/2024 04:51, Lawrence D'Oliveiro wrote: > On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote: > >> On 7/9/24 20:57, Lawrence D'Oliveiro wrote: >> >>> On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: >>> >>>> On many platforms, if _Alignof(type) is less than the word size, then >>>> a C pointer to that type is implemented as the combination of the >>>> machine address of the correct word, combined with an offset within >>>> that word of the first byte of that object. >>> >>> Which is a terrific idea, except it cannot be carried to its logical >>> conclusion (addressing of arbitrarily-aligned dynamically-defined >>> bitfields) because of the requirement in the C spec that the size of a >>> “byte” be at least 8 bits. >> >> I will grant you that I failed to mention the fact that this is a >> feasible way of implementing C only on platforms with a word size of 16 >> bits or longer. > > Don’t you think C needs a better way of handling bitfields than shift-and- > mask? Many architectures have bitfield instructions, but C cannot easily > make use of them without the ability to have arbitrarily-bit-aligned > pointers. There are pros and cons of different ways to support bitfields in a language, and there are certainly aspects of C's bitfields that many people think are less than ideal. But (good) C compilers have no problem using bitfield instructions on architectures that have these, so that at least is not an issue.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-07-11 13:57 +0100 |
| Message-ID | <v6okru$2fdnt$1@dont-email.me> |
| In reply to | #387050 |
On 11/07/2024 11:46, David Brown wrote: > On 11/07/2024 04:51, Lawrence D'Oliveiro wrote: >> On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote: >> >>> On 7/9/24 20:57, Lawrence D'Oliveiro wrote: >>> >>>> On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: >>>> >>>>> On many platforms, if _Alignof(type) is less than the word size, then >>>>> a C pointer to that type is implemented as the combination of the >>>>> machine address of the correct word, combined with an offset within >>>>> that word of the first byte of that object. >>>> >>>> Which is a terrific idea, except it cannot be carried to its logical >>>> conclusion (addressing of arbitrarily-aligned dynamically-defined >>>> bitfields) because of the requirement in the C spec that the size of a >>>> “byte” be at least 8 bits. >>> >>> I will grant you that I failed to mention the fact that this is a >>> feasible way of implementing C only on platforms with a word size of 16 >>> bits or longer. >> >> Don’t you think C needs a better way of handling bitfields than >> shift-and- >> mask? Many architectures have bitfield instructions, but C cannot easily >> make use of them without the ability to have arbitrarily-bit-aligned >> pointers. > > There are pros and cons of different ways to support bitfields in a > language, and there are certainly aspects of C's bitfields that many > people think are less than ideal. > > But (good) C compilers have no problem using bitfield instructions on > architectures that have these, so that at least is not an issue. > It's something I very rarely need for the type of prgramming I do, which is portable algortithm implentations on systems wheee the constraint is primarily time rather than memory.And that type of programming does represent quite a lot of C programming or larger hosted systems. Bitfields come into their own in embedded systems, either to save memory, or to address hardware bits directly. And the last use is inherently non-portable, so it's OK if non-target compilers cannot generate efficient code. And the first use is theoretically portable, but but practice not very likely to be ported, because when you do that sor of micro-optimisation you lose portabliity. -- Check out my hobby project. http://malcolmmclean.github.io/babyxrc
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-11 14:50 +0100 |
| Message-ID | <v6oo01$2fja8$1@dont-email.me> |
| In reply to | #387038 |
On 11/07/2024 03:51, Lawrence D'Oliveiro wrote: > On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote: > >> On 7/9/24 20:57, Lawrence D'Oliveiro wrote: >> >>> On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: >>> >>>> On many platforms, if _Alignof(type) is less than the word size, then >>>> a C pointer to that type is implemented as the combination of the >>>> machine address of the correct word, combined with an offset within >>>> that word of the first byte of that object. >>> >>> Which is a terrific idea, except it cannot be carried to its logical >>> conclusion (addressing of arbitrarily-aligned dynamically-defined >>> bitfields) because of the requirement in the C spec that the size of a >>> “byte” be at least 8 bits. >> >> I will grant you that I failed to mention the fact that this is a >> feasible way of implementing C only on platforms with a word size of 16 >> bits or longer. > > Don’t you think C needs a better way of handling bitfields than shift-and- > mask? Yes. But because it's not hard for a million programmers to each create their own macros like GETBIT and SETBIT, that's not going to happen. Although bit operations are unusual in other languages too. > Many architectures have bitfield instructions, but C cannot easily > make use of them without the ability to have arbitrarily-bit-aligned > pointers. When you look in depth at working with bits and bitfields, it is a surprisingly wide area with lots of possibilities * Define named bits and bitfields within a struct (C already has this, although with little control). These bitfields are fixed length and location known at compile-time (although only to the compiler!), and can be of size 1 to 64 bits * Extract a bit/bitfield from an integer value. These can have a position and length only known at runtime. * Inject such a bit/bitfield into an integer value * Allow bitfields that can straddle a word boundary. * Allow small arrays of bitfields of width 1, 2 or 4 bits that fit within an integer. (8-bit bitfields are just bytes.) * Allow full arrays of such bitfields, and slices of such arrays * Allow arrays of bitfields of any width 1..64 bits * Allow pointers to a bitfield of a certain fixed width 1..64 bits * Allow that pointer to to stepped either to the next bitfield, or by any arbitrary number of bits * Allow a bit-pointer with a variable target bit-width * Allow bitwise ops between arrays of bits * .... ---------------------- For my static language, I have: * Bitfields within structs with more control than C, and are defined inside a regular integer field. * Bit indexing to extract or inject bits/bitfields: A.[i] and A.[i..j] My dynamic language also has arbitrary arrays of 1/2/4 bits, bit-slices, and bit-pointers to fields of 1..64 bits. It also has bit-sets of any size on which bitwise ops can be used. At the level of C, I believe that bit-arrays are a possibility, without also needing to have bit-pointers that are bit-aligned. Pointers to the start of such arrays are fine, as they will be byte-aligned.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-11 12:44 -0700 |
| Message-ID | <v6pcmg$2jl67$2@dont-email.me> |
| In reply to | #387059 |
On 7/11/2024 6:50 AM, bart wrote: > On 11/07/2024 03:51, Lawrence D'Oliveiro wrote: >> On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote: >> >>> On 7/9/24 20:57, Lawrence D'Oliveiro wrote: >>> >>>> On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote: >>>> >>>>> On many platforms, if _Alignof(type) is less than the word size, then >>>>> a C pointer to that type is implemented as the combination of the >>>>> machine address of the correct word, combined with an offset within >>>>> that word of the first byte of that object. >>>> >>>> Which is a terrific idea, except it cannot be carried to its logical >>>> conclusion (addressing of arbitrarily-aligned dynamically-defined >>>> bitfields) because of the requirement in the C spec that the size of a >>>> “byte” be at least 8 bits. >>> >>> I will grant you that I failed to mention the fact that this is a >>> feasible way of implementing C only on platforms with a word size of 16 >>> bits or longer. >> >> Don’t you think C needs a better way of handling bitfields than >> shift-and- >> mask? > > Yes. But because it's not hard for a million programmers to each create > their own macros like GETBIT and SETBIT, that's not going to happen. > > Although bit operations are unusual in other languages too. [...] Fwiw, the last time I really used them was for special lock/wait-free algorithms. Stealing bits from pointers and aligning and passing structures on special boundaries.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-12 12:17 -0700 |
| Message-ID | <v6rvh2$35bbn$4@dont-email.me> |
| In reply to | #387067 |
On 7/11/2024 12:44 PM, Chris M. Thomasson wrote: > On 7/11/2024 6:50 AM, bart wrote: [...] >> Although bit operations are unusual in other languages too. > [...] > > Fwiw, the last time I really used them was for special lock/wait-free > algorithms. Stealing bits from pointers and aligning and passing > structures on special boundaries. > Damn typos! passing should be padding! Damn it. ;^o aligning _and_ padding structures
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web