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 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-10 11:32 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shfc90$oqf$1@dont-email.me> |
| In reply to | #81133 |
On 10/09/2021 10:10, Juha Nieminen wrote: > 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. The 'supercomputer' on my desk is not significantly faster than the RPi4 you mention below. It can still build all of my projects in 1/4 second or less. (Which is actually still mildly annoying as it's long enough to notice.) And, it runs Windows. gcc however takes 0.4 seconds to compile hello.c. > 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.) If your code is fairly standard C, try using Tiny C. I expect your program will build in one second or thereabouts. I've just compared building 3 programs, comparing tcc to gcc-O0, and these compile-times (figures are 'real' times): 0.3 seconds vs 22 seconds 0.2 seconds vs 6.3 seconds 0.1 seconds vs 1.1 seconds
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-12 09:00 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shkfil$1lpj$2@gioia.aioe.org> |
| In reply to | #81136 |
Bart <bc@freeuk.com> wrote: > The 'supercomputer' on my desk is not significantly faster than the RPi4 > you mention below. Then you must have a PC from the 1990's, because the Raspberry Pi 4 is a *very slow* system, believe me. I know, I have one. What takes a few seconds to compile on my PC can take a minute to compile on the Pi. > If your code is fairly standard C, try using Tiny C. I expect your > program will build in one second or thereabouts. It's C++. (This is a C++ newsgroup, after all.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-12 11:29 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shkkr2$52j$1@dont-email.me> |
| In reply to | #81191 |
On 12/09/2021 10:00, Juha Nieminen wrote: > Bart <bc@freeuk.com> wrote: >> The 'supercomputer' on my desk is not significantly faster than the RPi4 >> you mention below. > > Then you must have a PC from the 1990's, because the Raspberry Pi 4 > is a *very slow* system, believe me. I know, I have one. What takes > a few seconds to compile on my PC can take a minute to compile on > the Pi. My machine is from 2010. I probably under-represented the RPi4 timings because it was running a 32-bit OS, so programs were 32-bit, but my PC compilers were 64-bit. There might be other reasons for the discrepancy you see; maybe your projects uses lots of files, and your PC uses SSD while the RPI uses the slower (?) SD. Or your project is large and is putting pressure on the RPi4's perhaps more limited RAM. (I chose my comparisons to be within the capabilities of both machines.) >> If your code is fairly standard C, try using Tiny C. I expect your >> program will build in one second or thereabouts. > > It's C++. (This is a C++ newsgroup, after all.) See my reply to Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-10 13:47 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shfgke$lvf$1@dont-email.me> |
| In reply to | #81133 |
On 10/09/2021 11:10, Juha Nieminen wrote: > 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.) > You might (indeed, you /should/) also use other compilers if you want to check compatibility for other tools. But that was not really what I was talking about. > 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. I always compile with debugging information, and I regularly use breakpoints, stepping, assembly-level debug, etc. I /hate/ having to deal with unoptimised "gcc -O0" code - it is truly awful. You have vast amounts of useless extra code that hides the real action. In the assembly, the code to load and store variables from the stack, instead of registers, often outweighs the actual interesting stuff. Single-stepping through your important functions becomes far harder because all the little calls that should be inlined out of existence, become layers of calls that you might have to dig through. Most of the what you are looking for is drowned out in the noise. Debugging is an art - there is no way to get the "perfect" debugable code generation. In practice, you often need to make temporary changes to aid debugging - adding a "noinline" attribute here, and a volatile trace variable there, etc. A few gcc pragmas for things like "-fno-reorder-blocks" and "-fno-toplevel-reorder" make the code a lot clearer to follow, with optimisation enabled. I sometimes go down to -O1 for difficult debugging tasks, but usually I debug at -O2. > 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. > That was true 20 years ago, perhaps, with C. Not now, and not with C++. > 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. Don't solve that by using weaker tools. Solve it by improving how you use the tools - get better build systems to avoid unnecessary compilation, use ccache if you have build options or variations that you swap back and forth, use distcc to spread the load, explain to your boss why a Ryzen or even a ThreadRipper will save money overall as /your/ time costs more than the computer's time. "I don't use optimisation because it is too slow" is an excuse for hobby developers, not professionals. > > 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.) > It is better to only compile the bits that need to be compiled. Who cares how long a full build takes? (For big enough projects, linking is usually the big problem, and that's harder to handle.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-11 11:02 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iq26fuFgmbiU9@mid.individual.net> |
| In reply to | #81140 |
On 10/09/2021 23:47, David Brown wrote: > On 10/09/2021 11:10, Juha Nieminen wrote: >> >> 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. > > Don't solve that by using weaker tools. Solve it by improving how you > use the tools - get better build systems to avoid unnecessary > compilation, use ccache if you have build options or variations that you > swap back and forth, use distcc to spread the load, explain to your boss > why a Ryzen or even a ThreadRipper will save money overall as /your/ > time costs more than the computer's time. "I don't use optimisation > because it is too slow" is an excuse for hobby developers, not > professionals. I agree 100%. I guess I have to given you have just described my home and work build systems! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-11 00:33 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shgq1m$id4$1@dont-email.me> |
| In reply to | #81140 |
On 10/09/2021 12:47, David Brown wrote: > On 10/09/2021 11:10, Juha Nieminen wrote: >> 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. > > I always compile with debugging information, and I regularly use > breakpoints, stepping, assembly-level debug, etc. I /hate/ having to > deal with unoptimised "gcc -O0" code - it is truly awful. You have vast > amounts of useless extra code that hides the real action. In the > assembly, the code to load and store variables from the stack, instead > of registers, often outweighs the actual interesting stuff. > Single-stepping through your important functions becomes far harder > because all the little calls that should be inlined out of existence, > become layers of calls that you might have to dig through. Most of the > what you are looking for is drowned out in the noise. I agree with JN. With optimised code, what you have may have little relationship with the original source code. If you're trying to trace a logic problem, how do you map machine code to the corresponding source? Or more importantly, how does the debugger do so? For such purposes, an interpreter might be a better bet for some kinds of bugs. However, I've never used a debugger (other than some distant attempts at writing one); what are you actually stepping through: machine code, or lines of source code, or both? I would have thought that for a logic problem (or most bugs actually provided they are reproducable), you'd want to be looking at source code, not native code. (Unless you're perhaps debugging a compiler, which is what I do quite a lot.) And for source code, what difference should it make whether the generated code is optimised or not? >> 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. > > Don't solve that by using weaker tools. Solve it by improving how you > use the tools - get better build systems to avoid unnecessary > compilation, use ccache if you have build options or variations that you > swap back and forth, use distcc to spread the load, explain to your boss > why a Ryzen or even a ThreadRipper will save money overall as /your/ > time costs more than the computer's time. "I don't use optimisation > because it is too slow" is an excuse for hobby developers, not > professionals. After continually bawling me out for putting too much emphasis on compilation speed, are you saying for the first time that it might be important after all?! However you seem to be in favour of letting off the people who write the tools (because it is unheard of for them create an inefficient product!), and just throwing more hardware - and money - at the problem.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-11 11:42 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iq28qoFgmbiU11@mid.individual.net> |
| In reply to | #81157 |
On 11/09/2021 11:33, Bart wrote: > On 10/09/2021 12:47, David Brown wrote: >> On 10/09/2021 11:10, Juha Nieminen wrote: > >>> 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. >> >> I always compile with debugging information, and I regularly use >> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to >> deal with unoptimised "gcc -O0" code - it is truly awful. You have vast >> amounts of useless extra code that hides the real action. In the >> assembly, the code to load and store variables from the stack, instead >> of registers, often outweighs the actual interesting stuff. >> Single-stepping through your important functions becomes far harder >> because all the little calls that should be inlined out of existence, >> become layers of calls that you might have to dig through. Most of the >> what you are looking for is drowned out in the noise. > > I agree with JN. With optimised code, what you have may have little > relationship with the original source code. If you're trying to trace a > logic problem, how do you map machine code to the corresponding source? If you are trying to trace a logic problem, unit tests are your friend. The debugger is the last resort... > After continually bawling me out for putting too much emphasis on > compilation speed, are you saying for the first time that it might be > important after all?! If your project has thousands of source files and builds for several targets, then build times are obviously important. > However you seem to be in favour of letting off the people who write the > tools (because it is unheard of for them create an inefficient > product!), and just throwing more hardware - and money - at the problem. Build systems are a collection of tools, one of which is the compiler. The collection gives you the performance you want. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-09-15 19:20 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shta19$1spq$1@gioia.aioe.org> |
| In reply to | #81158 |
On 9/11/2021 1:42 AM, Ian Collins wrote: > On 11/09/2021 11:33, Bart wrote: >> On 10/09/2021 12:47, David Brown wrote: >>> On 10/09/2021 11:10, Juha Nieminen wrote: >> >>>> 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. >>> >>> I always compile with debugging information, and I regularly use >>> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to >>> deal with unoptimised "gcc -O0" code - it is truly awful. You have vast >>> amounts of useless extra code that hides the real action. In the >>> assembly, the code to load and store variables from the stack, instead >>> of registers, often outweighs the actual interesting stuff. >>> Single-stepping through your important functions becomes far harder >>> because all the little calls that should be inlined out of existence, >>> become layers of calls that you might have to dig through. Most of the >>> what you are looking for is drowned out in the noise. >> >> I agree with JN. With optimised code, what you have may have little >> relationship with the original source code. If you're trying to trace a >> logic problem, how do you map machine code to the corresponding source? > > If you are trying to trace a logic problem, unit tests are your friend. > The debugger is the last resort... One additional consideration is that spotting a logic problem that involves local variables only is usually easy just looking at the source code. Harder bugs may involve data that is spread across different TUs, which, unlike local variables, have a low chance of being optimized away or into registers by the compiler - while on the other hand the nesting level of calls may be reduced, which makes debugging faster as David Brown was relating to. So, even if optimized code is theoretically harder to debug, practical circumstances may come to the rescue. But I agree that the debugger is the last resort. > >> After continually bawling me out for putting too much emphasis on >> compilation speed, are you saying for the first time that it might be >> important after all?! > > If your project has thousands of source files and builds for several > targets, then build times are obviously important. > >> However you seem to be in favour of letting off the people who write the >> tools (because it is unheard of for them create an inefficient >> product!), and just throwing more hardware - and money - at the problem. > > Build systems are a collection of tools, one of which is the compiler. > The collection gives you the performance you want. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-11 19:15 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shio80$rg$1@dont-email.me> |
| In reply to | #81157 |
On 11/09/2021 01:33, Bart wrote: > On 10/09/2021 12:47, David Brown wrote: >> On 10/09/2021 11:10, Juha Nieminen wrote: > >>> 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. >> >> I always compile with debugging information, and I regularly use >> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to >> deal with unoptimised "gcc -O0" code - it is truly awful. You have vast >> amounts of useless extra code that hides the real action. In the >> assembly, the code to load and store variables from the stack, instead >> of registers, often outweighs the actual interesting stuff. >> Single-stepping through your important functions becomes far harder >> because all the little calls that should be inlined out of existence, >> become layers of calls that you might have to dig through. Most of the >> what you are looking for is drowned out in the noise. > > I agree with JN. With optimised code, what you have may have little > relationship with the original source code. If you're trying to trace a > logic problem, how do you map machine code to the corresponding source? > It's a /lot/ easier with -O1 than -O0. Or you use the debugger. > Or more importantly, how does the debugger do so? The compiler generates lots of debug information, and the debugger reads it. How else would it work? > > For such purposes, an interpreter might be a better bet for some kinds > of bugs. > There are many kinds of bugs, and many tools and tactics for finding and squashing them. As well as compiling at -O2 with debugging information enabled, and running with a good debugger, there are many other tools in my toolbox. I mentioned some, such as varying compiler options with pragmas or adding virtual variables for tracing. Like most people, I will also add debug output (though it is usually on a UART in my systems, rather than a console printf). Sometimes I will drive test pins and have an oscilloscope connected - there are many possibilities. And I can quite happy accept that for some kinds of bugs an interpreter could be handy. Certainly there are many tools that I /don't/ use, such as some types of sanitizers and tracing malloc libraries, since they are not relevant to my needs. > However, I've never used a debugger (other than some distant attempts at > writing one); what are you actually stepping through: machine code, or > lines of source code, or both? > Yes, yes and yes :-) > I would have thought that for a logic problem (or most bugs actually > provided they are reproducable), you'd want to be looking at source > code, not native code. (Unless you're perhaps debugging a compiler, > which is what I do quite a lot.) > Mostly, that is correct. > And for source code, what difference should it make whether the > generated code is optimised or not? > Because it is not always correct! Sometimes the issue is on the lines of "Why is this taking so long? I had expected less than 0.1µs, but it is taking nearly 0.2µs." You need to look at the assembly for that. > >>> 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. >> >> Don't solve that by using weaker tools. Solve it by improving how you >> use the tools - get better build systems to avoid unnecessary >> compilation, use ccache if you have build options or variations that you >> swap back and forth, use distcc to spread the load, explain to your boss >> why a Ryzen or even a ThreadRipper will save money overall as /your/ >> time costs more than the computer's time. "I don't use optimisation >> because it is too slow" is an excuse for hobby developers, not >> professionals. > > After continually bawling me out for putting too much emphasis on > compilation speed, are you saying for the first time that it might be > important after all?! No, I am saying that if compilation speed is a problem for how you work, then you are probably not using the tools in the appropriate way. Use the good tools in a better way, rather than using poorer tools (and I count "gcc -O0" as a poor tool here). > > However you seem to be in favour of letting off the people who write the > tools (because it is unheard of for them create an inefficient > product!), and just throwing more hardware - and money - at the problem. The people making gcc do not work for me. They /do/ get some money from me (or rather, my employer) in indirect ways - for example, we buy microcontrollers with ARM cores, and ARM pays some gcc developers. But I am hardly in a position to tell the gcc developers "stop adding optimisations and extra warning checks, and forget supporting new devices and new language standards - make everything faster instead". I don't have a problem with compile speed. I think the same applies to most people who get appropriate tools for their tasks, learn to use them in the most suitable ways, and match their development processes thoughtfully. Of course it is always great if a compiler runs faster - I have never heard anyone complain that their tools are too fast! But that is very different from saying there is a /problem/. I'd be happy if my car could be upgraded to get twice the petrol mileage. But I don't see its petrol usage as a problem - and I certainly would not swap it for a moped just because the moped uses much less petrol.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-11 20:56 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shj1l6$b41$1@dont-email.me> |
| In reply to | #81180 |
On 11/09/2021 18:15, David Brown wrote:
> On 11/09/2021 01:33, Bart wrote:
>> On 10/09/2021 12:47, David Brown wrote:
>>> On 10/09/2021 11:10, Juha Nieminen wrote:
>>
>>>> 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.
>>>
>>> I always compile with debugging information, and I regularly use
>>> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to
>>> deal with unoptimised "gcc -O0" code - it is truly awful. You have vast
>>> amounts of useless extra code that hides the real action. In the
>>> assembly, the code to load and store variables from the stack, instead
>>> of registers, often outweighs the actual interesting stuff.
>>> Single-stepping through your important functions becomes far harder
>>> because all the little calls that should be inlined out of existence,
>>> become layers of calls that you might have to dig through. Most of the
>>> what you are looking for is drowned out in the noise.
>>
>> I agree with JN. With optimised code, what you have may have little
>> relationship with the original source code. If you're trying to trace a
>> logic problem, how do you map machine code to the corresponding source?
>>
>
> It's a /lot/ easier with -O1 than -O0. Or you use the debugger.
Oh, you mean look at the ASM manually? In that case definitely through
-O0. If I take this fragment:
for (int i=0; i<100; ++i) {
a[i]=b+c*d;
fn(a[i]);
}
then using 'gcc -S -O1 -fverbose-asm' gives me:
# c.c:8: a[i]=b+c*d;
movl $0, %esi #, _2
movl $100, %ebx #, ivtmp_4
.L2:
# c.c:9: fn(a[i]);
movl %esi, %ecx # _2,
call fn #
# c.c:7: for (int i=0; i<100; ++i) {
subl $1, %ebx #, ivtmp_4
jne .L2 #,
Where's all my code gone?! With -O0 I get this:
# c.c:7: for (int i=0; i<100; ++i) {
movl $0, -4(%rbp) #, i
# c.c:7: for (int i=0; i<100; ++i) {
jmp .L2 #
.L3:
# c.c:8: a[i]=b+c*d;
movl -8(%rbp), %eax # c, tmp87
imull -12(%rbp), %eax # d, tmp87
movl %eax, %edx # tmp87, _1
# c.c:8: a[i]=b+c*d;
movl -16(%rbp), %eax # b, tmp88
addl %eax, %edx # tmp88, _2
# c.c:8: a[i]=b+c*d;
movl -4(%rbp), %eax # i, tmp90
cltq
movl %edx, -64(%rbp,%rax,4) # _2, a[i_4]
# c.c:9: fn(a[i]);
movl -4(%rbp), %eax # i, tmp92
cltq
movl -64(%rbp,%rax,4), %eax # a[i_4], _3
movl %eax, %ecx # _3,
call fn #
# c.c:7: for (int i=0; i<100; ++i) {
addl $1, -4(%rbp) #, i
.L2:
# c.c:7: for (int i=0; i<100; ++i) {
cmpl $99, -4(%rbp) #, i
jle .L3 #,
This looks pretty dreadful (gas format always does; gcc can produce
Intel-style eee below). However you can much more clearly match the
elements of your C code with lines of the ASM.
My own C compiler can produce this, which is one step back from it's -S
output:
mov word32 [Dframe+i], 0
jmp L4
L5:
iwiden D0, word32 [Dframe+i]
mov A1, [Dframe+b]
mov A3, [Dframe+c]
imul A3, [Dframe+d]
add A1, A3
mov [Dframe+D0*4+a], A1
sub Dstack, 32
iwiden D10, word32 [Dframe+i]
mov A10, [Dframe+D10*4+a]
call fn*
add Dstack, 32
L2:
inc word32 [Dframe+i]
L4:
mov A0, [Dframe+i]
cmp A0, 100
jl L5
(The proper ASM changes 'iwiden' to 'movsx', and the local variable
names to offsets.)
If I code the equivalent in my language [where ints are 64 bits], and
turn on its very modest optimiser, it produces this (with simplified
local names specific for debugging purposes):
mov R.i, 0
L5:
mov D0, R.c
imul2 D0, R.d
mov D1, R.b
add D1, D0
mov [Dframe+R.i*8+start.a], D1
mov D10, D1
call t.fn
L6:
inc R.i
cmp R.i, 9
jle L5
So which one gets the prize?
To me, both gcc-produced listings look like a nightmare. TBF that can
probably be cleaned up; the listing produced via godbolt.org looks like
this for -O0 in Intel format:
mov DWORD PTR [rbp-4], 0
jmp .L2
.L3:
mov eax, DWORD PTR [rbp-8]
imul eax, DWORD PTR [rbp-12]
mov edx, eax
mov eax, DWORD PTR [rbp-16]
add edx, eax
mov eax, DWORD PTR [rbp-4]
cdqe
mov DWORD PTR [rbp-64+rax*4], edx
mov eax, DWORD PTR [rbp-4]
cdqe
mov eax, DWORD PTR [rbp-64+rax*4]
mov edi, eax
call fn
add DWORD PTR [rbp-4], 1
.L2:
cmp DWORD PTR [rbp-4], 99
jle .L3
mov eax, 0
But it's still not as easy to follow as either of mine.
So, yes, decent tools are important...
>> Or more importantly, how does the debugger do so?
>
> The compiler generates lots of debug information, and the debugger reads
> it. How else would it work?
Have a look at my first example above; would the a[i]=b+c*d be
associated with anything more meaningful than those two lines of assembly?
>> And for source code, what difference should it make whether the
>> generated code is optimised or not?
>>
>
> Because it is not always correct!
>
> Sometimes the issue is on the lines of "Why is this taking so long? I
> had expected less than 0.1µs, but it is taking nearly 0.2µs." You need
> to look at the assembly for that.
That's the kind of thing that the unit tests Ian is always on about
don't really work.
> I don't have a problem with compile speed.
Then just scale up the size of the project; you will hit a point where
it /is/ a problem! Or change the threshold at which any hanging about
becomes incredibly annoying; mine is about half a second.
Just evading the issue by, insteading of getting a tool to work more
quickly, making it try to avoid compiling things as much as possible,
isn't a satisfactory solution IMO.
It's like avoiding spending too long driving your car, due to its only
managing to do 3 mph, by cutting down on your trips as much as possible.
It's a slow car - /that's/ the problem.
> I'd be happy if my car could be upgraded to get twice the petrol
> mileage. But I don't see its petrol usage as a problem - and I
> certainly would not swap it for a moped just because the moped uses much
> less petrol.
There are probably other reasons why deliveries are often done by moped.
Being cheap to run is one, that it's small and nippy and can go anywhere
might be others. You might also be able to afford to have a dozen on the
go at any one time.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-12 12:11 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iq4utmFh2ruU1@mid.individual.net> |
| In reply to | #81184 |
On 12/09/2021 07:56, Bart wrote:
> On 11/09/2021 18:15, David Brown wrote:
>> On 11/09/2021 01:33, Bart wrote:
>>> On 10/09/2021 12:47, David Brown wrote:
>>>> On 10/09/2021 11:10, Juha Nieminen wrote:
>>>
>>>>> 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.
>>>>
>>>> I always compile with debugging information, and I regularly use
>>>> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to
>>>> deal with unoptimised "gcc -O0" code - it is truly awful. You have vast
>>>> amounts of useless extra code that hides the real action. In the
>>>> assembly, the code to load and store variables from the stack, instead
>>>> of registers, often outweighs the actual interesting stuff.
>>>> Single-stepping through your important functions becomes far harder
>>>> because all the little calls that should be inlined out of existence,
>>>> become layers of calls that you might have to dig through. Most of the
>>>> what you are looking for is drowned out in the noise.
>>>
>>> I agree with JN. With optimised code, what you have may have little
>>> relationship with the original source code. If you're trying to trace a
>>> logic problem, how do you map machine code to the corresponding source?
>>>
>>
>> It's a /lot/ easier with -O1 than -O0. Or you use the debugger.
>
> Oh, you mean look at the ASM manually? In that case definitely through
> -O0. If I take this fragment:
>
> for (int i=0; i<100; ++i) {
> a[i]=b+c*d;
> fn(a[i]);
> }
>
<snip listings>
>
> So which one gets the prize?
The one which runs correctly the fastest!
You appear to be stuck in the "C as a high level assembler" mindset.
This shouldn't be true for C and definitely isn't true for C++.
Optimised code often bears little resemblance to the original source and
the same source compiled with the same compiler can be optimised in
different ways depending on the context.
<snip>
> But it's still not as easy to follow as either of mine.
>
> So, yes, decent tools are important...
They are, and decent appears to have different meanings to different
people! From my perspective a decent compiler will correctly compile my
code, provide excellent diagnostics and a high degree of optimisation.
>>> Or more importantly, how does the debugger do so?
>>
>> The compiler generates lots of debug information, and the debugger reads
>> it. How else would it work?
>
> Have a look at my first example above; would the a[i]=b+c*d be
> associated with anything more meaningful than those two lines of assembly?
Does it matter?
>>> And for source code, what difference should it make whether the
>>> generated code is optimised or not?
>>>
>>
>> Because it is not always correct!
>>
>> Sometimes the issue is on the lines of "Why is this taking so long? I
>> had expected less than 0.1µs, but it is taking nearly 0.2µs." You need
>> to look at the assembly for that.
>
> That's the kind of thing that the unit tests Ian is always on about
> don't really work.
Unit tests test logic, not performance. We run automated regression
tests on real hardware to track performance. If there's a change
between builds, it's trivial to identify the code commits that caused
the change.
>> I don't have a problem with compile speed.
>
> Then just scale up the size of the project; you will hit a point where
> it /is/ a problem! Or change the threshold at which any hanging about
> becomes incredibly annoying; mine is about half a second.
Correct, so you scale up the thing you have control over, the build
infrastructure. It's safe to say that no one here has their own C++
compiler the can tweak to go faster! Even with your tools, you have to
sacrifice diagnostics and optimisations for speed.
> Just evading the issue by, insteading of getting a tool to work more
> quickly, making it try to avoid compiling things as much as possible,
> isn't a satisfactory solution IMO.
A build system is more than just a compiler, there are plenty of other
tools you can deploy to speed up builds.
> It's like avoiding spending too long driving your car, due to its only
> managing to do 3 mph, by cutting down on your trips as much as possible.
> It's a slow car - /that's/ the problem.
Poor analogy. A better one is your car is slow because it only has a
single cylinder engine, so you can make it faster with a bigger cylinder
or more of them!
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-12 11:53 +0200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shkim6$n29$1@dont-email.me> |
| In reply to | #81187 |
On 12/09/2021 02:11, Ian Collins wrote: > On 12/09/2021 07:56, Bart wrote: >> So which one gets the prize? > > The one which runs correctly the fastest! > > You appear to be stuck in the "C as a high level assembler" mindset. > This shouldn't be true for C and definitely isn't true for C++. > > Optimised code often bears little resemblance to the original source and > the same source compiled with the same compiler can be optimised in > different ways depending on the context. > With modern C++, generated code - optimised or unoptimised - regularly bears no resemblance to the original code. Use a few templates and lambdas, and the source code structure is guaranteed to be very different from the object code structure. But I suspect that Bart disapproves of templates and lambdas. But sometimes I find it useful to look at, debug or otherwise work with the generated assembly - and for that, for me, -O1 or -O2 is better than -O0 because there is so much less noise.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-12 11:17 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shkk3o$hp$1@dont-email.me> |
| In reply to | #81187 |
On 12/09/2021 01:11, Ian Collins wrote:
> On 12/09/2021 07:56, Bart wrote:
>> On 11/09/2021 18:15, David Brown wrote:
>>> On 11/09/2021 01:33, Bart wrote:
>>>> On 10/09/2021 12:47, David Brown wrote:
>>>>> On 10/09/2021 11:10, Juha Nieminen wrote:
>>>>
>>>>>> 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.
>>>>>
>>>>> I always compile with debugging information, and I regularly use
>>>>> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to
>>>>> deal with unoptimised "gcc -O0" code - it is truly awful. You have
>>>>> vast
>>>>> amounts of useless extra code that hides the real action. In the
>>>>> assembly, the code to load and store variables from the stack, instead
>>>>> of registers, often outweighs the actual interesting stuff.
>>>>> Single-stepping through your important functions becomes far harder
>>>>> because all the little calls that should be inlined out of existence,
>>>>> become layers of calls that you might have to dig through. Most of
>>>>> the
>>>>> what you are looking for is drowned out in the noise.
>>>>
>>>> I agree with JN. With optimised code, what you have may have little
>>>> relationship with the original source code. If you're trying to trace a
>>>> logic problem, how do you map machine code to the corresponding source?
>>>>
>>>
>>> It's a /lot/ easier with -O1 than -O0. Or you use the debugger.
>>
>> Oh, you mean look at the ASM manually? In that case definitely through
>> -O0. If I take this fragment:
>>
>> for (int i=0; i<100; ++i) {
>> a[i]=b+c*d;
>> fn(a[i]);
>> }
>>
> <snip listings>
>>
>> So which one gets the prize?
>
> The one which runs correctly the fastest!
Let's say none of them run correctly and your job is to find out why. Or
maybe you're comparing two compilers at the same optimisation level, and
you want to find why one runs correctly and the other doesn't.
Or maybe this is part of a benchmark where writing to a[i] is part of
the test, but it's hard to gauge where one lot of generated code is
better than another, because the other has disappeared completely!
(I suppose in your world, a set of benchmark results where every one
runs in 0.0 seconds is perfection! I would say those are terrible
benchmarks.)
>> Have a look at my first example above; would the a[i]=b+c*d be
>> associated with anything more meaningful than those two lines of
>> assembly?
>
> Does it matter?
Ask why you're looking at the ASM in the first place. If there's no
discernible correspondence with your source, then you might as well look
at any random bit of ASM code; it would be just as useful!
>>>> And for source code, what difference should it make whether the
>>>> generated code is optimised or not?
>>>>
>>>
>>> Because it is not always correct!
>>>
>>> Sometimes the issue is on the lines of "Why is this taking so long? I
>>> had expected less than 0.1µs, but it is taking nearly 0.2µs." You need
>>> to look at the assembly for that.
>>
>> That's the kind of thing that the unit tests Ian is always on about
>> don't really work.
>
> Unit tests test logic, not performance. We run automated regression
> tests on real hardware to track performance. If there's a change
> between builds, it's trivial to identify the code commits that caused
> the change.
Most of the stuff I do is not helped with unit tests.
Where there are things that possibly be tested by ticking off entries in
a list, you find the real problems come up with combinations or contexts
you haven't anticipated and that can't be enumerated.
>>> I don't have a problem with compile speed.
>>
>> Then just scale up the size of the project; you will hit a point where
>> it /is/ a problem! Or change the threshold at which any hanging about
>> becomes incredibly annoying; mine is about half a second.
>
> Correct, so you scale up the thing you have control over, the build
> infrastructure. It's safe to say that no one here has their own C++
> compiler the can tweak to go faster!
There are lots of C compilers around that are faster than ones like gcc,
clang and msvc. Tiny C is an extreme example.
I guess there are not so many independent compilers for C++ written by
individuals, which tend to be the faster ones.
I don't have the skills, knowledge and inclination to have a go at C++,
but I just get the feeling that such a streamlined product ought to be
possible.
After all, most functionality of C++ is implemented in user-code (isn't
it?), so the core language must be quite small?
>> It's like avoiding spending too long driving your car, due to its only
>> managing to do 3 mph, by cutting down on your trips as much as possible.
>> It's a slow car - /that's/ the problem.
>
> Poor analogy. A better one is your car is slow because it only has a
> single cylinder engine, so you can make it faster with a bigger cylinder
> or more of them!
OK, let's say it's slow around town because your car is a 40-ton truck,
and you need to file the equivalent of a flight-plan with the
authorities before any trip.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-13 12:51 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iq7lkaFh2ruU3@mid.individual.net> |
| In reply to | #81204 |
On 12/09/2021 22:17, Bart wrote:
> On 12/09/2021 01:11, Ian Collins wrote:
>> On 12/09/2021 07:56, Bart wrote:
>>> On 11/09/2021 18:15, David Brown wrote:
>>>> On 11/09/2021 01:33, Bart wrote:
>>>>> On 10/09/2021 12:47, David Brown wrote:
>>>>>> On 10/09/2021 11:10, Juha Nieminen wrote:
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> I always compile with debugging information, and I regularly use
>>>>>> breakpoints, stepping, assembly-level debug, etc. I /hate/ having to
>>>>>> deal with unoptimised "gcc -O0" code - it is truly awful. You have
>>>>>> vast
>>>>>> amounts of useless extra code that hides the real action. In the
>>>>>> assembly, the code to load and store variables from the stack, instead
>>>>>> of registers, often outweighs the actual interesting stuff.
>>>>>> Single-stepping through your important functions becomes far harder
>>>>>> because all the little calls that should be inlined out of existence,
>>>>>> become layers of calls that you might have to dig through. Most of
>>>>>> the
>>>>>> what you are looking for is drowned out in the noise.
>>>>>
>>>>> I agree with JN. With optimised code, what you have may have little
>>>>> relationship with the original source code. If you're trying to trace a
>>>>> logic problem, how do you map machine code to the corresponding source?
>>>>>
>>>>
>>>> It's a /lot/ easier with -O1 than -O0. Or you use the debugger.
>>>
>>> Oh, you mean look at the ASM manually? In that case definitely through
>>> -O0. If I take this fragment:
>>>
>>> for (int i=0; i<100; ++i) {
>>> a[i]=b+c*d;
>>> fn(a[i]);
>>> }
>>>
>> <snip listings>
>>>
>>> So which one gets the prize?
>>
>> The one which runs correctly the fastest!
>
> Let's say none of them run correctly and your job is to find out why. Or
> maybe you're comparing two compilers at the same optimisation level, and
> you want to find why one runs correctly and the other doesn't.
In that rare event, unit tests pass, target behavior is in correct,
study whatever assembly is generated. This will be optimised code,
which is often fun to read...
> Or maybe this is part of a benchmark where writing to a[i] is part of
> the test, but it's hard to gauge where one lot of generated code is
> better than another, because the other has disappeared completely!
>
> (I suppose in your world, a set of benchmark results where every one
> runs in 0.0 seconds is perfection! I would say those are terrible
> benchmarks.)
Where did you get the strange idea from? Benchmarks measure
performance, a step change in the results is worth checking out (and we
often do).
>>> Have a look at my first example above; would the a[i]=b+c*d be
>>> associated with anything more meaningful than those two lines of
>>> assembly?
>>
>> Does it matter?
>
> Ask why you're looking at the ASM in the first place. If there's no
> discernible correspondence with your source, then you might as well look
> at any random bit of ASM code; it would be just as useful!
If your target code is, by necessity, optimised then you don't have a
choice.
>>>>> And for source code, what difference should it make whether the
>>>>> generated code is optimised or not?
>>>>>
>>>>
>>>> Because it is not always correct!
>>>>
>>>> Sometimes the issue is on the lines of "Why is this taking so long? I
>>>> had expected less than 0.1µs, but it is taking nearly 0.2µs." You need
>>>> to look at the assembly for that.
>>>
>>> That's the kind of thing that the unit tests Ian is always on about
>>> don't really work.
>>
>> Unit tests test logic, not performance. We run automated regression
>> tests on real hardware to track performance. If there's a change
>> between builds, it's trivial to identify the code commits that caused
>> the change.
>
> Most of the stuff I do is not helped with unit tests.
So it doesn't have any functions that can be tested? That's a new on
one me!
> Where tshere are things that possibly be tested by ticking off entries in
> a list, you find the real problems come up with combinations or contexts
> you haven't anticipated and that can't be enumerated.
If you find a problem, add a test fro it to prove that you have fixed it
and to make sure it does not recur.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-13 11:03 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shn7n4$ej5$1@dont-email.me> |
| In reply to | #81228 |
On 13/09/2021 01:51, Ian Collins wrote: > On 12/09/2021 22:17, Bart wrote: >> Most of the stuff I do is not helped with unit tests. > > So it doesn't have any functions that can be tested? That's a new on > one me! > You mean some tiny leaf function that has a well-defined task with a known range of inputs? That would be in the minority. The problems I have to deal with are several levels above that and involve the bigger picture. A flaw in an approach might be discovered that means changes to global data structures and new or rewritten functions. Also, if you're developing languages then you might have multiple sets of source code where the problem might lie. One extreme example a few years back, involved six distinct sets of source! (Sources of my systems language; revised sources I was testing; sources of my C compiler that I was testing the revised compiler on; the sources of Seed7 I was testing that rebuilt C compiler on; a test program Bas7.sd7 (a Basic interpreter) that I ran rebuilt Seed7 on; and a test program test.bas to try out.) Maybe unit tests could have applied to one of those sources, such as that C compiler, which might have inherent bugs exposed by the revised implementation language. But how effective are those in such a product? gcc has been going since 1987; there are still active bugs! >> Where tshere are things that possibly be tested by ticking off entries in >> a list, you find the real problems come up with combinations or contexts >> you haven't anticipated and that can't be enumerated. > > If you find a problem, add a test fro it to prove that you have fixed it > and to make sure it does not recur. My 'unit tests' for language products consist of running non-trivial applications to see if they still work. Or running multiple generations of a compiler. So while I know that my C compiler bcc.exe can build Tiny C into tcc.exe and the result can build a range of C programs, if I take that tcc.exe and build Tiny C with it, that new tcc2.exe doesn't work (error in the generated binaries). So where do you start with that? (The problem is still there. I don't have 100% confidence in bcc's code generator; so I will replace it at some point with a new one, and try again.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-14 12:05 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iqa7b4Fh2ruU6@mid.individual.net> |
| In reply to | #81242 |
On 13/09/2021 22:03, Bart wrote: > On 13/09/2021 01:51, Ian Collins wrote: >> On 12/09/2021 22:17, Bart wrote: > >>> Most of the stuff I do is not helped with unit tests. >> >> So it doesn't have any functions that can be tested? That's a new on >> one me! >> > You mean some tiny leaf function that has a well-defined task with a > known range of inputs? That would be in the minority. Doesn't every bit of well designed code have functions, leaf or otherwise, with well defined tasks? > The problems I have to deal with are several levels above that and > involve the bigger picture. A flaw in an approach might be discovered > that means changes to global data structures and new or rewritten functions. > > Also, if you're developing languages then you might have multiple sets > of source code where the problem might lie. So just use those for higher level testing. <snip> > Maybe unit tests could have applied to one of those sources, such as > that C compiler, which might have inherent bugs exposed by the revised > implementation language. Unit tests apply to small "units" of code, such as classes or functions, not whole products. >>> Where tshere are things that possibly be tested by ticking off entries in >>> a list, you find the real problems come up with combinations or contexts >>> you haven't anticipated and that can't be enumerated. >> >> If you find a problem, add a test fro it to prove that you have fixed it >> and to make sure it does not recur. > > My 'unit tests' for language products consist of running non-trivial > applications to see if they still work. Those aren't by any definition unit tests. They are what would normally be know as acceptance tests. > Or running multiple generations of a compiler. > > So while I know that my C compiler bcc.exe can build Tiny C into tcc.exe > and the result can build a range of C programs, if I take that tcc.exe > and build Tiny C with it, that new tcc2.exe doesn't work (error in the > generated binaries). > > So where do you start with that? By testing the logic in your code? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-14 10:28 +0100 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shpq08$6hp$1@dont-email.me> |
| In reply to | #81258 |
On 14/09/2021 01:05, Ian Collins wrote: > On 13/09/2021 22:03, Bart wrote: >> So while I know that my C compiler bcc.exe can build Tiny C into tcc.exe >> and the result can build a range of C programs, if I take that tcc.exe >> and build Tiny C with it, that new tcc2.exe doesn't work (error in the >> generated binaries). >> >> So where do you start with that? > > By testing the logic in your code? Which bit of logic out of 10s of 1000s of lines? The actual bug might be in bcc, or maybe in mm.exe which generated the code of bcc.exe, or it might be a latent bug in tcc.exe (or maybe yet another quirk of C which I wasn't aware of), and I'm not going to start delving into /its/ 25K lines of C code, because the next program might have 250K lines or 2.5M. I get the impression from you that, with a product like a compiler, if it passes all its unit tests, then it is unnecessary to test it further with any actual applications! Just ship it immediately. In actuality, you will see new bugs you didn't anticipate. The bug may only manifest itself in a second or subsequent generation. Or the application built with your compiler may only go wrong with certain inputs.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-15 08:17 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iqceakFh2ruU7@mid.individual.net> |
| In reply to | #81262 |
On 14/09/2021 21:28, Bart wrote: > On 14/09/2021 01:05, Ian Collins wrote: >> On 13/09/2021 22:03, Bart wrote: > >>> So while I know that my C compiler bcc.exe can build Tiny C into tcc.exe >>> and the result can build a range of C programs, if I take that tcc.exe >>> and build Tiny C with it, that new tcc2.exe doesn't work (error in the >>> generated binaries). >>> >>> So where do you start with that? >> >> By testing the logic in your code? > > Which bit of logic out of 10s of 1000s of lines? If you've never had tests, adding a full set after the fact will be too painful. What you can do is add tests for code you are about to change in order to enure you understand what the code currently does and that your change hasn't broken anything. <snip> > I get the impression from you that, with a product like a compiler, if > it passes all its unit tests, then it is unnecessary to test it further > with any actual applications! Just ship it immediately. Where did you get that strange idea? Not from me. There should always be layers of testing. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-09-12 09:10 +0000 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <shkg5g$3cc$1@gioia.aioe.org> |
| In reply to | #81140 |
David Brown <david.brown@hesbynett.no> wrote: > I always compile with debugging information, and I regularly use > breakpoints, stepping, assembly-level debug, etc. I /hate/ having to > deal with unoptimised "gcc -O0" code - it is truly awful. You have vast > amounts of useless extra code that hides the real action. In the > assembly, the code to load and store variables from the stack, instead > of registers, often outweighs the actual interesting stuff. > Single-stepping through your important functions becomes far harder > because all the little calls that should be inlined out of existence, > become layers of calls that you might have to dig through. Most of the > what you are looking for is drowned out in the noise. Most interactive debuggers support stepping into a function call, or stepping over it (ie. call the function but don't break there and just wait for it to return). >> 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. > > That was true 20 years ago, perhaps, with C. Not now, and not with C++. I don't see how it isn't true now. If there's a bug in your code, you need to see and examine every line of code that could be the culprit. If the compiler has done things at compile time and essentially optimized the faulty line of code away (essentially "merging" it with subsequent lines), you'll be drawn to the wrong line of code. The first line of code that exhibits the wrong values may not be the one that's actually creating the wrong values, because that line has been optimized away. (The same applies to optimizing away function calls.) >> 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. > > Don't solve that by using weaker tools. Solve it by improving how you > use the tools That's exactly what I'm doing by doing a fast "g++ -O0" compilation instead of a slow "g++ -O3" compilation. > get better build systems to avoid unnecessary > compilation, use ccache if you have build options or variations that you > swap back and forth, use distcc to spread the load, explain to your boss > why a Ryzen or even a ThreadRipper will save money overall as /your/ > time costs more than the computer's time. "I don't use optimisation > because it is too slow" is an excuse for hobby developers, not > professionals. There's no reason to use optimizations while writing code and testing it. "I don't use optimization because it is too slow" is *perfectly valid*. If it is too slow, and is slowing down your development, it's *good* to make it faster. I doubt your boss will be unhappy with you developing the program in less time. You can compile the final result with optimizations, of course. > It is better to only compile the bits that need to be compiled. Who > cares how long a full build takes? In the example I provided the project consists of two source files and one header file. It's very heavy to compile. Inclusion optimization isn't of much help.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2021-09-12 21:51 +1200 |
| Subject | Re: Examples of current platforms/architectures where sizeof(void*) > |
| Message-ID | <iq60t5Fh2ruU2@mid.individual.net> |
| In reply to | #81192 |
On 12/09/2021 21:10, Juha Nieminen wrote: > > There's no reason to use optimizations while writing code and testing it. There may be many! Unoptimised code being too slow or too big to run on the target is common in real-time or pretend (i.e. Linux) real-time systems. Getting more comprehensive error checking is another. -- Ian.
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web