Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #385836 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2024-06-11 10:13 +0100 |
| Last post | 2024-06-11 18:21 +0000 |
| Articles | 20 on this page of 351 — 23 participants |
Back to article view | Back to comp.lang.c
Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 10:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 13:59 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 14:35 +0100
Mac users (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 10:04 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-11 15:16 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 15:35 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-12 00:34 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 00:50 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 18:02 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 17:15 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 07:40 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 09:01 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 10:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:20 +0200
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 13:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 12:27 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 14:35 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:13 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 15:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:46 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 00:29 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 23:22 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-13 13:53 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 14:46 +0100
Re: Baby X is bor nagain tTh <tth@none.invalid> - 2024-06-13 17:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 16:32 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 08:47 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 19:13 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 17:43 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-14 18:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-14 19:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-15 12:35 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:22 -0400
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-17 07:30 +0000
Are Javascript and Python similarly slow ? (Was: Baby X is bor nagain) Michael S <already5chosen@yahoo.com> - 2024-06-17 12:11 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-17 12:25 +0300
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 10:54 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:23 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 11:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:36 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 17:38 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:54 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 14:14 -0400
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 20:52 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 16:07 -0400
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 15:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:15 +0200
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 21:09 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 18:40 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 17:39 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:49 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 10:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:42 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 17:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:49 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 21:42 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 22:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 12:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 14:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 17:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-20 20:28 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 20:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 22:16 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 23:40 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 10:02 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 09:55 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 09:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 13:18 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 12:24 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 13:36 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:26 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 08:05 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 17:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 17:45 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 13:55 -0400
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 19:01 +0000
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:41 -0700
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:34 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:44 -0700
Re: Baby X is bor nagain vallor <vallor@cultnix.org> - 2024-06-20 22:21 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 22:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:19 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:37 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:39 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-21 00:56 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-21 22:07 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 14:57 -0700
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 20:59 -0400
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 18:42 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-21 21:10 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 12:19 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-23 10:30 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 11:04 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:33 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 03:28 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:35 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-25 05:38 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 16:33 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 07:40 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 14:25 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 09:47 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-23 19:55 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 09:34 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 01:53 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 12:59 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 23:46 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 17:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 13:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:44 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:27 -0700
sort - C, python, C++, glibc Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-19 13:17 +0300
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:53 +0200
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 18:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:39 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:26 -0400
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 11:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:43 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 16:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:21 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 20:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 21:29 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 22:06 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 08:44 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:21 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 11:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:47 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:25 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 19:21 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 22:09 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-24 00:52 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 01:25 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 00:56 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:28 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 12:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 13:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 14:01 +0100
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:16 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 16:09 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 15:00 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 17:09 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:19 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 19:15 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:25 +0000
Re: Baby X is bor nagain "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-25 20:29 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 22:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 21:34 +0000
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 22:03 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 10:19 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 12:18 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:08 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:28 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:17 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 12:52 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 20:39 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 16:28 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-26 00:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:23 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-26 15:18 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:45 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 12:04 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:21 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-26 08:31 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 13:15 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 12:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 18:10 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:51 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:02 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 18:50 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 18:10 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 20:33 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 11:36 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 15:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 15:08 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:12 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 16:59 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 16:27 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 19:51 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 18:11 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:42 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:35 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 13:15 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 12:16 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-27 15:24 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 14:13 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 14:31 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 17:28 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 21:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 22:47 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:23 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:19 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 10:26 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 15:14 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-29 08:38 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 17:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:42 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:49 +0300
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 15:43 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:43 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:23 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-30 00:36 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-03 17:12 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:49 -0700
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:46 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 20:55 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 12:18 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:54 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 19:10 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-01 00:20 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 19:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 16:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 10:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 12:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-30 11:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 12:22 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-01 13:09 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 15:14 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:20 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:00 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 16:44 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 00:58 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 01:23 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 00:47 +0000
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 01:18 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 01:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-03 09:08 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 10:36 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-07-03 09:41 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:33 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-04 09:14 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 22:58 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:24 +0200
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-02 13:16 -0500
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:46 +0000
Re: Baby X is bor nagain Phillip <nntp@fulltermprivacy.com> - 2025-01-02 16:47 -0500
Re: Baby X is bor nagain antispam@fricas.org (Waldek Hebisch) - 2025-01-02 22:22 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 13:48 +0100
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-03 12:04 -0500
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 18:12 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:18 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-03 11:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-03 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:20 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:52 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 11:05 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-29 09:15 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:11 +0200
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:51 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:17 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:57 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 13:23 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:44 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 17:50 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 00:16 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-27 23:58 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:21 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:53 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:08 -0700
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:30 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:11 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:41 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:36 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 15:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 20:37 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:42 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 16:01 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:45 +0300
tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-01 20:09 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-01 12:14 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:48 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 15:09 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 11:54 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 12:22 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 16:27 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 15:18 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 17:55 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 13:57 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:50 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:47 -0700
Re: tcc - first impression. Was: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 11:50 -0400
Re: tcc - first impression. Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-02 10:35 +0100
Re: tcc - first impression. Was: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-07-02 14:33 +0000
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 15:43 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:17 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:32 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:45 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 17:12 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 00:42 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-04 00:04 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:07 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-27 23:24 +0100
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-28 00:44 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 20:41 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:39 +0300
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 16:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 22:01 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 09:01 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 19:52 -0400
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 11:26 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 20:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:40 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:55 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 09:39 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:58 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 14:33 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 13:02 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:06 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:07 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:22 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 16:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 10:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 11:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:53 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 12:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 14:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 19:43 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:56 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-23 15:22 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 15:11 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 14:09 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:38 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:28 -0400
Topicality is not your strong suit (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 09:40 +0000
Re: Topicality is not your strong suit (Was: Baby X is bor nagain) Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 12:59 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 18:09 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 20:22 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 20:31 +0100
Re: Baby X is bor nagain kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-06-11 18:21 +0000
Page 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-06-29 09:15 +0000 |
| Message-ID | <20240629021345.405@kylheku.com> |
| In reply to | #386653 |
On 2024-06-29, David Brown <david.brown@hesbynett.no> wrote: > gcc toolchains are free, and the standard from manufacturers for a very > long time. The others are very expensive, and it's very questionable if > they actually provide much extra value for most development teams. > (They /do/ provide better tools for some kinds of development.) > Consequently, gcc is overwhelmingly the most popular. One thing: builds having to talk to some god forsaken licensing server to get permission to compile is beyond ridiculous. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-29 19:11 +0200 |
| Message-ID | <v5pf8v$118l$1@dont-email.me> |
| In reply to | #386654 |
On 29/06/2024 11:15, Kaz Kylheku wrote: > On 2024-06-29, David Brown <david.brown@hesbynett.no> wrote: >> gcc toolchains are free, and the standard from manufacturers for a very >> long time. The others are very expensive, and it's very questionable if >> they actually provide much extra value for most development teams. >> (They /do/ provide better tools for some kinds of development.) >> Consequently, gcc is overwhelmingly the most popular. > > One thing: builds having to talk to some god forsaken licensing server > to get permission to compile is beyond ridiculous. > I agree. I understand that vendors want to get paid for people using their tools (especially if that's their main business), and that it's hard to enforce license usage without some kind of license server or lock system. But it is really bad for the user. I've seen countless tricks to get around licensing restrictions - not to avoid paying money or cheating the supplier, but simply to get the flexibility and long-term usage that you have paid for. For me, the zero cost price of most gcc toolchains is not a big deal. I've paid for gcc toolchains and other toolchains, and am fine with that if they are good value for money. The zero restrictions on usage, on the other hand, is an enormous benefit. I think the gcc model is one that works out well - big sponsors of the development include cpu manufacturers like ARM. We use the gcc toolchain and make programs that run on ARM microcontrollers. And each microcontroller we buy then results in a bit of money back to ARM.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-06-29 18:51 +0100 |
| Message-ID | <v5phiq$168u$2@dont-email.me> |
| In reply to | #386654 |
On 29/06/2024 10:15, Kaz Kylheku wrote: > On 2024-06-29, David Brown <david.brown@hesbynett.no> wrote: >> gcc toolchains are free, and the standard from manufacturers for a very >> long time. The others are very expensive, and it's very questionable if >> they actually provide much extra value for most development teams. >> (They /do/ provide better tools for some kinds of development.) >> Consequently, gcc is overwhelmingly the most popular. > > One thing: builds having to talk to some god forsaken licensing server > to get permission to compile is beyond ridiculous. > I haven't seen that since, like, the 90s. Does that actually still happen?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-29 21:56 +0300 |
| Message-ID | <20240629215642.000075b7@yahoo.com> |
| In reply to | #386653 |
On Sat, 29 Jun 2024 11:05:41 +0200 David Brown <david.brown@hesbynett.no> wrote: It does not sound like you know what you are talking about. Just download latest Arm MCU variant of TI CCS or of STM32 Cube and see. They are free (like beer) and they are based on clang.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-30 11:17 +0200 |
| Message-ID | <v5r7ru$f07f$1@dont-email.me> |
| In reply to | #386665 |
On 29/06/2024 20:56, Michael S wrote: > On Sat, 29 Jun 2024 11:05:41 +0200 > David Brown <david.brown@hesbynett.no> wrote: > > > It does not sound like you know what you are talking about. > Just download latest Arm MCU variant of TI CCS or of STM32 Cube and see. > They are free (like beer) and they are based on clang. > It is a very long time since I have used TI's ARM devices, and therefore its tools. For STM, it was maybe a year or two ago. There are many manufacturers of microcontrollers, and while I have used a fair number over the years, I don't use all the different ones all the time. I also don't change development tools in existing projects. If TI and STM have changed over to providing clang-based tools, that is interesting to know. I will probably be working on a new STM32 project later this year. So that's nice information to know. It doesn't surprise me that some have moved to clang-based tools - I think it was inevitable. And I think it is good to see some variety and competition. But if the clang toolchains are not freely available in a device-independent fashion in the manner of the ARM-sponsored gcc toolchains, then it will be a big step backwards. The last thing embedded developers want is more custom variant toolchains and vendor lock-in. We used to have that - gcc let us escape from it. A disadvantage of clang's license is that it lets vendors try that shit again. So this is all very interesting, but it does not change the fact that gcc totally dominates for embedded development at the moment. It does, however, mean the proportions may change significantly in the coming years.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-28 11:05 +0100 |
| Message-ID | <v5m1ti$39qob$1@dont-email.me> |
| In reply to | #386609 |
On 28/06/2024 05:56, David Brown wrote:
> On 27/06/2024 23:47, bart wrote:
>> On 27/06/2024 20:51, David Brown wrote:
>>> On 27/06/2024 18:28, bart wrote:
>>>> On 27/06/2024 13:31, David Brown wrote:
>>>>> On 27/06/2024 13:16, bart wrote:
>>>>
>>>
>
>>> No one doubts that gcc is slower than tcc. That is primarily because
>>> it does vastly more, and is a vastly more useful tool. And for most
>>> C compiles, gcc (even gcc -O2) is more than fast enough.
>>
>> And for most of /my/ compiles, the code produced by gcc-O0 is fast
>> enough. It also about the same speed as code produced by one of my
>> compilers.
>>
>
> With most of your compiles, is "gcc -O2" too slow to compile? If not,
> then why would you or anyone else actively /choose/ to have a poorer
> quality output and poorer quality warnings? I appreciate that fast
> enough output is fast enough (just as I say the same for compilation
> speed) - but choosing a slower output when a faster one is just as easy
> makes little sense. The only reason I can think of why "gcc -O2 -Wall"
> is not the starting point for compiler flags is because you write poor C
> code and don't want your compiler to tell you so!
I might very occasionally use gcc -O2/-O3 when I want a fast product,
(this is mostly with generated C) most often when I'm benchmarking and
what to report a higher lines/second figure or some such measure. Since
that would be a fairer comparison with other products which almost
certainly will be using an optimised build.
But usually I never bother. The 40% boost that gcc-O3 gives me, makes
most runtimes of my language tools 10-20ms faster (so 0.07 seconds
instead of 0.09 seconds; I can live with that).
The cost of the speedup is not just having to hang about for gcc-O3
(it's like doing 80mph on the M6 and having to stop for a red light).
It's keeping my non-C source code conservative - avoiding features that
are troublesome to transpile to C.
(One feature is a special looping switch that I implemented as a fast
computed-goto. It is transpiled into a regular C switch, but it means
gcc-O3 can't generate code faster than mine. Only if I were to use C
extensions.)
My other language product that could be speeded up is a bytecode
interpreter, which has two dispatch modes. One HLL-only dispatch mode
can have that 40-50% speed-up via C and gcc-O3.
But I normally use the ASM-accelerated mode, which is about 150-200%
faster even than the interpreter using transpiled C + gcc-O3.
Note that all these examples benefit from whole-program optimisation of
C. If written directly in C, while programs like interpreters can
benefit from all sorts of tricks like inlining everything, they would
lose that whole-program analysis.
>> So I tend to use it when I want the extra speed, or other compilers
>> don't work, or when a particular app only builds with that compiler.
>>
>> Otherwise the extra overheads are not worth the bother.
>>
>>
>>
>>> And it is free, and easily available on common systems. Therefore
>>> there is no benefit to using tcc except in very niche cases.
>>
>> And my argument would be the opposite. The use of gcc would be the
>> exception. (Long before I used gcc or tcc, I used lccwin32.)
>
> On Linux, almost everyone uses gcc, except for a proportion who actively
> choose to use clang or icc. The same applies to other many other *nix
> systems, though some people will use their system compiler on commercial
> Unixes. For Macs, it is clang disguised as gcc that dominates. On
> Windows, few people use C for native code (C++, C# and other languages
> dominate). I expect the majority use MSVC for C, and there will be
> people using a variety of other tools including lcc-win and Borland, as
> well as gcc in various packagings. (And embedded developers use
> whatever cross-compile tools are appropriate for their target,
> regardless of the host - the great majority use gcc now.)
>
> I don't believe that in any graph of compiler usage on any platform, tcc
> would show up as anything more than a tiny sliver under "others".
>
>>
>> Here's the result of an experiment I did. gcc 14 is about 800MB and
>> over 10,000 files. I wanted to see the minimal set of files that would
>> compile one of my generated C files.
>
> Why? 800 MB is a few pence worth of disk space. For almost all uses,
> it simply doesn't matter.
It's sloppy.
If I transpile code to C via my one-file 0.3MB compiler, I'd have to
tell people they need also this 800MB/10000-file dependency, of which
they only need 45MB/15 files (or more with linking), but, sorry, I have
no idea which bits are actually essential!
>>
>> I can't explain to somebody who doesn't get it why a small, simple
>> tool is desirable.
>>
>
> If you were trying to say that tcc is simpler to /use/ than gcc, that
> would be a different matter entirely. That would be a relevant factor.
> The size of the gcc installation, is all hidden behind the scenes. Few
> people know how big it is on their system, fewer still care.
>
> (And I am not sure I agree with such a claim - certainly you /can/ have
> very advanced and complicated use of gcc. But in comparison to learning
> C itself, running "gcc -Wall -O2 -o hello hello.c" is hardly rocket
> science. But I would certainly be much more open to a "simpler to use"
> argument.)
Actually, on Windows, tcc is harder to use than gcc for my generated C.
Most of that is due to needing the -fdollars-in-identifiers option
because my C uses '$'.
It probably takes longer to type that, if you compile half a dozen
times, than it would take to fix tcc to allow '$' /unless/ such an
option was used.
(I just tried it; what tool longer was finding the write source file.
The fix was to change:
set_idnum('$', s1->dollars_in_identifiers ? IS_ID : 0);
to:
set_idnum('$', s1->dollars_in_identifiers ? 0 : IS_ID);
But that only fixes one copy of it. It doesn't fix the versions that
other people use.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-28 06:57 +0200 |
| Message-ID | <v5lfrn$35vli$2@dont-email.me> |
| In reply to | #386597 |
On 27/06/2024 23:47, bart wrote: (I'm off on holiday today - if I don't reply more, it's not because I am ghosting you!)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-27 13:23 -0700 |
| Message-ID | <867ceadtih.fsf@linuxsc.com> |
| In reply to | #386590 |
bart <bc@freeuk.com> writes: > On 26/06/2024 13:15, Ben Bacarisse wrote: > >> bart <bc@freeuk.com> writes: >> >>> On 25/06/2024 16:12, David Brown wrote: >> >> ... >> >>>> I /do/ use Python. I use it when it is an appropriate language to use, >>>> which is very different circumstances from when I use C (or >>>> C++). Different tools for different tasks. >>> >>> And yet neither of you are interested in answering my question, which was >>> why its simplistic bytecode compiler is acceptable in this scenario, but >>> would be considered useless if applied to C code. >> >> You throw out a lot of these sorts of question, by which I mean >> questions that you either /do/ know the answers to or which you /should/ >> know the answers to. >> >> If a software engineering student asked me this sort of "challenge" >> question it would immediately become homework: come up with at least two >> scenarios in which a simplistic C bytecode compiler would be an >> unacceptable tool to use, and two in which Python with a trivial >> bytecode compiler would be an acceptable tool to use. In each case >> explain why. Anyone who could not would get marked down on the course. > > I'm not sure what you're implying here. > > Some here are consistently saying that any compiler whose internal > processes are not at the scale or depth that you find in > professional', 'industrial scale' products like gcc, clang, icc, is > not worth bothering with and is basically a useless toy. After reading the above I decided to try tcc. I used tcc for the first time earlier today. First I tried using tcc for my most recent project. That didn't go anywhere, because that project relies on C11, and tcc doesn't support C11. Next I tried using tcc on a small part of my larger current project. That test involves compiling one .c file to produce a .o file, and linking with several other .o files to produce an executable, and running the executable. The .c file being compiled uses C99 and doesn't need C11. The first thing that came up is tcc doesn't support all of C99. There are some C99 features that tcc just doesn't understand. In this case the infringements were minor so I edited the source to work around the missing features. The second thing to come up is some language incompatibilities. There are language features that tcc understands, sort of, but implements them in a way that didn't work with my source code. To be fair, a case could be made that what tcc does conforms to the C standard. However, the code I had before works fine with gcc and clang, and doesn't with tcc. Here again the changes needed were minor so I edited the source to work around the problem. The third thing to come up was the link step. Compiling the one .c file with tcc -- and there are three other .o files produced using gcc -- implicated the link step, which needed to be done with tcc to avoid some undefined symbols. That kind of surprised me; I'm used to being able to mix gcc object files and clang object files with no difficulty, so having the link step fail caught me off guard. After taking care of all that the build did manage to produce an executable, which appears to have run successfully. After doing a trial run with the produced executable, I looked at the tcc man page. As best I can tell, tcc simply silently ignores the -fPIC option. (I didn't test that, I only read what the tcc man page says.) That project absolutely relies on -fPIC, so if tcc doesn't support it that's a deal breaker. Not offering any conclusion. Just reporting my experience.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-27 15:44 -0700 |
| Message-ID | <87tthexayl.fsf@nosuchdomain.example.com> |
| In reply to | #386596 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> After reading the above I decided to try tcc. I used tcc for
> the first time earlier today.
[...]
You probably used tcc 0.9.27, the most recent release, from 2017.
Development has continued, with a git repo at
git://repo.or.cz/tinycc.git
The master branch hasn't gone past 9.9.27, but the "mob" branch has been
updated as recently as 2024-03-22. It builds in just a few seconds on
my system. The same version is available on godbot.org as "TCC (trunk)".
I haven't paid much attention to what's actually been implemented
post-0.9.27. See the included Changelog if you're curious. The one
thing I've noticed is that the "mob" version implements the C99 rule
that falling off the end of main does an implicit "return 0;",
admittedly a minor point.
I'm not suggesting you should build tcc from source and repeat the
experiment (I suspect it wouldn't make much difference), but it's there
if you're so inclined.
--
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-06-27 17:50 -0700 |
| Message-ID | <8634oxevqq.fsf@linuxsc.com> |
| In reply to | #386599 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> After reading the above I decided to try tcc. I used tcc for >> the first time earlier today. > > [...] > > You probably used tcc 0.9.27, the most recent release, from 2017. > > Development has continued, with a git repo at > > git://repo.or.cz/tinycc.git > > The master branch hasn't gone past 9.9.27, but the "mob" branch has been > updated as recently as 2024-03-22. It builds in just a few seconds on > my system. The same version is available on godbot.org as "TCC (trunk)". > > I haven't paid much attention to what's actually been implemented > post-0.9.27. See the included Changelog if you're curious. The one > thing I've noticed is that the "mob" version implements the C99 rule > that falling off the end of main does an implicit "return 0;", > admittedly a minor point. > > I'm not suggesting you should build tcc from source and repeat the > experiment (I suspect it wouldn't make much difference), but it's there > if you're so inclined. Thank you for the info. If I were going to use tcc I would want to use only the version that is standard for my environment, rather than try to deal with a custom build, but maybe things will be different in the future.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-28 00:16 +0100 |
| Message-ID | <v5krsp$2v9va$1@dont-email.me> |
| In reply to | #386596 |
On 27/06/2024 21:23, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> On 26/06/2024 13:15, Ben Bacarisse wrote: >> >>> bart <bc@freeuk.com> writes: >>> >>>> On 25/06/2024 16:12, David Brown wrote: >>> >>> ... >>> >>>>> I /do/ use Python. I use it when it is an appropriate language to use, >>>>> which is very different circumstances from when I use C (or >>>>> C++). Different tools for different tasks. >>>> >>>> And yet neither of you are interested in answering my question, which was >>>> why its simplistic bytecode compiler is acceptable in this scenario, but >>>> would be considered useless if applied to C code. >>> >>> You throw out a lot of these sorts of question, by which I mean >>> questions that you either /do/ know the answers to or which you /should/ >>> know the answers to. >>> >>> If a software engineering student asked me this sort of "challenge" >>> question it would immediately become homework: come up with at least two >>> scenarios in which a simplistic C bytecode compiler would be an >>> unacceptable tool to use, and two in which Python with a trivial >>> bytecode compiler would be an acceptable tool to use. In each case >>> explain why. Anyone who could not would get marked down on the course. >> >> I'm not sure what you're implying here. >> >> Some here are consistently saying that any compiler whose internal >> processes are not at the scale or depth that you find in >> professional', 'industrial scale' products like gcc, clang, icc, is >> not worth bothering with and is basically a useless toy. > > After reading the above I decided to try tcc. I used tcc for > the first time earlier today. > > First I tried using tcc for my most recent project. That > didn't go anywhere, because that project relies on C11, > and tcc doesn't support C11. > > Next I tried using tcc on a small part of my larger current > project. That test involves compiling one .c file to produce a > .o file, and linking with several other .o files to produce an > executable, and running the executable. The .c file being > compiled uses C99 and doesn't need C11. > > The first thing that came up is tcc doesn't support all of > C99. There are some C99 features that tcc just doesn't > understand. Which ones? I thought its C99 support was far more complete than mine. > In this case the infringements were minor so I > edited the source to work around the missing features. > > The second thing to come up is some language incompatibilities. > There are language features that tcc understands, sort of, > but implements them in a way that didn't work with my source > code. To be fair, a case could be made that what tcc does > conforms to the C standard. However, the code I had before > works fine with gcc People develop sofware using compilers like gcc, and will naturally do whatever it takes to make them work with that tool. They might inadvertently use extensions. Probably not many test across multiple compilers, though some projects specifically check for compilers like GCC or MSVC and will use dedicated conditional blocks for each. I don't think I've seen such code for TCC. and clang, and doesn't with tcc. Here > again the changes needed were minor so I edited the source > to work around the problem. > > The third thing to come up was the link step. Compiling the > one .c file with tcc -- and there are three other .o files > produced using gcc -- implicated the link step, which needed > to be done with tcc to avoid some undefined symbols. That > kind of surprised me; I'm used to being able to mix gcc > object files and clang object files with no difficulty, > so having the link step fail caught me off guard. > > After taking care of all that the build did manage to produce an > executable, which appears to have run successfully. > > After doing a trial run with the produced executable, I looked at > the tcc man page. As best I can tell, tcc simply silently > ignores the -fPIC option. I think that it tries to be a drop-in replacement for gcc, so supports some of its options, even if they don't do anything. Like -O3. Position-independent code seems to be a recent thing with gcc tools. My tools didn't support it either, until a year ago when I found out about ASLR. For most, PIC isn't a necessity. But tcc supports shared libraries, and some kinds of relocation, if not full PIC, are necessary. > the tcc man page says.) That project absolutely relies on -fPIC, > so if tcc doesn't support it that's a deal breaker. tcc isn't perfect and there are missing bits especially with headers and libraries. Fixing that would make it a bit bigger, but not 100 times bigger. If more people took it seriously then it might get done. gcc has been under development since 1987.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-27 23:58 +0000 |
| Message-ID | <K0nfO.155094$7NFd.18547@fx16.iad> |
| In reply to | #386601 |
bart <bc@freeuk.com> writes: >On 27/06/2024 21:23, Tim Rentsch wrote: >> After taking care of all that the build did manage to produce an >> executable, which appears to have run successfully. >> >> After doing a trial run with the produced executable, I looked at >> the tcc man page. As best I can tell, tcc simply silently >> ignores the -fPIC option. > >I think that it tries to be a drop-in replacement for gcc, so supports >some of its options, even if they don't do anything. Like -O3. > >Position-independent code seems to be a recent thing with gcc tools. My >tools didn't support it either, until a year ago when I found out about >ASLR. gcc has supported generating position independent code for at over a quarter of a century. > >For most, PIC isn't a necessity. That's your opinion. I don't think it matches reality. For most applications it doesn't matter and PIC code works just as well as PDC.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-27 18:21 -0700 |
| Message-ID | <86tthddfq6.fsf@linuxsc.com> |
| In reply to | #386603 |
scott@slp53.sl.home (Scott Lurndal) writes: > bart <bc@freeuk.com> writes: > >> On 27/06/2024 21:23, Tim Rentsch wrote: >> >>> After taking care of all that the build did manage to produce an >>> executable, which appears to have run successfully. >>> >>> After doing a trial run with the produced executable, I looked at >>> the tcc man page. As best I can tell, tcc simply silently >>> ignores the -fPIC option. >> >> I think that it tries to be a drop-in replacement for gcc, so supports >> some of its options, even if they don't do anything. Like -O3. >> >> Position-independent code seems to be a recent thing with gcc tools. My >> tools didn't support it either, until a year ago when I found out about >> ASLR. > > gcc has supported generating position independent code for at > over a quarter of a century. > >> For most, PIC isn't a necessity. > > That's your opinion. Not really an opinion, but either a conjecture or a belief about a question of fact. It may not be easy to determine whether the conjecture is true or not, but it's still a question of fact and not just an opinion. > I don't think it matches reality. That it is reasonable to ask whether the statement matches reality is a giveaway that the proposition is a question of fact and not merely a matter of opinion.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-28 11:15 +0100 |
| Message-ID | <v5m2g6$39qob$2@dont-email.me> |
| In reply to | #386603 |
On 28/06/2024 00:58, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 27/06/2024 21:23, Tim Rentsch wrote: > >>> After taking care of all that the build did manage to produce an >>> executable, which appears to have run successfully. >>> >>> After doing a trial run with the produced executable, I looked at >>> the tcc man page. As best I can tell, tcc simply silently >>> ignores the -fPIC option. >> >> I think that it tries to be a drop-in replacement for gcc, so supports >> some of its options, even if they don't do anything. Like -O3. >> >> Position-independent code seems to be a recent thing with gcc tools. My >> tools didn't support it either, until a year ago when I found out about >> ASLR. > > gcc has supported generating position independent code for at > over a quarter of a century. I'm pretty sure that just 4 years ago, I was able to generate non-PIC object files that could be linked with gcc-ld on Windows. When I tried it last year, it didn't work. So something changed, whether in compiler, or OS loader, where a dynamic image base address, which requires PIC, became the default. >> >> For most, PIC isn't a necessity. > > That's your opinion. I don't think it matches reality. The fact that it hasn't been needed, or been the default, for decades suggests that it isn't a necessity. A 'necessity' isn't someone arbitrarily decreeing: 'all code must be PIC'. If you took any Windows EXE and changed some flags in the headers, so loading at the given base address, it would probably still work. > For most applications it doesn't matter and PIC code > works just as well as PDC. Hang on, isn't that what /I/ said, which you just disagreed with?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-28 13:53 +0000 |
| Message-ID | <pfzfO.17727$zMs3.1648@fx48.iad> |
| In reply to | #386616 |
bart <bc@freeuk.com> writes: >On 28/06/2024 00:58, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> Position-independent code seems to be a recent thing with gcc tools. My >>> tools didn't support it either, until a year ago when I found out about >>> ASLR. >> >> gcc has supported generating position independent code for at >> over a quarter of a century. > >I'm pretty sure that just 4 years ago, I was able to generate non-PIC >object files that could be linked with gcc-ld on Windows. So what? That doesn't mean gcc didn't support generation of PIC code three decades ago.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-27 18:08 -0700 |
| Message-ID | <86y16pdgcs.fsf@linuxsc.com> |
| In reply to | #386601 |
bart <bc@freeuk.com> writes: > On 27/06/2024 21:23, Tim Rentsch wrote: > >> bart <bc@freeuk.com> writes: >> >>> On 26/06/2024 13:15, Ben Bacarisse wrote: >>> >>>> bart <bc@freeuk.com> writes: >>>> >>>>> On 25/06/2024 16:12, David Brown wrote: >>>> >>>> ... >>>> >>>>>> I /do/ use Python. I use it when it is an appropriate language to use, >>>>>> which is very different circumstances from when I use C (or >>>>>> C++). Different tools for different tasks. >>>>> >>>>> And yet neither of you are interested in answering my question, which was >>>>> why its simplistic bytecode compiler is acceptable in this scenario, but >>>>> would be considered useless if applied to C code. >>>> >>>> You throw out a lot of these sorts of question, by which I mean >>>> questions that you either /do/ know the answers to or which you /should/ >>>> know the answers to. >>>> >>>> If a software engineering student asked me this sort of "challenge" >>>> question it would immediately become homework: come up with at least two >>>> scenarios in which a simplistic C bytecode compiler would be an >>>> unacceptable tool to use, and two in which Python with a trivial >>>> bytecode compiler would be an acceptable tool to use. In each case >>>> explain why. Anyone who could not would get marked down on the course. >>> >>> I'm not sure what you're implying here. >>> >>> Some here are consistently saying that any compiler whose internal >>> processes are not at the scale or depth that you find in >>> professional', 'industrial scale' products like gcc, clang, icc, is >>> not worth bothering with and is basically a useless toy. >> >> After reading the above I decided to try tcc. I used tcc for >> the first time earlier today. >> >> First I tried using tcc for my most recent project. That >> didn't go anywhere, because that project relies on C11, >> and tcc doesn't support C11. >> >> Next I tried using tcc on a small part of my larger current >> project. That test involves compiling one .c file to produce a >> .o file, and linking with several other .o files to produce an >> executable, and running the executable. The .c file being >> compiled uses C99 and doesn't need C11. >> >> The first thing that came up is tcc doesn't support all of >> C99. There are some C99 features that tcc just doesn't >> understand. > > Which ones? I thought its C99 support was far more complete than > mine. I didn't post to have a conversation about tcc. I just thought people might be interested to hear about the trial. >> In this case the infringements were minor so I >> edited the source to work around the missing features. >> >> The second thing to come up is some language incompatibilities. >> There are language features that tcc understands, sort of, >> but implements them in a way that didn't work with my source >> code. To be fair, a case could be made that what tcc does >> conforms to the C standard. However, the code I had before >> works fine with gcc > > People develop sofware using compilers like gcc, and will naturally do > whatever it takes to make them work with that tool. They might > inadvertently use extensions. I routinely use -pedantic-errors for my compiles, and am totally intolerant of any warning or error messages. I very much doubt my builds use any extensions. >> After doing a trial run with the produced executable, I looked at >> the tcc man page. As best I can tell, tcc simply silently >> ignores the -fPIC option. > > I think that it tries to be a drop-in replacement for gcc, so supports > some of its options, even if they don't do anything. Like -O3. I would say tcc accepts the -fPIC option but does not support it. > Position-independent code seems to be a recent thing with gcc > tools. My tools didn't support it either, until a year ago when I > found out about ASLR. > > For most, PIC isn't a necessity. But tcc supports shared libraries, > and some kinds of relocation, if not full PIC, are necessary. Support for -fPIC is a must-have for that project. I'm not going to spend time investigating possible partial solutions when I already have other options available that are known to work.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-06-28 03:30 +0000 |
| Message-ID | <20240627202641.177@kylheku.com> |
| In reply to | #386601 |
On 2024-06-27, bart <bc@freeuk.com> wrote: > For most, PIC isn't a necessity. Only because they use a virtual memory operating system which allows every executable to be mapped to the same fixed address in its own address space. If you designed your personal OS, which would be the case? [ ] Programs must be PIC [ ] Programs needn't be PIC -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-28 11:11 +0300 |
| Message-ID | <20240628111151.00002e50@yahoo.com> |
| In reply to | #386608 |
On Fri, 28 Jun 2024 03:30:07 -0000 (UTC) Kaz Kylheku <643-408-1753@kylheku.com> wrote: > On 2024-06-27, bart <bc@freeuk.com> wrote: > > For most, PIC isn't a necessity. > > Only because they use a virtual memory operating system which allows > every executable to be mapped to the same fixed address in its own > address space. It does not sound right. For "simple" program that does not mess with copying pats of itself and such, PIC just allows simpler exe format and more primitive loader. If you already have advanced exe format and smart loader then all PIC buys is faster load at cost of slower execution. Hopefully, just a little slower, but that depends on architecture. PID is more "interesting". Even on x86-64, where address displacement field is ether 8 or 32 bits, completely free relocation of data segments would need co-operation from code generator. More so on architectures with significantly narrower displacement range. > > If you designed your personal OS, which would be the case? > > [ ] Programs must be PIC > > [ ] Programs needn't be PIC > >
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-06-28 11:41 +0100 |
| Message-ID | <v5m41l$39qob$4@dont-email.me> |
| In reply to | #386608 |
On 28/06/2024 04:30, Kaz Kylheku wrote: > On 2024-06-27, bart <bc@freeuk.com> wrote: >> For most, PIC isn't a necessity. > > Only because they use a virtual memory operating system which allows > every executable to be mapped to the same fixed address in its own > address space. PIC never seemed to be a requirement during the 1980s and half the 90s. But then OSes only ran one program a time. And when virtual addressing came along, and multiple programs could co-exist at the same address, PIC wasn't really needed either. > > If you designed your personal OS, which would be the case? > > [ ] Programs must be PIC > > [ ] Programs needn't be PIC With or without virtual addressing? On x64, there are several aspects to this: * Code that runs within the low 2GB (4GB is troublesome) * Code that runs above 2GB, so that 32-bit fields (often signed so that only 31 bits are usable) that refer to absolute addresses of code or data will need 33 bits or more * Dynamically linked /shared/ libraries, which need to have base-relocation tables (since you can't have multiple libraries all at the same address within the host process's virtual space), but which are not necessarily relocated above 2GB * True PIC that requires special compiler support (to avoid generating address modes that involve registers plus absolute 32-bit address offsets). RIP-relative address modes, when there are no registers, can be done with instruction encoding outside of the compiler It's all rather messy. I can generate true PIC if necessary (for OBJ files that might be linked with ld, or DLLs that /might/ be relocated above 2GB). But usually I generate code to load within the first 2GB.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-06-28 13:48 +0000 |
| Message-ID | <9bzfO.17725$zMs3.2568@fx48.iad> |
| In reply to | #386621 |
bart <bc@freeuk.com> writes: >On 28/06/2024 04:30, Kaz Kylheku wrote: >> On 2024-06-27, bart <bc@freeuk.com> wrote: >>> For most, PIC isn't a necessity. >> >> Only because they use a virtual memory operating system which allows >> every executable to be mapped to the same fixed address in its own >> address space. > >PIC never seemed to be a requirement during the 1980s and half the 90s. >But then OSes only ran one program a time. Interactive operating systems in 1967 (e.g. TSS8) were running multiple programs at a time. > >And when virtual addressing came along, and multiple programs could >co-exist at the same address, PIC wasn't really needed either. Virtual addressing has been part of computer systems since the 1960s. PIC is obviously necessary for any kind of shared code (shared object or DLL) that gets loaded at different base addressses in different processes. > >> >> If you designed your personal OS, which would be the case? >> >> [ ] Programs must be PIC >> >> [ ] Programs needn't be PIC > >With or without virtual addressing? That's completely irrelevent.
[toc] | [prev] | [next] | [standalone]
Page 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web