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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 07:25 +0200 |
| Message-ID | <qio8st$279$3@news.albasani.net> |
| In reply to | #67545 |
> You are missing a critical detail. I said that no compiler would > ever rely on trapping and emulation for handling unaligned accesses > to /packed/ objects. Since you are allowed to get an address of such a packed objekt support for standalone-pointers that do the same must be guaranteed also.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 07:24 +0200 |
| Message-ID | <qio8qc$279$2@news.albasani.net> |
| In reply to | #67540 |
> Solaris SPARC? Linux / SPARC also traps unaligned accesses.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-10 17:22 -0700 |
| Message-ID | <lnef1s8sb3.fsf@kst-u.example.com> |
| In reply to | #67535 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> The standard says that you can't do unaligned accesses.
No, it doesn't. It says that unaligned accesses are undefined behavior.
> It is only if a
> compiler documents that it allows such accesses that you can use it safely.
--
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 | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 07:23 +0200 |
| Message-ID | <qio8p5$279$1@news.albasani.net> |
| In reply to | #67535 |
> You've given no evidence to suggest that any OS emulates unaligned > access. It might well be that some OS's do, for compatibility with > binaries for related processors - but your "proof by repeated assertion" > is getting tedious. I didn't tell that every OS does this. > No compiler would /ever/ rely on trapping and emulation for handling > unaligned accesses to packed objects - that would be absurdly inefficient. The compiler doesn't care about trapping. It just compiles unaligned accesse. >>> No, C does not allow that - converting a value into a pointer type >>> that is not properly aligned is undefined behaviour. >> This is done only on embedded-platforms with fixed adresses of hardware >> -registers. > You have no idea what you are talking about. No, I'm knowing what I'm talking about. >> So you're in the context of a certain compiler and hardware. >> There you don't have to worry about what the standard says. > The standard says that you can't do unaligned accesses. We're talking about certain compilers and not about the standard.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-10 17:10 +0200 |
| Message-ID | <qimmpf$f3t$2@dont-email.me> |
| In reply to | #67488 |
On 09/08/2019 17:43, Bart wrote: > On 09/08/2019 16:04, Bonita Montero wrote: >>> 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. > > Being able to define such a layout doesn't necessarily mean that > unaligned accesses are supported by hardware. > More importantly here, it also does not mean you can take pointers to the unaligned members and use them as normal pointers, nor does it mean that the compiler supports unaligned access in other cases - /even/ if the hardware supports it. On platforms that don't support unaligned access in the hardware, accessing members of a "packed" struct will give you byte-by-byte instructions. No guarantees are usually given if you take a pointer to the member and work from there.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-10 17:21 +0200 |
| Message-ID | <qimndh$8dh$1@news.albasani.net> |
| In reply to | #67525 |
> More importantly here, it also does not mean you can take pointers > to the unaligned members and use them as normal pointers, ... Quote the part of the standard that says that. > ..., nor does it mean that the compiler supports unaligned access > in other cases - /even/ if the hardware supports it. Which compiler does specify this? Show me a link to the documentation.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-10 17:31 +0200 |
| Message-ID | <qimo10$90k$1@news.albasani.net> |
| In reply to | #67527 |
>> More importantly here, it also does not mean you can take pointers >> to the unaligned members and use them as normal pointers, ... > Quote the part of the standard that says that. Oh, I wasn't correct here: since #pragma pack is a compiler-specific feature it sould be specified by the compiler-documentation that it isn't legal to take the address of an unaligned member. So show me some compilers documentations that say that it isn't legal to take the address of an unaligned member!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-10 23:47 +0200 |
| Message-ID | <qine1u$om3$2@dont-email.me> |
| In reply to | #67529 |
On 10/08/2019 17:31, Bonita Montero wrote: >>> More importantly here, it also does not mean you can take pointers >>> to the unaligned members and use them as normal pointers, ... > >> Quote the part of the standard that says that. > > Oh, I wasn't correct here: since #pragma pack is a compiler-specific > feature it sould be specified by the compiler-documentation that it > isn't legal to take the address of an unaligned member. > So show me some compilers documentations that say that it isn't > legal to take the address of an unaligned member! No, it would take compiler-specific documentation to say that it /is/ legal to take the address of an unaligned packed member - because the standard already says that this is undefined behaviour. Thus if a compiler wants to say it is allowed, it must document it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-10 17:40 -0700 |
| Message-ID | <ln5zn48rgq.fsf@kst-u.example.com> |
| In reply to | #67538 |
David Brown <david.brown@hesbynett.no> writes:
> On 10/08/2019 17:31, Bonita Montero wrote:
>>>> More importantly here, it also does not mean you can take pointers
>>>> to the unaligned members and use them as normal pointers, ...
>>
>>> Quote the part of the standard that says that.
>>
>> Oh, I wasn't correct here: since #pragma pack is a compiler-specific
>> feature it sould be specified by the compiler-documentation that it
>> isn't legal to take the address of an unaligned member.
>> So show me some compilers documentations that say that it isn't
>> legal to take the address of an unaligned member!
>
> No, it would take compiler-specific documentation to say that it /is/
> legal to take the address of an unaligned packed member - because the
> standard already says that this is undefined behaviour. Thus if a
> compiler wants to say it is allowed, it must document it.
If you're going to talk about things that are "legal" or "allowed",
please define what you mean by those words. The standard doesn't
use them.
Is the program ill-formed? Is its behavior undefined? Does it
violate a diagnosable rule?
There are very few things that are not *allowed* by the language.
--
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 | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 07:27 +0200 |
| Message-ID | <qio8vm$279$4@news.albasani.net> |
| In reply to | #67538 |
> No, it would take compiler-specific documentation to say that it /is/ > legal to take the address of an unaligned packed member - because the > standard already says that this is undefined behaviour. Thus if a > compiler wants to say it is allowed, it must document it. The standard is irrelevant here since we are talking about secific implementations with #pragma packed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-10 23:46 +0200 |
| Message-ID | <qindvc$om3$1@dont-email.me> |
| In reply to | #67527 |
On 10/08/2019 17:21, Bonita Montero wrote: >> More importantly here, it also does not mean you can take pointers >> to the unaligned members and use them as normal pointers, ... > > Quote the part of the standard that says that. I already did. These are from N1570, draft of C11 standard - C++ inherits this from C and the C standards are simpler. 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. """ 6.5.3.2p4: """ If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. 102) """ Footnote 102: """ Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime. """ > >> ..., nor does it mean that the compiler supports unaligned access >> in other cases - /even/ if the hardware supports it. > > Which compiler does specify this? Show me a link to the documentation. Compilers don't document things they /don't/ do - the document things that they /do/.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-10 23:22 +0100 |
| Message-ID | <ftH3F.817022$T66.487531@fx14.am4> |
| In reply to | #67537 |
On 10/08/2019 22:46, David Brown wrote: > On 10/08/2019 17:21, Bonita Montero wrote: >>> More importantly here, it also does not mean you can take pointers >>> to the unaligned members and use them as normal pointers, ... >> >> Quote the part of the standard that says that. > > I already did. > > These are from N1570, draft of C11 standard - C++ inherits this from C > and the C standards are simpler. > > 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. > """ What does 'correctly aligned' mean? Does C not allow the address of a 32-bit int to be at anything other than a multiple of 4, when the machine has byte-addressed memory, even when the hardware allows it?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-08-10 16:11 -0700 |
| Message-ID | <52b7afac-e701-40d9-8257-d9cfa7c51243@googlegroups.com> |
| In reply to | #67539 |
On Saturday, August 10, 2019 at 6:23:16 PM UTC-4, Bart wrote: > On 10/08/2019 22:46, David Brown wrote: ... > > 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. > > """ > > > What does 'correctly aligned' mean? That's implementation-defined (6.2.8p1). In C2011 you can determine the alignment of a given type under a given implementation by using _Alignof(typename). > Does C not allow the address of a 32-bit int to be at anything other > than a multiple of 4, when the machine has byte-addressed memory, even > when the hardware allows it? The C standard merely allows each implementation to impose alignment requirements for each type; each implementation is free to choose what those requirements are. Many implementations do choose alignment requirements greater than 1, to simplify code generation and to speed up code execution for particular platforms.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-10 17:32 -0700 |
| Message-ID | <lna7cg8rt6.fsf@kst-u.example.com> |
| In reply to | #67541 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Saturday, August 10, 2019 at 6:23:16 PM UTC-4, Bart wrote:
>> On 10/08/2019 22:46, David Brown wrote:
> ...
>> > 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.
>> > """
>>
>> What does 'correctly aligned' mean?
>
> That's implementation-defined (6.2.8p1). In C2011 you can determine the
> alignment of a given type under a given implementation by using
> _Alignof(typename).
There is a possibly useful distinction that this doesn't capture.
For example, on my x86_64 system, gcc has sizeof (int) == 4
and _Alignof (int) == 4. The compiler will, in the absence of
implementation-specific directives, align int objects at 4-byte
boundaries, and any attempt to access an int object that's not
4-byte aligned has undefined behavior.
But you can successfully access int objects at odd addresses,
though doing so is likely to be less efficient (but probably more
efficient than accessing it a byte at a time). (Possibly compiler
optimizations might result in surprising and misbehaving code in
such cases.)
Would it be useful to be able to query both the alignment at which
objects will be allocated and the (possibly smaller) alignment at
which objects can be accessed without going kaboom?
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 15:41 +0200 |
| Message-ID | <qip5ut$l9e$1@dont-email.me> |
| In reply to | #67539 |
On 11/08/2019 00:22, Bart wrote: > On 10/08/2019 22:46, David Brown wrote: >> On 10/08/2019 17:21, Bonita Montero wrote: >>>> More importantly here, it also does not mean you can take pointers >>>> to the unaligned members and use them as normal pointers, ... >>> >>> Quote the part of the standard that says that. >> >> I already did. >> >> These are from N1570, draft of C11 standard - C++ inherits this from C >> and the C standards are simpler. >> >> 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. >> """ > > > What does 'correctly aligned' mean? > > Does C not allow the address of a 32-bit int to be at anything other > than a multiple of 4, when the machine has byte-addressed memory, even > when the hardware allows it? > The alignment for any given type is determined by the implementation, which will base it on the target platform's common ABI. Typically, alignment is based on the size of the type (4-byte types have 4-byte alignment, etc.) but reduced if the maximum access size for the cpu is smaller. Thus on a 16-bit target, any type 16-bit or bigger is likely to be 2 byte aligned. On a 32-bit machine, 16-bit types will be 2-byte aligned and 32-bit types will be 4-byte aligned. There is some variation - on a 32-bit machine, you might find that 8-byte doubles are 8-byte aligned, but they might be 4-byte aligned. With that alignment decision made, the C standard explicitly says that conversions to pointers that result in them being unaligned, are undefined behaviour - as is dereferencing unaligned pointers. A C implementation can, of course, give a definition for how it treats unaligned pointers - but if it does not, then you have to assume that they are simply not allowed.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 15:55 +0200 |
| Message-ID | <qip6p1$bk$1@news.albasani.net> |
| In reply to | #67557 |
> 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 18:06 +0200 |
| Message-ID | <qipees$3k3$1@dont-email.me> |
| In reply to | #67559 |
On 11/08/2019 15: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 Reference? > and such > pointers are indistinguishable from any other unaligned pointer. Reference? > So > an implemtation that has support for #pragma pack must generally > support unaligned accesses. Reference?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 18:15 +0200 |
| Message-ID | <qipevq$ahj$1@news.albasani.net> |
| In reply to | #67561 |
>>> 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 > Reference? If the compilers wouldn't allow this, they wouldn't allow taking the adddress of an unaligned member, but just accessig it with obj.member. And there must be an information that this isn't allowed in the language -reference. So you must give the reference that this isn't allowed. So show me this. >> ... and such >> pointers are indistinguishable from any other unaligned pointer. > Reference? You can assign to a pointer an aligned and unaligned element on these compilers. So the compiler can't distinguish this.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 18:59 +0200 |
| Message-ID | <qiphha$kfq$2@dont-email.me> |
| In reply to | #67562 |
On 11/08/2019 18:15, 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 > >> Reference? > > If the compilers wouldn't allow this, they wouldn't allow taking the > adddress of an unaligned member, but just accessig it with obj.member. Ah, the old "it compiles so it must work" argument? > And there must be an information that this isn't allowed in the language > -reference. So you must give the reference that this isn't allowed. > So show me this. I've given references to say it is undefined at the language level. If a compiler wants to override that and define its behaviour, fine - it should document it. > >>> ... and such >>> pointers are indistinguishable from any other unaligned pointer. > >> Reference? > > You can assign to a pointer an aligned and unaligned element on these > compilers. So the compiler can't distinguish this. Again, it is all just "it worked when I tried it".
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 19:03 +0200 |
| Message-ID | <qiphps$2f0$2@news.albasani.net> |
| In reply to | #67564 |
>> If the compilers wouldn't allow this, they wouldn't allow taking the >> adddress of an unaligned member, but just accessig it with obj.member. > Ah, the old "it compiles so it must work" argument? The compiler can't warn you about everything you're doing wrong. But this would be clearly recognizable by the compiler and if this would be an issue you would at least get a warning.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web