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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-09 16:43 +0100 |
| Message-ID | <iwg3F.642677$Ho1.369267@fx40.am4> |
| In reply to | #67487 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 19:18 +0200 |
| Message-ID | <qik9tj$cps$1@news.albasani.net> |
| In reply to | #67488 |
>> 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. Ok, you're soooo right. #pragma pack is supported without making sense.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-09 23:28 +0100 |
| Message-ID | <2tm3F.2462684$ng1.1031546@fx36.am4> |
| In reply to | #67494 |
On 09/08/2019 18:18, Bonita Montero wrote:
>>> 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.
>
> Ok, you're soooo right.
> #pragma pack is supported without making sense.
>
I'm saying one needn't have anything to do with the other.
For example, take this struct:
struct {char a,b,c,d;}
where char is 8 bits. What happens when you run this on a machine which
only has 32-bit word-addressable memory?
Structs may need to have layouts matching external files or streams or
hardware or languages. That could include:
#pragma pack(1)
struct {char a; int b;}
on a machine that doesn't support unaligned accesses in hardware.
And after all, C also allows this:
int *p = f();
f (in code not visible from the call-site) returns this:
(void*)0x12345; // ie. non-aligned pointer
The compiler might assume that p points to an aligned address. If the
hardware doesn't support unaligned, what would happen when *p is evaluated?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-10 08:55 +0200 |
| Message-ID | <qilpo5$qdj$1@news.albasani.net> |
| In reply to | #67507 |
> I'm saying one needn't have anything to do with the other.
> For example, take this struct:
> struct {char a,b,c,d;}
> where char is 8 bits. What happens when you run this on a machine
> which only has 32-bit word-addressable memory?
On these machines sizeof(char) is also 1. And all larger types are
a multiple of this. So there can be also a misalignment in this way
if the compiler supports this. I.e. a 32-bit-value might be directly
followed by a 64-bit value.
> Structs may need to have layouts matching external files or streams
> or hardware or languages. That could include:
> #pragma pack(1)
> struct {char a; int b;}
> on a machine that doesn't support unaligned accesses in hardware.
I alread told in another posting here that if a compiler supports
#pragma pack it supports generating correct code; but this doesn't
mean that the CPU / OS supports this at runtime. F.e. Linux on SPARC
emulates unaligned acesses through trapping whereas on Solaros on
SPARC this depends on how you compile your code.
> And after all, C also allows this:
> int *p = f();
>
> (void*)0x12345; // ie. non-aligned pointer
> The compiler might assume that p points to an aligned address. If the
> hardware doesn't support unaligned, what would happen when *p is evaluated?
No, the compiler might not assume this. It simply generates a correct
load suitable for this. But if it works at runtime depends on the CPU
(on Intel-CPUs this always works) and on other systems on the combina-
tion off CPU and OS.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-10 17:21 +0200 |
| Message-ID | <qimnde$ki1$1@dont-email.me> |
| In reply to | #67507 |
On 10/08/2019 00:28, Bart wrote:
> On 09/08/2019 18:18, Bonita Montero wrote:
>>>> 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.
>>
>> Ok, you're soooo right.
>> #pragma pack is supported without making sense.
Bart /is/ right. Lots of processors don't support unaligned access, and
compilers for them will usually still have some type of "packed" struct
solution.
>>
>
> I'm saying one needn't have anything to do with the other.
>
> For example, take this struct:
>
> struct {char a,b,c,d;}
>
> where char is 8 bits. What happens when you run this on a machine which
> only has 32-bit word-addressable memory?
If the system only has 32-bit word addressable memory, then usually char
will be 32-bit (you get this in some DSP's). Alternatively, it can
emulate access to smaller objects - this may even mean that char*
pointers are bigger than int* pointers. Either way, "pack" will not
affect the layout of a struct containing only char members.
>
> Structs may need to have layouts matching external files or streams or
> hardware or languages. That could include:
>
> #pragma pack(1)
> struct {char a; int b;}
>
> on a machine that doesn't support unaligned accesses in hardware.
>
> And after all, C also allows this:
>
> int *p = f();
>
> f (in code not visible from the call-site) returns this:
>
> (void*)0x12345; // ie. non-aligned pointer
No, C does not allow that - converting a value into a pointer type that
is not properly aligned is undefined behaviour. You can use other lower
level methods, such as memcpy, to end up with an unaligned int* pointer
- but dereferencing it will be undefined behaviour.
That is true regardless of whether or not the hardware supports
unaligned pointers.
(Of course any C implementation could choose to define such behaviour in
the obvious way - but I have not seen any compiler document such behaviour.)
Note that it is very dangerous to talk about "code not visible from the
call site". The trend in compilation is that more and more is visible,
with cross-unit compilation and optimisation. Techniques that used to
"work" by hiding information from the compiler no longer work when you
have link-time optimisation and similar systems.
>
> The compiler might assume that p points to an aligned address. If the
> hardware doesn't support unaligned, what would happen when *p is evaluated?
The compiler can always assume "p" is aligned properly, and use that
fact for optimisation or code re-arrangement, regardless of unaligned
access support in the hardware.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-10 17:25 +0200 |
| Message-ID | <qimnlg$8q8$1@news.albasani.net> |
| In reply to | #67526 |
> Bart /is/ right. Lots of processors don't support unaligned access, > and compilers for them will usually still have some type of "packed" > struct solution. Yes, they generate the correct code and let the rest depend on the CPU or the OS (trapping). > 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. So you're in the context of a certain compiler and hardware. There you don't have to worry about what the standard says.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-10 23:32 +0200 |
| Message-ID | <qind4k$kp8$1@dont-email.me> |
| In reply to | #67528 |
On 10/08/2019 17:25, Bonita Montero wrote: >> Bart /is/ right. Lots of processors don't support unaligned access, >> and compilers for them will usually still have some type of "packed" >> struct solution. > > Yes, they generate the correct code and let the rest depend on the CPU > or the OS (trapping). 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. No compiler would /ever/ rely on trapping and emulation for handling unaligned accesses to packed objects - that would be absurdly inefficient. > >> 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. > 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. It is only if a compiler documents that it allows such accesses that you can use it safely.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-08-11 10:59 +1200 |
| Message-ID | <gr90j0Fu65U2@mid.individual.net> |
| In reply to | #67535 |
On 11/08/2019 09:32, David Brown wrote: > On 10/08/2019 17:25, Bonita Montero wrote: >>> Bart /is/ right. Lots of processors don't support unaligned access, >>> and compilers for them will usually still have some type of "packed" >>> struct solution. >> >> Yes, they generate the correct code and let the rest depend on the CPU >> or the OS (trapping). > > 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. > > No compiler would /ever/ rely on trapping and emulation for handling > unaligned accesses to packed objects - that would be absurdly inefficient. Solaris SPARC? https://blogs.oracle.com/d/on-misaligned-memory-accesses -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 02:24 +0200 |
| Message-ID | <qinn70$514$1@dont-email.me> |
| In reply to | #67540 |
On 11/08/2019 00:59, Ian Collins wrote: > On 11/08/2019 09:32, David Brown wrote: >> On 10/08/2019 17:25, Bonita Montero wrote: >>>> Bart /is/ right. Lots of processors don't support unaligned access, >>>> and compilers for them will usually still have some type of "packed" >>>> struct solution. >>> >>> Yes, they generate the correct code and let the rest depend on the CPU >>> or the OS (trapping). >> >> 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. >> >> No compiler would /ever/ rely on trapping and emulation for handling >> unaligned accesses to packed objects - that would be absurdly >> inefficient. > > Solaris SPARC? > > https://blogs.oracle.com/d/on-misaligned-memory-accesses > 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. We are not talking about accessing data via a pointer here - then it makes sense on a processor like the SPARC to assume accesses are aligned, and handle anything else by crashing or slow emulation. We are talking about structs with some sort of "packed" feature. The compiler knows these are unaligned, and would use smaller accesses. It won't let the program crash - that would be pointless in the face of a packed struct. It won't rely on seriously slow trap handling when it knows without doubt that the data is misaligned - it will use appropriate smaller accesses.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-10 17:53 -0700 |
| Message-ID | <ln1rxs8qut.fsf@kst-u.example.com> |
| In reply to | #67545 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/08/2019 00:59, Ian Collins wrote:
>> On 11/08/2019 09:32, David Brown wrote:
[...]
>>> 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.
>>>
>>> No compiler would /ever/ rely on trapping and emulation for handling
>>> unaligned accesses to packed objects - that would be absurdly
>>> inefficient.
>>
>> Solaris SPARC?
>>
>> https://blogs.oracle.com/d/on-misaligned-memory-accesses
>
> 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. We are not talking about accessing data via a pointer
> here - then it makes sense on a processor like the SPARC to assume
> accesses are aligned, and handle anything else by crashing or slow
> emulation. We are talking about structs with some sort of "packed"
> feature. The compiler knows these are unaligned, and would use smaller
> accesses. It won't let the program crash - that would be pointless in
> the face of a packed struct. It won't rely on seriously slow trap
> handling when it knows without doubt that the data is misaligned - it
> will use appropriate smaller accesses.
Have you examined the code generated by a SPARC compiler for an
unaligned access to a member of a packed structure? (I'm assuming
that the compiler supports packed structures.)
I don't have access to a SPARC system. Perhaps someone who does could
compile this program and compare the code to access obj.x to the code to
access obj.z. The "__attribute__((packed))" syntax works for gcc;
replace it as needed for whatever compiler you're using.
#include <iostream>
#include <cstddef>
int main() {
struct foo {
int x;
char y;
int z;
} __attribute__((packed));
foo obj = { 10, '?', 20 };
int x_value = obj.x;
int z_value = obj.z;
std::cout << x_value << " at " << offsetof(struct foo, x) << "\n";
std::cout << z_value << " at " << offsetof(struct foo, z) << "\n";
}
--
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 17:26 +0200 |
| Message-ID | <qipc36$m3u$1@dont-email.me> |
| In reply to | #67548 |
On 11/08/2019 02:53, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/08/2019 00:59, Ian Collins wrote:
>>> On 11/08/2019 09:32, David Brown wrote:
> [...]
>>>> 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.
>>>>
>>>> No compiler would /ever/ rely on trapping and emulation for handling
>>>> unaligned accesses to packed objects - that would be absurdly
>>>> inefficient.
>>>
>>> Solaris SPARC?
>>>
>>> https://blogs.oracle.com/d/on-misaligned-memory-accesses
>>
>> 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. We are not talking about accessing data via a pointer
>> here - then it makes sense on a processor like the SPARC to assume
>> accesses are aligned, and handle anything else by crashing or slow
>> emulation. We are talking about structs with some sort of "packed"
>> feature. The compiler knows these are unaligned, and would use smaller
>> accesses. It won't let the program crash - that would be pointless in
>> the face of a packed struct. It won't rely on seriously slow trap
>> handling when it knows without doubt that the data is misaligned - it
>> will use appropriate smaller accesses.
>
> Have you examined the code generated by a SPARC compiler for an
> unaligned access to a member of a packed structure? (I'm assuming
> that the compiler supports packed structures.)
>
> I don't have access to a SPARC system. Perhaps someone who does could
> compile this program and compare the code to access obj.x to the code to
> access obj.z. The "__attribute__((packed))" syntax works for gcc;
> replace it as needed for whatever compiler you're using.
>
> #include <iostream>
> #include <cstddef>
> int main() {
> struct foo {
> int x;
> char y;
> int z;
> } __attribute__((packed));
> foo obj = { 10, '?', 20 };
> int x_value = obj.x;
> int z_value = obj.z;
> std::cout << x_value << " at " << offsetof(struct foo, x) << "\n";
> std::cout << z_value << " at " << offsetof(struct foo, z) << "\n";
> }
>
I don't have a SPARC compiler either - and my favourite resource
<https://godbolt.org> doesn't have it.
If someone could compile this code, and also show the instructions used
by the compiler for accessing obj.x and obj.z, that would be nice.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 19:18 +0200 |
| Message-ID | <qipilg$1gp$1@news.albasani.net> |
| In reply to | #67560 |
>> #include <iostream>
>> #include <cstddef>
>> int main() {
>> struct foo {
>> int x;
>> char y;
>> int z;
>> } __attribute__((packed));
>> foo obj = { 10, '?', 20 };
>> int x_value = obj.x;
>> int z_value = obj.z;
>> std::cout << x_value << " at " << offsetof(struct foo, x) << "\n";
>> std::cout << z_value << " at " << offsetof(struct foo, z) << "\n";
>> }
>>
> I don't have a SPARC compiler either - and my favourite resource
> <https://godbolt.org> doesn't have it.
> If someone could compile this code, and also show the instructions used
> by the compiler for accessing obj.x and obj.z, that would be nice.
Read this, honk:
http://cmynhier.blogspot.com/2008/10/memory-alignment-on-sparc-or-300x.html
But in your head, such compilers might not exist.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 23:00 +0200 |
| Message-ID | <qipvl0$7b2$1@dont-email.me> |
| In reply to | #67566 |
On 11/08/2019 19:18, Bonita Montero wrote:
>>> #include <iostream>
>>> #include <cstddef>
>>> int main() {
>>> struct foo {
>>> int x;
>>> char y;
>>> int z;
>>> } __attribute__((packed));
>>> foo obj = { 10, '?', 20 };
>>> int x_value = obj.x;
>>> int z_value = obj.z;
>>> std::cout << x_value << " at " << offsetof(struct foo, x) << "\n";
>>> std::cout << z_value << " at " << offsetof(struct foo, z) << "\n";
>>> }
>>>
>> I don't have a SPARC compiler either - and my favourite resource
>> <https://godbolt.org> doesn't have it.
>> If someone could compile this code, and also show the instructions
>> used by the compiler for accessing obj.x and obj.z, that would be nice.
>
> Read this, honk:
> http://cmynhier.blogspot.com/2008/10/memory-alignment-on-sparc-or-300x.html
> But in your head, such compilers might not exist.
I never said anything remotely like that.
First, I did not say that no OS emulates unaligned accesses - I said
that you were wrong to say that /every/ OS did so, and I challenged you
to find a reference to even /one/ example that does. It turns out that
some OS's /do/ emulate unaligned accesses, such as Solaris - but you
didn't know even one real sample when you blatantly declared that it
applied to all OS's.
Secondly, I said that no compiler would rely on OS emulation for
unaligned /packed/ field access. This reference does not mention packed
structs - ergo, it is irrelevant to the subthread.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 23:44 +0200 |
| Message-ID | <qiq28a$lss$1@news.albasani.net> |
| In reply to | #67572 |
> First, I did not say that no OS emulates unaligned accesses - > I said that you were wrong to say that /every/ OS did so, ... I didn't say that every OS does this. > ..., and I challenged you to find a reference to even /one/ > example that does. The lattter link to the example with Solaris is a reference on that. > Secondly, I said that no compiler would rely on OS emulation for > unaligned /packed/ field access. That's stupid. Some compilers might rely on the emulation, some compilers might do the disassemby and assembly of the data-word themselfes.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 23:46 +0200 |
| Message-ID | <qiq2as$lt3$1@news.albasani.net> |
| In reply to | #67574 |
>> Secondly, I said that no compiler would rely on OS emulation for >> unaligned /packed/ field access. > That's stupid. Some compilers might rely on the emulation, some > compilers might do the disassemby and assembly of the data-word > themselfes. And as I told the Oracle C/C++ compiler on solaris can do both.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-12 01:02 +0200 |
| Message-ID | <qiq6qc$c75$1@dont-email.me> |
| In reply to | #67575 |
On 11/08/2019 23:46, Bonita Montero wrote: >>> Secondly, I said that no compiler would rely on OS emulation for >>> unaligned /packed/ field access. > >> That's stupid. Some compilers might rely on the emulation, some >> compilers might do the disassemby and assembly of the data-word >> themselfes. > > And as I told the Oracle C/C++ compiler on solaris can do both. The link does not mention packed structs! How many times can I repeat this and /still/ you don't get it?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-12 09:15 +0200 |
| Message-ID | <qir3mh$92o$2@news.albasani.net> |
| In reply to | #67580 |
>> And as I told the Oracle C/C++ compiler on solaris can do both. > The link does not mention packed structs! The link says that accesses to memory larger than a byte are (dis)asssembled by smaller operations if you set the proper compile-flag. So this also does apply for packed stucts.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> |
|---|---|
| Date | 2019-08-11 16:37 -0700 |
| Message-ID | <qiq8sl$3ld$1@gioia.aioe.org> |
| In reply to | #67560 |
On 8/11/2019 8:26 AM, David Brown wrote:
> On 11/08/2019 02:53, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 11/08/2019 00:59, Ian Collins wrote:
>>>> On 11/08/2019 09:32, David Brown wrote:
>> [...]
>>>>> 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.
>>>>>
>>>>> No compiler would /ever/ rely on trapping and emulation for handling
>>>>> unaligned accesses to packed objects - that would be absurdly
>>>>> inefficient.
>>>>
>>>> Solaris SPARC?
>>>>
>>>> https://blogs.oracle.com/d/on-misaligned-memory-accesses
>>>
>>> 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. We are not talking about accessing data via a pointer
>>> here - then it makes sense on a processor like the SPARC to assume
>>> accesses are aligned, and handle anything else by crashing or slow
>>> emulation. We are talking about structs with some sort of "packed"
>>> feature. The compiler knows these are unaligned, and would use smaller
>>> accesses. It won't let the program crash - that would be pointless in
>>> the face of a packed struct. It won't rely on seriously slow trap
>>> handling when it knows without doubt that the data is misaligned - it
>>> will use appropriate smaller accesses.
>>
>> Have you examined the code generated by a SPARC compiler for an
>> unaligned access to a member of a packed structure? (I'm assuming
>> that the compiler supports packed structures.)
>>
>> I don't have access to a SPARC system. Perhaps someone who does could
>> compile this program and compare the code to access obj.x to the code to
>> access obj.z. The "__attribute__((packed))" syntax works for gcc;
>> replace it as needed for whatever compiler you're using.
>>
>> #include <iostream>
>> #include <cstddef>
>> int main() {
>> struct foo {
>> int x;
>> char y;
>> int z;
>> } __attribute__((packed));
>> foo obj = { 10, '?', 20 };
>> int x_value = obj.x;
>> int z_value = obj.z;
>> std::cout << x_value << " at " << offsetof(struct foo, x) << "\n";
>> std::cout << z_value << " at " << offsetof(struct foo, z) << "\n";
>> }
>>
>
> I don't have a SPARC compiler either - and my favourite resource
> <https://godbolt.org> doesn't have it.
>
> If someone could compile this code, and also show the instructions used
> by the compiler for accessing obj.x and obj.z, that would be nice.
DAMN! I won a Sun Fire T2000 from the CoolThreads contest a while back,
around 2005 iirc. But sold it for 2000$ after several years of winning
it! I will never forgive myself for this. It sounded like a damn vacuum
cleaner.
https://www.webwire.com/ViewPressRel.asp?aId=6542
All of the Sun links are destroyed.
It was for my experimental vZoom project. Sun got purchased by Oracle
right around the same time. Actually, I was a finalist. Each one was
given a T2000.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> |
|---|---|
| Date | 2019-08-11 16:42 -0700 |
| Message-ID | <qiq95i$4pm$1@gioia.aioe.org> |
| In reply to | #67582 |
On 8/11/2019 4:37 PM, Chris M. Thomasson wrote: > On 8/11/2019 8:26 AM, David Brown wrote: >> On 11/08/2019 02:53, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 11/08/2019 00:59, Ian Collins wrote: >>>>> On 11/08/2019 09:32, David Brown wrote: [...] > DAMN! I won a Sun Fire T2000 from the CoolThreads contest a while back, > around 2005 iirc. But sold it for 2000$ after several years of winning > it! I will never forgive myself for this. It sounded like a damn vacuum > cleaner. [...] Here is an old post where I mention it: http://boost.2283326.n4.nabble.com/lockfree-fifo-Review-td2648279i40.html
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> |
|---|---|
| Date | 2019-08-11 22:05 -0700 |
| Message-ID | <qiqs31$jvj$1@gioia.aioe.org> |
| In reply to | #67583 |
On 8/11/2019 4:42 PM, Chris M. Thomasson wrote: > On 8/11/2019 4:37 PM, Chris M. Thomasson wrote: >> On 8/11/2019 8:26 AM, David Brown wrote: >>> On 11/08/2019 02:53, Keith Thompson wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>>> On 11/08/2019 00:59, Ian Collins wrote: >>>>>> On 11/08/2019 09:32, David Brown wrote: > [...] >> DAMN! I won a Sun Fire T2000 from the CoolThreads contest a while >> back, around 2005 iirc. But sold it for 2000$ after several years of >> winning it! I will never forgive myself for this. It sounded like a >> damn vacuum cleaner. > [...] > > Here is an old post where I mention it: > > http://boost.2283326.n4.nabble.com/lockfree-fifo-Review-td2648279i40.html Remember firing that sucker up, right next to my computer with windows installed, and got a Solaris gui viewable on the windows machine right up running on the server after the Sun ALOM booted. I forgot the damn program.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web