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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 09:56 +0200 |
| Message-ID | <qigkjo$v3k$1@dont-email.me> |
| In reply to | #67404 |
On 07/08/2019 22:48, Bonita Montero wrote:
> Consider this code. It compiles on whether certain platforms support
> unaligned loads with proper code and without vaguely relying on the
> compiler to strip away the assembly of a uint32_t with shifts and
> ORs with a single load / store.
>
I support the principle of using conditional compilation to let you use
known efficient methods on platforms that support it, and fall back to
generic but safe methods elsewhere. That is a good way to handle
getting maximal efficiency on platforms you view as important, while
keeping portability.
Unfortunately, you are completely wrong about where unaligned accesses
are actually supported by the compiler. You have identified some
/targets/ that support unaligned access, but the /compilers/ do not
support it.
Note that this does /not/ mean the compilers will not generate code that
does what you want. The code you write might work fine in testing. You
could look at the assembly, and it looks fine. And then one day you
make a minor change to another part of the code, and suddenly it does
/not/ work as you expect. Or you upgrade your compiler. Or you change
an optimisation flag.
C (C++ follows here) does not allow you to create an unaligned pointer
by conversions - see C11 6.3.2.3p7 "A pointer to an object type may be
converted to a pointer to a different object type. If the resulting
pointer is not correctly aligned 68) for the referenced type, the
behavior is undefined." It does not, except for certain cases, allow
you to take a pointer to one type, convert it to a pointer to a
different type, and use that to access data (6.5p7). It does not allow
you to access data through an unaligned pointer (6.5.3.3p4).
Nothing in the gcc documentation, nor the MSVC documentation I have
read, nor the documentation for any other compiler I have ever used (and
that's a lot, on many embedded systems) gives the impression that the
compilers support unaligned access.
You are living on luck. That is a ridiculous attitude to take, when it
is not difficult to get code that is correct /and/ efficient.
> #include <cstdint>
>
> #ifdef _MSC_VER
> // MSC only works on x86/x64 and ARMv8
> #define SUPPORTS_UNALIGNED
MSVC does not, as far as I can tell, support unaligned accesses on any
platform unless you use the __unaligned keyword.
> #elif(__GNUC__)
> #if defined(__x86_64__) || defined(__i386__)
> #define SUPPORTS_UNALIGNED
gcc does not support unaligned accesses on any platforms.
> #elif defined(__aarch64__)
> #define SUPPORTS_UNALIGNED
Compilers for aarch64 do not support unaligned accesses unless they
specifically document that they do.
> #endif
> #endif
>
> struct unaligned_uint32
> {
> union
> {
> uint8_t ub[sizeof(uint32_t)];
> uint32_t u;
> } uu;
> operator uint32_t();
> unaligned_uint32 &operator = ( uint32_t ui );
> };
>
> inline
> unaligned_uint32::operator uint32_t()
> {
> #if defined(SUPPORTS_UNALIGNED)
> return uu.u;
> #else
> return ((uint32_t)uu.ub[0] | (uint32_t)uu.ub[1] << 8) |
> ((uint32_t)uu.ub[2] << 16 | (uint32_t)uu.ub[3] << 24);
> #endif
> }
>
> inline
> unaligned_uint32 &unaligned_uint32::operator = ( uint32_t ui )
> {
> #if defined(SUPPORTS_UNALIGNED)
> uu.u = ui;
> return *this;
> #else
> uu.ub[0] = (uint8_t)ui;
> uu.ub[1] = (uint8_t)(ui << 8);
> uu.ub[2] = (uint8_t)(ui << 16);
> uu.ub[3] = (uint8_t)(ui << 24);
> return *this;
> #endif
> }
>
That would work (as I said above, the principle of conditional
compilation here is right), except for three things:
1. None of the implementations you test for support unaligned access,
even though the underlying hardware does. So SUPPORTS_UNALIGNED should
not be set for those implementations.
2. There is no legal way in standard C or C++ to create and use an
"unaligned_uint32" object or lvalue that is not correctly aligned.
3. If you are thinking of using casts to get unaligned_uint32 pointers
from char pointers, you fall foul of the type-based pointer aliasing
rules of C - you can't do that unless you originally started with
correctly aligned unaligned_uint32 objects.
Particular compilers, extensions, flags, etc., can of course allow these.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 16:51 +0200 |
| Message-ID | <qihcsq$nmc$3@news.albasani.net> |
| In reply to | #67429 |
> Unfortunately, you are completely wrong about where unaligned accesses > are actually supported by the compiler. You have identified some > /targets/ that support unaligned access, but the /compilers/ do not > support it. The compilers I conditionally select suport it. And the list might be extended.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 17:10 +0200 |
| Message-ID | <qihe1k$55u$1@dont-email.me> |
| In reply to | #67447 |
On 08/08/2019 16:51, Bonita Montero wrote: >> Unfortunately, you are completely wrong about where unaligned accesses >> are actually supported by the compiler. You have identified some >> /targets/ that support unaligned access, but the /compilers/ do not >> support it. > > The compilers I conditionally select suport it. > And the list might be extended. > Show me links to the documentation supporting this claim. I don't mean post examples of it working - I mean /documentation/. Written information, from the compiler writers, saying that this sort of code is valid for their compiler. Until you can do that, you are an example of the cowboy attitude to programming that crashes cars, brings down planes, and innumerable time wasted and frustration caused when programs crash yet again. It's one thing to have bugs in code by mistake, or because the programming task is particularly hard, or because you don't know there is a problem. It is inexcusable to write code that you know is wrong and risky, just because you are too lazy and arrogant to write it safely.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 17:35 +0200 |
| Message-ID | <qihfgf$fp3$2@news.albasani.net> |
| In reply to | #67451 |
> Show me links to the documentation supporting this claim. There needs not to be any documentation on that. The thing is simply that the compiler usually won't see that an access is unaligned in mot times so it can't be incompatible to this. So the whole thing is simply defined by the architecture and not by the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 17:38 +0200 |
| Message-ID | <qihfm6$g0t$1@news.albasani.net> |
| In reply to | #67454 |
And even more: compilers for those CPUs that support unaligned access usually have special #pragma pack() or unaligned-directives. They won't have these if they don't allow unaligned accesses.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 21:45 +0200 |
| Message-ID | <qihu4e$1bv$2@dont-email.me> |
| In reply to | #67455 |
On 08/08/2019 17:38, Bonita Montero wrote: > And even more: compilers for those CPUs that support unaligned access > usually have special #pragma pack() or unaligned-directives. They won't > have these if they don't allow unaligned accesses. Compilers support unaligned accesses when using "pragma pack", "__unaligned", or other such features. Those features are documented to do the job. They exist /precisely/ because unaligned accesses are not allowed without them. The fact that compilers have this kind of extension shows that using normal pointers for unaligned access is not supported!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-08 20:00 +0000 |
| Message-ID | <_b%2F.113867$qC7.38177@fx11.iad> |
| In reply to | #67461 |
David Brown <david.brown@hesbynett.no> writes:
>On 08/08/2019 17:38, Bonita Montero wrote:
>> And even more: compilers for those CPUs that support unaligned access
>> usually have special #pragma pack() or unaligned-directives. They won't
>> have these if they don't allow unaligned accesses.
>
>Compilers support unaligned accesses when using "pragma pack",
>"__unaligned", or other such features. Those features are documented to
>do the job. They exist /precisely/ because unaligned accesses are not
>allowed without them.
Or sometimes, they just support them:
int
main(void)
{
unsigned long a_variable = 0xaabbccddeeff0011ul;
unsigned short *b_variable = (unsigned short *)((unsigned char *)&a_variable + 1);
printf("addr=%p value=%x\n", b_variable, *b_variable);
return 0;
}
$ cc -o /tmp/a /tmp/a.c
/tmp/a.c: In function 'main':
/tmp/a.c:9: warning: incompatible implicit declaration of built-in function 'printf'
$ /tmp/a
addr=0x7fff9644d151 value=ff00
>
>The fact that compilers have this kind of extension shows that using
>normal pointers for unaligned access is not supported!
>
Well sort of.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 06:52 +0200 |
| Message-ID | <qiiu6n$o41$1@news.albasani.net> |
| In reply to | #67461 |
> Compilers support unaligned accesses when using "pragma pack", > "__unaligned", or other such features. Those features are documented > to do the job. They exist /precisely/ because unaligned accesses are > not allowed without them. > The fact that compilers have this kind of extension shows that using > normal pointers for unaligned access is not supported! It it ridiculous to believe that they support unaligned access through this means but not by unaligned pointers.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 07:59 +0200 |
| Message-ID | <qij248$q5t$1@news.albasani.net> |
| In reply to | #67467 |
>> Compilers support unaligned accesses when using "pragma pack", >> "__unaligned", or other such features. Those features are documented >> to do the job. They exist /precisely/ because unaligned accesses are >> not allowed without them. >> The fact that compilers have this kind of extension shows that using >> normal pointers for unaligned access is not supported! > It it ridiculous to believe that they support unaligned access through > this means but not by unaligned pointers. And even more: someone might argue that an unaligned attribute attached to a data-type might result in a different kind of access suitable for the architecture. But if you have a structure packed through #pragma pack and take the address of an unaligned member the pointer will have the same kind of unalignedness like if you would have done the math yourself and calculated the address with pointer-arithmetics.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-09 09:19 +0200 |
| Message-ID | <qij6qd$gr3$1@dont-email.me> |
| In reply to | #67468 |
On 09/08/2019 07:59, Bonita Montero wrote: >>> Compilers support unaligned accesses when using "pragma pack", >>> "__unaligned", or other such features. Those features are documented >>> to do the job. They exist /precisely/ because unaligned accesses are >>> not allowed without them. >>> The fact that compilers have this kind of extension shows that using >>> normal pointers for unaligned access is not supported! > >> It it ridiculous to believe that they support unaligned access through >> this means but not by unaligned pointers. Really? What possible reason could you have for that? Do you also think it is ridiculous that compilers support wrapping arithmetic through the means of unsigned types, but not through signed types? Do you also think it is ridiculous that compilers support multiplying by 4 by writing "x << 2", but not by writing "x >> -2" ? What more silliness do you believe on the basis of "it worked when I tried it" ? > > And even more: someone might argue that an unaligned attribute attached > to a data-type might result in a different kind of access suitable for > the architecture. I am sure that anyone would expect that an unaligned attribute attached to a data type (or more realistically, a pointer) would result in an access suitable for unaligned access on that architecture. Whether or not that means different instructions will depend on the architecture. > But if you have a structure packed through #pragma > pack and take the address of an unaligned member the pointer will have > the same kind of unalignedness like if you would have done the math > yourself and calculated the address with pointer-arithmetics. If you have a packed struct, and you take the address of an unaligned field in that struct and assign it to a normal pointer, you get an unaligned pointer. The standards don't say if this is allowed or not, since "packed" is not part of the standards, but they say clearly that dereferencing that pointer is undefined behaviour. gcc will warn you about this mistake (finally - it took them 7 years to get it in place). I don't know if other compilers warn about this, ban it, or document that it is allowed - you'd have to look up their documentation. But there is no doubt at all that the behaviour is not defined by the standards. Similarly, using pointer arithmetic, casts, etc, that give you an unaligned pointer is likely to be undefined behaviour when the pointer is assigned, and certainly undefined behaviour when it is used, unless the compiler says it supports such code. And so far you have given absolutely /no/ evidence to suggest that any compiler documents or guarantees support for this kind of thing. There is work in progress amongst the C and C++ workgroups about formalising "pointer provenance". The aim is to provide compilers with better information about pointer validity, and pointer and data aliasing possibilities, leading to better static analysis and better optimisation. I have already mentioned how link-time optimisation is enhancing the flow of information within programs. The more you screw around with clearly bad code that is explicitly disallowed by the language, the greater your risks of having silent errors and hard to find trouble in the future. And what, exactly, do you gain from all this nonsense and risky behaviour? Nothing, really.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 09:32 +0200 |
| Message-ID | <qij7im$94r$1@news.albasani.net> |
| In reply to | #67470 |
> If you have a packed struct, and you take the address of an unaligned > field in that struct and assign it to a normal pointer, you get an > unaligned pointer. That's the same kind of pointer you would get if you would have done the math on your own and offsetted the address from the former member. So there's not the least problem here. > The standards don't say if this is allowed or not, The standards are not relevant here. We're talking about compiler-specific features. > gcc will warn you about this mistake ... That's not because it won't work but it's not portable to every platform.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-09 10:14 +0200 |
| Message-ID | <qija1p$vl7$1@dont-email.me> |
| In reply to | #67471 |
On 09/08/2019 09:32, Bonita Montero wrote: >> If you have a packed struct, and you take the address of an unaligned >> field in that struct and assign it to a normal pointer, you get an >> unaligned pointer. > > That's the same kind of pointer you would get if you would have done > the math on your own and offsetted the address from the former member. > So there's not the least problem here. > The problem is that it is wrong - whether you do the calculations manually or by taking a pointer to the packed member. >> The standards don't say if this is allowed or not, > > The standards are not relevant here. What language are you using? I thought this was a group for a language that has the advantage of a standardised definition, and a (reasonably) clear set of rules. Perhaps you are more familiar with single-source languages like Visual Basic or Delphi where the language is defined as "whatever the tool does in this version". > We're talking about compiler-specific features. I'm /asking/ about compiler-specific features. You are making up stuff as you go along, extrapolating from "it worked in this test". Give me a reference to compiler documentation that says unaligned pointers are acceptable coding on that tool, and I will happily agree that it is valid on that compiler. But you can't give such references. You can make wild claims about what you think is valid, and about what you think all OS's do, but fail to provide the slightest hint of evidence, references, or documentation to back them up. I've shown you the documentation that unaligned pointers and accesses are undefined behaviour - they should not be used in code unless a compiler gives you clear documentation and guarantees that they are supported by that tool. So now it is your turn - show your references to documentation, or accept that you rely on luck for the validity of your code. > >> gcc will warn you about this mistake ... > > That's not because it won't work but it's not portable to every > platform. >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 10:21 +0200 |
| Message-ID | <qijadu$i2$1@news.albasani.net> |
| In reply to | #67472 |
>> That's the same kind of pointer you would get if you would have done >> the math on your own and offsetted the address from the former member. >> So there's not the least problem here. > The problem is that it is wrong - whether you do the calculations > manually or by taking a pointer to the packed member. No, you would get the same adress and the same kind of pointer; that is tha guarantee #pragma pack makes. > What language are you using? We're talking about the behaviour of specific implementations. > I'm /asking/ about compiler-specific features. You are making up stuff > as you go along, extrapolating from "it worked in this test". Give me > a reference to compiler documentation that says unaligned pointers are > acceptable coding on that tool, and I will happily agree that it is > valid on that compiler. The reference is simply the documentation on #pragma pack. If the compiler wouldn't be able to allow unaligned access there would be no #pragma pack.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-09 13:01 +0200 |
| Message-ID | <qijjqs$fsl$1@dont-email.me> |
| In reply to | #67473 |
On 09/08/2019 10:21, Bonita Montero wrote: >>> That's the same kind of pointer you would get if you would have done >>> the math on your own and offsetted the address from the former member. >>> So there's not the least problem here. > >> The problem is that it is wrong - whether you do the calculations >> manually or by taking a pointer to the packed member. > > No, you would get the same adress and the same kind of pointer; > that is tha guarantee #pragma pack makes. > >> What language are you using? > > We're talking about the behaviour of specific implementations. > >> I'm /asking/ about compiler-specific features. You are making up stuff >> as you go along, extrapolating from "it worked in this test". Give me >> a reference to compiler documentation that says unaligned pointers are >> acceptable coding on that tool, and I will happily agree that it is >> valid on that compiler. > > The reference is simply the documentation on #pragma pack. If the > compiler wouldn't be able to allow unaligned access there would be > no #pragma pack. So you don't understand the problem - you don't understand how the language works, you don't understand how compilers work, you don't even understand the concept of "documentation". You can't understand the difference between how a compiler implements code and what code it guarantees to support. You can't provide any justification or references for your claims. You are happy to write pointlessly and uselessly bad code, and to insist that wishful thinking is enough to make it good. I think we are done here.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 13:09 +0200 |
| Message-ID | <qijk9k$77t$1@news.albasani.net> |
| In reply to | #67474 |
>> The reference is simply the documentation on #pragma pack. If the >> compiler wouldn't be able to allow unaligned access there would be >> no #pragma pack. > So you don't understand the problem - you don't understand how the > language works, you don't understand how compilers work, you don't even > understand the concept of "documentation". You can't understand the > difference between how a compiler implements code and what code it > guarantees to support. You can't provide any justification or > references for your claims. You are happy to write pointlessly and > uselessly bad code, and to insist that wishful thinking is enough to > make it good. You don't understand why a compiler that supports #pragma pack has reliable unaligned memory access. When I assign the address of an unaligned member to a pointer that pointer hasnt special properties that would help the compiler to access an unaligned value differently; it's just the same kind of every pointer tothat type. So you can be assured that a compiler that has #pragma pack has reliable unaligned memory-access.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-09 15:38 +0200 |
| Message-ID | <qijt10$3b1$1@dont-email.me> |
| In reply to | #67475 |
On 09/08/2019 13:09, Bonita Montero wrote: >>> The reference is simply the documentation on #pragma pack. If the >>> compiler wouldn't be able to allow unaligned access there would be >>> no #pragma pack. > >> So you don't understand the problem - you don't understand how the >> language works, you don't understand how compilers work, you don't even >> understand the concept of "documentation". You can't understand the >> difference between how a compiler implements code and what code it >> guarantees to support. You can't provide any justification or >> references for your claims. You are happy to write pointlessly and >> uselessly bad code, and to insist that wishful thinking is enough to >> make it good. > > You don't understand why a compiler that supports #pragma pack has > reliable unaligned memory access. I understand the compiler defines unaligned accesses when using packed structs - I also understand that this says /nothing/ about what accesses it supports through unaligned pointers. (Any support in the cpu hardware is irrelevant.) Can't you understand the difference? > When I assign the address of an > unaligned member to a pointer that pointer hasnt special properties > that would help the compiler to access an unaligned value differently; > it's just the same kind of every pointer tothat type. So you can be > assured that a compiler that has #pragma pack has reliable unaligned > memory-access. No, you can't. C and C++ are full of things that a naïve person might think make obvious sense, and certainly could be implemented simply, but they are still undefined behaviour. In some cases, compilers will assume that you haven't done this kind of illegal coding, and optimise on that basis. In most cases, such code works simply because it is less effort to ignore the issue entirely than for the compiler to generate something weird - but it does not prevent weird things from happening if optimisations could be performed.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 15:45 +0200 |
| Message-ID | <qijte7$d22$1@news.albasani.net> |
| In reply to | #67477 |
> C and C++ are full of things that a naïve person might think make > obvious sense, and certainly could be implemented simply, but they > are still undefined behaviour. We are talking about compilers with #pragma packed support. On these those things aren't undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-08-09 09:37 -0500 |
| Message-ID | <ok0rkele4e9stnfpedvi8ip6n1qek5s767@4ax.com> |
| In reply to | #67478 |
On Fri, 9 Aug 2019 15:45:44 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> C and C++ are full of things that a naïve person might think make >> obvious sense, and certainly could be implemented simply, but they >> are still undefined behaviour. > >We are talking about compilers with #pragma packed support. >On these those things aren't undefined behaviour. There is neither a requirement that #pragma pack has a particular effect (which you are assuming is to byte align all structure members), or that any pointer created that don't point to members of such structure can actually be used if forced to pointed to someplace unaligned. For example, I could see a compiler do a data flow analysis to see if a pointer might possibly come from such an unaligned structure member. An implementation might also use fat pointers to have the same effect at runtime. Probably preconditions both are true on most, perhaps even all, compilers that implement #pragma pack(), but there's nothing, except the implementation specific documentation, that defines that. You might find some cross-platform documentation that applies (Posix* for example) to the required behaviors. David isn't saying that there are no implementations where what you're doing works - he'd probably agree that there are many. Rather, that you're making assumptions about which implementations support that behavior, as well as *promise* to support that behavior, on an inadequate basis. *I don't actually know that Posix defines the behavior that you're assuming (and I lack the interest to go look), but it might, just like it guarantees 8-bit bytes.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 16:59 +0200 |
| Message-ID | <qik1o7$2iq$1@news.albasani.net> |
| In reply to | #67482 |
>> We are talking about compilers with #pragma packed support. >> On these those things aren't undefined behaviour. > There is neither a requirement that #pragma pack has a particular > effect (which you are assuming is to byte align all structure > members), or that any pointer created that don't point to members of > such structure can actually be used if forced to pointed to someplace > unaligned. Check your compiler-documentation. It says that #pragma pack allows unaligned packing.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 17:04 +0200 |
| Message-ID | <qik213$m7$1@news.albasani.net> |
| In reply to | #67486 |
> Check your compiler-documentation. > It says that #pragma pack allows unaligned packing. MSVC-documentation: "To pack a class is to place its members directly after each other in memory, which can mean that some or all members can be ligned on a boundary smaller than the default alignment the target architecture" gcc supports the same kind of #pragma pack, even with the same push- / pop-syntax. According to the documentation this is to be MSVC-compatible here.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web