Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #117702 > unrolled thread
| Started by | jgd@cix.co.uk (John Dallman) |
|---|---|
| First post | 2026-08-31 17:35 +0100 |
| Last post | 2026-09-07 17:15 -0700 |
| Articles | 20 on this page of 475 — 30 participants |
Back to article view | Back to comp.arch
Styles of addressing jgd@cix.co.uk (John Dallman) - 2026-08-31 17:35 +0100
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-08-31 17:35 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-08-31 17:48 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-08-31 17:43 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-08-31 22:20 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-01 16:10 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-01 18:01 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 11:55 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 19:58 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 17:07 -0700
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 01:06 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 08:28 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-08 13:31 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:19 +0000
Re: Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-09 18:21 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 18:41 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 20:42 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 21:45 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:49 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 23:28 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 03:45 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:57 +0000
Re: Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-23 22:08 -0400
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:24 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-02 01:31 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 02:44 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 07:45 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 22:32 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 00:12 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-01 05:24 +0000
Re: 370 address sizes, Styles of addressing John Levine <johnl@taugh.com> - 2026-09-01 16:05 +0000
Re: 370 address sizes, Styles of addressing Andy Valencia <vandys@vsta.org> - 2026-09-01 10:07 -0700
Re: 370 address sizes, Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-01 21:17 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-02 18:59 -0400
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 01:50 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-09 16:30 -0400
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 20:50 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 23:25 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:53 +0000
Re: 370 address sizes, Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 16:36 +0000
Re: 370 address sizes, Styles of addressing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 08:46 -0700
Re: 370 address sizes, Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-16 17:21 +0000
Re: 370 address sizes, Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 10:58 -0700
Re: 370 address sizes, Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 10:00 +0000
Re: 370 address sizes, Styles of addressing John Levine <johnl@taugh.com> - 2026-09-17 20:37 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:15 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-16 18:59 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 19:16 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:19 +0000
Re: 370 address sizes, Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 12:24 -0700
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:20 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 17:12 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 17:26 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 18:27 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 20:29 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-16 18:03 -0400
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-03 02:46 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-05 04:26 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 14:40 +0000
Re: 370 address sizes, Styles of addressing jgd@cix.co.uk (John Dallman) - 2026-09-03 20:53 +0100
Re: 370 address sizes, Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-03 15:48 +0000
Re: 370 address sizes, Styles of addressing David Schultz <david.schultz@earthlink.net> - 2026-09-03 12:07 -0500
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 17:33 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 20:23 +0000
Re: 370 address sizes, Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-03 16:44 -0400
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 17:32 +0000
Re: 370 address sizes, Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-03 14:43 -0400
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 20:32 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 21:08 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-04 01:11 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-05 01:08 +0000
Re: Styles of addressing mas@a4.home - 2026-09-06 03:56 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-06 13:51 +0000
Re: Styles of addressing kegs@provalid.com (Kent Dickey) - 2026-09-10 04:11 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:59 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 15:16 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 16:06 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 16:55 +0000
Re: Styles of addressing Robert Finch <robfi680@gmail.com> - 2026-09-10 21:43 -0400
Re: Styles of addressing kegs@provalid.com (Kent Dickey) - 2026-09-13 17:50 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-14 00:42 +0000
CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:02 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 18:58 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 19:01 +0000
Re: CHERI Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 22:45 +0200
Re: CHERI Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-11 16:49 -0400
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:00 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 17:50 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 18:14 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 21:59 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 22:34 +0000
Data-independent timing (was: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 06:22 +0000
Re: Data-independent timing (was: CHERI Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-14 10:04 -0700
Re: Data-independent timing (was: CHERI scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:08 +0000
Re: Data-independent timing (was: CHERI anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 21:35 +0000
Re: CHERI (was: Styles of addressing) jgd@cix.co.uk (John Dallman) - 2026-09-12 11:31 +0100
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 16:42 +0000
Re: CHERI (was: Styles of addressing) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-11 07:01 +0000
Re: CHERI (was: Styles of addressing) kegs@provalid.com (Kent Dickey) - 2026-09-13 17:21 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 18:00 +0000
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 06:35 +0000
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-06 10:44 -0400
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 14:56 +0000
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-06 12:58 -0400
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-06 12:04 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:59 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-07 04:29 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-07 10:40 +0200
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:25 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-07 23:10 +0200
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 21:58 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 05:30 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-08 11:20 +0200
Re: Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-09 12:23 -0400
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 03:47 +0000
Re: Styles of addressing Josh Vanderhoof <x@y.z> - 2026-09-07 18:22 -0400
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-07 13:28 -0400
Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:33 +0000
Re: Addressing Shared Stuff scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 15:48 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 20:05 +0000
Re: Addressing Shared Stuff Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 12:05 -0400
Re: Addressing Shared Stuff jgd@cix.co.uk (John Dallman) - 2026-09-16 23:11 +0100
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:26 +0000
Re: Addressing Shared Stuff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 09:32 +0000
Re: Addressing Shared Stuff jgd@cix.co.uk (John Dallman) - 2026-09-17 13:32 +0100
Re: Addressing Shared Stuff Michael S <already5chosen@yahoo.com> - 2026-09-18 01:08 +0300
Re: Addressing Shared Stuff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-18 06:10 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 16:06 +0000
Re: Addressing Shared Stuff scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 17:26 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 19:40 +0000
Re: Addressing Shared Stuff Andy Valencia <vandys@vsta.org> - 2026-09-14 12:52 -0700
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 20:25 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:02 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:09 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-07 06:17 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:46 +0000
Re: Styles of addressing Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-06 20:21 +0300
Re: Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-08 15:08 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 20:11 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 00:35 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 08:19 +0200
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-09 10:58 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-10 06:16 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:22 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 22:42 +0200
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:32 +0000
Re: Styles of addressing George Neuner <gneuner2@comcast.net> - 2026-09-10 17:02 -0400
Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:33 +0000
Re: Optimization by programmers (was: Styles of addressing) Thomas Koenig <tkoenig@netcologne.de> - 2026-09-11 08:55 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 17:54 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-11 23:19 +0200
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 22:05 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-12 09:30 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-12 13:23 +0200
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-12 13:18 +0200
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-12 17:09 +0000
Re: Optimization by programmers (was: Styles of addressing) George Neuner <gneuner2@comcast.net> - 2026-09-11 23:25 -0400
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 08:38 +0000
Re: Optimization by programmers (was: Styles of addressing) Thomas Koenig <tkoenig@netcologne.de> - 2026-09-12 09:09 +0000
Re: Optimization by programmers (was: Styles of addressing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 09:17 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-14 16:24 +0200
Re: Optimization by programmers (was: Styles of addressing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:34 -0700
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-12 17:15 +0000
Re: Optimization by programmers (was: Styles of addressing) jgd@cix.co.uk (John Dallman) - 2026-09-12 19:13 +0100
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 18:14 +0000
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-13 03:28 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-13 14:27 +0000
Re: Optimization by programmers (was: Styles of addressing) John Levine <johnl@taugh.com> - 2026-09-13 14:58 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-13 16:09 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 17:38 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 17:34 +0000
Re: Optimization by programmers (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 14:43 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 15:44 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-14 18:01 +0000
Re: Optimization by programmers Paul Clayton <paaronclayton@gmail.com> - 2026-09-16 13:14 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 16:47 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 19:38 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 21:25 +0000
Re: Optimization by programmers Paul Clayton <paaronclayton@gmail.com> - 2026-09-21 22:10 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 16:38 -0400
Re: Optimization by programmers David LaRue <huey.dll@tampabay.rr.com> - 2026-09-19 06:01 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-19 06:25 +0000
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-20 02:56 -0400
Re: Optimization by programmers John Levine <johnl@taugh.com> - 2026-09-20 20:12 +0000
Microarchitectural effects on performance (was: Optimization ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 06:55 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-21 17:04 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-23 05:39 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-23 18:34 +0000
Re: Microarchitectural effects on performance Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-23 13:53 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-21 12:48 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 17:17 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-21 20:06 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-21 23:48 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-22 05:25 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-22 14:13 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-26 07:44 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-22 14:48 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 19:28 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-22 05:19 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-22 08:29 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 05:40 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 06:45 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-22 14:32 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-22 15:21 -0700
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-23 05:23 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-23 14:01 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 16:52 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 08:01 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 10:38 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 07:54 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 18:24 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 11:20 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 21:24 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-02 04:10 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-02 10:05 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 22:04 -0700
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-03 13:13 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-24 11:56 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-24 16:35 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 07:47 -0700
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 07:59 -0700
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-24 09:29 -0700
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-25 07:27 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 17:12 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 11:51 -0700
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-25 11:16 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 19:00 +0200
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 18:12 +0000
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-26 10:25 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-27 13:42 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 18:18 +0300
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-27 18:04 +0200
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 19:43 +0300
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 10:55 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-27 22:12 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-28 02:59 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-28 14:43 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:14 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 11:36 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-05 16:48 +0300
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-06 23:16 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 13:28 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 16:43 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 19:57 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 22:31 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 21:28 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-11 08:41 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-11 18:14 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-11 20:56 +0200
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 07:47 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-12 11:25 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 16:20 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-12 17:10 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 21:05 +0200
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 12:03 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 10:27 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 20:00 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 08:02 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 08:50 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-14 23:39 +0200
Re: Optimization by programmers Andy Valencia <vandys@vsta.org> - 2026-10-13 09:09 -0700
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 16:31 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-10-13 18:12 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 20:02 +0300
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-13 19:50 +0200
Comment delimiters (was: Optimization by programmers) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-13 23:24 -0400
Re: Comment delimiters David Brown <david.brown@hesbynett.no> - 2026-10-14 09:56 +0200
Re: Comment delimiters (was: Optimization by programmers) George Neuner <gneuner2@comcast.net> - 2026-10-14 12:14 -0400
Re: Comment delimiters (was: Optimization by programmers) quadibloc@invalid.com (John Savard) - 2026-10-14 18:07 +0000
Re: Comment delimiters (was: Optimization by programmers) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-14 18:50 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-14 15:45 -0400
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-15 06:17 +0000
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-16 06:35 +0000
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 17:10 +0000
Re: Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-16 18:55 +0000
Re: Comment delimiters George Neuner <gneuner2@comcast.net> - 2026-10-16 18:57 -0400
Re: Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 04:01 +0000
Re: Comment delimiters Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-15 15:42 -0400
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-16 12:46 -0400
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 17:56 +0000
Re: FORTRAN, was Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 03:56 +0000
Re: FORTRAN, was Comment delimiters Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-17 11:09 -0400
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-17 10:06 -0400
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-17 14:58 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-18 10:55 -0400
Re: Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-18 17:56 +0000
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-19 18:09 +0000
Re: more Fortran, Comment delimiters John Levine <johnl@taugh.com> - 2026-10-20 03:50 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-20 20:53 +0100
Re: more Fortran, Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-20 20:15 +0000
Re: more Fortran, Comment delimiters scott@slp53.sl.home (Scott Lurndal) - 2026-10-20 20:44 +0000
Re: more Fortran, Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-20 22:49 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-21 23:06 +0100
Re: more Fortran, Comment delimiters scott@slp53.sl.home (Scott Lurndal) - 2026-10-22 00:02 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-22 23:43 +0100
Re: more Fortran, Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-23 00:27 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-23 03:46 +0100
Re: more Fortran, Comment delimiters Michael S <already5chosen@yahoo.com> - 2026-10-23 11:21 +0300
Re: more Fortran, Comment delimiters David Brown <david.brown@hesbynett.no> - 2026-10-23 12:49 +0200
Re: Algol, was more Fortran, Comment delimiters John Levine <johnl@taugh.com> - 2026-10-21 03:28 +0000
Re: Algol, was more Fortran, Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-21 14:10 +0000
Re: Algol, was more Fortran, Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:11 +0000
Re: Algol, was more Fortran, Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:38 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-17 10:06 -0400
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-16 20:35 +0000
Re: FORTRAN, was Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 03:49 +0000
Re: FORTRAN, was Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-17 17:16 +0000
Re: FORTRAN, was Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-18 02:03 +0000
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-17 08:51 +0000
Re: Comment delimiters Robert Finch <robfi680@gmail.com> - 2026-10-18 22:54 -0400
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-19 08:39 +0000
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-19 08:42 +0000
Re: Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:43 +0000
Re: Comment delimiters (was: Optimization by programmers) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-14 22:43 +0000
Re: Comment delimiters (was: Optimization by programmers) quadibloc@invalid.com (John Savard) - 2026-10-15 18:15 +0000
Re: Optimization by programmers quadibloc@invalid.com (John Savard) - 2026-10-12 16:12 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 18:40 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:21 +0000
Re: Optimization by programmers John Levine <johnl@taugh.com> - 2026-10-12 19:54 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 21:10 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 22:37 +0000
Re: smashing constants, sort of like Optimization by programmers John Levine <johnl@taugh.com> - 2026-10-13 00:35 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-13 18:40 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 15:47 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 15:41 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 18:37 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 21:07 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 22:35 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 02:03 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-10-07 22:25 +0300
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 20:05 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-10-07 23:25 +0300
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 22:36 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 22:05 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-09 16:36 +0200
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-07 16:49 -0400
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-07 22:13 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-08 05:46 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-08 12:05 -0400
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 22:55 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-28 19:58 +0300
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-29 15:44 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:57 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-30 17:50 +0300
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 11:47 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-30 18:03 +0200
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-30 17:49 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 06:58 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-02 20:38 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 21:23 -0700
Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-03 11:12 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:45 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 08:29 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 18:29 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-10 14:18 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 17:31 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 15:40 +0000
Re: Rust Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-11 14:26 -0400
Re: Rust cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:14 +0000
Re: Rust Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 21:15 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:13 +0000
Re: Rust (was: Optimization by programmers) Michael S <already5chosen@yahoo.com> - 2026-10-10 22:28 +0300
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 09:27 +0000
Re: Rust (was: Optimization by programmers) Michael S <already5chosen@yahoo.com> - 2026-10-11 22:43 +0300
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 05:01 -0700
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 15:21 +0000
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-07 05:41 -0700
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 14:23 +0000
Re: Rust (was: Optimization by programmers) George Neuner <gneuner2@comcast.net> - 2026-10-06 21:18 -0400
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 22:17 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 14:25 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 21:08 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:29 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 01:49 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 13:05 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:29 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:34 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-29 12:42 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-28 10:54 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-27 17:39 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 21:23 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-29 16:53 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-27 11:46 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-27 14:42 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 06:12 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-28 07:57 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 08:56 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-28 11:06 +0200
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 14:32 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-27 16:40 +0200
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 01:58 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-29 10:16 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-02 05:31 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 19:52 +0000
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 13:52 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 11:06 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-25 05:43 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 05:49 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 10:45 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-25 05:39 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:36 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:45 +0000
Re: Optimization by programmers aph@littlepinkcloud.invalid - 2026-10-04 08:15 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 12:15 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 14:16 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 16:36 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 17:46 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 20:04 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-06 02:17 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-06 10:05 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-19 12:06 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-19 15:56 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-20 10:46 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 14:24 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-20 11:52 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 15:09 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-21 05:27 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 12:13 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 15:35 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 16:43 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-21 20:23 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 11:49 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-20 07:31 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 20:01 +0200
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 20:52 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 13:17 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-22 16:50 -0700
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-03 05:28 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 04:38 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 13:55 +0000
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-05 22:54 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 06:35 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 02:53 -0700
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-06 14:55 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 15:16 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-22 06:15 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-24 17:05 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-26 09:18 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 19:57 +0200
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-14 16:31 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-14 16:58 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:45 -0700
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:53 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 17:21 +0200
Re: Optimization by programmers quadibloc@invalid.com (John Savard) - 2026-09-15 16:00 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 19:40 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-18 15:58 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-11 10:15 +0200
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-11 08:54 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 10:54 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 15:56 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 21:46 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 12:07 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 20:04 +0000
Re: PDP-10 Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 01:15 +0000
Re: PDP-10 Styles of addressing Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 13:55 -0300
Re: PDP-10 Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 17:32 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 02:42 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-02 11:19 -0700
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 20:39 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-02 21:09 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 22:01 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 08:34 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 01:37 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 08:25 +0200
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 08:13 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 08:43 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 05:41 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:16 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-12 02:29 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 07:49 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-11 23:30 -0700
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 08:23 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-12 18:34 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 17:15 -0700
Page 5 of 24 — ← Prev page 1 … 3 4 [5] 6 7 … 24 Next page →
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-14 00:42 +0000 |
| Message-ID | <1789346528-5857@newsgrouper.org> |
| In reply to | #117997 |
kegs@provalid.com (Kent Dickey) posted:
> In article <eAAoS.242$3vg8.225@fx37.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
> >MitchAlsup <user5857@newsgrouper.org.invalid> writes:
--------------------
>
> CHERI creates new system requirements. You could have DMA maintain
> capabilities, and that has some nice properties, but then means you have
> to trust your DMA device.
No, it means devices need to address memory using capabilities--
good luck with that {since 99.99% of devices now use PCIe}.
> The CHERI documentation says whether DMA
> should be able to read/write capabilities is an open question, but that
> the current default is that DMA writes clear capabilities.
Why should a device be able to read/write capabilities and cores cannot--
seems like an attack vector waiting to happen.
> So what's the hole with that? To support paging, it means you must have
> a mechanism to write in the page data to memory using DMA, then DMA
> in the tags elsewhere, and then write in the tags to be valid separately
> (probably done by a CPU using special instructions).
Back in 1974, we used 360/67 to perform DMA and got system privilege
{since the OS got so bloated, TSS put some OS data in page 0 of our
thread.} I, personally, would not think it is secure to allow DMA to
manipulate capabilities--we don't allow them to manipulate MMU tables.
> And this lack of atomicity creates a security issue (which again, can be
> fixed, but you have to DOCUMENT it clearly to make sure it's handled).
> When allowing any DMA to user pages, the lack of atomicity means the OS
> must completely unmap the page from the use before doing any tag operations.
Why would an application be accessing a page that is currently undergoing
DMA ?? Seems like a direct race condition. If app is writing a page getting
written, what gets to SSD ? if app is reading a page getting written by DMA
what gets read ??
> Otherwise, the case that happens is there are 2 threads, a page is paged out,
> one thread touches that page, and starts in the page-in procedure. The
> OS is lazy and has let the second thread have access to the page (because
> this is NOT a security hole without CHERI, it's the process's private data
> page, if it wants to "corrupt" it, it's no concern of the OS's). DMA writes
> in the data, and then an OS task waits for DMA to finish, then it sets the
> tag bits. Meanwhile, the second thread could be aggressively writing
> to a pointer on the page, changing the bounds to be the whole memory space.
> Then the OS process sets the tag to validate the capability, and then
> we've let the user forge a capability.
Illustrating but one race condition...
> There's a similar race in paging out--if the OS copies the tags first,
> then does the DMA reads, and it's mapped in the second user thread still,
> it can similarly forge capabilities. If DMA is first and OS copies the
> tags second, the user could set up the page with a forged pointer that is not
> a valid capability, and then write in a dummy capability before the OS
> copies the tags. So the data is the forged pointer, and the tag is valid.
> When paged back in, the page has a valid forged capability.
>
> So, CHERI adds a requirement that any page being used for DMA must be
> fully unmapped from the user address space first. Again, some OS'es may
> do this by default, but this is a security problem with CHERI and it must
> be done properly. The whole idea of CXL is to allow DMA right into
> user space, and that's not very compatible with CHERI.
It is a security problem with or without CHERI.
> If you think of valid tag bits as a virus that needs to be contained, you'll
> see there are MANY new requirements for how the OS needs to handle user
> data. There needs to be no path where the user creates a malicious
> capability,
at a minimum
> and then an OS operation copies what it thought was data as
> a capability. The OS must not accidentally create capabilities in the
> user space. Morello's all-new-instructions actually help solve this,
> by making normal integer instructions clear the tag always. But there are
> many possibilities here, and since I can find no discussion of how they
> think they've solved this, I'm doubtful they've covered everything.
>
> Kent
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-10 17:02 +0000 |
| Subject | CHERI (was: Styles of addressing) |
| Message-ID | <2026Sep10.190203@mips.complang.tuwien.ac.at> |
| In reply to | #117923 |
kegs@provalid.com (Kent Dickey) writes:
>A CHERI-lite just providing bounds checking could be useful.
I doubt it. The problems I see here (as well as in CHERI) is that we
have nested data structures (not in every programming language, but
certainly in some relevant ones), such as
struct foo {
char x[3];
struct bar {
char u[5];
int v[3];
} y[4];
long z[5];
} a[3];
Sometimes you want to check that you do not exceed the bounds of a,
sometimes that you do not exceed the bounds of z, sometimes that you
do not exceed the bounds of u. Sometimes you want to treat all of a
as one thing, sometimes, only some part, sometimes your software does
things beyond a single nested struct, such as garbage collection.
I guess there are ways to do these things in CHERI, but I very much
doubt that the only cost CHERI has for them is the doubled memory
consumption. And does it buy anything that Rust does not buy us?
Given that the computing world seems to have decided that it does not
even want to pay the very moderate cost of invisible speculation to
protect against Spectre and friends, I very much doubt that CHERI will
be a widespread success.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-10 18:58 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <1789066716-5857@newsgrouper.org> |
| In reply to | #117935 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> kegs@provalid.com (Kent Dickey) writes:
> >A CHERI-lite just providing bounds checking could be useful.
>
> I doubt it. The problems I see here (as well as in CHERI) is that we
> have nested data structures (not in every programming language, but
> certainly in some relevant ones), such as
>
> struct foo {
> char x[3];
> struct bar {
> char u[3]; // making a 2-byte hole in the struct element
> int v[3];
> } y[4];
> long z[5];
> } a[3];
>
> Sometimes you want to check that you do not exceed the bounds of a,
> sometimes that you do not exceed the bounds of z, sometimes that you
> do not exceed the bounds of u. Sometimes you want to treat all of a
> as one thing, sometimes, only some part, sometimes your software does
> things beyond a single nested struct, such as garbage collection.
And sometimes you even want to prevent accessing data that is not
"in" the struct due to internal alignments--such as the bytes between
u[2] and v[0].
> I guess there are ways to do these things in CHERI, but I very much
> doubt that the only cost CHERI has for them is the doubled memory
> consumption. And does it buy anything that Rust does not buy us?
>
> Given that the computing world seems to have decided that it does not
> even want to pay the very moderate cost of invisible speculation to
> protect against Spectre and friends, I very much doubt that CHERI will
> be a widespread success.
My 66000 architecture has means maintain robustness in the face of
Spectré attack vectors. Stashing microarchitectural state in the
miss buffers until the causing instruction retires--and only then
updating microarchitectural state.
Don't see why CHERI could not do similarly.
Nor do I see other microarchitectures implementing this fairly easy
"suit of armor" to mitigate Spectré!?!?
> - anton
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-10 19:01 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <s8DoS.4335$Pwy8.1645@fx36.iad> |
| In reply to | #117938 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>> kegs@provalid.com (Kent Dickey) writes:
>> >A CHERI-lite just providing bounds checking could be useful.
>>
>> I doubt it. The problems I see here (as well as in CHERI) is that we
>> have nested data structures (not in every programming language, but
>> certainly in some relevant ones), such as
>>
>> struct foo {
>> char x[3];
>> struct bar {
>> char u[3]; // making a 2-byte hole in the struct element
>> int v[3];
>> } y[4];
>> long z[5];
>> } a[3];
>>
>> Sometimes you want to check that you do not exceed the bounds of a,
>> sometimes that you do not exceed the bounds of z, sometimes that you
>> do not exceed the bounds of u. Sometimes you want to treat all of a
>> as one thing, sometimes, only some part, sometimes your software does
>> things beyond a single nested struct, such as garbage collection.
>
>And sometimes you even want to prevent accessing data that is not
>"in" the struct due to internal alignments--such as the bytes between
>u[2] and v[0].
That would be difficult, since one needs to be able to copy
the structure, which necessarily will need to access those bytes.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-10 22:45 +0200 |
| Subject | Re: CHERI |
| Message-ID | <117v4tk$2asg3$2@dont-email.me> |
| In reply to | #117939 |
Scott Lurndal wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>
>>> kegs@provalid.com (Kent Dickey) writes:
>>>> A CHERI-lite just providing bounds checking could be useful.
>>>
>>> I doubt it. The problems I see here (as well as in CHERI) is that we
>>> have nested data structures (not in every programming language, but
>>> certainly in some relevant ones), such as
>>>
>>> struct foo {
>>> char x[3];
>>> struct bar {
>>> char u[3]; // making a 2-byte hole in the struct element
>>> int v[3];
>>> } y[4];
>>> long z[5];
>>> } a[3];
>>>
>>> Sometimes you want to check that you do not exceed the bounds of a,
>>> sometimes that you do not exceed the bounds of z, sometimes that you
>>> do not exceed the bounds of u. Sometimes you want to treat all of a
>>> as one thing, sometimes, only some part, sometimes your software does
>>> things beyond a single nested struct, such as garbage collection.
>>
>> And sometimes you even want to prevent accessing data that is not
>> "in" the struct due to internal alignments--such as the bytes between
>> u[2] and v[0].
>
> That would be difficult, since one needs to be able to copy
> the structure, which necessarily will need to access those bytes.
>
Not true:
You _just_ need to do such a deep copy element by element, and suffer
about an order of magnitude slowdown.
For better performance, the compiler will figure out if there are any
holes, if not just do a memcpy().
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-11 16:49 -0400 |
| Subject | Re: CHERI |
| Message-ID | <jwvmrtnzf8t.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #117939 |
Scott Lurndal [2026-09-10 19:01:44] wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>And sometimes you even want to prevent accessing data that is not
>>"in" the struct due to internal alignments--such as the bytes between
>>u[2] and v[0].
> That would be difficult, since one needs to be able to copy
> the structure, which necessarily will need to access those bytes.
Of course, if the copy enjoys the same property ("you can't read the
padding"), then it's OK to "blindly" copy all the bytes. 🙂
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-11 06:00 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <2026Sep11.080019@mips.complang.tuwien.ac.at> |
| In reply to | #117938 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>> Given that the computing world seems to have decided that it does not
>> even want to pay the very moderate cost of invisible speculation to
>> protect against Spectre and friends, I very much doubt that CHERI will
>> be a widespread success.
>
>My 66000 architecture has means maintain robustness in the face of
>Spectré attack vectors. Stashing microarchitectural state in the
>miss buffers until the causing instruction retires--and only then
>updating microarchitectural state.
This is a good approach to implement invisible speculation as far as
cache side channel is concerned. Behnia et al. [behnia+21] describe a
side channel that uses resource contention from speculative
instructions to affect the timing of committing instructions, i.e., it
uses the scheduler (reservation station) behaviour as a side channel.
Behnia et al. also describe how to close this side channel. There may
be other side channels through microarchitectural resources, and they
need to be closed, too, but the cache side channel probably is the
widest and therefore most relevant one by far.
@InProceedings{ behnia+21,
author = {Mohammad Behnia and Prateek Sahu and Riccardo Paccagnella
and Jiyong Yu and Zirui Neil Zhao and Xiang Zou and Thomas
Unterluggauer and Josep Torrellas and Carlos Rozas and Adam
Morrison and Frank Mckeen and Fangfei Liu and Ron Gabor and
Christo- pher W. Fletcher and Abhishek Basak and Alaa
Alameldeen},
title = {Speculative Interference Attacks: Breaking Invisible
Speculation Schemes},
booktitle = {Architectural Support for Programming Languages and
Operating Systems (ASPLOS ’21)},
year = {2021},
pages = {1046--1060},
url = {https://dl.acm.org/doi/10.1145/3445814.3446708},
optannote = {}
}
Spectre and friends are microarchitectural side channels, you can
implement microarchitectures for any architecture that are vulnerable
to Spectre, and microarchitectures that are not vulnerable. Therefore
your mention of the My 66000 architecture makes no sense.
>Don't see why CHERI could not do similarly.
Certainly one can implement a core with CHERI that is not vulnerable
to speculative side channels (either by not implementing speculation
(slow), or by implementing invisible speculation), and if the
financers and the prospective customers are serious about security,
they will insist on that for eventual products.
But my point is that in the mainstream, not even invisible speculation
with its moderate cost in hardware and performance is implemented, so
I don't expect that a high-cost solution like CHERI becomes
mainstream, in particular given that it provides nothing that cannot
be provided more cheaply through programming languages and compilers.
Ok, you might say, what about legacy code in unsafe languages such as
C? Rewriting all of that in Rust (or using a solution like Ivy/Deputy
<http://ivy.cs.berkeley.edu/ivywiki/uploads/deputy-manual.html>, which
would be cheaper, but somehow did not catch on) would also be very
costly. But I expect that much of this code does not work on CHERI in
the secure configuration; so to run it on CHERI, you would have to
change it anyway, so you could just as well Deputize it, which is
cheaper in hardware and in execution time. Or rewrite it in Rust, if
you prefer that.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-11 17:50 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <1789149045-5857@newsgrouper.org> |
| In reply to | #117944 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> /ERROR "unexpected byte sequence starting at index 434: '\xC3'" while decoding/:
>
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >> Given that the computing world seems to have decided that it does not
> >> even want to pay the very moderate cost of invisible speculation to
> >> protect against Spectre and friends, I very much doubt that CHERI will
> >> be a widespread success.
> >
> >My 66000 architecture has means maintain robustness in the face of
> >Spectré attack vectors. Stashing microarchitectural state in the
> >miss buffers until the causing instruction retires--and only then
> >updating microarchitectural state.
>
> This is a good approach to implement invisible speculation as far as
> cache side channel is concerned. Behnia et al. [behnia+21] describe a
> side channel that uses resource contention from speculative
> instructions to affect the timing of committing instructions, i.e., it
> uses the scheduler (reservation station) behaviour as a side channel.
My 66000 does not have architectural constraints on the timing of
instructions--each implementation gets that set of choices. And
thanks for the reference.
> Behnia et al. also describe how to close this side channel. There may
> be other side channels through microarchitectural resources, and they
> need to be closed, too, but the cache side channel probably is the
> widest and therefore most relevant one by far.
Caches and TLBs (which are (ARE) caches). And this is where My 66000
has statements in the architectural documents that disallow an imple-
mentation from modifying cache (+ TLB) state prior to the retirement
of the causing instruction. Additionally, there is a requirement that
prevents using a value read from memory (through the caches) being
used as a pointer or index in a subsequent memory reference until
the producing instruction is known to complete (access checks applied).
> @InProceedings{ behnia+21,
> author = {Mohammad Behnia and Prateek Sahu and Riccardo Paccagnella
> and Jiyong Yu and Zirui Neil Zhao and Xiang Zou and Thomas
> Unterluggauer and Josep Torrellas and Carlos Rozas and Adam
> Morrison and Frank Mckeen and Fangfei Liu and Ron Gabor and
> Christo- pher W. Fletcher and Abhishek Basak and Alaa
> Alameldeen},
> title = {Speculative Interference Attacks: Breaking Invisible
> Speculation Schemes},
> booktitle = {Architectural Support for Programming Languages and
> Operating Systems (ASPLOS â21)},
> year = {2021},
> pages = {1046--1060},
> url = {https://dl.acm.org/doi/10.1145/3445814.3446708},
> optannote = {}
> }
>
> Spectre and friends are microarchitectural side channels, you can
> implement microarchitectures for any architecture that are vulnerable
> to Spectre, and microarchitectures that are not vulnerable. Therefore
> your mention of the My 66000 architecture makes no sense.
It is the architectural statements that constrain implementations from
updating (directly or indirectly) visible µArch state until it is known
that the instruction will retire (even in the face of interrupts).
> >Don't see why CHERI could not do similarly.
>
> Certainly one can implement a core with CHERI that is not vulnerable
> to speculative side channels (either by not implementing speculation
> (slow), or by implementing invisible speculation), and if the
> financers and the prospective customers are serious about security,
> they will insist on that for eventual products.
Absolutely--however it appears no prospective customer yet cares too.
> But my point is that in the mainstream, not even invisible speculation
> with its moderate cost in hardware and performance is implemented, so
> I don't expect that a high-cost solution like CHERI becomes
> mainstream, in particular given that it provides nothing that cannot
> be provided more cheaply through programming languages and compilers.
I have no complaint to this paragraph.
> Ok, you might say, what about legacy code in unsafe languages such as
> C? Rewriting all of that in Rust (or using a solution like Ivy/Deputy
> <http://ivy.cs.berkeley.edu/ivywiki/uploads/deputy-manual.html>, which
> would be cheaper, but somehow did not catch on) would also be very
> costly.
C says nothing about inter instruction timing. Spectré exploits that.
What My 66000 does at the architectural level is to constrain all µArch
from updating <potentially> visible µArch state.
> But I expect that much of this code does not work on CHERI in
> the secure configuration; so to run it on CHERI, you would have to
> change it anyway, so you could just as well Deputize it, which is
> cheaper in hardware and in execution time. Or rewrite it in Rust, if
> you prefer that.
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-11 18:14 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <dyXoS.788$NE2.27@fx20.iad> |
| In reply to | #117957 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> /ERROR "unexpected byte sequence starting at index 434: '\xC3'" while decoding/: >> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> > >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> >> Given that the computing world seems to have decided that it does not >> >> even want to pay the very moderate cost of invisible speculation to >> >> protect against Spectre and friends, I very much doubt that CHERI will >> >> be a widespread success. >> > >> >My 66000 architecture has means maintain robustness in the face of >> >Spectré attack vectors. Stashing microarchitectural state in the >> >miss buffers until the causing instruction retires--and only then >> >updating microarchitectural state. >> >> This is a good approach to implement invisible speculation as far as >> cache side channel is concerned. Behnia et al. [behnia+21] describe a >> side channel that uses resource contention from speculative >> instructions to affect the timing of committing instructions, i.e., it >> uses the scheduler (reservation station) behaviour as a side channel. > >My 66000 does not have architectural constraints on the timing of >instructions--each implementation gets that set of choices. And >thanks for the reference. Are there any instructions where the timing will vary based on the data being operated on?
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-11 21:59 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <1789163964-5857@newsgrouper.org> |
| In reply to | #117961 |
scott@slp53.sl.home (Scott Lurndal) posted:
> /ERROR "unexpected byte sequence starting at index 665: '\xC3'" while decoding/:
>
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >
> >> /ERROR "unexpected byte sequence starting at index 434: '\xC3'" while decoding/:
> >>
> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >> >
> >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >> >> Given that the computing world seems to have decided that it does not
> >> >> even want to pay the very moderate cost of invisible speculation to
> >> >> protect against Spectre and friends, I very much doubt that CHERI will
> >> >> be a widespread success.
> >> >
> >> >My 66000 architecture has means maintain robustness in the face of
> >> >Spectré attack vectors. Stashing microarchitectural state in the
> >> >miss buffers until the causing instruction retires--and only then
> >> >updating microarchitectural state.
> >>
> >> This is a good approach to implement invisible speculation as far as
> >> cache side channel is concerned. Behnia et al. [behnia+21] describe a
> >> side channel that uses resource contention from speculative
> >> instructions to affect the timing of committing instructions, i.e., it
> >> uses the scheduler (reservation station) behaviour as a side channel.
> >
> >My 66000 does not have architectural constraints on the timing of
> >instructions--each implementation gets that set of choices. And
> >thanks for the reference.
>
> Are there any instructions where the timing will vary based on the
> data being operated on?
Things like::
TAN, ATAN, ASIN, ACOS where 1/2 the paths do not need a reciprocal and 1/2 do.
One could imagine MUL, DIV, FMUL, and FDIV having early out FUs. MUL and FMUL
are a lot less likely to have early outs than DIV and FDIV.
{Direct write to IP via HR, CALX, CALA, JMPX, JMPA}-instruction taking a
cache miss versus not taking that miss.
Invalidation {by-ASID or of-Page} to {cache or TLB}
{assuming proper privilege:
Direct write to Root Pointer which results in reloading of TLB state which
could be cached (or not).
Direct write to Interrupt Table control register resulting in a pending
interrupt being taken (or not).
Direct write to {Priority, voltage, clock} control registers
}
Otherwise: No
But I don't think constant time evaluations need those instructions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-11 22:34 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <Bl%oS.2186$XsT2.199@fx01.iad> |
| In reply to | #117964 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >scott@slp53.sl.home (Scott Lurndal) posted: > >> /ERROR "unexpected byte sequence starting at index 665: '\xC3'" while decoding/: >> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> > >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> > >> >> /ERROR "unexpected byte sequence starting at index 434: '\xC3'" while decoding/: >> >> >> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >> > >> >> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> >> >> Given that the computing world seems to have decided that it does not >> >> >> even want to pay the very moderate cost of invisible speculation to >> >> >> protect against Spectre and friends, I very much doubt that CHERI will >> >> >> be a widespread success. >> >> > >> >> >My 66000 architecture has means maintain robustness in the face of >> >> >Spectré attack vectors. Stashing microarchitectural state in the >> >> >miss buffers until the causing instruction retires--and only then >> >> >updating microarchitectural state. >> >> >> >> This is a good approach to implement invisible speculation as far as >> >> cache side channel is concerned. Behnia et al. [behnia+21] describe a >> >> side channel that uses resource contention from speculative >> >> instructions to affect the timing of committing instructions, i.e., it >> >> uses the scheduler (reservation station) behaviour as a side channel. >> > >> >My 66000 does not have architectural constraints on the timing of >> >instructions--each implementation gets that set of choices. And >> >thanks for the reference. >> >> Are there any instructions where the timing will vary based on the >> data being operated on? > >Things like:: > >TAN, ATAN, ASIN, ACOS where 1/2 the paths do not need a reciprocal and 1/2 do. > >One could imagine MUL, DIV, FMUL, and FDIV having early out FUs. MUL and FMUL >are a lot less likely to have early outs than DIV and FDIV. So, those are all security issues. ARM has added a 'data independent timing' flag that can be used to ensure that a given instruction executes in constant time, regardless of the data being operated on. > > > >But I don't think constant time evaluations need those instructions. Hard to predict. Best to assume someone will use those instructions in timing sensitive code.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-14 06:22 +0000 |
| Subject | Data-independent timing (was: CHERI (was: Styles of addressing) |
| Message-ID | <2026Sep14.082202@mips.complang.tuwien.ac.at> |
| In reply to | #117966 |
scott@slp53.sl.home (Scott Lurndal) writes: >So, those are all security issues. ARM has added a 'data independent timing' >flag that can be used to ensure that a given instruction executes in constant >time, regardless of the data being operated on. Interesting approach. So when you use this flag on a load, it will take the maximum time that a load can take (e.g., RAM access to RAM under contention, or access to a remote cache under contention), wherever it finds the item? Intel has taken a different approach: It has documented the instructions that are guaranteed to have data-independent timings across all Intel microarchitectures; not sure if AMD gives the same guarantee. So if you want to write code that does not have a timing side-channel that reveals something about the data, you use only these instructions. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-14 10:04 -0700 |
| Subject | Re: Data-independent timing (was: CHERI |
| Message-ID | <11899ff$1nme8$1@dont-email.me> |
| In reply to | #118002 |
On 9/13/2026 11:22 PM, Anton Ertl wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> So, those are all security issues. ARM has added a 'data independent timing' >> flag that can be used to ensure that a given instruction executes in constant >> time, regardless of the data being operated on. > > Interesting approach. So when you use this flag on a load, it will > take the maximum time that a load can take (e.g., RAM access to RAM > under contention, or access to a remote cache under contention), > wherever it finds the item? Sure sounds ugly. :-( On a modern system, how long can this be? > Intel has taken a different approach: It has documented the > instructions that are guaranteed to have data-independent timings > across all Intel microarchitectures; not sure if AMD gives the same > guarantee. So if you want to write code that does not have a timing > side-channel that reveals something about the data, you use only these > instructions. So loads couldn't be on that list. So you couldn't use any load instructions in such code. Also sounds ugly, but I am not sure which alternative is worse. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-14 18:08 +0000 |
| Subject | Re: Data-independent timing (was: CHERI |
| Message-ID | <oKWpS.245225$ORN1.73725@fx24.iad> |
| In reply to | #118016 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >On 9/13/2026 11:22 PM, Anton Ertl wrote: >> scott@slp53.sl.home (Scott Lurndal) writes: >>> So, those are all security issues. ARM has added a 'data independent timing' >>> flag that can be used to ensure that a given instruction executes in constant >>> time, regardless of the data being operated on. >> >> Interesting approach. So when you use this flag on a load, it will >> take the maximum time that a load can take (e.g., RAM access to RAM >> under contention, or access to a remote cache under contention), >> wherever it finds the item? > >Sure sounds ugly. :-( On a modern system, how long can this be? The ARM DIT flag doesn't apply to standard loads or stores. However, software can use non-temporal loads (or explictly warm the cache) to eliminate timing variability due to caching on most modern architectures. The primary use for DIT is in cryptographic algorithms.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-14 21:35 +0000 |
| Subject | Re: Data-independent timing (was: CHERI |
| Message-ID | <2026Sep14.233507@mips.complang.tuwien.ac.at> |
| In reply to | #118016 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >On 9/13/2026 11:22 PM, Anton Ertl wrote: >> Intel has taken a different approach: It has documented the >> instructions that are guaranteed to have data-independent timings >> across all Intel microarchitectures; not sure if AMD gives the same >> guarantee. So if you want to write code that does not have a timing >> side-channel that reveals something about the data, you use only these >> instructions. > >So loads couldn't be on that list. So you couldn't use any load >instructions in such code. You can, but the address must not depend on the data you process. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-09-12 11:31 +0100 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <memo.20260912113111.20460C@jgd.cix.co.uk> |
| In reply to | #117944 |
In article <2026Sep11.080019@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Ok, you might say, what about legacy code in unsafe languages such > as C? Rewriting all of that in Rust (or using a solution like > Ivy/Deputy > <http://ivy.cs.berkeley.edu/ivywiki/uploads/deputy-manual.html>, > which would be cheaper, but somehow did not catch on) That link seems to have rotted. > But I expect that much of this code does not work on CHERI in > the secure configuration; so to run it on CHERI, you would have to > change it anyway, so you could just as well Deputize it, which is > cheaper in hardware and in execution time. Or rewrite it in Rust, > if you prefer that. CHERI does not seem to have established a niche for itself. A few years ago, my employer was offered a Morello board for trials. We concluded that while it would be interesting and educational, it wasn't going to be commercially useful unless CHERI caught on. That decision seems to have been realistic. John
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-12 16:42 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <2026Sep12.184233@mips.complang.tuwien.ac.at> |
| In reply to | #117976 |
jgd@cix.co.uk (John Dallman) writes: >In article <2026Sep11.080019@mips.complang.tuwien.ac.at>, >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> Ok, you might say, what about legacy code in unsafe languages such >> as C? Rewriting all of that in Rust (or using a solution like >> Ivy/Deputy >> <http://ivy.cs.berkeley.edu/ivywiki/uploads/deputy-manual.html>, >> which would be cheaper, but somehow did not catch on) > >That link seems to have rotted. Works for me. Anyway, it's about annotating existing C such that the annotated portions would be memory-safe; the annotations insert checks unless the compiler can prove that they hold anyway. In this way, existing C code can be turned into memory-safe code in a piecemeal way, rather than rewriting it completely, like the Rust conversions are doing. My guess is that it did not catch on, because the programmers who wrote the C code do not (or maybe did not, while Ivy/Deputy was somewhat current, and now it's too late) see the need to do all this work, because they thought that their programs are memory-safe already, and other people prefered rewriting the code to annotating the legacy code of other programmers. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-11 07:01 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <11808vh$2lpqm$1@dont-email.me> |
| In reply to | #117935 |
On Thu, 10 Sep 2026 17:02:03 GMT, Anton Ertl wrote: > I guess there are ways to do these things in CHERI, but I very much > doubt that the only cost CHERI has for them is the doubled memory > consumption. And does it buy anything that Rust does not buy us? From what I understand of the CHERI project, they have produced a complete desktop OS in the form of CheriBSD, complete with a port of the KDE Plasma desktop environment. This is a pretty comprehensive collection of C++ code, so it sounds like a good testbed for getting experience with running a real-world codebase under the CHERI constraints. Interestingly, the reason they gave for choosing a BSD variant as a basis rather than Linux, was that the Linux project was moving too fast for them to keep up. Didn’t they know about LTS releases?
[toc] | [prev] | [next] | [standalone]
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2026-09-13 17:21 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <1186m21$qab6$1@dont-email.me> |
| In reply to | #117935 |
In article <2026Sep10.190203@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>kegs@provalid.com (Kent Dickey) writes:
>>A CHERI-lite just providing bounds checking could be useful.
>
>I doubt it. The problems I see here (as well as in CHERI) is that we
>have nested data structures (not in every programming language, but
>certainly in some relevant ones), such as
>
>struct foo {
> char x[3];
> struct bar {
> char u[5];
> int v[3];
> } y[4];
> long z[5];
>} a[3];
>
>Sometimes you want to check that you do not exceed the bounds of a,
>sometimes that you do not exceed the bounds of z, sometimes that you
>do not exceed the bounds of u. Sometimes you want to treat all of a
>as one thing, sometimes, only some part, sometimes your software does
>things beyond a single nested struct, such as garbage collection.
>
>I guess there are ways to do these things in CHERI, but I very much
>doubt that the only cost CHERI has for them is the doubled memory
>consumption. And does it buy anything that Rust does not buy us?
This is off the top of my head, so it will be "wrong", but you'll get the
idea.
If you want to evaulate:
out = a[i].y[j].v[k];
You have a pointer to the start of the 'a' array, a, and it allows access to
sizeof(foo)*3 bytes: a.ptr = a, a.bound=3*sizeof(foo)
You do (each line is one instruction, everything is registers):
Then the evaluation is:
tmp = sizeof(foo)
off = i*tmp + offset(a[0].y[0])
a_i.ptr = a + off, a_i.bound=sizeof(bar)*4
[ The above checks that a_i is within the range a allows, then
creates a new pointer with the smaller range ]
tmp = sizeof(bar)
off = j*tmp + offset(y[0].v[0])
y_j.ptr = a_i + off, y_j.bound = 3
[ The above checks that y_j is within the range a_i allows ]
out = LOAD(y_j + k)
[ The above checks that y_j+k is within the y_j range ]
This checks that each lookup is within bounds. The CHERI overhead is the
formation of a_i and y_j, the other address calculations are needed even
without CHERI. So 6 instructions become 7 instructions. What helps CHERI
is this type of indexing takes several instructions on many architectures
already, so adding the pointer creation steps sometimes are just replacing
an ADD that was needed anyway.
[Note: the above is more efficient than what Morello does, where the
setting of the bounds is a separate instruction, but that was a poor choice
for the implementation: It's pretty easy to implement PTR = PTR + REG, with
a small immediate encoding a new bounds, and PTR = PTR + REG, size=REG2 where
the new size comes from another register. ARM has the encoding space
available for this, but CHERI is so much more than just bounds checking
they lost the forest for the trees and added like 160+ instructions].
Kent
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-13 18:00 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <1789322411-5857@newsgrouper.org> |
| In reply to | #117994 |
kegs@provalid.com (Kent Dickey) posted:
------------------
Inserting minor corrections:
> This is off the top of my head, so it will be "wrong", but you'll get the
> idea.
>
> If you want to evaulate:
>
> out = a[i].y[j].v[k];
>
-------------------
Rewriting using variable-types instead of base-types::
>
> You do (each line is one instruction, everything is registers):
>
> Then the evaluation is:
>
> tmp = sizeof(a[0]);
> off = i*tmp + offset(a[0].y[0]);
>
> a_i.ptr = a + off, a_i.bound=sizeof(a[0].y);
--------
>
> tmp = sizeof(a[0].y[0]);
> off = j*tmp + offset(y[0].v[0]);
>
> y_j.ptr = a_i + off, y_j.bound = Sizeof( a[0].y[0].v );
--------
>
k_tmp = k*sizeof( a[0].y[0].v[0] );
> out = LOAD(y_j + k_tmp);
The types carry their sizes, no need to use base types.
AND I am assuming the + in LOAD() is non-scaled.
--------
>
> Kent
[toc] | [prev] | [next] | [standalone]
Page 5 of 24 — ← Prev page 1 … 3 4 [5] 6 7 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web