Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80902 > unrolled thread
| Started by | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| First post | 2021-08-29 20:57 +0200 |
| Last post | 2021-09-01 16:32 -0400 |
| Articles | 20 on this page of 301 — 30 participants |
Back to article view | Back to comp.lang.c++
Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-29 20:57 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-30 21:59 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-30 21:53 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-08-30 21:59 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-08-31 09:01 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-08-31 03:00 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-31 23:46 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 08:19 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:32 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 19:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 19:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 13:17 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 20:32 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:00 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 15:06 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 20:14 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 20:37 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-31 10:08 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 14:54 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 15:00 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Lynn McGuire <lynnmcguire5@gmail.com> - 2021-09-01 12:49 -0500
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Siri Cruise <chine.bleu@yahoo.com> - 2021-08-30 21:23 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-30 23:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 12:27 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Richard Damon <Richard@Damon-Family.org> - 2021-08-31 07:37 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 14:14 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-31 07:06 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 17:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 15:36 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 17:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-31 09:12 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 18:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 16:40 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 19:04 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-31 21:37 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 07:25 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 09:26 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:14 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 11:07 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-01 10:31 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 20:27 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:22 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? red floyd <no.spam.here@its.invalid> - 2021-09-01 07:52 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 15:21 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? red floyd <no.spam.here@its.invalid> - 2021-09-01 09:41 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-01 18:11 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 18:04 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 18:27 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:02 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 21:36 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-02 06:58 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-02 11:34 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-02 14:51 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-02 23:31 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 11:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 15:35 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 16:46 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-03 22:01 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 20:45 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-04 01:06 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-04 02:12 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-04 09:12 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Manfred <noname@add.invalid> - 2021-09-04 18:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-06 08:43 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-06 08:59 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-06 10:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-06 11:27 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-06 12:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-04 15:28 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-04 17:44 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ian Collins <ian-news@hotmail.com> - 2021-09-05 11:24 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ian Collins <ian-news@hotmail.com> - 2021-09-04 10:14 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-04 09:36 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-04 17:00 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-06 11:03 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-06 09:11 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-06 13:08 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-06 15:26 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-07 15:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-07 15:07 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-07 19:41 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-08 09:38 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-08 10:29 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 10:58 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 08:55 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-09 12:15 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 09:19 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-09 14:41 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 22:19 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 16:09 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-09 12:41 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-08 10:24 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-08 20:22 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 08:54 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-09 14:47 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-09 16:13 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-09 12:42 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 09:37 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 13:27 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-10 05:41 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 15:31 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-10 16:45 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-10 07:21 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-11 11:20 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-10 14:50 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 14:56 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 17:38 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 15:47 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-11 18:40 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 09:23 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-12 12:57 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 16:22 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 12:49 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 16:13 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 18:45 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 10:55 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 14:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 15:32 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-13 12:07 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-13 22:18 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 09:48 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 10:52 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-12 23:12 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-13 22:00 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-14 09:24 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-13 21:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-14 10:15 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-14 09:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-14 15:01 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-14 17:07 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-14 21:42 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 16:13 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 17:45 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 12:23 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 17:09 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-10 14:17 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-11 09:06 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-09 12:41 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-09 22:17 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-10 09:39 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 13:29 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 08:56 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 09:18 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:21 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 09:29 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 12:55 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-12 16:14 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-12 23:13 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-13 05:23 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > HorseyWorsey@the_stables.com - 2021-09-13 10:56 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-13 14:55 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-12 01:09 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 01:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 11:46 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 04:42 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 13:54 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 06:01 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-12 15:22 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 18:53 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-12 11:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 08:38 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-12 17:38 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-13 03:52 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-12 19:10 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 11:32 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-09 18:37 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-07 17:56 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > MisterMule@stubborn.uk - 2021-09-08 10:28 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-08 13:31 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 11:06 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-09 01:27 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 13:05 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-09 10:29 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-09 22:28 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-09 12:40 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-10 09:51 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 00:07 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-10 11:26 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 10:02 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-10 09:10 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 11:32 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:00 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-12 11:29 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-10 13:47 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-11 11:02 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-11 00:33 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-11 11:42 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Manfred <noname@add.invalid> - 2021-09-15 19:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-11 19:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-11 20:56 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-12 12:11 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 11:53 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-12 11:17 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-13 12:51 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-13 11:03 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-14 12:05 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-14 10:28 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-15 08:17 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:10 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Ian Collins <ian-news@hotmail.com> - 2021-09-12 21:51 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-09-12 15:55 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-12 21:18 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 08:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > scott@slp53.sl.home (Scott Lurndal) - 2021-09-13 15:09 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > Juha Nieminen <nospam@thanks.invalid> - 2021-09-13 05:28 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-13 09:23 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > David Brown <david.brown@hesbynett.no> - 2021-09-12 12:21 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > Michael S <already5chosen@yahoo.com> - 2021-09-10 05:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > Bart <bc@freeuk.com> - 2021-09-10 12:20 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-06 11:51 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 05:13 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 11:30 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 11:19 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-03 13:33 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 15:44 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 17:40 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-03 17:58 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-03 22:23 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-04 12:20 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-06 05:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-03 08:49 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-03 17:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-05 04:29 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Michael S <already5chosen@yahoo.com> - 2021-09-05 05:11 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-06 05:45 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-06 03:38 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-06 12:00 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-06 16:38 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-06 15:52 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-07 04:39 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-07 07:23 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-07 07:31 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Ian Collins <ian-news@hotmail.com> - 2021-09-07 21:47 +1200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-08 10:18 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-08 11:32 -0400
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-08 05:02 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-08 13:44 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-08 07:41 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-08 16:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-08 09:04 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-08 20:16 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-08 17:27 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-08 20:23 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-08 22:38 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-09 08:11 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Öö Tiib <ootiib@hot.ee> - 2021-09-09 09:25 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-09 18:43 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:37 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-09-06 11:54 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:01 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 23:41 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-01 23:32 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-02 12:31 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bart <bc@freeuk.com> - 2021-09-02 11:11 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-02 16:04 +0300
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? RantingRover <noemail@4u.com> - 2021-09-02 13:14 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-01 21:43 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 04:40 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-08-31 15:02 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "see.my....@gmail.com" <see.my.homepage@gmail.com> - 2021-08-31 10:26 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 19:46 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 04:42 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 07:26 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 07:41 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 08:03 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 08:34 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 08:43 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Christian Gollwitzer <auriocus@gmx.de> - 2021-09-01 08:55 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Vir Campestris <vir.campestris@invalid.invalid> - 2021-09-01 21:34 +0100
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:10 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:37 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:51 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 11:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:15 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-01 06:49 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 15:50 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-09-01 07:16 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 16:30 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:28 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 09:57 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 10:13 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 10:44 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 11:05 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 11:17 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:17 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 12:48 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:54 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-01 15:20 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? David Brown <david.brown@hesbynett.no> - 2021-09-01 11:11 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 12:19 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 18:14 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 20:34 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bo Persson <bo@bo-persson.se> - 2021-09-01 21:55 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-01 16:30 -0700
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-02 05:30 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? scott@slp53.sl.home (Scott Lurndal) - 2021-09-01 19:03 +0000
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 21:12 +0200
Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-01 16:32 -0400
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-13 08:38 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shmrko$ucc$1@dont-email.me> |
| In reply to | #81225 |
On 12/09/2021 20:29, Michael S wrote: > On Sunday, September 12, 2021 at 7:53:29 PM UTC+3, David Brown wrote: >> On 12/09/2021 15:01, Michael S wrote: >>> On Sunday, September 12, 2021 at 2:55:15 PM UTC+3, David Brown >>>> I think it's fair to say there is scope for improvement in the way >>>> gcc documentation is handled, but it is still a good deal better >>>> than many compilers and other projects. >>> >>> Comparatively to public variant of llvm/clang docs - sure, but that's >>> pretty low bar. I never looked at apple's and google's releases of >>> clang docs, hopefully they are better than public release. >>> Comparatively to Microsoft - it depends. Some parts of the gcc docs >>> are better others are worse. However I would think that when >>> Microsoft's maintainers see a mistake in their online docs for old >>> compiler, or, more likely, are pointed to mistake by community, they >>> fix it without hesitation. >>> >> I have not nearly enough experience with the documentation of MS's >> compiler to tell - I have only ever looked up a few points. (The same >> with clang.) I've read manuals for many other compilers over the years, >> which are often much worse, but none of these tools are direct >> comparisons with gcc (being commercial embedded toolchains targetting >> one or a few specific microcontroller cores). >> >> One especially "fun" case was a toolchain that failed to zero-initialise >> non-local objects that were not explicitly initialised - what you >> normally get by startup code clearing the ".bss" segment. This >> "feature" was documented in a footnote in the middle of the manual, >> noting that the behaviour was not standards conforming and would >> silently break existing C code. > > I suppose, you are talking about TI compilers. > IIRC, in their old docs (around 1998 to 2002) it was documented in relatively clear way. > But it was quite a long time ago so it's possible that I misremember. > > I was omitting the names, to protect the guilty. Yes, it was TI compilers. And not just such old ones either, or just one target device - I have seen the same "feature" on wildly separate twos for at least two TI device architectures. Neither was well documented, certainly not with the flashing red warning lamps you would expect for such a pointless, unexpected and critical deviation from standard C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-12 17:38 -0700 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <87k0jle2dg.fsf@nosuchdomain.example.com> |
| In reply to | #81211 |
Michael S <already5chosen@yahoo.com> writes:
> On Sunday, September 12, 2021 at 12:46:42 PM UTC+3, David Brown wrote:
>> On 12/09/2021 10:29, Michael S wrote:
[...]
>> > gcc maintainers have policy against updating/fixing docs.
>> > From their perspective, compiler and docs are inseparable parts of holy "release".
>> Well, yes. The gcc manual of a particular version documents the gcc of
>> that version. It seems an excellent policy to me.
>>
>> It would be a little different if they were publishing a tutorial on
>> using gcc.
>> > I tried to change their mind about it few years ago, but didn't succeed.
>> Thankfully. It would be rather messy if they only had one reference
>> manual which was full of comments about which versions the particular
>> options or features applied to, as these come and go over time.
>
> That's not what I was suggesting.
> I was suggesting to add an clarifications and suggestions for a
> feature (it was something about function attribute 'optimize') that
> existed in gcc5 to online copy of respective manual hosted on
> gcc.gnu.org/onlinedocs Obviously, a previous version of the manual
> could have been available to historians among us in gcc source control
> database.
Then the online version of the gcc-5.5.0 documentation would be out of
sync with the released version. I'm not saying that's completely a bad
thing, but it's something to consider.
> Instead, said clarifications+suggestions were added to the *next*
> release of the manual. Oh, in fact, no, it didn't made it into gcc6
> manual. It was added to gcc 7 manual.
> So, gcc5 users now have no way to know that changes in docs apply to
> gcc5 every bit as much as they apply to gcc7 and later.
gcc has always (?) been released as gcc-X.Y.Z.tar.gz (or .bz2), which
includes source code and documentation. If the documentation in
gcc-5.5.0.tar.bz2 incorrectly describes the behavior of gcc-5.5.0,
that's obviously a problem. I think the gcc maintainers would consider
that to be a bug in the gcc 5.5.0 release, and they would no more release
an updated "gcc-5.5.0.tar.bz2" to correct a documentation error than to
correct a code error. That would cause too much confusion for users who
already downloaded the old version of the tar file.
If they considered the error important enough to justify a new release,
they could release a new gcc-5.5.1.tar.bz2 or gcc-5.6.0.tar.bz2, perhaps
with only documentation updates (which would be mentioned in the release
notes). But the long-term solution is to fix it in a newer release (the
latest is 11.2.0), and there's a legitimate question about how much
effort is justified to support gcc-5.* users.
Adding footnotes to the online versions of the manuals isn't a bad idea,
but again there are question about how much effort it takes to support
something that few people are using.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-13 03:52 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shmatl$vuf$1@gioia.aioe.org> |
| In reply to | #81200 |
On 9/12/2021 11:46 AM, David Brown wrote: > On 12/09/2021 10:29, Michael S wrote: >> On Sunday, September 12, 2021 at 2:09:30 AM UTC+3, Manfred wrote: > >>> (As a side note, it wouldn't hurt if the GCC people updated their docs >>> from time to time...) >> > > Your reference here was to the "make" manual, rather than the gcc > documentation. But the gcc folk could add an example like this to their > manual for the "-MT" option. > Yes, I know I linked a page from the "make" docs, and I meant to write the /GNU/ people (but my fingers typed gcc) - or whatever team takes care of GNU make. I think the GCC man page is OK, and so is the paragraph about -MT, but a page of "GNU make" that titles "Automatic Prerequisites" would be nice to give an example of the 1-line rule command that uses -MT instead of a 'sed' hieroglyph sequence (which I can read, but defining it user friendly could be controversial) + a temp file + a couple of rogue rm -f commands, expecially considering that -MT is available since gcc 3.04 (i.e. it dates back a /long/ time)) I guess someone from the gcc team somewhere during the last couple of decades could have sent a carrier pigeon to their colleague in the 'make' maintenance team next door, with a small paper roll along the lines of "hey, we've got this cool feature that might make makefile writers' life easier, what do you think about it?" and the receiver might have put hand to their doc page... >> >> gcc maintainers have policy against updating/fixing docs. >> From their perspective, compiler and docs are inseparable parts of holy "release". > > Well, yes. The gcc manual of a particular version documents the gcc of > that version. It seems an excellent policy to me. Yes, for the record the page that I linked is not about a specific version of 'make', it is part of the GNU make online manual. > > It would be a little different if they were publishing a tutorial on > using gcc. > >> I tried to change their mind about it few years ago, but didn't succeed. > > Thankfully. It would be rather messy if they only had one reference > manual which was full of comments about which versions the particular > options or features applied to, as these come and go over time. > > I suppose it would be possible to make some kind of interactive > reference where you selected your choice of compiler version, target > processor, etc., and the text adapted to suit. That could be a useful > tool, and help people see exactly what applied to their exact toolchain. > But it would take a good deal of work, and a rather different thing > from the current manuals. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-12 19:10 -0700 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <87fsu9dy3r.fsf@nosuchdomain.example.com> |
| In reply to | #81229 |
Manfred <noname@add.invalid> writes:
[...]
> Yes, for the record the page that I linked is not about a specific
> version of 'make', it is part of the GNU make online manual.
The link you posted was:
https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html
The URL doesn't refer to a particular version of GNU make, but I believe
it will always refer to the latest version of the manual. If you go up
a couple of levels, it says:
This is Edition 0.75, last updated 17 January 2020, of The GNU Make
Manual, for GNU make version 4.3.
I expect that when 4.4 is released the URL will refer to a newer version
of the manual.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-12 11:32 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shkhf2$fb9$1@dont-email.me> |
| In reply to | #81186 |
On 12/09/2021 01:09, Manfred wrote:
> On 9/9/2021 10:17 PM, David Brown wrote:
>> On 09/09/2021 18:41, James Kuyper wrote:
>>> On 9/9/21 4:54 AM, MisterMule@stubborn.uk wrote:
>>>> On Wed, 8 Sep 2021 20:22:52 +0300
>>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>>> 08.09.2021 13:24 MisterMule@stubborn.uk kirjutas:
>>>>>>
>>>>>> You can write a makefile just as simple. However what happens when
>>>>>> you
>>>>>> want foo.c recompiled when foo.h and bar.h changes but bar.c
>>>>>> should only
>>>>>> be recompiled when bar.h and moo.h change, moo.c should only be
>>>>>> recompiled
>>>>> when
>>>>>> moo.h changes and main.c should be recompiled when anything changes?
>>>>>>
>>>>>
>>>>> Such dependencies are taken care automatically by the gcc -MD option,
>>>>
>>>> No unless the compiler is clairvoyant they arn't.
>>>
>>> That option causes a dependencies file to be created specifying all the
>>> dependencies that the compiler notices during compilation. That file can
>>> then be used to avoid unnecessary re-builds the next time the same file
>>> is compiled. The dependency file is therefore always one build
>>> out-of-date; if you created any new dependencies, or removed any old
>>> ones, the dependencies file will be incorrect until after the next time
>>> you do a build. It's therefore not a perfect solution - but neither is
>>> it useless.
>>>
>>
>> The trick is to have makefile (or whatever build system you use) rules
>> along with gcc so that the dependency file not only labels the object
>> file as dependent on the C or C++ file and all the include files it
>> uses, recursively, but also labels the dependency file itself to be
>> dependent on the same files. Then if the source file or includes are
>> changed, the dependency file is re-created, and make is smart enough to
>> then reload that dependency file to get the new dependencies for
>> building the object file.
>>
>> The makefile rules involved are close to APL in readability, but once
>> you have figured out what you need, you can re-use it for any other
>> project. And it solves the problem you have here.
>>
>>
>> So, for example, if you have these files:
>>
>> a.h
>> ---
>> #include "b.h"
>>
>> b.h
>> ---
>> #define TEST 1
>>
>> c.c
>> ---
>> #include "a.h"
>> #include <stdio.h>
>>
>> int main(void) {
>> printf("Test is %d\n", TEST);
>> }
>>
>>
>> Then "gcc -MD c.c" makes a file
>>
>> c.d
>> ---
>> c.o: c.c /usr/include/stdc-predef.h a.h b.h /usr/include/stdio.h \
>> /usr/include/x86_64-linux-gnu/bits/libc-header-start.h \
>> /usr/include/features.h /usr/include/x86_64-linux-gnu/sys/cdefs.h \
>> /usr/include/x86_64-linux-gnu/bits/wordsize.h \
>> ...
>>
>>
>> Using "gcc -MMD c.c" is more helpful, usually, because it skips the
>> system includes:
>>
>> c.d
>> ---
>> c.o: c.c a.h b.h
>>
>>
>> But the real trick is "gcc -MMD -MT 'c.d c.o' c.c" :
>>
>> c.d
>> ---
>> c.d c.o: c.c a.h b.h
>>
>>
>> Now "make" knows that the dependency file is also dependent on the C
>> file and headers.
>>
>
> What you are describing is substantially:
>
> https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html
>
>
> with the addition of the -MT gcc option, which removes the need for the
> nasty 'sed' command in the "%.d: %.c" rule - which is the kind of thing
> that tends to keep people away.
That is /exactly/ where I got all this! I had been using the
suggestions from that page, plus a couple of other "automate
dependencies with makefiles and gcc" web pages, along with sed, for many
years. Then when starting a new project not long ago, I needed a bit
more complicated makefile than usual (building a few different
variations at the same time). While thinking about the makefile and
looking at gcc manual, I realised this could replace the "sed" and make
things a little easier for others working on the same project but using
Windows.
>
> Thanks for pointing this out.
>
> I guess in that rule one can use the single command:
> %.d: %.c
> $(CC) $(CPPFLAGS) -MM -MT '$*.o $@' -MF $@ $<
>
Yes, something like that is the starting point - but there's usually a
bit in there about directories if you want your build directories
separate from the source directories.
> (As a side note, it wouldn't hurt if the GCC people updated their docs
> from time to time...)
Agreed!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-09 18:37 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <Evs_I.10025$2e3.1696@fx29.iad> |
| In reply to | #81083 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
>07.09.2021 18:07 MisterMule@stubborn.uk kirjutas:
>> On Tue, 7 Sep 2021 15:05:34 +0200
>> Manfred <noname@add.invalid> wrote:
>>> On 9/6/2021 5:26 PM, MisterMule@stubborn.uk wrote:
>>>> On Mon, 6 Sep 2021 13:08:34 +0300
>>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>>>> 06.09.2021 12:11 MisterMule@stubborn.uk kirjutas:
>>>>>
>>>>>> Unless you're writing highly cross platform code there's zero reason to use
>>>
>>>>>> cmake or autoconf at all. A Makefile for *nix is a lot simpler to use and
>>>>>> debug.
>>>>>
>>>>> Been there, done that. And I am sorry for the brain cells I have lost
>>>>> over years when trying to force the Makefile system to work properly.
>>>>> Unfortunately I never quite succeeded at, they always rebuilt either too
>>>>> many or too few files, or both.
>>>
>>> That's a severe limitation of Makefiles, yes. GNU Make addresses that
>>> issue, but if you read through its documentation on how to solve that,
>>> the clearest message you get is to keep away of it.
>>
>> And CMake files are any better? They usually look like a script file thats
>> been edited by a cat walking over the keyboard.
>
>I guess one can write Fortran in any language, including CMake. My CMake
>files are pretty clean, partially thanks to putting all common settings
>into a common file which is included by the top-level CMakeLists.txt.
>
>In a typical CMakeLists.txt in a leaf directory I just say that what
>files need to be compiled (typically *.cpp and *.h), into which library
>they must be be linked into, and what third-party libraries are
>involved. That's all what I'm interested in, and CMake will take care of
>generating all the technical details. That's literally 5 CMake commands:
>
>target_include_directories(...)
>target_link_directories(...)
>target_link_libraries(...)
>file(GLOB MY_SOURCES *.cpp *.h)
>target_sources(... ${MY_SOURCES})
TOP=..
include $(TOP)/Makefile.defs
SOURCES = analyze.cpp
SOURCES += base.cpp
SOURCES += breakpoint.cpp
SOURCES += cf.cpp
SOURCES += channel.cpp
SOURCES += clear.cpp
SOURCES += command.cpp
SOURCES += control.cpp
SOURCES += decompile.cpp
SOURCES += delete.cpp
SOURCES += dis.cpp
SOURCES += dump.cpp
SOURCES += exchange.cpp
SOURCES += haltwait.cpp
SOURCES += iocbdump.cpp
SOURCES += iodump.cpp
SOURCES += load.cpp
SOURCES += mem.cpp
SOURCES += mp.cpp
SOURCES += quit.cpp
SOURCES += rle.cpp
SOURCES += run.cpp
SOURCES += save.cpp
SOURCES += search.cpp
SOURCES += so.cpp
SOURCES += start.cpp
SOURCES += state.cpp
SOURCES += status.cpp
SOURCES += step.cpp
SOURCES += stop.cpp
SOURCES += table.cpp
SOURCES += to.cpp
SOURCES += trace.cpp
OBJECTS = $(SOURCES:.cpp=.o)
all: $(LIBMP)
install:: all
$(LIBMP): $(OBJECTS)
ar cr $@ $+
include $(TOP)/Makefile.rules
-include *.d
Yes, I could replace the SOURCES += with a single wildcard expansion in gmake,
but I prefer them listed individually for flexibility in the contents of the
directory containing the (sub) makefile.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-07 17:56 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <sh85jr$1u8$1@dont-email.me> |
| In reply to | #81082 |
On 07/09/2021 16:07, MisterMule@stubborn.uk wrote: > On Tue, 7 Sep 2021 15:05:34 +0200 > Manfred <noname@add.invalid> wrote: >> On 9/6/2021 5:26 PM, MisterMule@stubborn.uk wrote: >>> On Mon, 6 Sep 2021 13:08:34 +0300 >>> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>>> 06.09.2021 12:11 MisterMule@stubborn.uk kirjutas: >>>> >>>>> Unless you're writing highly cross platform code there's zero reason to use >> >>>>> cmake or autoconf at all. A Makefile for *nix is a lot simpler to use and >>>>> debug. >>>> >>>> Been there, done that. And I am sorry for the brain cells I have lost >>>> over years when trying to force the Makefile system to work properly. >>>> Unfortunately I never quite succeeded at, they always rebuilt either too >>>> many or too few files, or both. >> >> That's a severe limitation of Makefiles, yes. GNU Make addresses that >> issue, but if you read through its documentation on how to solve that, >> the clearest message you get is to keep away of it. > > And CMake files are any better? They usually look like a script file thats > been edited by a cat walking over the keyboard. > >> But the point is that on *nix systems they work and are pretty >> straightforward only for relatively simple projects - as someone else >> wrote on this thread, they don't scale well. > > Never had a problem with scaling - you simply call subsidiary makefiles if > you have a tree structure to build. Ultimately all you need is the source, > include, library and output paths and files somewhere. Its really not rocket > science. > Yesterday I downloaded a beginner's C project from github. It consisted of 2 .c files and 2 .h files, in their own src and include directories (and one of each was only a stub anyway). Yet it came with not only a makefile, but files related to Cmake, and a file called build.sh for good measure. I didn't bother with any of that, I just compiled main.c (after copying those four files into the same directory and adjusting #includes) and that was it. Probably all those build files and directories (there were loads more) were automatically created by some IDE; just perpetuating that presentation and requiring anyone else to evermore having to download compatible tools to be able to build even straightforward projects. The requirements for somebody developing a project, together with the organisation of the various components, and the information needed to make incremental compilation or debugging work, are quite different for someone who just wants to build everything from source anyway, in order to get a working program. My own projects [in my language] have their own organisation of the various modules. Even though this is usually very simple, I still wouldn't impose it on anyone else who wanted to build my project from source. I instead have a compiler option that flattens all the source files and all support files, into a single text file (basically, it concatenates them). That text file can be directly built by the compiler without needing to expand the contents, which makes for an even tidier distribution than it already is anyway. No need to create a sprawling mess on the user's machine.
[toc] | [prev] | [next] | [standalone]
| From | MisterMule@stubborn.uk |
|---|---|
| Date | 2021-09-08 10:28 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <sha37n$7s5$1@gioia.aioe.org> |
| In reply to | #81084 |
On Tue, 7 Sep 2021 17:56:20 +0100 Bart <bc@freeuk.com> wrote: >On 07/09/2021 16:07, MisterMule@stubborn.uk wrote: >> Never had a problem with scaling - you simply call subsidiary makefiles if >> you have a tree structure to build. Ultimately all you need is the source, >> include, library and output paths and files somewhere. Its really not rocket >> science. >> > >Yesterday I downloaded a beginner's C project from github. It consisted >of 2 .c files and 2 .h files, in their own src and include directories >(and one of each was only a stub anyway). > >Yet it came with not only a makefile, but files related to Cmake, and a >file called build.sh for good measure. A lot of people try to make something compile out of the box but just end up with a fragile mess that doesn't work and is more complex to troubleshoot than if they'd just had a README saying "Uncomment this line in the Makefile for Linux, that line for BSD..." etc. >I instead have a compiler option that flattens all the source files and >all support files, into a single text file (basically, it concatenates >them). > >That text file can be directly built by the compiler without needing to >expand the contents, which makes for an even tidier distribution than it >already is anyway. No need to create a sprawling mess on the user's machine. Having all the source in one file certainly simplifies the build process but unfortunately it requires recompiling everything. Thats fine for a program with a few hundred lines but once you get into line counts of 5 or 6 figures it would be very tedious.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-08 13:31 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shaaei$4aq$1@dont-email.me> |
| In reply to | #81089 |
On 08/09/2021 11:28, MisterMule@stubborn.uk wrote: > On Tue, 7 Sep 2021 17:56:20 +0100 > Bart <bc@freeuk.com> wrote: >> On 07/09/2021 16:07, MisterMule@stubborn.uk wrote: >>> Never had a problem with scaling - you simply call subsidiary makefiles if >>> you have a tree structure to build. Ultimately all you need is the source, >>> include, library and output paths and files somewhere. Its really not rocket >>> science. >>> >> >> Yesterday I downloaded a beginner's C project from github. It consisted >> of 2 .c files and 2 .h files, in their own src and include directories >> (and one of each was only a stub anyway). >> >> Yet it came with not only a makefile, but files related to Cmake, and a >> file called build.sh for good measure. > > A lot of people try to make something compile out of the box but just end up > with a fragile mess that doesn't work and is more complex to troubleshoot than > if they'd just had a README saying "Uncomment this line in the Makefile for > Linux, that line for BSD..." etc. > >> I instead have a compiler option that flattens all the source files and >> all support files, into a single text file (basically, it concatenates >> them). >> >> That text file can be directly built by the compiler without needing to >> expand the contents, which makes for an even tidier distribution than it >> already is anyway. No need to create a sprawling mess on the user's machine. > > Having all the source in one file certainly simplifies the build process > but unfortunately it requires recompiling everything. Thats fine for a program > with a few hundred lines but once you get into line counts of 5 or 6 figures > it would be very tedious. > You don't need to go as far as having one source file (although that's what I do when a project needs to be built elsewhere). But not having them spread around 100 nested directories would help! As for recompiling everything: you need to do that anyway when you download a project in source form and want to turn it into an executable. Here, the hoops normally needed to define dependencies between modules and to allow incremental builds are not necessary. But as an illustration of how simple it could be, here are the single-file versions of five language projects of mine [written in my language]: C:\demo>dir 08/09/2021 12:47 260,104 aa.ma (x64 assembler/linker) 08/09/2021 12:47 1,330,207 cc.ma (C compiler) 08/09/2021 12:47 891,159 mm.ma (M compiler) 08/09/2021 12:47 295,325 pc.ma (Experimental Backend) 08/09/2021 12:47 968,210 qq.ma (Q interpreter) 03/09/2021 20:30 521,728 mm.exe M compiler binary 08/09/2021 12:49 58 buildall.bat The .ma composite source files represent about 130 modules and 60 support files; 175Kloc in all. This is the script (Windows BAT file) that I will use to build all those 5 projects using mm.exe: C:\demo>type buildall.bat mm cc.ma mm aa.ma mm qq.ma mm pc.ma mm mm.ma -out:mm2.exe (can't overwrite mm.exe) And here it is in action, where 'tm' is a timing tool: C:\demo>tm buildall C:\demo>mm cc.ma Compiling cc.m---------- to cc.exe C:\demo>mm aa.ma Compiling aa.m---------- to aa.exe C:\demo>mm qq.ma Compiling qq.m---------- to qq.exe C:\demo>mm pc.ma Compiling pc.m---------- to pc.exe C:\demo>mm mm.ma -out:mm2.exe Compiling mm.m---------- to mm2.exe TM: 0.62 It took 0.6 seconds to build 5 projects (and on an ancient PC, using a single core, with an unoptimised compiler). Imagine trying to do the same with mainstream versions of these products. (AA is like NASM plus a linker; CC is like a C compiler, assembler, and linker; PC is my version of LLVM; QQ is what I use instead of CPython; MM is the self-hosted compiler for my systems language.) Everything needed to build 5 major projects from source, including the compiler, is in those handful of files. Not even the script is needed, as you can just type 'mm cc.ma', to build an entire compiler. No make or Cmake needed! How hard was it to create those .ma files? Here's cc.ma being made: C:\archive\cx>tm mm -ma cc Compiling cc.m---------- to cc.ma Writing MA File cc.ma TM: 0.12 It took about 1/8th of a second (this one incorporates 30 modules plus 45 support files including standard C header files). I like to make things simple to use ... (I no longer support Linux versions of this stuff, but at one point I was able to do things like this, on Ubuntu I think: ./mu mu.ma -out:mu2 -tcc This relied on using C as an intermediate language, and -tcc tells it to invoke Tiny C to compile the output, otherwise it defaulted to gcc, which was like hitting a break wall. 'mu' is just of 'mm', but with a different lead module (mu.m not mm.m), which is just an 11-line stub containing module mappings suitable for a C target and a Linux OS. mu.ma could be created on Windows, for compiling on Linux. See, it's not hard!)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-09 11:06 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <ipstvqFgmbiU3@mid.individual.net> |
| In reply to | #81093 |
On 09/09/2021 00:31, Bart wrote: > > You don't need to go as far as having one source file (although that's > what I do when a project needs to be built elsewhere). But not having > them spread around 100 nested directories would help! > > As for recompiling everything: you need to do that anyway when you > download a project in source form and want to turn it into an executable. > > Here, the hoops normally needed to define dependencies between modules > and to allow incremental builds are not necessary. Your projects, no surprise, are ideally suited to your way of working. Large cross platform projects with scores or geographically distributed developers are a different fish kettle. Most significant open source and propitiatory projects fall into that category. Even our little embedded product has 2600+ source and 4500+ header files. Combining those would probably take longer than building them! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-09 01:27 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shbkec$rr9$1@dont-email.me> |
| In reply to | #81106 |
On 09/09/2021 00:06, Ian Collins wrote: > On 09/09/2021 00:31, Bart wrote: >> >> You don't need to go as far as having one source file (although that's >> what I do when a project needs to be built elsewhere). But not having >> them spread around 100 nested directories would help! >> >> As for recompiling everything: you need to do that anyway when you >> download a project in source form and want to turn it into an executable. >> >> Here, the hoops normally needed to define dependencies between modules >> and to allow incremental builds are not necessary. > > Your projects, no surprise, are ideally suited to your way of working. > Large cross platform projects with scores or geographically distributed > developers are a different fish kettle. Most significant open source > and propitiatory projects fall into that category. Even our little > embedded product has 2600+ source and 4500+ header files. Combining > those would probably take longer than building them! Have you tried it? I've just downloaded the sources of the GMP project that has been discussed, from github. There are about 960 .c and .h files in all (not including any that may be synthesised when building, but including files specific to many different targets). Extracting all those files from the directory structure, into a single file, took my script 0.6 seconds. That 5MB file contained 173K lines of code, which is not huge. (The 5 language projects of mine that I'd posted about, coincidentally also totalled 173K lines of code; and also coincidentally took 0.6 seconds to build into 5 executables.) The 'configure' script that comes with this is 30.5K lines of somewhat denser code than the C sources. That's like needing a heavy 100-line script in order to compile a 600-line program. I couldn't see much in the way of .s files, or inline asm() statements, so I don't know where that comes from.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-09 13:05 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <ipt4vcFgmbiU4@mid.individual.net> |
| In reply to | #81107 |
On 09/09/2021 12:27, Bart wrote: > On 09/09/2021 00:06, Ian Collins wrote: >> On 09/09/2021 00:31, Bart wrote: >>> >>> You don't need to go as far as having one source file (although that's >>> what I do when a project needs to be built elsewhere). But not having >>> them spread around 100 nested directories would help! >>> >>> As for recompiling everything: you need to do that anyway when you >>> download a project in source form and want to turn it into an executable. >>> >>> Here, the hoops normally needed to define dependencies between modules >>> and to allow incremental builds are not necessary. >> >> Your projects, no surprise, are ideally suited to your way of working. >> Large cross platform projects with scores or geographically distributed >> developers are a different fish kettle. Most significant open source >> and propitiatory projects fall into that category. Even our little >> embedded product has 2600+ source and 4500+ header files. Combining >> those would probably take longer than building them! > > Have you tried it? Nope. > I've just downloaded the sources of the GMP project that has been > discussed, from github. > > There are about 960 .c and .h files in all (not including any that may > be synthesised when building, but including files specific to many > different targets). > > Extracting all those files from the directory structure, into a single > file, took my script 0.6 seconds. > > That 5MB file contained 173K lines of code, which is not huge. (The 5 > language projects of mine that I'd posted about, coincidentally also > totalled 173K lines of code; and also coincidentally took 0.6 seconds to > build into 5 executables.) So what happens if you get an error at line 16,789? How do you map that back to the original source? It's much easier to combine C files than it is to combine C++ where there's often a fair bit of code in the headers. Even if it were feasible to combine all of the files, the resulting TU would probably break the compiler on a machine with a reasonable amount of RAM. Even it it could be compiled, it would take an age on a single core. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-09 10:29 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shck71$ctj$1@dont-email.me> |
| In reply to | #81108 |
On 09/09/2021 02:05, Ian Collins wrote: > On 09/09/2021 12:27, Bart wrote: >> On 09/09/2021 00:06, Ian Collins wrote: >>> On 09/09/2021 00:31, Bart wrote: >>>> >>>> You don't need to go as far as having one source file (although that's >>>> what I do when a project needs to be built elsewhere). But not having >>>> them spread around 100 nested directories would help! >>>> >>>> As for recompiling everything: you need to do that anyway when you >>>> download a project in source form and want to turn it into an >>>> executable. >>>> >>>> Here, the hoops normally needed to define dependencies between modules >>>> and to allow incremental builds are not necessary. >>> >>> Your projects, no surprise, are ideally suited to your way of working. >>> Large cross platform projects with scores or geographically distributed >>> developers are a different fish kettle. Most significant open source >>> and propitiatory projects fall into that category. Even our little >>> embedded product has 2600+ source and 4500+ header files. Combining >>> those would probably take longer than building them! >> >> Have you tried it? > > Nope. So you're guessing. IME pushing files around is insignificant comparing with building them, and that's with my fast tools. My timings all take advantage of files have been recently processed and therefore cached. Which will be the case if you've just downloaded some project and unpacked the files. >> I've just downloaded the sources of the GMP project that has been >> discussed, from github. >> >> There are about 960 .c and .h files in all (not including any that may >> be synthesised when building, but including files specific to many >> different targets). >> >> Extracting all those files from the directory structure, into a single >> file, took my script 0.6 seconds. >> >> That 5MB file contained 173K lines of code, which is not huge. (The 5 >> language projects of mine that I'd posted about, coincidentally also >> totalled 173K lines of code; and also coincidentally took 0.6 seconds to >> build into 5 executables.) > > So what happens if you get an error at line 16,789? How do you map that > back to the original source? What happens if you get an error in line 16,789 of the configure file? (Which for GMP is this line: $CC -Zdll -Zcrtdll -o $output_objdir/$soname $libobjs $deplibs $compiler_flags $output_objdir/$libname.def~ But I don't get that far: "'.\configure' is not recognized as an internal or external command, operable program or batch file.") What happens if you get an error on line 1234 of a makefile which is already gobbledygook? (Which I use to get all the time, though not specifically on that line.) In the case of a single file C distribution, you will have checked it compiles correctly using a range of recommended compilers before making it available. The range of likely errors is considerably smaller than the vast possibilities of going wrong with scripts, makefiles, running assorted other langages (like m4) and various source files not being in the right place or not being found because they don't exist. With a single file, it's relatively easy to check if it's present or not! I was anyway suggesting a streamlined version of the sources, not necessarily one amalgamated file. Like having them in one place. (However GMP has about 30% of the files having clashing names, which sounds like it needs to sort something out with the various targets. For example to have a separate version for each; after all I don't need the source code for MIPS etc, when I want to build for x64.) > It's much easier to combine C files than it is to combine C++ where > there's often a fair bit of code in the headers. Even if it were > feasible to combine all of the files, the resulting TU would probably > break the compiler on a machine with a reasonable amount of RAM. Even > it it could be compiled, it would take an age on a single core. That's just a mark against the approach used by C++. I don't even attempt to build such projects, and can't use libraries with a C++ API. But it also happens that some of the easiest C libraries to use are implemented as a single header file (just .h, not even .h and .c; example stb_image.h). Those are the ones where the authors have given some thought to ease of deployment.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-09 22:28 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <ipu5u5FgmbiU6@mid.individual.net> |
| In reply to | #81114 |
On 09/09/2021 21:29, Bart wrote: > On 09/09/2021 02:05, Ian Collins wrote: >> On 09/09/2021 12:27, Bart wrote: >>> On 09/09/2021 00:06, Ian Collins wrote: >>>> On 09/09/2021 00:31, Bart wrote: >>>>> >>>>> You don't need to go as far as having one source file (although that's >>>>> what I do when a project needs to be built elsewhere). But not having >>>>> them spread around 100 nested directories would help! >>>>> >>>>> As for recompiling everything: you need to do that anyway when you >>>>> download a project in source form and want to turn it into an >>>>> executable. >>>>> >>>>> Here, the hoops normally needed to define dependencies between modules >>>>> and to allow incremental builds are not necessary. >>>> >>>> Your projects, no surprise, are ideally suited to your way of working. >>>> Large cross platform projects with scores or geographically distributed >>>> developers are a different fish kettle. Most significant open source >>>> and propitiatory projects fall into that category. Even our little >>>> embedded product has 2600+ source and 4500+ header files. Combining >>>> those would probably take longer than building them! >>> >>> Have you tried it? >> >> Nope. > > So you're guessing. IME pushing files around is insignificant comparing > with building them, and that's with my fast tools. We can use distributed building to build our code. > My timings all take advantage of files have been recently processed and > therefore cached. Which will be the case if you've just downloaded some > project and unpacked the files. > >>> I've just downloaded the sources of the GMP project that has been >>> discussed, from github. >>> >>> There are about 960 .c and .h files in all (not including any that may >>> be synthesised when building, but including files specific to many >>> different targets). >>> >>> Extracting all those files from the directory structure, into a single >>> file, took my script 0.6 seconds. >>> >>> That 5MB file contained 173K lines of code, which is not huge. (The 5 >>> language projects of mine that I'd posted about, coincidentally also >>> totalled 173K lines of code; and also coincidentally took 0.6 seconds to >>> build into 5 executables.) >> >> So what happens if you get an error at line 16,789? How do you map that >> back to the original source? > > What happens if you get an error in line 16,789 of the configure file? We don't have one. We have a premake Lua script. Most of the open source libraries we use have CMake scripts. >> It's much easier to combine C files than it is to combine C++ where >> there's often a fair bit of code in the headers. Even if it were >> feasible to combine all of the files, the resulting TU would probably >> break the compiler on a machine with a reasonable amount of RAM. Even >> it it could be compiled, it would take an age on a single core. > > That's just a mark against the approach used by C++. I don't even > attempt to build such projects, and can't use libraries with a C++ API. So why are you complaining in a C++ group? You have failed to address the question of how distributed teams work with code. At some point, even if they distribute a single source (like sqlite) there must be a system to build individual files. You also gloss over the fact that any reasonably large project will build significantly faster as discrete files. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-09 12:40 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shcrsh$19n$1@dont-email.me> |
| In reply to | #81116 |
On 09/09/2021 11:28, Ian Collins wrote: > On 09/09/2021 21:29, Bart wrote: >> On 09/09/2021 02:05, Ian Collins wrote: >> What happens if you get an error in line 16,789 of the configure file? > > We don't have one. We have a premake Lua script. > > Most of the open source libraries we use have CMake scripts. CMake on Windows is a 93MB installion with 6000 files. For something I don't quite get the point of. (If it does scripting, Lua is a better bet with usually a single, smallish executable.) > >>> It's much easier to combine C files than it is to combine C++ where >>> there's often a fair bit of code in the headers. Even if it were >>> feasible to combine all of the files, the resulting TU would probably >>> break the compiler on a machine with a reasonable amount of RAM. Even >>> it it could be compiled, it would take an age on a single core. >> >> That's just a mark against the approach used by C++. I don't even >> attempt to build such projects, and can't use libraries with a C++ API. > > So why are you complaining in a C++ group? I can't remember; I think the thread has veered across both C and C++ groups and I haven't paid much attention. > You have failed to address the question of how distributed teams work > with code. I don't have experience with such code, so I don't know the problems and the approaches I might use to fix them. But I do have experience of trying to use open-source products, where what would be a trivial-to-build project, turns into a exasperating hunt for the necessary information which is buried with two levels of encryption inside makefiles and scripts. > At some point, even if they distribute a single source (like > sqlite) there must be a system to build individual files. In order to build Lua (that script language mentioned above), the hundreds of lines of makefiles and scripts can actually be reduced down to a list 34 .c files that needed to be compiled into the same executable; that's it. I used to build it with a @ file containing that list of files plus whatever compile options were needed. I just wish more projects would also provide that basic information. Some may be too impractical for that like yours, but very many could benefit from that approach. People building such things will usually be programmers; they can arrange their own scripting when necessary! > You also gloss over the fact that any reasonably large project will > build significantly faster as discrete files. The actual compile-time is not that critical for something that hopefully you only do once. It will still be faster than running that brain-dead configure script! Optimisation is not important for the first step of getting /anything/ working, so that you can use a fast compiler, or turn off some options. But when you do need the extra speed, a single file gives you whole-program optimisation for free. It's true that discrete files that make parallelising a build more practical. But it's also true that a fast compiler can generate up to 1-2MB of unoptimised binary code per second per core; so exactly how big is the thing you're building?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-10 09:51 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <ipvdufFgmbiU7@mid.individual.net> |
| In reply to | #81117 |
On 09/09/2021 23:40, Bart wrote: > On 09/09/2021 11:28, Ian Collins wrote: > >> You have failed to address the question of how distributed teams work >> with code. > > I don't have experience with such code, so I don't know the problems and > the approaches I might use to fix them. > > But I do have experience of trying to use open-source products, where > what would be a trivial-to-build project, turns into a exasperating hunt > for the necessary information which is buried with two levels of > encryption inside makefiles and scripts. We build binaries for 28 open source projects for four platforms (includes Windows). All are trivial to build except for openssl, which is a bitch to build on Windows. >> At some point, even if they distribute a single source (like >> sqlite) there must be a system to build individual files. > > In order to build Lua (that script language mentioned above), the > hundreds of lines of makefiles and scripts can actually be reduced down > to a list 34 .c files that needed to be compiled into the same > executable; that's it. Reducing down to a list of source files is effectively what build generators like CMake and premake do. In our case, we use premake to generate ninja files which ninja build uses to perform a flat compile of every file that matches the search rules in the project tree. >> You also gloss over the fact that any reasonably large project will >> build significantly faster as discrete files. > > The actual compile-time is not that critical for something that > hopefully you only do once. It will still be faster than running that > brain-dead configure script! If you change a top level header, you build a lot and often. Everyone who pulls your changes also builds a lot. > Optimisation is not important for the first step of getting /anything/ > working, so that you can use a fast compiler, or turn off some options. > But when you do need the extra speed, a single file gives you > whole-program optimisation for free. Optimization may not be important initially, but error checking is. It's not uncommon for embedded products to be unusable unless optimised, so cross compile builds nearly always default to optimised builds. > It's true that discrete files that make parallelising a build more > practical. But it's also true that a fast compiler can generate up to > 1-2MB of unoptimised binary code per second per core; so exactly how big > is the thing you're building? 2,600 C++ source files x 3 platforms + Windows. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-10 00:07 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <she43m$ssj$1@dont-email.me> |
| In reply to | #81129 |
On 09/09/2021 22:51, Ian Collins wrote: > On 09/09/2021 23:40, Bart wrote: >> Optimisation is not important for the first step of getting /anything/ >> working, so that you can use a fast compiler, or turn off some options. >> But when you do need the extra speed, a single file gives you >> whole-program optimisation for free. > > Optimization may not be important initially, but error checking is. For development, certainly. But I'm mainly talking about a product or application someone may want to use, for which, for one reason or another, a ready-to-run binary is not available. Then, bearing in mind that (1) this should be a finished debugged application; (2) a process already exists to flatten even an untidy source repository into a small number (often one), of linear binary files, it might be possible to take just one step back from that final stage, and have a flat epresentation not quite yet committed to a specific target. All my current language programs take multiple files as input, and produce a single file as output. While it's no surprise that outputs such as EXE or DLL are single files, this also appplies to OBJ (one for the whole program); ASM (one for the whole program); C where supported (one for the whole program); PCL (my new portable IL, again representing an entire program); MA (a specific amalgamation of the source files of a project). So, getting one-file outputs is a by-product of how I do things, but it turns out to be useful for not-quite-binary distributions too, and is likely to be useful also on somewhat larger scales than my own projects. I doubt any real products work like this, or that anyone is actively working on making non-binary distributions smaller, simpler, faster, or more foolproof (they are mainly intent on creating bigger products!) People could however give more thought to making things better by conventional means, and minimising dependencies. > It's > not uncommon for embedded products to be unusable unless optimised, so > cross compile builds nearly always default to optimised builds. This might be another characteristic of C++ code, where lots of boilerplate is generated, and it /needs/ an optimising compiler to reduce it all down. (I normally keep away from such features in a language, but my new intermediate language, if set to generate C source, will produce absolutely appalling code in a subset I call 'Linear-C'. That also /needs/ an optimising compiler to remove all the redundancy.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-10 11:26 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <ipvjgqFgmbiU8@mid.individual.net> |
| In reply to | #81130 |
On 10/09/2021 11:07, Bart wrote: > On 09/09/2021 22:51, Ian Collins wrote: >> On 09/09/2021 23:40, Bart wrote: > >>> Optimisation is not important for the first step of getting /anything/ >>> working, so that you can use a fast compiler, or turn off some options. >>> But when you do need the extra speed, a single file gives you >>> whole-program optimisation for free. >> >> Optimization may not be important initially, but error checking is. > > For development, certainly. But I'm mainly talking about a product or > application someone may want to use, for which, for one reason or > another, a ready-to-run binary is not available. > <snip> > > I doubt any real products work like this, or that anyone is actively > working on making non-binary distributions smaller, simpler, faster, or > more foolproof (they are mainly intent on creating bigger products!) Which is why so many recent projects use CMake - a simple build process anywhere... mkdir build && cd build cmake .. cmake --build . --target install Are the usual three steps. Most of the projects we build are built this way for all of the target platforms. > People could however give more thought to making things better by > conventional means, and minimising dependencies. That's certainly true. >> It's >> not uncommon for embedded products to be unusable unless optimised, so >> cross compile builds nearly always default to optimised builds. > > This might be another characteristic of C++ code, where lots of > boilerplate is generated, and it /needs/ an optimising compiler to > reduce it all down. No, the unoptimised builds are simply too slow on the target platform. Unless stripped (which is silly for a debug build) they also tend to be too big! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-10 10:02 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shf3f6$ulu$1@dont-email.me> |
| In reply to | #81130 |
On 10/09/2021 01:07, Bart wrote: > On 09/09/2021 22:51, Ian Collins wrote: >> On 09/09/2021 23:40, Bart wrote: > >>> Optimisation is not important for the first step of getting /anything/ >>> working, so that you can use a fast compiler, or turn off some options. >>> But when you do need the extra speed, a single file gives you >>> whole-program optimisation for free. >> >> Optimization may not be important initially, but error checking is. > > For development, certainly. But I'm mainly talking about a product or > application someone may want to use, for which, for one reason or > another, a ready-to-run binary is not available. As I see it, there are usually two main purposes in running a compiler. One is to build the code for a program (or library) that is already developed, debugged, and tested, and has been distributed as source code rather than an optimised pre-built binary. For that, you often want a good optimising compiler to generate fast results. You are not interested in warnings or generating debugger information, but the result should be efficient in size and speed. The other is when /you/ are developing the code - and then you want your compiler to help you in that work. For that, you need a compiler that does a lot of analysis and static error checking. You also want the results to be efficient - after all, that is often a prime reason for using languages like C and C++. And you want the code you are debugging and testing to be as close as possible to the code you are planning to ship. If you have a good enough /automated/ test environment, as many big teams do, then it can make sense to have distinct "development" and "release" build setups, both of which are done using top-range compilers with heavy analysis for optimisation and static checking, with small differences in the emphasis. For smaller teams or single developers, you want just one setup, so that you test what you will release, and release what you have tested. And you do that using a top-range compiler that does analysis, optimisation and static checks. (Other tools such as additional static analysers, simulators, test suites, sanitizer tests, etc., are also useful - but these are often slower than compilation and more likely to be done at night.) All in all, I simply cannot see any point in software development in which a non-optimising (including "gcc -O0") or weak compiler is useful. There may be times in which a very small but reasonable compiler such as tcc can be helpful - perhaps you have need of compiling a small program on a very old and limited computer. Of course no one will complain if these tools are faster at their job. But doing a /good/ job is more important than doing a /fast/ job. (And the size of the tool is almost completely irrelevant.) > > People could however give more thought to making things better by > conventional means, and minimising dependencies. > Sure. >> It's not uncommon for embedded products to be unusable unless >> optimised, so cross compile builds nearly always default to optimised >> builds. > > This might be another characteristic of C++ code, where lots of > boilerplate is generated, and it /needs/ an optimising compiler to > reduce it all down. > > (I normally keep away from such features in a language, but my new > intermediate language, if set to generate C source, will produce > absolutely appalling code in a subset I call 'Linear-C'. That also > /needs/ an optimising compiler to remove all the redundancy.) > Then you are missing out. Part of the advantage of using good tools is that /you/, the developer, can concentrate on writing clear and maintainable code, and let the compiler worry about the details of turning it into optimal results. This applies to C as well as C++. As an example, when I work with a small microcontroller like the AVR, the processing capabilities are weak. It is 8-bit, and while some models have an 8-bit multiply instruction, division and arithmetic bigger types are all much slower and may use library functions. Floating point is extremely slow and the library support code might use more flash space than the chip has. A common feature of the electronic boards using such microcontrollers is analogue inputs, and these often have resistor networks for scaling, biasing, protection, etc. To turn the ADC measured value into a useful value, you generally have a linear transform - "x = (raw * A) >> N + B;". For efficient but accurate results on such microcontrollers, all types will be 16-bit but the multiply will be 32-bit, downshifted and then a 16-bit addition. But what should these 16-bit integers A, B and N be? With poor quality compilers, you calculate it all by hand or an external tool (like a spreadsheet), and fill in the magic numbers in the code. With a good compiler, you make "static const" (or C++ constexpr) specifying the various resistors and voltage references, then do the calculations in code. Static assertions check that there are no overflows. The compiler can be relied on to pre-calculate everything, including all the floating point calculations and reduction to integers. This gives much clearer and more maintainable code. There are no "magic numbers", just values copied from the electronics schematics. If a new board version has a different value for a resistor, you change that one value in the code. Compilation with optimisation leads to optimal code of a few dozen instructions and clock cycles. Compilation without optimisation means thousands of clock cycles and perhaps 10K of extra library code (on a device with maybe 16K of flash memory). In the C++ world, a compiler that can't inline functions is /useless/. It is essential for code structure and code reuse. On my current C++ project, targeting a high-end 32-bit ARM microcontroller, I use a set of templates for abstracting IO pins. In my source code, I can write "led_error.on();" and know that the generated code is optimal, whether the pin is active high, active low, or various other complications supported. Without inlining, it would involve five or six nested function calls and lots of run-time logic that otherwise disappears by constant propagation passes. Being able to rely on having a good compiler means you can write better source code. It means you can write C code, and C++ code, and not some kind of transliterated assembly, and get near-optimal results in the end. Am I willing to wait 5 more seconds for a project build, in order to use "gcc -O2" instead of "gcc -O0" ? Yes, I certainly am.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-10 09:10 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shf7db$td7$1@gioia.aioe.org> |
| In reply to | #81132 |
David Brown <david.brown@hesbynett.no> wrote: > All in all, I simply cannot see any point in software development in > which a non-optimising (including "gcc -O0") or weak compiler is useful. If we are talking about using a separate compiler from the one you intend to build the final version with, then sure, there may be little sense in using that (other than, perhaps, that other compiler having better checks or diagnostics than the ones in your "main" compiler.) However, gcc -O0 is quite useful in development. For starters, when you are interactively debugging (eg. with gdb, or any of the myriads of debuggers in different IDEs), you usually don't want things like your functions being inlined, loops unrolled, compile-time arithmetic (other than, of course, that of constexpr/consteval functions), etc. When debugging using an interactive debugger, the execution path should follow the source code line-by-line, with *each* line included and nothing optimized away. Of course there's also the question of compilation speed. When compiling small or even medium-sized projects, we seldom tend to pay attention to how fast "gcc -O0" compiles compared to "gcc -O3", especially since we tend to have these supercomputers on our desks. However, when compiling much larger projects, or when compiling on a very inefficient platform, the difference can become substantial, and detrimental to development if it's too long. For example, I have a hobby project that has some ARM-specific code, which I simply cannot compile nor run in my desktop computer. I need an ARM system to compile it. The only ARM system where I can do this easily is a Raspberry Pi. And even though it's the RPi 4, it's a *slow* system. The project, even though it's not extraordinarly large, takes quite a substantial amount of time to compile on the Raspi. Here are some compile times with different optimization levels of gcc: -O0: 30s -O1: 43s -O2: 1m 4s -O3: 1m 30s As you might imagine, it's better to have the project compile in 30 seconds rather than 1 minute and 30 seconds, whan you are developing the code and constantly making changes to it that need to be tested. (The 43 seconds of -O1 is bearable, but still the 13 seconds longer compile time can be felt in the long run.)
[toc] | [prev] | [next] | [standalone]
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web