Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67345 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-08-07 07:13 +0200 |
| Last post | 2019-08-08 17:14 +0200 |
| Articles | 20 on this page of 215 — 20 participants |
Back to article view | Back to comp.lang.c++
Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 07:13 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-06 23:20 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 08:57 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:22 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 09:26 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:33 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 09:52 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 13:37 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:14 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson " <ahh_f_it@crap.nothing> - 2019-08-08 00:00 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson " <ahh_f_it@crap.nothing> - 2019-08-07 23:59 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-08-17 22:13 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:35 -0700
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 14:47 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 16:55 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 15:11 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 17:41 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 15:58 +0000
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:24 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 10:07 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 20:55 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:03 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 23:54 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 08:57 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 22:42 -0700
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 14:46 +0000
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 14:09 -0700
Re: Performance of unaligned memory-accesses Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-07 11:00 +0300
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 10:03 +0200
Re: Performance of unaligned memory-accesses Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-07 11:46 +0300
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 11:19 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 13:13 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 13:29 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 14:02 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 14:08 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 15:57 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-07 12:37 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 14:47 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 16:18 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 16:53 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 17:30 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 17:39 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 18:12 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 18:33 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 21:32 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:01 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:48 +0200
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-07 23:02 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 07:43 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 22:54 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:04 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-08 00:16 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 09:58 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-08 01:20 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:47 +0200
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-08 10:29 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:50 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 17:05 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 17:33 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 09:56 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:51 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 17:10 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 17:35 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 17:38 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 21:45 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-08 20:00 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 06:52 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 07:59 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 09:19 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 09:32 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 10:14 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 10:21 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 13:01 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 13:09 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 15:38 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 15:45 +0200
Re: Performance of unaligned memory-accesses Robert Wessel <robertwessel2@yahoo.com> - 2019-08-09 09:37 -0500
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 16:59 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 17:04 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-09 16:43 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 19:18 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-09 23:28 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 08:55 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 17:21 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 17:25 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 23:32 +0200
Re: Performance of unaligned memory-accesses Ian Collins <ian-news@hotmail.com> - 2019-08-11 10:59 +1200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 02:24 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:53 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 17:26 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 19:18 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 23:00 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 23:44 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 23:46 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-12 01:02 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 09:15 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> - 2019-08-11 16:37 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> - 2019-08-11 16:42 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> - 2019-08-11 22:05 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:25 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:24 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:22 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:23 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 17:10 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 17:21 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 17:31 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 23:47 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:40 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:27 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 23:46 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-10 23:22 +0100
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-10 16:11 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:32 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 15:41 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 15:55 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 18:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 18:15 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 18:59 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 19:03 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 23:48 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 00:15 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-12 01:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 09:13 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-12 13:32 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 13:40 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 11:44 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 14:30 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 13:09 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 15:14 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 19:13 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 21:15 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 19:25 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-13 02:28 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-13 01:08 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-13 16:03 +0200
Re: Performance of unaligned memory-accesses Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-14 09:27 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-14 20:51 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-14 13:14 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-14 15:04 -0700
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-14 15:47 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-15 10:15 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 07:11 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-14 23:37 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 09:25 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-15 03:41 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 14:25 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-15 16:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 16:21 +0200
Re: Performance of unaligned memory-accesses Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-15 16:56 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-16 06:44 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-14 16:53 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 18:40 +0200
Re: Performance of unaligned memory-accesses Ralf Goertz <me@myprovider.invalid> - 2019-08-13 08:53 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-13 09:18 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-11 19:00 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 21:06 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-11 13:07 -0700
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-11 23:58 +0100
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-11 17:07 -0700
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-12 10:14 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 11:30 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 13:03 +0200
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-12 13:06 +0100
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-12 10:34 +0100
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-12 08:49 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 18:10 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-12 09:22 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 18:24 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-12 16:38 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-12 09:33 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-11 13:11 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 23:59 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-10 19:31 -0400
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 15:52 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:28 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-10 16:37 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 21:35 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 21:43 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-08 12:51 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:55 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:57 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 16:07 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 18:38 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 17:34 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 20:07 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 20:16 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:42 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 21:19 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 23:40 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-07 19:58 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:08 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 22:13 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-21 20:26 +0000
Re: Performance of unaligned memory-accesses Christopher Collins <ccollins476ad@gmail.com> - 2019-08-07 12:50 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 22:18 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-07 22:52 +0100
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 17:52 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 10:39 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-08 13:48 +0100
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 15:53 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 17:27 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 10:43 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-08 13:33 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 23:34 +0200
Re: Performance of unaligned memory-accesses Christopher Collins <ccollins476ad@gmail.com> - 2019-08-07 17:28 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 09:30 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 14:20 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 17:27 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 11:39 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-07 19:48 +0000
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 15:51 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 12:51 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-08 14:46 +0000
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 17:14 +0200
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-08-14 15:47 -0700 |
| Message-ID | <db3ca7ac-f134-411a-adbb-c3bd8b2f8db4@googlegroups.com> |
| In reply to | #67658 |
On Thursday, 15 August 2019 01:05:03 UTC+3, Keith Thompson wrote: > Öö Tiib <ootiib@hot.ee> writes: > > On Wednesday, 14 August 2019 21:51:32 UTC+3, Bonita Montero wrote: > >> >> As I said that's not undefined behaviour because the compiler would > >> >> be unable to generate the code as expected but because the CPU might > >> >> fail / trap an unaligned access at runtime and the OS might emulate > >> >> tzhe unaligned access or not. So it depends on the platform you > >> >> target. > >> > >> > If a given operation has undefined behavior, it doesn't stop > >> > having undefined behavior just because it happens to do what > >> > you want it to. > >> > >> In theory, but in practice it has an expectable behaviour depending > >> on the platform. > > > > So it may change because of change of compiler, its version, compiling > > options, device that it is ran on, settings of operating system or > > other (possibly unrelated) code in same code-base. > > Program that happens to do something in narrow conditions but not in > > others is unreliable and unreliability is the most disliked property > > of software. > > It's important to remember what "undefined behavior" means. It's not > "this program will blow up". It is simply > > behavior for which this document imposes no requirements > > where "this document" is the C++ standard. If something other than > the standard imposes requirements, it's still undefined behavior. > > If you want to talk about unexpected or undesirable behavior, > call it that. That's not what "undefined behavior" means. You are correct but it was not about behavior documented somewhere else. It was about unaligned access. For example in lot of context on MS Windows it works but not in all. I have experienced that if to call some API functions with wrongly aligned pointers then it may work incorrectly, oddly or even to crash exactly because of those pointers being wrongly aligned. And I'd like to see from where to get the people who can tell what functions of what APIs are such and where it is defined and documented.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-15 10:15 +0200 |
| Message-ID | <qj34ac$4m0$1@dont-email.me> |
| In reply to | #67658 |
On 15/08/2019 00:04, Keith Thompson wrote: > Öö Tiib <ootiib@hot.ee> writes: >> On Wednesday, 14 August 2019 21:51:32 UTC+3, Bonita Montero wrote: >>>>> As I said that's not undefined behaviour because the compiler would >>>>> be unable to generate the code as expected but because the CPU might >>>>> fail / trap an unaligned access at runtime and the OS might emulate >>>>> tzhe unaligned access or not. So it depends on the platform you >>>>> target. >>> >>>> If a given operation has undefined behavior, it doesn't stop >>>> having undefined behavior just because it happens to do what >>>> you want it to. >>> >>> In theory, but in practice it has an expectable behaviour depending >>> on the platform. >> >> So it may change because of change of compiler, its version, compiling >> options, device that it is ran on, settings of operating system or >> other (possibly unrelated) code in same code-base. >> Program that happens to do something in narrow conditions but not in >> others is unreliable and unreliability is the most disliked property >> of software. > > It's important to remember what "undefined behavior" means. It's not > "this program will blow up". It is simply > > behavior for which this document imposes no requirements > > where "this document" is the C++ standard. If something other than > the standard imposes requirements, it's still undefined behavior. > True. But in this case, nothing else imposes requirements or definitions either, leaving the behaviour undefined. Neither Bonita nor anyone else has given any references, pointers to documentation or manuals, or other indications that their C or C++ compiler supports unaligned accesses via normal pointers. So this /is/ undefined behaviour - nothing has defined the behaviour in question. But that does not imply that there is unexpected or undesirable behaviour - it seems that in all testing that has been done, compilers treated the unaligned accesses as though they /were/ defined, in the expected way, and that is what Bonita desires. > If you want to talk about unexpected or undesirable behavior, > call it that. That's not what "undefined behavior" means. > That distinction is important. However, the behaviour here is undefined, but it is not unexpected and not (to Bonita) undesirable. Let me try to summarise what we know about unaligned accesses, and I think you will see what I mean. At the hardware level, we know: 1. Many cpus support unaligned accesses (though perhaps with limitations, such as slower access or lacking features like locks or atomic guarantees). Examples include x86 and Arm-64. 2. Many cpus trap on unaligned accesses. Examples include SPARC, Arm-32. 3. Some cpus have silent corruption on unaligned accesses, such as the MSP430. 4. For some cpu families, there are members that support unaligned accesses, and members that trap, despite having broadly compatible binary code. That includes the 68K family. At the OS level, we know: 1. Some OS's have trap handlers that emulate the unaligned access for processors that don't support it in hardware. That includes at least some versions of Solaris for SPARC, and some (but not all) 32-bit ARM Linux systems. 2. Other OS's don't have such handlers. At the language standards level, we know: 1. The C standards clearly state that creating unaligned pointers is undefined behaviour in most cases. (It may be possible, using something like memcpy.) Dereferencing unaligned pointers is explicitly undefined behaviour. 2. The C++ standards are not as clear to me (due to lack of familiarity), but I believe using unaligned pointers is also undefined in C++. 3. In C and C++, the actual alignments are implementation dependent, and are not required to be the same as the sizes of the types or the "natural" alignment preferred by the hardware. 4. The standards rarely say something is "not allowed", but explicitly stating that something is "undefined behaviour" is usually interpreted as a strong suggestion to avoid the behaviour in portable code, and to avoid it in non-portable code unless the compiler explicitly defines the behaviour. For safe and reliable coding standards, this is often an rule rather than a suggestion. At the compiler level, we know: 1. You can always access unaligned data by char, or by using memcpy. Many compilers will turn common patterns into optimal instructions for the target, while the source code remains safe, portable and fully defined on all toolchains and targets. 2. Many compilers support extensions that can be used to safely and reliably access unaligned data in convenient ways, such as "packed" structs or MSVC's "__unaligned" keyword. These methods are documented, and will work correctly even on targets that don't support unaligned access in hardware. 3. Compilers try to minimise surprises, unexpected code generation, and behaviour changes for code that "worked with an older version". 4. Compilers try to maximise efficiency of correct code. This is sometimes in conflict with point 3. 5. Compilers optimise on the assumption that certain types of undefined behaviour do not occur (or at least, the programmer doesn't care what happens if it does occur). This applies to /all/ compilers. But some compilers are more aggressive about this than others. 6. No tests have yet shown a compiler optimising on the assumption that pointers are aligned (for targets that support unaligned accesses). That may be luck, limitations of tests, or limitations of optimisations. It may also be intentional but undocumented behaviour for the compiler. 7. No references have been found for any compiler that explicitly documents supporting unaligned accesses (other than via specific extensions). 8. Compilers are often poor at issuing warnings or errors about undefined behaviour or potentially undefined behaviour, such as making or using unaligned pointers. 9. Future directions of compiler technology, including link-time optimisations and pointer provenance tracking, make it a serious risk that compilers /will/ optimise code on the assumption that pointers are valid (including being aligned). Hopefully, this will also improve their ability to warn about potential problems. So we know that general unaligned accesses usually appear to work as expected and as desired (by those that use them). But we know that this is not documented or defined anywhere, not guaranteed, and certainly not portable to all types of processor. We know it is often considered bad, or at least risky, programming practice from general rule of "don't rely on undefined behaviour". We know that despite working now, it might fail in the future. We know that some programmers are quite happy with "it worked when I tried it" coding, without concern for guarantees or documentation of behaviour. To me, using unaligned pointers is therefore a fine example of undefined behaviour, and Bonita's blasé attitude is an example of what is often wrong in the programming world.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-15 07:11 +0200 |
| Message-ID | <qj2pie$jd2$1@news.albasani.net> |
| In reply to | #67657 |
> So it may change because of change of compiler, its version, compiling > options, device that it is ran on, settings of operating system or > other (possibly unrelated) code in same code-base. There's no reason why a compiler might get incorrect code because of this. It's undefined behaviour only because of the runtime-behaivour of the CPU / OS.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-08-14 23:37 -0700 |
| Message-ID | <fc779880-3fc5-4570-a231-280079a936a9@googlegroups.com> |
| In reply to | #67664 |
On Thursday, 15 August 2019 08:11:52 UTC+3, Bonita Montero wrote: > > So it may change because of change of compiler, its version, compiling > > options, device that it is ran on, settings of operating system or > > other (possibly unrelated) code in same code-base. > > There's no reason why a compiler might get incorrect code because of > this. It's undefined behaviour only because of the runtime-behaivour > of the CPU / OS. It is all interrelated. Compiler translates by its settings and uses CPU operations and OS calls that those settings allow. It is not changing its settings because you used #pragma pack(1) in some other, potentially unrelated translation unit and certainly it can't recompile OS because of that.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-15 09:25 +0200 |
| Message-ID | <qj31di$i72$1@news.albasani.net> |
| In reply to | #67665 |
No, that's stupid. It simply depends on the CPU / OS at runtime. And not on the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-08-15 03:41 -0700 |
| Message-ID | <731ce70c-8702-4eed-b8dd-4a8f70ee3df4@googlegroups.com> |
| In reply to | #67666 |
On Thursday, 15 August 2019 10:25:49 UTC+3, Bonita Montero wrote: > No, that's stupid. It simply depends on the CPU / OS at runtime. > And not on the compiler. Hundreds of millions of programmers have expressed opinions that what C or C++ compilers actually do or have started to do or have stopped doing is stupid. Yet the only things that matter in such disputes are specifications. Without cites and quotes of specifications (or improvement requests of such) their opinions have remained hollow, muffled and meaningless. All the decades. Why you differ?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-15 14:25 +0200 |
| Message-ID | <qj3j04$deh$1@news.albasani.net> |
| In reply to | #67668 |
> Yet the only things that matter in such disputes are specifications. No, the things that matters are the compiler you target. And pointers are internally numbers on all processors; they aren't technicall dis- tinguishable. So the compiler usally even can't see that it is compi- ling an unaligned access. And theres no logical reason that a compiler might not do this. The reason why this might not run only depends on the CPU and / or OS at runtime.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-15 16:06 +0200 |
| Message-ID | <qj3osq$gq2$1@dont-email.me> |
| In reply to | #67669 |
On 15/08/2019 14:25, Bonita Montero wrote:
>> Yet the only things that matter in such disputes are specifications.
>
> No, the things that matters are the compiler you target.
Is your code only ever compiled with one version of one compiler, with
one set of options, one set of libraries (static and dynamic), for one
processor and one host (a single specific version and set of libraries),
and with one set of source code that does not change?
Sometimes that is appropriate. I have written code like that, where it
was acceptable to depend on certain behaviour which was confirmed by
examining the generated assembly, and where /everything/ involved in
code generation was tied down so tightly that "it gives the code I want
when I tried it" is actually good enough.
I severely doubt the same thing applies to the code /you/ write - it
very rarely does, outside of constrained embedded systems.
For anyone else, what matters is that the toolchain documents the
behaviour for the code you write. It doesn't matter if the
documentation is in the C or C++ specifications, the host system's ABI,
the compiler manual, or any other appropriate documents.
Use of normal pointers with unaligned values is not documented anywhere
- ergo, it is undefined behaviour. And that /does/ matter. At least,
it matters to people who care about quality in their code and their
development practices.
> And pointers
> are internally numbers on all processors;
Really? You know this for a fact? On /all/ processors? You don't
imagine that on some processors, pointers combine addresses with valid
ranges, or security features, or access control, or bits controlling
caching or buffering features? Many of these only found on obscure
systems. You would not be extrapolating from your knowledge of Windows
and the x86 world and making assumptions about every processor or every
system again?
I have personally used at least four compilers and processors where
pointers are not merely a "number" - where you can't, for example,
assume that you can find the distance between unrelated objects by
simply subtracting the pointers.
> they aren't technicall distinguishable.
You do know that the compiler can implement pointers in all sorts of
ways, in certain circumstances? And it can do odd things with them, or
assume things that it cannot when dealing with simple numbers?
void inc(int *p) {
(*p)++;
}
int addtwo(int x) {
inc(&x);
inc(&x);
return x;
}
gcc compiles "addtwo" as though it were just:
int addtwo(int x) {
return x + 2;
}
The "just number" pointers have disappeared entirely.
Depending on the circumstances, the compiler can often know that two
pointers cannot possibly be equal even though it does not know their
values (such as when they are different types).
At the cpu level, on many processors, a pointer is just a number. But C
and C++ are not assembly.
> So the compiler usally even can't see that it is compi-
> ling an unaligned access. And theres no logical reason that a compiler
> might not do this. The reason why this might not run only depends on
> the CPU and / or OS at runtime.
If the compiler doesn't know anything about a pointer, it will use it
blindly - since using an invalid pointer would be undefined behaviour,
it can assume the pointer is valid and can be used directly. But it can
still make assumptions about it.
int foo(int * p) {
*p = 1;
return (p == 0);
}
gcc compiles that to:
foo(int*):
movl $1, (%rdi)
xorl %eax, %eax
ret
Note that the compiler assumes "p" is not zero. The pointer is not just
treated as a number.
And if you write:
int bar(int * p) {
*p = 1;
return ((uintptr_t) p) & 0x03;
}
the compiler /could/ implement that as:
bar(int*):
movl $1, (%rdi)
xorl %eax, %eax
ret
No compiler I tested does that, but compilers are allowed to do so.
Unless, of course, they document their behaviour with unaligned pointers
- which no compiler (that I have seen) does.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-15 16:21 +0200 |
| Message-ID | <qj3pom$2lp$1@news.albasani.net> |
| In reply to | #67670 |
> Is your code only ever compiled with one version of one compiler, with > one set of options, one set of libraries (static and dynamic), for one > processor and one host (a single specific version and set of libraries), > and with one set of source code that does not change? Thats plainly idiotic! No compiler will prevent unaligned acccesses. That's a pure runtime-issuel.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-08-15 16:56 -0700 |
| Message-ID | <86o90qc7a2.fsf@mailhub.linuxsc.com> |
| In reply to | #67664 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> So it may change because of change of compiler, its version, compiling >> options, device that it is ran on, settings of operating system or >> other (possibly unrelated) code in same code-base. > > There's no reason why a compiler might get incorrect code because of > this. It's undefined behaviour only because of the runtime-behaivour > of the CPU / OS. If you think that then you don't understand how the C and C++ standards define the term "undefined behavior".
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-16 06:44 +0200 |
| Message-ID | <qj5cb8$ofl$1@news.albasani.net> |
| In reply to | #67672 |
>> There's no reason why a compiler might get incorrect code because of >> this. It's undefined behaviour only because of the runtime-behaivour >> of the CPU / OS. > If you think that then you don't understand how the C and > C++ standards define the term "undefined behavior". I'm more precise about that.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-08-14 16:53 -0700 |
| Message-ID | <1400d49d-9085-4f3c-a2a8-92e5b574eca8@googlegroups.com> |
| In reply to | #67656 |
On Wednesday, August 14, 2019 at 2:51:32 PM UTC-4, Bonita Montero wrote: [attributions stripped by Bonita] > > If a given operation has undefined behavior, it doesn't stop > > having undefined behavior just because it happens to do what > > you want it to. > > In theory, but in practice it has an expectable behaviour depending > on the platform. Undefined behavior includes, as one possibility "expectable behavior depending upon the platform", so that fact does not, in any way, conflict with his statement.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 18:40 +0200 |
| Message-ID | <qipgem$7fd$1@news.albasani.net> |
| In reply to | #67561 |
I don't even get a warning compiling that code with MSVC and gcc.
#pragma pack(1)
struct S
{
char c;
int i;
};
void fInc( int *p )
{
++(*p);
}
void f()
{
S s;
int i;
int *p;
p = &s.i;
fInc( p );
p = &i;
fInc( p );
}
[toc] | [prev] | [next] | [standalone]
| From | Ralf Goertz <me@myprovider.invalid> |
|---|---|
| Date | 2019-08-13 08:53 +0200 |
| Message-ID | <qitmq4$afd$1@dont-email.me> |
| In reply to | #67563 |
Am Sun, 11 Aug 2019 18:40:55 +0200
schrieb Bonita Montero <Bonita.Montero@gmail.com>:
> I don't even get a warning compiling that code with MSVC and gcc.
>
> #pragma pack(1)
>
> struct S
> {
> char c;
> int i;
> };
>
> void fInc( int *p )
> {
> ++(*p);
> }
>
> void f()
> {
> S s;
> int i;
> int *p;
> p = &s.i;
> fInc( p );
> p = &i;
> fInc( p );
> }
After changing S to
struct S
{
char c;
int i;
} __attribute__((packed));
I get
gcc -c packed.cc -o packed
packed.cc: In function ‘void f()’:
packed.cc:17:10: warning: taking address of packed member of ‘S’ may
result in an unaligned pointer value [-Waddress-of-packed-member] 17 |
p = &s.i; | ^~~~
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-13 09:18 +0200 |
| Message-ID | <qito84$esh$1@news.albasani.net> |
| In reply to | #67612 |
> gcc -c packed.cc -o packed > packed.cc: In function ‘void f()’: > packed.cc:17:10: warning: taking address of packed member of ‘S’ may > result in an unaligned pointer value [-Waddress-of-packed-member] 17 | > p = &s.i; | ^~~~ Ok, I have an older gcc-version on my WSL. But that's just a warning and I think it's there because for comatibility- and performance-reasons. But as I said a compiler will generate correct code. If it runs at last simply depends on the CPU / operating-system.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-11 19:00 +0100 |
| Message-ID | <dJY3F.202577$_L3.170636@fx35.am4> |
| In reply to | #67559 |
On 11/08/2019 14:55, Bonita Montero wrote: >> With that alignment decision made, the C standard explicitly says >> that conversions to pointers that result in them being unaligned, >> are undefined behaviour - ... > > Hey, are you still that stupid? We were talking about implementations > with specific support for #pragma pack! On these implementations it > is perfectly legal to take an adress of an unaligned member and such > pointers are indistinguishable from any other unaligned pointer. So > an implemtation that has support for #pragma pack must generally > support unaligned accesses. On one simple C compiler I use (actually, my own) '#pragma pack(1)' simply disables the padding that would otherwise be inserted to ensure proper alignment. It doesn't consider the legality of such accesses, although the whole compiler does assume the target is byte-addressable (offsets of struct members are byte-offsets from the start).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 21:06 +0200 |
| Message-ID | <qipovs$g16$1@news.albasani.net> |
| In reply to | #67567 |
> On one simple C compiler I use (actually, my own) '#pragma pack(1)' > simply disables the padding that would otherwise be inserted to ensure > proper alignment. > It doesn't consider the legality of such accesses, although the whole > compiler does assume the target is byte-addressable (offsets of struct > members are byte-offsets from the start). But if the compiler does support #pragma pack it does generate code that the developer intended. If the code really runs depends on the CPU and if the CPU doesn't support unaligned acesses, it depends on the OS to emulate the access through trapping. The Oracle C++ compiler has support for pragma pack and unaligned accesses. With this compiler you have three choices: 1. Unaligned accesses are emulated through emulating a load by assem- bling the bytes in memory to the larger data type. But that means every access is assembled / disassembled in that way because the compiler can't distinguish all unaligned and aligned acceses. That feature could be of course implemented on a per-translationunit basis. 2. Unaligned accesses are just compiled like other accesses and the compiler is instructed to let the OS emulate this accesses by trapping I guess that's not really a compiler-feaute, i.e. that's not per trans- lation-unit but the compiler does forward this option to the linker which sets this for the whole executable. 3. Unaligned accesses are forced to cause a SIGBUS.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-11 13:07 -0700 |
| Message-ID | <lnimr379eu.fsf@kst-u.example.com> |
| In reply to | #67567 |
Bart <bc@freeuk.com> writes:
[...]
> On one simple C compiler I use (actually, my own) '#pragma pack(1)'
> simply disables the padding that would otherwise be inserted to ensure
> proper alignment.
>
> It doesn't consider the legality of such accesses, although the whole
> compiler does assume the target is byte-addressable (offsets of struct
> members are byte-offsets from the start).
And what happens if a program accesses a misaligned member?
#pragma pack(1)
struct foo {
char c;
int i;
} obj = { 0 };
printf("%d\n", obj.i);
If your compiler targets x86 and/or x86_64, such an access will
probably just work. On other targets, it might blow up -- and if
so, I would seriously question the wisdom of claiming to support
#pragma pack(1).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-11 23:58 +0100 |
| Message-ID | <b514F.554939$YG3.490231@fx16.am4> |
| In reply to | #67569 |
On 11/08/2019 21:07, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> On one simple C compiler I use (actually, my own) '#pragma pack(1)'
>> simply disables the padding that would otherwise be inserted to ensure
>> proper alignment.
>>
>> It doesn't consider the legality of such accesses, although the whole
>> compiler does assume the target is byte-addressable (offsets of struct
>> members are byte-offsets from the start).
>
> And what happens if a program accesses a misaligned member?
>
> #pragma pack(1)
> struct foo {
> char c;
> int i;
> } obj = { 0 };
> printf("%d\n", obj.i);
>
> If your compiler targets x86 and/or x86_64, such an access will
> probably just work. On other targets, it might blow up -- and if
> so, I would seriously question the wisdom of claiming to support
> #pragma pack(1).
Actually, most of the time when pack(1) is used, elements will be
properly aligned anyway. Because they will be sized and arranged
manually to get the most efficient packing.
When done properly, then I should be able to comment out the pack(1),
and it ought to still work, and with the same sizes of structs, and the
same member offsets.
But pack(1) can also be used to define a particular layout, in instances
where I don't need to access individual misaligned members, just to get
the right overall size.
More difficult is supporting pack(1) when a machine doesn't have
byte-addressability, but I don't know if that is common these days.
(My own compilers target x64. A quick test involving passes over an
array of 100 million of your structs, took 1.33 seconds with normal
alignment to write to and read from the .i element (all unoptimised code).
Using pack(1), that increased to 1.57 seconds. But this included
multiplication by 5 for each access. When I manually optimised that out,
the timing went down to 1.26 seconds; faster then aligned access!
I guess because 37.5% less memory was used, coupled with the x64's
apparently efficient handling of misaligned reads and writes.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-11 17:07 -0700 |
| Message-ID | <lna7cf6ybq.fsf@kst-u.example.com> |
| In reply to | #67579 |
Bart <bc@freeuk.com> writes:
> On 11/08/2019 21:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> On one simple C compiler I use (actually, my own) '#pragma pack(1)'
>>> simply disables the padding that would otherwise be inserted to ensure
>>> proper alignment.
>>>
>>> It doesn't consider the legality of such accesses, although the whole
>>> compiler does assume the target is byte-addressable (offsets of struct
>>> members are byte-offsets from the start).
>>
>> And what happens if a program accesses a misaligned member?
>>
>> #pragma pack(1)
>> struct foo {
>> char c;
>> int i;
>> } obj = { 0 };
>> printf("%d\n", obj.i);
>>
>> If your compiler targets x86 and/or x86_64, such an access will
>> probably just work. On other targets, it might blow up -- and if
>> so, I would seriously question the wisdom of claiming to support
>> #pragma pack(1).
>
> Actually, most of the time when pack(1) is used, elements will be
> properly aligned anyway. Because they will be sized and arranged
> manually to get the most efficient packing.
>
> When done properly, then I should be able to comment out the pack(1),
> and it ought to still work, and with the same sizes of structs, and the
> same member offsets.
Then there's no point in using pack(1), is there? But I asked
specifically about a case where it causes a member to be aligned
differently than it would without the pack(1).
> But pack(1) can also be used to define a particular layout, in instances
> where I don't need to access individual misaligned members, just to get
> the right overall size.
If you have
struct foo { char c; int i; }
(assume int is 4 bytes), and #pragma pack(1) gives the struct a size of
5 bytes, then an array of struct foo will result in misaligned members.
#pragma pack(1)
struct foo { char c; int i; } array[2];
One of array[0].i and array[1].i will be at an odd address.
> More difficult is supporting pack(1) when a machine doesn't have
> byte-addressability, but I don't know if that is common these days.
It depends on what you mean by "byte-addressibility". Almost all
machines can access bytes at arbitrary addresses. The question is
whether they can access words at odd addresses.
> (My own compilers target x64.
[snip]
And since x64 can access words at odd addresses, there's no problem.
If you wanted to target your compiler to systems that don't support
accessing words at odd addresses, you might have a problem.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web