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 1 of 16 [1] 2 3 … 16 Next page →
| From | aotto1968 <aotto1968@t-online.de> |
|---|---|
| Date | 2024-07-04 17:16 +0200 |
| Subject | technology discussion → does the world need a "new" C ? |
| Message-ID | <v66eci$2qeee$1@dont-email.me> |
Hi,
1. does the world need a "new" C ?
-> http://thedev.nhi1.de/theKernel/main/managed-object.htm
2. is one compiler enough ?
-> http://thedev.nhi1.de/theCompiler/main/alc-compiler.htm
[toc] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-05 01:05 +0000 |
| Message-ID | <v67gt1$2vq6a$2@dont-email.me> |
| In reply to | #386767 |
It’s called “Rust”.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-05 02:30 -0500 |
| Message-ID | <v687h2$36i6p$1@dont-email.me> |
| In reply to | #386768 |
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.
Goal would be to make it easier to get more consistent behavior across
implementations, and also to make it simpler to implement (vs an actual
C compiler); with a sub-goal to allow for implementing a compiler within
a small memory footprint (as would be possible for K&R or C89).
Say for example:
Integer type sizes are defined;
Nominally, integers are:
Twos complement;
Little endian;
Wrap on overflow.
Dropped features:
VLAs
Multidimensional arrays (*1)
Bitfields
...
Simplified declaration syntax (*2):
{Modifier|Attribute}* TypeName Declarator
*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. If using pointers, one almost invariably needs to fall back
to doing "arr[y*N+x]" or similar anyways, so it is arguable that it
could make sense to drop them and have people always do their
multidimensional indexing manually.
Note that multidimensional indexing via multiple levels of pointer
indirection would not be effected by this.
*2: This can be used to both make parsing easier, and also make parsing
faster, as it can eliminate needing to lookup symbols to see if they
were a previously defined typedef or similar (which in effect in C ends
up being needed for pretty much every non-keyword identifier encountered
here; ideally you don't want to need to do it at all in the parsing stage).
Say, integer types:
sbyte, byte/ubyte: 8 bits
short, ushort: 16 bits
int, uint: 32 bits
long, ulong: 64 bits
intNN/uintNN: Explicit sized types, may map to the above.
Unclear:
char: 8-bit, unsigned
Could go either way, signed is more traditional,
but unsigned makes more logical sense here.
wchar: 16-bit, unsigned
Arrays:
Basic array types are always one dimensional;
Type[] will alias with "Type*" in most contexts.
Would likely drop C's function pointer syntax, likely in favor of, say:
typedef int fooFunc_t(); //declare a function type
fooFunc_t *fptr; //actual function pointer
Similarly, structs may not be declared at the point of use, but only as
types.
struct FooStruct {
int x, y;
}
FooStruct *fs; //pointer to FooStruct
Where, declaring a struct will also behave as-if it had also been
implicitly typedef'ed with the same name.
Struct semantics would be tweaked:
A by-value struct will behave as if it were pass-by-reference with
copy-on-assignment (as is typically the case when structs are used as
lvalues).
Would make some other restrictions:
Variable declarations are only allowed in the top-level block of a
function, and (regardless of location) will always behave as if they
were declared at the top of the function.
Initial values in a declaration may only be a constant expression or a
reference to a global declaration (including for local variables).
Expressions like sizeof() and offsetof() will not (necessarily) be seen
as constants (except if the value may be trivially determined). Note
that these will also be only valid for type names, not for the type of
an arbitrary expression.
Note that only certain expressions (such as variable assignments or
function calls) will be allowed in statement context (most other
expressions would not be allowed).
...
So, for example:
int Foo(int x, int y)
{
BAD:
int z=x/y; //not allowed, not constant
OK:
int z;
z=x/y;
if(z>10)
{
BAD:
int w; //declaration is not allowed here
z+=3; //OK
z*4; //BAD, expression not allowed as statement
}
}
Maybe:
Pointers may be allowed to be bounds-checked;
But, casts between pointer and integer types will be restricted.
An implementation will be allowed to disallow this.
Granted, this would disallow traditional forms of pointer tagging.
An implementation may instead provide optional intrinsics for working
with pointer tagging (in place of raw casts and bit-twiddling). Though,
this would mean one would either need a runtime that is aware of
type-tagging, or allow for implementations which forbid pointer tagging
entirely (likely requiring a fallback to other strategies, such as boxed
values).
Though, in this case, requiring the runtime to be a little more clever
is an easier sell than trying to deal with it in the compiler.
...
Will also add a restriction to break and continue:
They will only be valid within the body of a loop, or within an if/else
block within the loop. Nearly any other constructs (such as another loop
or a "switch()" will entirely hide the visibility of the outer break or
continue).
...
Possible functional difference:
Will use explicit module importing rather than headers.
Modules will be parsed top-to-bottom, with the ability to see into any
imported modules. Each module will only be exported once, with a logical
declaration order based on a DAG walk.
Preprocessing defines/macros would not carry across module boundaries.
Modules would function in a way partway between headers and static
libraries, likely being built in advance, but pulled into the compiler
stage (likely with a manifest defining any types or global declarations
within the module). Ideally, the goal would be to allow for
implementation both with separate compilation (such as COFF or ELF
objects; where likely the object code and manifest would exist
separately) or with a bytecode IR (which would likely combine both into
a single entity). Ideally, it should be possible to determine module
dependency order without fully invoking the compiler (say, such that the
logic for compiling each module, and scheduling the compilation of
modules, can operate independently).
But, admittedly, I have had good results using a stack-machine IR in my
compilers for things like static libraries, so leveraging similar
technology could still make sense.
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).
Though, one likely option here would be to use a similar system to
"package" and "import" in Java (in strong contrast to how these keywords
were used in ActionScript, which would have more in common with
"namespace" and "using" in C++ and C#).
Potentially, a largish program could use something akin to a Unix-style
filesystem model for managing package importing (with libraries being
effectively mounted within a local VFS, potentially also allowing for
"symlinks" within the package space).
Note that within the modules, it would still behave as-if it were a C
style global namespace (it need not necessarily introduce any additional
scoping semantics, unlike Java).
Scoping semantics could help, but would add some additional complexity
to the compiler. If supported, one option would be to support these also
using "namespace" and "using" keywords (likely used in a similar way to
their usage in C#).
If pulled of well, such a module system could be both faster and require
less memory use in the compiler if compared with headers (where in many
programs, the amount of time and memory spent processing headers
significantly exceeds that spent processing the actual code within each
translation unit).
There is the typical workaround of include'ing everything into a single
big translation unit (AKA: "unity builds"), but while this is fast, it
can still eat a significant amount of memory in the compiler. Better
might be to provide an alternative both to textual header inclusion and
unity builds, while ideally allowing for fast and low-overhead
compilation (reading in a binary manifest of declared types and symbols
likely being a bit cheaper).
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. Granted, even if parsing is fast, this still leaves the
challenge of fast/efficient machine-code generation.
( Cough, and not like the horribly slow compile times one sees trying to
rebuild LLVM... )
...
It need not be directly backwards compatible with C, but ideally should
be close enough that "copy paste translation" shouldn't be too much
effort (IOW: There shouldn't be any drastic changes in terms of syntax
nor significant changes to commonly used features).
But, I don't know, just some idle thoughts at the moment.
Or basically, sort of like a hybridized common subset of C and a C-like
subset of "unsafe" C# (IOW: mo OOP nor Generics, nor a garbage
collector, ...).
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-05 07:52 +0000 |
| Message-ID | <v688n9$36tb0$1@dont-email.me> |
| In reply to | #386769 |
On Fri, 5 Jul 2024 02:30:34 -0500, 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. I think we already have enough of C. The only way forward is outward-- rethink the whole problem from a different angle.
[toc] | [prev] | [next] | [standalone]
| From | yeti <yeti@tilde.institute> |
|---|---|
| Date | 2024-07-05 09:12 +0042 |
| Message-ID | <87o77ci6lz.fsf@tilde.institute> |
| In reply to | #386770 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > I think we already have enough of C. No. -- Trust me, I know what I'm doing...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-05 01:09 -0700 |
| Message-ID | <871q48w98e.fsf@nosuchdomain.example.com> |
| In reply to | #386769 |
BGB <cr88192@gmail.com> writes:
> 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.
>
>
> Goal would be to make it easier to get more consistent behavior across
> implementations, and also to make it simpler to implement (vs an
> actual C compiler); with a sub-goal to allow for implementing a
> compiler within a small memory footprint (as would be possible for K&R
> or C89).
>
>
> Say for example:
> Integer type sizes are defined;
> Nominally, integers are:
> Twos complement;
> Little endian;
> Wrap on overflow.
> Dropped features:
> VLAs
> Multidimensional arrays (*1)
> Bitfields
> ...
> Simplified declaration syntax (*2):
> {Modifier|Attribute}* TypeName Declarator
>
>
> *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. If using pointers, one almost invariably needs to
> fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
> that it could make sense to drop them and have people always do their
> multidimensional indexing manually.
>
> Note that multidimensional indexing via multiple levels of pointer
> indirection would not be effected by this.
[...]
Multidimensional arrays in C are not a distinct language feature.
They are simply arrays of arrays, and all operations on them follow
from operations on ordinary arrays and pointers.
Are you proposing (in this hypothetical new language) to add
an arbitrary restriction, so that arrays can have elements of
arithmetic, pointer, struct, etc. type, but not of array type?
I'm not sure I see the point.
I personally would hope that this language would *not* inherit C's
odd treatment of arrays and pointers. If so, and if it supports
multidimensional arrays, they'd have to be defined differently than
the way they're defined in C.
(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.)
--
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-07-05 08:25 +0000 |
| Message-ID | <v68al5$376r6$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.) Algol 68 had it before that. It also had a “rowing” coercion, to convert a value of type T to type “row of T” (as a single-element array, of course).
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-05 04:19 -0500 |
| Message-ID | <v68dsm$37sg2$1@dont-email.me> |
| In reply to | #386771 |
On 7/5/2024 3:09 AM, Keith Thompson wrote:
> BGB <cr88192@gmail.com> writes:
>> 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.
>>
>>
>> Goal would be to make it easier to get more consistent behavior across
>> implementations, and also to make it simpler to implement (vs an
>> actual C compiler); with a sub-goal to allow for implementing a
>> compiler within a small memory footprint (as would be possible for K&R
>> or C89).
>>
>>
>> Say for example:
>> Integer type sizes are defined;
>> Nominally, integers are:
>> Twos complement;
>> Little endian;
>> Wrap on overflow.
>> Dropped features:
>> VLAs
>> Multidimensional arrays (*1)
>> Bitfields
>> ...
>> Simplified declaration syntax (*2):
>> {Modifier|Attribute}* TypeName Declarator
>>
>>
>> *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. If using pointers, one almost invariably needs to
>> fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
>> that it could make sense to drop them and have people always do their
>> multidimensional indexing manually.
>>
>> Note that multidimensional indexing via multiple levels of pointer
>> indirection would not be effected by this.
> [...]
>
> Multidimensional arrays in C are not a distinct language feature.
> They are simply arrays of arrays, and all operations on them follow
> from operations on ordinary arrays and pointers.
>
> Are you proposing (in this hypothetical new language) to add
> an arbitrary restriction, so that arrays can have elements of
> arithmetic, pointer, struct, etc. type, but not of array type?
> I'm not sure I see the point.
>
As-is, the multidimensional arrays require the compiler to realize that
it needs to multiply one index by the product of all following indices.
So, say:
int a[4][4];
int j, k, l;
l=a[j][k];
Essentially needs to be internally translated to, say:
l=a[j*4+k];
Eliminating multidimensional arrays eliminates the need for this
translation logic, and the need to be able to represent this case in the
typesystem handling logic (which is, as I see it, in some ways very
different from what one needs for a struct).
While eliminating structs could also simplify things; structs also tend
to be a lot more useful.
At least in BGBCC, internally types are represented as several logical
fields:
array size (usually 0 for non-arrays);
(sometimes) a field holding an additional "modifier mode";
pointer indirection level;
ID number for primitive type or complex type/structure.
So, for part of the range, it is understood to represent one of the
primitive types. Else it identifies a structure, which identifies the
contents of a struct or function pointer or similar.
One can represent a multidimensional array by daisy-chaining the types
(via a "typedef" entry whose sole purpose is to hold another type), but
this is wonky. Though, C contains other occasionally used edge cases
which require this.
Though, within the serialized IR stage, there is an ASCII notation, say:
i //int
A4i //int[4]
A4,4i //int[4][4]
Pi //int*
PPi //int**
XSomeStruct; //SomeStruct, given by name
X123 //SomeStruct (given by index number)
A4X123 //SomeStruct[4]
P(xx)y //unsigned long long (*)(long long, long long);
...
Where:
a..z: Various primitive types.
Cx, Gx: More primitive types.
Most capital letters represent structural features of the type.
Versus the compiler internally using a bit-packed format.
In the normal bit-packed form (with multiple sub-layouts existing), the
various fields have a limited range. Going bigger turns into a case
where the type is instead interpreted as an index into a table of
"overflowed" types, which are represented as structures.
This is less desirable, as an entry in a table holding a dedicated
struct is less desirable than a packed bit-pattern (but, logically, both
can represent the same general information).
> I personally would hope that this language would *not* inherit C's
> odd treatment of arrays and pointers. If so, and if it supports
> multidimensional arrays, they'd have to be defined differently than
> the way they're defined in C.
>
The idea in this case was to make it so that:
int[16];
Can be functionally identical to:
int*
As far as most of the compiler's type-system handling is concerned. In
this case, one only needs to care about the size when reserving space
for the array.
One other simplification is also to make is so that:
SomeStruct tfoo, tbar;
And:
SomeStruct *pfoo, *pbar;
Are treated as equivalent at the lower levels, with the primary
difference that:
pbar=pfoo;
Will merely assign the pointer, whereas:
tbar=tfoo;
Needs to reserve memory for the structs in the stack-frame or similar,
and then effectively turns the assignment internally into:
memcpy(&tbar, &tfoo, sizeof(SomeStruct));
The ABI in my case also typically passes (and returns) structs by
reference (thus, at the low-level, the compiler and ABI can treat them
as pointers). Though, struct return is a little wonky as one effectively
passes in a hidden argument for where the structure is to be returned
into (and trying to call a function that returns a struct by value with
a missing prototype will very possibly result in a crash).
Though, functionally it is not that much different in this sense from
either the Win64 x64 ABI, or the WinCE SH-4 ABI (from which part the
core of my ABI design was derived). Though, can note that both the Win64
x64 and WinCE SH-4 ABI are "oddly similar" in many areas.
Granted, arrays of structs still represent some hassle, as one needs to
multiply the index by the size of the struct when offsetting the pointer.
This is in strong contrast, say, to the RISC-V ABI, which directly
copies the structure contents around in memory to pass and return them.
Well, and needs logic much more complex than:
Does the struct fit into an integer type?
Pass/return contents as the integer type.
Else, pass/return as a pointer.
But, to preserve lvalue semantics, one may still need to pass structs by
reference within a function (even if they are small enough to fit into
an integer register).
> (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.)
>
Also kinda similar with C#.
But, I figured possibly going in a direction more like Java.
...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-05 12:20 +0100 |
| Message-ID | <87plrsultu.fsf@bsb.me.uk> |
| In reply to | #386774 |
BGB <cr88192@gmail.com> writes:
> On 7/5/2024 3:09 AM, Keith Thompson wrote:
>> BGB <cr88192@gmail.com> writes:
>>> 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.
>>>
>>>
>>> Goal would be to make it easier to get more consistent behavior across
>>> implementations, and also to make it simpler to implement (vs an
>>> actual C compiler); with a sub-goal to allow for implementing a
>>> compiler within a small memory footprint (as would be possible for K&R
>>> or C89).
>>>
>>>
>>> Say for example:
>>> Integer type sizes are defined;
>>> Nominally, integers are:
>>> Twos complement;
>>> Little endian;
>>> Wrap on overflow.
>>> Dropped features:
>>> VLAs
>>> Multidimensional arrays (*1)
>>> Bitfields
>>> ...
>>> Simplified declaration syntax (*2):
>>> {Modifier|Attribute}* TypeName Declarator
>>>
>>>
>>> *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. If using pointers, one almost invariably needs to
>>> fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
>>> that it could make sense to drop them and have people always do their
>>> multidimensional indexing manually.
>>>
>>> Note that multidimensional indexing via multiple levels of pointer
>>> indirection would not be effected by this.
>> [...]
>> Multidimensional arrays in C are not a distinct language feature.
>> They are simply arrays of arrays, and all operations on them follow
>> from operations on ordinary arrays and pointers.
>> Are you proposing (in this hypothetical new language) to add
>> an arbitrary restriction, so that arrays can have elements of
>> arithmetic, pointer, struct, etc. type, but not of array type?
>> I'm not sure I see the point.
>
> As-is, the multidimensional arrays require the compiler to realize that it
> needs to multiply one index by the product of all following indices.
>
> So, say:
> int a[4][4];
> int j, k, l;
> l=a[j][k];
>
> Essentially needs to be internally translated to, say:
> l=a[j*4+k];
>
> Eliminating multidimensional arrays eliminates the need for this
> translation logic, and the need to be able to represent this case in the
> typesystem handling logic (which is, as I see it, in some ways very
> different from what one needs for a struct).
How can it be eliminated? All your plan does is force me to wrap the
inner array in a struct in order to get anything like the convenience of
the above:
struct a { int a[4]; };
struct a a[4];
l = a[j].a[k];
Most compilers with generate the same arithmetic (indeed exactly the
same code) for this as for the more convenient from that you don't like.
All you can do to eliminate this code generation is to make it so hard
to re-write the convenient code you dislike. (And yes, I used the same
name all over the place because you are forcing me to.)
> While eliminating structs could also simplify things; structs also tend to
> be a lot more useful.
Indeed. And I'd have to use them for this!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-05 08:28 -0500 |
| Message-ID | <v68sft$3a6lh$1@dont-email.me> |
| In reply to | #386775 |
On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
> BGB <cr88192@gmail.com> writes:
>
>> On 7/5/2024 3:09 AM, Keith Thompson wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> 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.
>>>>
>>>>
>>>> Goal would be to make it easier to get more consistent behavior across
>>>> implementations, and also to make it simpler to implement (vs an
>>>> actual C compiler); with a sub-goal to allow for implementing a
>>>> compiler within a small memory footprint (as would be possible for K&R
>>>> or C89).
>>>>
>>>>
>>>> Say for example:
>>>> Integer type sizes are defined;
>>>> Nominally, integers are:
>>>> Twos complement;
>>>> Little endian;
>>>> Wrap on overflow.
>>>> Dropped features:
>>>> VLAs
>>>> Multidimensional arrays (*1)
>>>> Bitfields
>>>> ...
>>>> Simplified declaration syntax (*2):
>>>> {Modifier|Attribute}* TypeName Declarator
>>>>
>>>>
>>>> *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. If using pointers, one almost invariably needs to
>>>> fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
>>>> that it could make sense to drop them and have people always do their
>>>> multidimensional indexing manually.
>>>>
>>>> Note that multidimensional indexing via multiple levels of pointer
>>>> indirection would not be effected by this.
>>> [...]
>>> Multidimensional arrays in C are not a distinct language feature.
>>> They are simply arrays of arrays, and all operations on them follow
>>> from operations on ordinary arrays and pointers.
>>> Are you proposing (in this hypothetical new language) to add
>>> an arbitrary restriction, so that arrays can have elements of
>>> arithmetic, pointer, struct, etc. type, but not of array type?
>>> I'm not sure I see the point.
>>
>> As-is, the multidimensional arrays require the compiler to realize that it
>> needs to multiply one index by the product of all following indices.
>>
>> So, say:
>> int a[4][4];
>> int j, k, l;
>> l=a[j][k];
>>
>> Essentially needs to be internally translated to, say:
>> l=a[j*4+k];
>>
>> Eliminating multidimensional arrays eliminates the need for this
>> translation logic, and the need to be able to represent this case in the
>> typesystem handling logic (which is, as I see it, in some ways very
>> different from what one needs for a struct).
>
> How can it be eliminated? All your plan does is force me to wrap the
> inner array in a struct in order to get anything like the convenience of
> the above:
>
> struct a { int a[4]; };
>
> struct a a[4];
> l = a[j].a[k];
>
> Most compilers with generate the same arithmetic (indeed exactly the
> same code) for this as for the more convenient from that you don't like.
>
> All you can do to eliminate this code generation is to make it so hard
> to re-write the convenient code you dislike. (And yes, I used the same
> name all over the place because you are forcing me to.)
>
It is not so much a dislike of multidimensional arrays as a concept, but
rather, the hair they add to the compiler and typesystem.
Granted, one would still have other complex types, like structs and
function pointers, so potentially the complexity savings would be limited.
>> While eliminating structs could also simplify things; structs also tend to
>> be a lot more useful.
>
> Indeed. And I'd have to use them for this!
>
Errm, the strategy I would assume is, as noted:
int a[4][4];
...
l=a[j][k];
Becomes:
int a[16];
...
l=a[j*4+k];
Much like what one would typically need to do anyways if the array was
heap-allocated.
Though, the major goal for this sort of thing is mostly to try to limit
the complexity required to write a compiler (as opposed to programmer
convenience).
Like, for example, I had tried (but failed) to write a usable C compiler
in less than 30k lines (and also ideally needing less than 4MB of RAM).
But, if the language design is simplified some, this might be a little
closer. Might still be doable, but a C compiler in 50-75k lines is much
less impressive.
Though, admittedly, my current C compiler (used for my project)
currently weighs in at around 250k lines, and much of the code
complexity is in the backend code generator. One would need to have some
fairly weak code-generation to get this down (likely translating the IR
to 3AC form, and then doing a pretty close to 1:1 mapping between 3AC
operations and output code, possibly with no register allocator or other
optimizations).
But, even with this massive 250k line compiler, I am still running into
edge cases which don't work correctly (as recently discovered after
resuming the effort to port Quake3 to my ISA).
Granted, this is along with needing to fix a bunch of bugs in my DLL
loading and similar (Quake3 being a more complex engine than Doom or
Quake1; in this case effectively requiring virtual memory and a DLL
loader). And, discovering various other bugs in the runtime libraries
and other things in the process (and, Quake3 builds and sorta works, but
it seems the BSP doesn't load correctly and the player just sort of
falls out the bottom of the incorrectly loaded map).
As-is, also, for the main Quake3 EXE, my compiler ends up using about
270MB of RAM, which is a bit steep...
A big chunk of the RAM in this case ends up being:
Memory needed for the parser ASTs;
Memory needed for the structures representing globals;
Memory needed for the IR stages (mostly the 3AC IR, *1);
...
*1: Where, as-is, pretty much every operation in the program ends up
being represented as a struct.
My compiler generally does code generation for an entire executable
image at the same time. The AST is a lot bulkier, but generally the AST
only needs enough memory to parse a single translation unit (and the AST
nodes are reused between translation units).
Though, yes, granted, porting something these games would still require
a proper C compiler, so alas...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-05 23:40 +0100 |
| Message-ID | <87ed87v4wi.fsf@bsb.me.uk> |
| In reply to | #386776 |
BGB <cr88192@gmail.com> writes:
> On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
>> BGB <cr88192@gmail.com> writes:
>>
>>> On 7/5/2024 3:09 AM, Keith Thompson wrote:
>>>> BGB <cr88192@gmail.com> writes:
>>>>> 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.
>>>>>
>>>>>
>>>>> Goal would be to make it easier to get more consistent behavior across
>>>>> implementations, and also to make it simpler to implement (vs an
>>>>> actual C compiler); with a sub-goal to allow for implementing a
>>>>> compiler within a small memory footprint (as would be possible for K&R
>>>>> or C89).
>>>>>
>>>>>
>>>>> Say for example:
>>>>> Integer type sizes are defined;
>>>>> Nominally, integers are:
>>>>> Twos complement;
>>>>> Little endian;
>>>>> Wrap on overflow.
>>>>> Dropped features:
>>>>> VLAs
>>>>> Multidimensional arrays (*1)
>>>>> Bitfields
>>>>> ...
>>>>> Simplified declaration syntax (*2):
>>>>> {Modifier|Attribute}* TypeName Declarator
>>>>>
>>>>>
>>>>> *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. If using pointers, one almost invariably needs to
>>>>> fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
>>>>> that it could make sense to drop them and have people always do their
>>>>> multidimensional indexing manually.
>>>>>
>>>>> Note that multidimensional indexing via multiple levels of pointer
>>>>> indirection would not be effected by this.
>>>> [...]
>>>> Multidimensional arrays in C are not a distinct language feature.
>>>> They are simply arrays of arrays, and all operations on them follow
>>>> from operations on ordinary arrays and pointers.
>>>> Are you proposing (in this hypothetical new language) to add
>>>> an arbitrary restriction, so that arrays can have elements of
>>>> arithmetic, pointer, struct, etc. type, but not of array type?
>>>> I'm not sure I see the point.
>>>
>>> As-is, the multidimensional arrays require the compiler to realize that it
>>> needs to multiply one index by the product of all following indices.
>>>
>>> So, say:
>>> int a[4][4];
>>> int j, k, l;
>>> l=a[j][k];
>>>
>>> Essentially needs to be internally translated to, say:
>>> l=a[j*4+k];
>>>
>>> Eliminating multidimensional arrays eliminates the need for this
>>> translation logic, and the need to be able to represent this case in the
>>> typesystem handling logic (which is, as I see it, in some ways very
>>> different from what one needs for a struct).
>> How can it be eliminated? All your plan does is force me to wrap the
>> inner array in a struct in order to get anything like the convenience of
>> the above:
>> struct a { int a[4]; };
>> struct a a[4];
>> l = a[j].a[k];
>> Most compilers with generate the same arithmetic (indeed exactly the
>> same code) for this as for the more convenient from that you don't like.
>> All you can do to eliminate this code generation is to make it so hard
>> to re-write the convenient code you dislike. (And yes, I used the same
>> name all over the place because you are forcing me to.)
>>
>
> It is not so much a dislike of multidimensional arrays as a concept, but
> rather, the hair they add to the compiler and typesystem.
>
> Granted, one would still have other complex types, like structs and
> function pointers, so potentially the complexity savings would be
> limited.
Then the "hair" is still there.
>>> While eliminating structs could also simplify things; structs also tend to
>>> be a lot more useful.
>> Indeed. And I'd have to use them for this!
>>
>
> Errm, the strategy I would assume is, as noted:
> int a[4][4];
> ...
> l=a[j][k];
> Becomes:
> int a[16];
> ...
> l=a[j*4+k];
That's what you want to force me to write, but I can use and array of
arrays despite your arbitrary ban on them by simply putting the array in
a struct.
Anyway, sine C exists, I won't be forced to use your proposed
alternative.
> Much like what one would typically need to do anyways if the array was
> heap-allocated.
Only if you forbid variably modified types (note not VLAs).
int (*a)[n] = malloc(m * sizeof *a);
allows me to index a[i][j] conveniently.
> Though, the major goal for this sort of thing is mostly to try to limit the
> complexity required to write a compiler (as opposed to programmer
> convenience).
Ah.
> Like, for example, I had tried (but failed) to write a usable C compiler in
> less than 30k lines (and also ideally needing less than 4MB of RAM). But,
> if the language design is simplified some, this might be a little
> closer. Might still be doable, but a C compiler in 50-75k lines is much
> less impressive.
Why do you think this matters to other people?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-05 22:30 -0500 |
| Message-ID | <v6adrm$3ljg6$1@dont-email.me> |
| In reply to | #386781 |
On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
> BGB <cr88192@gmail.com> writes:
>
>> On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>
>>>> On 7/5/2024 3:09 AM, Keith Thompson wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Goal would be to make it easier to get more consistent behavior across
>>>>>> implementations, and also to make it simpler to implement (vs an
>>>>>> actual C compiler); with a sub-goal to allow for implementing a
>>>>>> compiler within a small memory footprint (as would be possible for K&R
>>>>>> or C89).
>>>>>>
>>>>>>
>>>>>> Say for example:
>>>>>> Integer type sizes are defined;
>>>>>> Nominally, integers are:
>>>>>> Twos complement;
>>>>>> Little endian;
>>>>>> Wrap on overflow.
>>>>>> Dropped features:
>>>>>> VLAs
>>>>>> Multidimensional arrays (*1)
>>>>>> Bitfields
>>>>>> ...
>>>>>> Simplified declaration syntax (*2):
>>>>>> {Modifier|Attribute}* TypeName Declarator
>>>>>>
>>>>>>
>>>>>> *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. If using pointers, one almost invariably needs to
>>>>>> fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
>>>>>> that it could make sense to drop them and have people always do their
>>>>>> multidimensional indexing manually.
>>>>>>
>>>>>> Note that multidimensional indexing via multiple levels of pointer
>>>>>> indirection would not be effected by this.
>>>>> [...]
>>>>> Multidimensional arrays in C are not a distinct language feature.
>>>>> They are simply arrays of arrays, and all operations on them follow
>>>>> from operations on ordinary arrays and pointers.
>>>>> Are you proposing (in this hypothetical new language) to add
>>>>> an arbitrary restriction, so that arrays can have elements of
>>>>> arithmetic, pointer, struct, etc. type, but not of array type?
>>>>> I'm not sure I see the point.
>>>>
>>>> As-is, the multidimensional arrays require the compiler to realize that it
>>>> needs to multiply one index by the product of all following indices.
>>>>
>>>> So, say:
>>>> int a[4][4];
>>>> int j, k, l;
>>>> l=a[j][k];
>>>>
>>>> Essentially needs to be internally translated to, say:
>>>> l=a[j*4+k];
>>>>
>>>> Eliminating multidimensional arrays eliminates the need for this
>>>> translation logic, and the need to be able to represent this case in the
>>>> typesystem handling logic (which is, as I see it, in some ways very
>>>> different from what one needs for a struct).
>>> How can it be eliminated? All your plan does is force me to wrap the
>>> inner array in a struct in order to get anything like the convenience of
>>> the above:
>>> struct a { int a[4]; };
>>> struct a a[4];
>>> l = a[j].a[k];
>>> Most compilers with generate the same arithmetic (indeed exactly the
>>> same code) for this as for the more convenient from that you don't like.
>>> All you can do to eliminate this code generation is to make it so hard
>>> to re-write the convenient code you dislike. (And yes, I used the same
>>> name all over the place because you are forcing me to.)
>>>
>>
>> It is not so much a dislike of multidimensional arrays as a concept, but
>> rather, the hair they add to the compiler and typesystem.
>>
>> Granted, one would still have other complex types, like structs and
>> function pointers, so potentially the complexity savings would be
>> limited.
>
> Then the "hair" is still there.
>
Possibly true.
I am now left thinking maybe the issue was not that the multidimensional
arrays exist, but rather, how I had approached implementing them...
Ironically, I probably should have leaned harder into the "daisy chained
types" interpretation, rather than treating it as an undesirable
implementation tradeoff.
As noted, my conceptual approach to types was a little different; and,
implicitly, more directly mimics how types behave in the Java VM (but
with C like type semantics being expressed on top of this).
Though, rather than I/L/F/D/A (Int/Long/Float/Double/Address) as the
fundamental types, it is more like I/L/D/X/A/V
(Int/Long/Double/XLong/Address/Variant).
With arrays and by-value structs being treated like subtypes of the
Address type, just with pre reserved storage being created in the prolog.
Variant also exists, holding any types that are nominally represented as
tagged references (and type-checked at runtime; though using all this is
non-standard in C).
The XLong category mostly holds types with a 128-bit format.
Well, and with a C compiler that originally started out as an
interpreter for a JavaScript clone (before later taking influence from
the JVM and moving towards a static-typed core; with a fork of this VM
having been modified to be able to parse C, ...).
Design isn't entirely free from hair.
The backend did end up with a fair bit of complexity as well, as some
initial ideas turned out to not have been so good in retrospect.
>>>> While eliminating structs could also simplify things; structs also tend to
>>>> be a lot more useful.
>>> Indeed. And I'd have to use them for this!
>>>
>>
>> Errm, the strategy I would assume is, as noted:
>> int a[4][4];
>> ...
>> l=a[j][k];
>> Becomes:
>> int a[16];
>> ...
>> l=a[j*4+k];
>
> That's what you want to force me to write, but I can use and array of
> arrays despite your arbitrary ban on them by simply putting the array in
> a struct.
>
> Anyway, sine C exists, I won't be forced to use your proposed
> alternative.
>
IN most contexts, I don't really see how a struct is preferable to a
multiply, but either way...
Whole language design is still a hypothetical at this point anyways (and
my actual compiler does support multidimensional arrays).
>> Much like what one would typically need to do anyways if the array was
>> heap-allocated.
>
> Only if you forbid variably modified types (note not VLAs).
>
> int (*a)[n] = malloc(m * sizeof *a);
>
> allows me to index a[i][j] conveniently.
>
This is another one of the edge cases that I would likely omit from such
a language (rarely used in my experience).
But, as noted elsewhere, sizeof would also likely no longer be allowed
for expressions.
>> Though, the major goal for this sort of thing is mostly to try to limit the
>> complexity required to write a compiler (as opposed to programmer
>> convenience).
>
> Ah.
>
>> Like, for example, I had tried (but failed) to write a usable C compiler in
>> less than 30k lines (and also ideally needing less than 4MB of RAM). But,
>> if the language design is simplified some, this might be a little
>> closer. Might still be doable, but a C compiler in 50-75k lines is much
>> less impressive.
>
> Why do you think this matters to other people?
>
As-is, C compilers tend to be a relative pain to implement.
A simplified language would be less of a pain, so people can more easily
throw together their own compiler as-needed, rather than have an
implicit assumption of "one compiler to rule them all".
But, C is at least a little more amendable to people rolling their own
compilers, than, say, a language like C++ (where hand-rolling a
full-featured C++ compiler seems likely out of reach for a single
developer project).
But, say, for example, you want to be able to write a compiler that runs
on a system with relatively limited RAM and possibly no MMU.
Granted, there is also MicroPython, but... blarg...
At present, I was left with inertia from my current compiler:
Given I am pretty much exclusively cross-compiling from a PC, the
incentive to invest effort on a smaller compiler is lacking.
Technically, I might also want a compiler that can deal with GLSL.
Using my existing compiler to static compile shader programs would be
possible, but tacky and wouldn't mesh well with the OpenGL API (which
generally expects shaders to be loaded in plain text form, rather than,
say, as a statically-compiled part of the program, or as COFF objects or
DLLs or similar).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-07-06 19:01 +0200 |
| Message-ID | <v6bta2$3svoi$2@dont-email.me> |
| In reply to | #386787 |
On 06/07/2024 05:30, BGB wrote: > > Ironically, I probably should have leaned harder into the "daisy chained > types" interpretation, rather than treating it as an undesirable > implementation tradeoff. > I once had to use a very limited C compiler that supported arrays, and structs, but not arrays of structs or structs containing arrays. It was truly a PITA. A language that has such inconvenient limitations would be unusable for me - I'd rather go back to using BASIC on a ZX Spectrum.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-06 13:47 -0500 |
| Message-ID | <v6c3ip$3u078$2@dont-email.me> |
| In reply to | #386808 |
On 7/6/2024 12:01 PM, David Brown wrote: > On 06/07/2024 05:30, BGB wrote: >> >> Ironically, I probably should have leaned harder into the "daisy >> chained types" interpretation, rather than treating it as an >> undesirable implementation tradeoff. >> > > I once had to use a very limited C compiler that supported arrays, and > structs, but not arrays of structs or structs containing arrays. It was > truly a PITA. A language that has such inconvenient limitations would > be unusable for me - I'd rather go back to using BASIC on a ZX Spectrum. > I would not assume going quite that far.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-06 23:41 +0100 |
| Message-ID | <87v81ita77.fsf@bsb.me.uk> |
| In reply to | #386787 |
BGB <cr88192@gmail.com> writes: > On 7/5/2024 5:40 PM, Ben Bacarisse wrote: >> BGB <cr88192@gmail.com> writes: >> >>> On 7/5/2024 6:20 AM, Ben Bacarisse wrote: >>>> BGB <cr88192@gmail.com> writes: >>>>> While eliminating structs could also simplify things; structs also tend to >>>>> be a lot more useful. >>>> Indeed. And I'd have to use them for this! >>>> >>> >>> Errm, the strategy I would assume is, as noted: >>> int a[4][4]; >>> ... >>> l=a[j][k]; >>> Becomes: >>> int a[16]; >>> ... >>> l=a[j*4+k]; >> That's what you want to force me to write, but I can use and array of >> arrays despite your arbitrary ban on them by simply putting the array in >> a struct. ... > IN most contexts, I don't really see how a struct is preferable to a > multiply, but either way... And I can't see how an array of arrays is harder for your compiler than an array of structs. C's indexing requires the compiler to know that size of the items pointed to. I suspect that there is something amiss with your design if you are considering this limiting in order to simplify the compiler. A simple compiler should not care what kind of thing p points to in p[i] only what size of object p points to. > Whole language design is still a hypothetical at this point anyways (and my > actual compiler does support multidimensional arrays). Ah. I think that when you've written most of it, you will see that ruling out arrays of arrays will have not simplifying effect. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-06 16:42 -0700 |
| Message-ID | <87sewmt7da.fsf@nosuchdomain.example.com> |
| In reply to | #386827 |
Ben Bacarisse <ben@bsb.me.uk> writes:
> BGB <cr88192@gmail.com> writes:
>> On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
[...]
>> Whole language design is still a hypothetical at this point anyways (and my
>> actual compiler does support multidimensional arrays).
>
> Ah. I think that when you've written most of it, you will see that
> ruling out arrays of arrays will have not simplifying effect.
Indeed. I believe (based on no direct experience) that you could write
a fully conforming C compiler without even thinking about
multidimensional arrays, and if you get the array code right,
multidimensional arrays will just work.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-06 20:04 -0700 |
| Message-ID | <86msmtc37y.fsf@linuxsc.com> |
| In reply to | #386837 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Ben Bacarisse <ben@bsb.me.uk> writes:
>
>> BGB <cr88192@gmail.com> writes:
>>
>>> On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
>
> [...]
>
>>> Whole language design is still a hypothetical at this point anyways (and my
>>> actual compiler does support multidimensional arrays).
>>
>> Ah. I think that when you've written most of it, you will see that
>> ruling out arrays of arrays will have not simplifying effect.
>
> Indeed. I believe (based on no direct experience) that you could write
> a fully conforming C compiler without even thinking about
> multidimensional arrays, and if you get the array code right,
> multidimensional arrays will just work.
There are some corner cases that seem to require some thinking.
For example,
extern int x[];
extern int y[][10];
are both alright, but
extern int z[10][];
is not. There are similar cases with function parameters, and
maybe with VLAs. Also, possibly, flexible array members (do I
have that name right?).
Not saying the amount of thinking needed is overpowering, but
it does seem to be greater than zero.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-06 23:28 -0500 |
| Message-ID | <v6d5k0$6rk5$1@dont-email.me> |
| In reply to | #386827 |
On 7/6/2024 5:41 PM, Ben Bacarisse wrote:
> BGB <cr88192@gmail.com> writes:
>
>> On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>
>>>> On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>
>>>>>> While eliminating structs could also simplify things; structs also tend to
>>>>>> be a lot more useful.
>>>>> Indeed. And I'd have to use them for this!
>>>>>
>>>>
>>>> Errm, the strategy I would assume is, as noted:
>>>> int a[4][4];
>>>> ...
>>>> l=a[j][k];
>>>> Becomes:
>>>> int a[16];
>>>> ...
>>>> l=a[j*4+k];
>>> That's what you want to force me to write, but I can use and array of
>>> arrays despite your arbitrary ban on them by simply putting the array in
>>> a struct.
> ...
>> IN most contexts, I don't really see how a struct is preferable to a
>> multiply, but either way...
>
> And I can't see how an array of arrays is harder for your compiler than
> an array of structs. C's indexing requires the compiler to know that
> size of the items pointed to.
>
> I suspect that there is something amiss with your design if you are
> considering this limiting in order to simplify the compiler. A simple
> compiler should not care what kind of thing p points to in
>
> p[i]
>
> only what size of object p points to.
>
When I designed the compiler code, the initial approach for internal
type layout was to bit-pack it into 32 bits, say (a lot of this is from
memory, so maybe wrong):
Basic1
(31:28): Layout of Type (0=Basic)
(27:16): Array Size
(15:12): Pointer Level Count
(11: 0): Base Type
Basic2
(31:28): Layout of Type (1=Basic2)
(27: 8): Array Size
( 7: 6): Pointer Level Count
( 5: 0): Base Type
Basic3
(31:28): Layout of Type (2=Basic3)
(27:24): Array Size
(23:20): Pointer Level Count
(19: 0): Base Type
Overflow
(31:28): Layout of Type (3=Overflow)
(27:24): MBZ
(23: 0): Index into Type-Overflow Table
And, a few other cases...
Basic1 was the default, able to express arrays from 0..4095 elements,
with 0..7 levels of pointer indirection, and 0..4095 for the base type.
Where, 0=T, 1=T*, 2=T**, ..., 7=T*******
8=T[], 9=T[][], A=T*[], B=T*[*], C=&T, ...
Note that at present, there is no way to express more than 7 levels of
pointer indirection, but this issue hasn't come up in practice.
Basic2 is for big arrays of a primitive type, 0..3 pointer levels. May
only encode low-numbered primitive types.
Basic3 is the opposite, able to express a wider range of types, but only
small arrays.
There is another variant of Basic1 that splits the Array Size field in
half, with a smaller array limit, but able to encode
const/volatile/restrict/etc (but only in certain combinations).
Overflow would be used if the type couldn't fit into one of the above,
the type is then expressed in a table. It is avoided when possible, as
overflow entry tables are comparably expensive.
Type Numbering space:
0.. 63: Primitive Types, Higher priority
64.. 255: Primitive Types, Lower priority
256 .. 4095: Complex Types, Index into Literals Table
4096..1048575: Complex Types, Index into Literals Table
Small numbered base types were higher priority:
00=Int, 01=Long(64bit), 02=Float, 03=Double,
04=Ptr(void*), 05=Void, 06=Struct(Abstract), 07=NativeLong
08=SByte, 09=UByte, 0A=Short, 0B=UShort,
0C=UInt, 0D=ULong, 0E=UNativeLong, 0F=ImplicitInt
Followed by, say:
10=Int128, 11=UInt128, 12=Float128/LongDouble, 13=Float16,
...
Where, Type Number 256 would map to index 0 in the Literal Table.
An index into the literals table will generally be used to encode a
Struct or Function Pointer or similar. This table will hold a structure
describing the fields of a struct, or the arguments and return value of
a function pointer (in my BS2 language, it may also define class
members, a superclass, implemented interfaces, ...).
It could also be used to encode another type, which was needed for
things like multidimensional arrays and some other complex types. But,
this seemed like an ugly hack... (And was at odds with how I imagined
types working, but seemed like a technical necessity).
These would often be packed inside of a 64-bit register/variable descriptor.
Local Variables:
(63:56): Descriptor Type
(55:24): Variable Type
(23:12): Sequence Number
(11: 0): Identity Number
Global Variables:
(63:56): Descriptor Type
(55:24): Variable Type
(23: 0): Index into Global Table
Integer Literal:
(63:56): Descriptor Type
(55:32): Compact Type
(31: 0): Value
String Literal:
(63:56): Descriptor Type
(55:32): Compact Type
(31: 0): Offset into String Table
There were various other types, representing larger integer and floating
point types:
Long and Double literals, representing the value as 56 bits
Low 8 bits cut off for Double
An index into a table of raw 64-bit values (if it can't be expressed
directly as one of the other options).
Values for 128-bit types were expressed as an index pair into the table
of 64-bit values:
(63:56): Descriptor Type
(55:48): Primitive Type
(47:24): Index into Value Table (High 64 bits)
(23: 0): Index into Value Table (Low 64 bits)
One downside as-is, is that if a given variable is assigned more than
4096 times in a given function, it can no longer be given a unique ID.
Though uncommon, this is not entirely implausible (with sufficiently
large functions), and there isn't currently any good way to deal with
this (apart from raising a compiler error).
This can happen potentially in large functions. Taking away bits from
the base ID isn't good either, as functions pushing 1000+ local
variables aren't entirely implausible either (though, thus far, not
really seen any with much more than around 400 local variables, but
still...).
Can note though, that generally, there seems to be an upper limit of 18
to 23 for the maximum number of function arguments in the code I have
tested.
Sequence numbers don't currently apply to global variables, where only
one instance of a global variable can exist at a time and global
variables are always synchronized at the end of a basic block.
Thus far, not dealt with any programs that push the current hard limit
of 16M global declarations (at present, ~ 30-60k seems more typical).
Where, there would be multiple such fields in each 3AC op, say (copy
pasting):
struct BGBCC_CCXL_VirtOp_s {
byte opn; //opcode number
byte opr; //operator
byte prd; //predication mode
byte immty; //immediate type
byte tgt_mult; //branch target multiplier
byte llvl; //Loop Level
ccxl_type type; //destination type of operation
ccxl_type stype; //source type of operation
ccxl_register dst; //destination
ccxl_register srca; //first source operand
ccxl_register srcb; //second source operand
ccxl_register srcc; //third source operand
ccxl_register srcd; //fourth source operand
ccxl_value imm; //operation immediate (union)
};
These operations are held in arrays, with spans within this array used
to define the various basic-blocks within a function.
The code for dealing with a lot of this got rather hairy...
But, as noted, the 3AC IR only exists in memory.
In the IR, the operations are expressed as a sort of linear bytecode
operating on a virtual stack machine; with types expressed as ASCII strings.
Logically, the stack holds "ccxl_register" values, and the number of 3AC
ops is typically less than the number of stack-machine operations (those
which exist simply to shuffle registers around essentially disappear in
the translation process).
Say, for example:
LOAD x
LOAD y
ADD
STORE z
Might turn into a single 3AC operation.
Note that (unlike a language like Forth or similar) generally control
flow may not be used to convey varying sets of items on the stack.
Note that in most cases, typically the stack is empty during any
control-flow operations.
>> Whole language design is still a hypothetical at this point anyways (and my
>> actual compiler does support multidimensional arrays).
>
> Ah. I think that when you've written most of it, you will see that
> ruling out arrays of arrays will have not simplifying effect.
>
I guess it is possible...
Well, and/or there might just be enough hair that something like this
will disappear into the noise.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-07 12:35 +0100 |
| Message-ID | <v6duhl$amlm$1@dont-email.me> |
| In reply to | #386850 |
On 07/07/2024 05:28, BGB wrote:
> On 7/6/2024 5:41 PM, Ben Bacarisse wrote:
>> BGB <cr88192@gmail.com> writes:
>>
>>> On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
>>>> BGB <cr88192@gmail.com> writes:
>>>>
>>>>> On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
>>>>>> BGB <cr88192@gmail.com> writes:
>>
>>>>>>> While eliminating structs could also simplify things; structs
>>>>>>> also tend to
>>>>>>> be a lot more useful.
>>>>>> Indeed. And I'd have to use them for this!
>>>>>>
>>>>>
>>>>> Errm, the strategy I would assume is, as noted:
>>>>> int a[4][4];
>>>>> ...
>>>>> l=a[j][k];
>>>>> Becomes:
>>>>> int a[16];
>>>>> ...
>>>>> l=a[j*4+k];
>>>> That's what you want to force me to write, but I can use and array of
>>>> arrays despite your arbitrary ban on them by simply putting the
>>>> array in
>>>> a struct.
>> ...
>>> IN most contexts, I don't really see how a struct is preferable to a
>>> multiply, but either way...
>>
>> And I can't see how an array of arrays is harder for your compiler than
>> an array of structs. C's indexing requires the compiler to know that
>> size of the items pointed to.
>>
>> I suspect that there is something amiss with your design if you are
>> considering this limiting in order to simplify the compiler. A simple
>> compiler should not care what kind of thing p points to in
>>
>> p[i]
>>
>> only what size of object p points to.
>>
>
>
> When I designed the compiler code, the initial approach for internal
> type layout was to bit-pack it into 32 bits, say (a lot of this is from
> memory, so maybe wrong):
> Basic1
> (31:28): Layout of Type (0=Basic)
> (27:16): Array Size
> (15:12): Pointer Level Count
> (11: 0): Base Type
> Basic2
> (31:28): Layout of Type (1=Basic2)
> (27: 8): Array Size
> ( 7: 6): Pointer Level Count
> ( 5: 0): Base Type
> Basic3
> (31:28): Layout of Type (2=Basic3)
> (27:24): Array Size
> (23:20): Pointer Level Count
> (19: 0): Base Type
> Overflow
> (31:28): Layout of Type (3=Overflow)
> (27:24): MBZ
> (23: 0): Index into Type-Overflow Table
> And, a few other cases...
>
>
> Basic1 was the default, able to express arrays from 0..4095 elements,
> with 0..7 levels of pointer indirection, and 0..4095 for the base type.
> Where, 0=T, 1=T*, 2=T**, ..., 7=T*******
> 8=T[], 9=T[][], A=T*[], B=T*[*], C=&T, ...
That's quite a level of detail. This looks more like an encoding you
might devise for a CPU instruction set. And yet you say elsewhere that
the whole compiler is 250K lines? So you're not trying to squeeze it
into a 16KB ROM or something.
> It could also be used to encode another type, which was needed for
> things like multidimensional arrays and some other complex types. But,
> this seemed like an ugly hack... (And was at odds with how I imagined
> types working, but seemed like a technical necessity).
I can see how multi-dim arrays would be troublesome with such a scheme.
My own approach is to use a bunch of parallel arrays (a table of structs
didn't appeal). They are populated with the standard types at the lower
end, then new types can be added.
A C type is represented by an index into those arrays. One of those
arrays is this (not C):
[0:maxtype]int tttarget # All names start with 'tt'
For a pointer, it is contains the index of the target type. For arrays,
it is the index of the element type. There is no restriction on nesting,
other than 'maxtype' (set to some large number; one day I'll make the
limit flexible).
> One downside as-is, is that if a given variable is assigned more than
> 4096 times in a given function, it can no longer be given a unique ID.
> Though uncommon, this is not entirely implausible (with sufficiently
> large functions), and there isn't currently any good way to deal with
> this (apart from raising a compiler error).
One of my compiler benchmarks is this program:
#include <stdio.h>
int main(void) {
int a, b=2, c=3, d=4;
a=b+c*d;
printf("%d\n", a);
}
Except that the 'a=b+c*d;' line is repeated 1M or 2M times, usually
within an included file.
Some compilers (including for other languages) find this challenging.
>
>
> But, as noted, the 3AC IR only exists in memory.
>
> In the IR, the operations are expressed as a sort of linear bytecode
> operating on a virtual stack machine; with types expressed as ASCII
> strings.
>
> Logically, the stack holds "ccxl_register" values, and the number of 3AC
> ops is typically less than the number of stack-machine operations (those
> which exist simply to shuffle registers around essentially disappear in
> the translation process).
>
> Say, for example:
> LOAD x
> LOAD y
> ADD
> STORE z
> Might turn into a single 3AC operation.
I've used 3AC as an IL (several attempts), and also a stack VM. The 3AC
always looked so simple, but it also was a lot of hard work to turn it
into decent register-based code.
Now I used a stack-based IL which is far easier to work with.
I wouldn't start off with turning stack code into 3AC! (SSA is supposed
to be /the/ way to generate code in compilers; they can keep it.)
Those 4 stack instructions might turn into 3/4 machine instructions on
x64 (perhaps fewere is register-resident). But if converting them to one
3AC instruction, you then have to expand them again.
Perhaps 3AC suits another architecture better (I think ARM uses
3-register ops; x64 is 2-register ops).
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-07-07 14:57 -0500 |
| Message-ID | <v6es1v$fian$1@dont-email.me> |
| In reply to | #386860 |
On 7/7/2024 6:35 AM, bart wrote:
> On 07/07/2024 05:28, BGB wrote:
>> On 7/6/2024 5:41 PM, Ben Bacarisse wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>
>>>> On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>
>>>>>> On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
>>>>>>> BGB <cr88192@gmail.com> writes:
>>>
>>>>>>>> While eliminating structs could also simplify things; structs
>>>>>>>> also tend to
>>>>>>>> be a lot more useful.
>>>>>>> Indeed. And I'd have to use them for this!
>>>>>>>
>>>>>>
>>>>>> Errm, the strategy I would assume is, as noted:
>>>>>> int a[4][4];
>>>>>> ...
>>>>>> l=a[j][k];
>>>>>> Becomes:
>>>>>> int a[16];
>>>>>> ...
>>>>>> l=a[j*4+k];
>>>>> That's what you want to force me to write, but I can use and array of
>>>>> arrays despite your arbitrary ban on them by simply putting the
>>>>> array in
>>>>> a struct.
>>> ...
>>>> IN most contexts, I don't really see how a struct is preferable to a
>>>> multiply, but either way...
>>>
>>> And I can't see how an array of arrays is harder for your compiler than
>>> an array of structs. C's indexing requires the compiler to know that
>>> size of the items pointed to.
>>>
>>> I suspect that there is something amiss with your design if you are
>>> considering this limiting in order to simplify the compiler. A simple
>>> compiler should not care what kind of thing p points to in
>>>
>>> p[i]
>>>
>>> only what size of object p points to.
>>>
>>
>>
>> When I designed the compiler code, the initial approach for internal
>> type layout was to bit-pack it into 32 bits, say (a lot of this is
>> from memory, so maybe wrong):
>> Basic1
>> (31:28): Layout of Type (0=Basic)
>> (27:16): Array Size
>> (15:12): Pointer Level Count
>> (11: 0): Base Type
>> Basic2
>> (31:28): Layout of Type (1=Basic2)
>> (27: 8): Array Size
>> ( 7: 6): Pointer Level Count
>> ( 5: 0): Base Type
>> Basic3
>> (31:28): Layout of Type (2=Basic3)
>> (27:24): Array Size
>> (23:20): Pointer Level Count
>> (19: 0): Base Type
>> Overflow
>> (31:28): Layout of Type (3=Overflow)
>> (27:24): MBZ
>> (23: 0): Index into Type-Overflow Table
>> And, a few other cases...
>>
>>
>> Basic1 was the default, able to express arrays from 0..4095 elements,
>> with 0..7 levels of pointer indirection, and 0..4095 for the base type.
>> Where, 0=T, 1=T*, 2=T**, ..., 7=T*******
>> 8=T[], 9=T[][], A=T*[], B=T*[*], C=&T, ...
>
> That's quite a level of detail. This looks more like an encoding you
> might devise for a CPU instruction set. And yet you say elsewhere that
> the whole compiler is 250K lines? So you're not trying to squeeze it
> into a 16KB ROM or something.
>
These values are packed inside of register descriptors, of which there
are multiple in each 3AC op. And, there may be a whole lot of 3AC ops in
a program. Much bulkier would cause the compiler to use a lot more RAM.
Though, a likely RAM-saving option would be to redesign the compiler
such that only one function needs to have 3AC loaded at a time. But, for
some tasks (such as tracing out everything that is reachable), this
would mean repetitively re-decoding the stack IR for various functions.
Well, and/or building more metadata, such as (for every function)
building a table of any other functions called, any global variables
accessed, etc. But, this is just trading one type of memory bulk for
another.
Like, say, if there are 4000 functions in a program, any metadata that
needs to be stored per function adds up quickly.
>> It could also be used to encode another type, which was needed for
>> things like multidimensional arrays and some other complex types. But,
>> this seemed like an ugly hack... (And was at odds with how I imagined
>> types working, but seemed like a technical necessity).
>
> I can see how multi-dim arrays would be troublesome with such a scheme.
>
Yeah.
It doesn't express them naturally, so I have to hack it.
It can, however, fairly easily express "FooStruct *x;".
But, if one wants, say:
FooStruct *x[8192];
Then it needs to put it into the type-overflow table.
> My own approach is to use a bunch of parallel arrays (a table of structs
> didn't appeal). They are populated with the standard types at the lower
> end, then new types can be added.
>
> A C type is represented by an index into those arrays. One of those
> arrays is this (not C):
>
> [0:maxtype]int tttarget # All names start with 'tt'
>
> For a pointer, it is contains the index of the target type. For arrays,
> it is the index of the element type. There is no restriction on nesting,
> other than 'maxtype' (set to some large number; one day I'll make the
> limit flexible).
>
Yeah, dunno...
I guess simpler could have been to do everything via the type-overflow
table and not have bothered with bit-twiddled type descriptors.
Originally though, the type overflow table was a response to noting that
there were a lot of situations that could not fit into a bit-packed format.
>
>> One downside as-is, is that if a given variable is assigned more than
>> 4096 times in a given function, it can no longer be given a unique ID.
>> Though uncommon, this is not entirely implausible (with sufficiently
>> large functions), and there isn't currently any good way to deal with
>> this (apart from raising a compiler error).
>
>
> One of my compiler benchmarks is this program:
>
> #include <stdio.h>
>
> int main(void) {
> int a, b=2, c=3, d=4;
>
> a=b+c*d;
>
> printf("%d\n", a);
> }
>
> Except that the 'a=b+c*d;' line is repeated 1M or 2M times, usually
> within an included file.
>
> Some compilers (including for other languages) find this challenging.
>
As-is, if the line were repeated more than 4096 times, it would break my
compiler absent adding an overflow case for the local variable descriptor.
Though, one option would be to drop the type field and expand the ID and
sequence numbers.
Since, generally, for local variables the type is also encoded in a
descriptor struct for the variable (though, the inline type is useful
for things like "soft casting", etc).
Also relevant for things like temporaries, where the descriptor only
contains an abstract type (temporaries primarily rely on sequence
numbers for identity, with only a small number of "canonical" temporary
variables representing every temporary in the function).
For temporaries, would need some sort of sequence-number overflow case
that does not lose the ability to encode the type.
But, yeah, compiler breaking because a given variable is assigned too
many times in a function is kinda lame.
>>
>>
>> But, as noted, the 3AC IR only exists in memory.
>>
>> In the IR, the operations are expressed as a sort of linear bytecode
>> operating on a virtual stack machine; with types expressed as ASCII
>> strings.
>>
>> Logically, the stack holds "ccxl_register" values, and the number of
>> 3AC ops is typically less than the number of stack-machine operations
>> (those which exist simply to shuffle registers around essentially
>> disappear in the translation process).
>>
>> Say, for example:
>> LOAD x
>> LOAD y
>> ADD
>> STORE z
>> Might turn into a single 3AC operation.
>
> I've used 3AC as an IL (several attempts), and also a stack VM. The 3AC
> always looked so simple, but it also was a lot of hard work to turn it
> into decent register-based code.
>
> Now I used a stack-based IL which is far easier to work with.
>
The problem with generating code directly from a stack IL is that the
generated code tends to be rather inefficient.
But, going directly from an AST to 3AC or SSA is a pain...
And storing and reloading SSA as a "good" IR is a pain (and something
that just sorta serializes the internal structures, like what LLVM
bitcode does, is not ideal).
Say, in effect, any compiler which uses LLVM bitcode, would also need to
do things the same way that LLVM does them. And, a structural flattening
of my compiler's internal 3AC form, would require any other compiler to
do things the same way.
Luckily at least, a stack IR/IL can avoid this.
But, annoyingly, my existing IL has some design issues that would limit
its "general use"; mostly in that it is a monolithic linear bytecode
format that also expresses all of the metadata using bytecode ops.
The likely fix would be to go over to a structure more like I used for
the BS2VM, of basically representing everything inside a TLV format,
with each function and variable being individually wrapped (with offset
indices mapping table numbers to their corresponding TLV lumps).
Though, the actual contents of the bytecode wouldn't change that much,
and I had gone back and forth on whether it would be better to use
structural representation for metadata, or continue the hack of using
bytecode ops to encode the metadata.
But, attempts to rework BGBCC to use such a structure have thus far
tended to fizzle out.
I had a few times also considered trying to adopt .NET CIL, except that
it doesn't express C very well, and it represents metadata very
differently than my existing compiler (and its way of expressing
metadata isn't very flexible, *).
*: Basically, it uses a bunch of tables organized in a way almost like
in a relational database, but with a bit-packed representation (with the
bit-width of various members also depending on the number of rows or
range of primary keys within the other tables, etc). The table layouts
are effectively fixed, so one would be SOL if they want to express
anything that doesn't fit into the existing tables.
> I wouldn't start off with turning stack code into 3AC! (SSA is supposed
> to be /the/ way to generate code in compilers; they can keep it.)
>
My 3AC format isn't pure 3AC, but rather an intermediate between 3AC and
SSA (hence the whole sequence number issue...).
But, I ended up going this direction (at first in my BGBScript VM), as
it allowed for significant performance improvements over operating in
terms of a stack machine.
Can note that I was able (at the time) to make BGBScript and BGBScript2,
when mostly using a static-typed language variant and JIT compiled,
reasonably performance competitive with native C. BGBScript2 (beyond the
syntax changes) was also in some ways somewhat simplified vs what its
predecessor had become (its scope model and type-inference was a
significant source of pain; and effectively turning it into C# made this
part simpler).
A naive purely dynamic interpreter is a lot simpler, but then one is
hard-pressed to get much better than around 50x to 100x slower versus
native C (and, if running any non-trivial code in the VM, something with
a 100x slowdown is undesirable; and one needs either static typing or
type inference to have any hope of decent performance).
> Those 4 stack instructions might turn into 3/4 machine instructions on
> x64 (perhaps fewere is register-resident). But if converting them to one
> 3AC instruction, you then have to expand them again.
>
FWIW:
No current plans to target BGBCC to x86-64, as MSVC and GCC serve this
use case well enough.
> Perhaps 3AC suits another architecture better (I think ARM uses
> 3-register ops; x64 is 2-register ops).
It makes sense on my own BJX2 ISA, which at this point is primarily
3-register ops (with 64 GPRs, etc).
I might have almost been tempted to consider switching more over to
RISC-V and GCC, except that (even with superscalar, etc), RISC-V
performance is a little weak.
Granted, "real world" it may not matter, because RISC-V is starting to
appear in ASICs, and a 1GHz CPU is going to beat a 50MHz CPU (in an
FPGA) fairly easily even if it takes more clock cycles to run similar code.
But, had noted that in some contrived benchmarks (software OpenGL and
neural-nets), my CPU core (at 50MHz) was able to be performance
competitive with an early 2000s laptop running at 1.4 GHz, but seemingly
mostly because x87 sucks in the NN case, ...
Well, and on some metrics the difference between them isn't as huge as
the difference in clock-speed would seem to imply. The laptop was
significantly faster at plain integer code though (for code that is not
memory bound).
The laptop seemed to be (relative to clock speed) bogged down in a few
areas:
The x87 FPU ops are slow;
Memory is also relatively slow.
Like, despite the 28x difference in clock speed, there was only around a
3.5x difference in memory bandwidth.
Technically though the laptop is slower than the newer RasPi models (or
running code in Termux on my cellphone...).
But, despite my efforts, getting Quake and similar running at decent
framerates on a 50MHz CPU remains elusive.
But, if I could bump it to 100MHz while keeping everything else the
same; Quake would generally be running at around 20fps.
Had ironically ended up mostly switching my efforts to GLQuake as,
ironically, my software OpenGL rasterizer had tended to be a little
faster than Quake's software renderer (at least, on my own ISA; on
RISC-V, the situation being very different).
Had also noted that vs my Ryzen, the my software GL rasterizer had
tended to be around 5x faster than x86-64 in a "clock cycles per pixel"
sense (though, the Ryzen still wins in terms of raw performance due to
having a 74x clock-speed advantage).
Much of this difference is because for my ISA, I had various "helper
instructions" for things like packing and unpacking RGB555 pixels into
packed-integer SIMD vectors, etc.
I suspect this sort of thing wrecks performance when building for the
other ISAs (turns into a bunch of shifting and masking).
Technically was using RGB555 and Z12.S4 buffers mostly because it needs
too much memory bandwidth to do RGBA32 and Z24.S8, ...
Though, my GL implementation currently still suffers from a relatively
slow transform/projection stage (an eventual TODO being likely to redo
this part).
As-is:
Pop a primitive off the stack;
Project vertices to screen space;
Check for culling;
If it can be culled, do so.
Check if primitive can be drawn as-is:
If yes, draw it.
Else, fragment primitive, and push fragments back onto stack.
Generally, the fragmentation is being done in world-space, so each
fragmented primitive requires any new vertices to be projected (it can
cache the previously projected vertices from the parent primitive).
Generally, the projection does the XYZ/W conversion upfront.
A likely "better" option:
Run polygon vertices through modelview and projection matrices;
Clip polygon against frustum planes (possibly in XYZW space);
Check and subdivide (similar to before, just in XYZW space);
Split into final triangles and quads and draw.
Theoretically, interpolating in XYZW space should work, with the XYZ/W
step being used for drawing the primitives (though, one sill needs to
divide by W to know whether the primitive needs to be subdivided).
Though, this is because the final rasterization stages (and generally
also my experimental hardware rasterizer) work in terms of affine
texturing; where larger on-screen primitives need to be subdivided to
avoid obvious texture warping.
Basically, if one has seen the 3D rendering on the original PlayStation,
they should probably know what sort of warping I am dealing with...
[toc] | [prev] | [next] | [standalone]
Page 1 of 16 [1] 2 3 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web