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 6 of 24 — ← Prev page 1 … 4 5 [6] 7 8 … 24 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-14 06:35 +0000 |
| Subject | Re: CHERI (was: Styles of addressing) |
| Message-ID | <2026Sep14.083534@mips.complang.tuwien.ac.at> |
| In reply to | #117994 |
kegs@provalid.com (Kent Dickey) writes:
>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.
[...]
>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.
Let's see (annotations in the assembly code by me
[/tmp:171793] cat xxx.c
#include <stddef.h>
struct foo {
char x[3];
struct bar {
char u[5];
int v[3];
} y[4];
long z[5];
} a[3];
int bar(size_t i, size_t j, size_t k)
{
return a[i].y[j].v[k];
}
[/tmp:171798] clang -Wall -O -S xxx.c
[/tmp:171799] cat xxx.s
[...]
shlq $7, %rdi #i1=i*sizeof(foo)
leaq a(%rip), %rax #tmp = a
addq %rdi, %rax #a_i = tmp+i1
leaq (%rsi,%rsi,4), %rcx #tmp2 = j*5
leaq (%rax,%rcx,4), %rax #tmp3 = a_i + tmp2*4
movl 12(%rax,%rdx,4), %eax #tmp4 = mem[tmp3+k*4+
# offsetof(struct foo, y)+
# offsetof(struct bar,v)
retq #return tmp4
[...]
[gcc produces code with the same number of instructions, but where the
address computations are more mixed, with even more liberal use of the
associative and distributive laws].
I wanted to map the assembly instructions directly to your code, but
the structure is sufficiently different that I did not find a way.
So let's look at your code:
> tmp = sizeof(foo)
> off = i*tmp + offset(a[0].y[0])
> a_i.ptr = a + off, a_i.bound=sizeof(bar)*4
> tmp = sizeof(bar)
> off = j*tmp + offset(y[0].v[0])
> y_j.ptr = a_i + off, y_j.bound = 3
> out = LOAD(y_j + k)
> [ The above checks that y_j+k is within the y_j range ]
You use an instruction with two source register operands and an
immediate operand. Ok for AMD64, but other instruction sets avoid
instruction formats with such requirements.
For your address computations with bounds, the associative and
distributive laws don't hold, so in addition to the additional
hardware required for holding and computing the bounds, you also
cannot use all the transformations that clang and gcc are using in the
code above.
Anyway, that's the easy case for the bounds checking. What if you
have:
bla = offsetof(struct foo,y)+sizeof(struct bar)*2+offsetof(struct bar, u);
blub = offsetof(struct foo,x);
char *addr = a[2]
if (cond)
c = addr[bla+i];
else
c = addr[blub+i];
And arrange enough interference (e.g., indirect calls or returns) that
using code duplication or somesuch to preserve knowledge becomes
impossible or at least impractical. How does architectural bounds
checking deal with that.
You might ask, how doing it at the language level would deal with
that. The programmers will have to find a way to explain what they
want to do in a way that's compatible with the bounds-checking
programming language. I am not sure how that would be done in Rust;
at worst one can chicken out and use unsafe Rust.
For something like Ivy/Deputy, I expect that a solution would be for
the programmers to turn bla and blub into structs that contain the
address, and type/bounds information (not sure if Deputy supports that
also for types, but one can image that an updated Deputy does), and
then have an annotation that i must be within the bounds for the type
speficied in bla or blub.
- 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 | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-06 10:44 -0400 |
| Message-ID | <i%enS.772$eXV3.329@fx39.iad> |
| In reply to | #117764 |
On 2026-Sep-04 21:08, MitchAlsup wrote: > > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > > Looking forward:: > > a) What kind of distinction should architects make between pointers > and addresses ?? My knee jerk reaction is 'none' - those are language issues. > b) are there other ways to make capabilities cheaper without losing > their protection properties ?? > > As to (a) a pointer could have some bits used to restrict access > rights. So, one could create a read-only pointer and use it only > for reading even when the PTE says it is writeable. That is normally left to the high level language because each language has it own set rules, and those rules can change. For example, in Ada a routine argument marked as 'out' is considered an uninitialized variable that must be written before the routine returns, and must be written before it is read. Ada85 originally did not allow 'out' arguments to be read after writing as 'out' meant write-only. But that was a stupid restriction which was just inconvenient so they later changed it to read-after-write. Do you really want to incorporate that into hardware? And if a pointer has a bit marking it as read-only then what stops me clearing that bit? Unless you make "pointer" a first class HW type with its own set of instructions. But then you also need the ability to bypass any "pointer" restrictions to handle things like Anton's software defined tagged integer-pointers. This is the problem with capabilities systems - they balloon very quickly. As HW tries to take on ALL the capabilities different languages might ever require, the generic nature of them drags in inefficiencies and they wind up as "a jack of all trades but a master of none". > As to (b) a capability might have a 64-bit pointer and a 64-bit > index into a capability table hidden in Guest OS address space. And what is in that hidden indexed capability table? To be flexible enough to handle any data type it would be a pointer to a privileged routine. And there is the ballooning. Microcode by any other name would smell as sweet. If programmers just used languages that checked array indexes then 99.999% of memory access errors would disappear. First make array index checks simple and cheap. This requires checked arithmetic for the index expression calculation, plus a set of simple compare-and-fault instructions various bounds checks. Then see what's left to address.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-06 14:56 +0000 |
| Message-ID | <117juut$2erud$1@dont-email.me> |
| In reply to | #117789 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb: > If programmers just used languages that checked array indexes > then 99.999% of memory access errors would disappear. Retrofitting memory safety onto C is an uphill battle. Address arithmetic stands in the way of that. > First make array index checks simple and cheap. > This requires checked arithmetic for the index expression calculation, > plus a set of simple compare-and-fault instructions various bounds checks. You would probably need more than 32 registers for this... Also, smarten up compilers so they move as much as possible of the checking outside of loops. > Then see what's left to address. Use after free will still be a problem, but maybe INVALIDATE can help there. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-06 12:58 -0400 |
| Message-ID | <kZgnS.16063$%N1.3403@fx16.iad> |
| In reply to | #117790 |
On 2026-Sep-06 10:56, Thomas Koenig wrote: > EricP <ThatWouldBeTelling@thevillage.com> schrieb: > >> If programmers just used languages that checked array indexes >> then 99.999% of memory access errors would disappear. > > Retrofitting memory safety onto C is an uphill battle. Address > arithmetic stands in the way of that. It might be possible to do but no one is interested. Making arrays a first class type and distinct from pointers would be the first step but would not be backwards compatible. Have different kinds of pointers: object pointers that may/may-not be NULL but don't allow pointer arithmetic, array element pointers that only point inside a particular array (so they can be bounds checked) and do allow pointer arithmetic. >> First make array index checks simple and cheap. >> This requires checked arithmetic for the index expression calculation, >> plus a set of simple compare-and-fault instructions various bounds checks. > > You would probably need more than 32 registers for this... No, there is no difference in register allocation. Use an ADDFS Add Fault Signed Overflow or ADDFU Add Fault Unsigned wrap instead of the unchecked ADD. MULS or MULU return a double wide register pair, and the high word then checked if != 0 to detect expression overflow - FLTNZ Fault if reg != 0. So 1 extra instruction to check each multiply for overflow. Or one can incorporate the overflow check into the MULFS Multiply Fault Signed or MULFU Fault Unsigned overflow and return a single wide result. Then a check the index register is < limit, FLTGE Fault if reg >= reg or imm. The index register is then used with a scaled-index addressing. For almost all array indexes the cost is a single reg-reg or reg-imm instruction. > Also, smarten up compilers so they move as much as possible of the > checking outside of loops. > >> Then see what's left to address. > > Use after free will still be a problem, but maybe INVALIDATE > can help there. I have difficulty judging use-after-free errors. I don't recall ever having had a use-after-free error ever since I started writing C in 1992 when I switched to developing on WinNT. But I'm fairly paranoid so I do things like having my own Assert() routines that throw my own fatal exceptions on errors and remain in production code, put validity check markers on all heap allocated objects and assert they are valid before using, on free zap the validity markers and NULL the pointer. Consequently if such programming error did happen, my code should immediately detect it itself and throw a fatal exception.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-06 12:04 -0700 |
| Message-ID | <117kdgl$2kkqr$1@dont-email.me> |
| In reply to | #117793 |
On 9/6/2026 9:58 AM, EricP wrote: > On 2026-Sep-06 10:56, Thomas Koenig wrote: >> EricP <ThatWouldBeTelling@thevillage.com> schrieb: >> >>> If programmers just used languages that checked array indexes >>> then 99.999% of memory access errors would disappear. >> >> Retrofitting memory safety onto C is an uphill battle. Address >> arithmetic stands in the way of that. > > It might be possible to do but no one is interested. Agreed. > Making arrays a first class type and distinct from pointers > would be the first step but would not be backwards compatible. Also agreed. > Have different kinds of pointers: object pointers > that may/may-not be NULL but don't allow pointer arithmetic, > array element pointers that only point inside a particular array > (so they can be bounds checked) and do allow pointer arithmetic. Would just disallowing arithmetic on pointers, thus forcing array references to use the existing subscript mechanism, be sufficient? Then you don't need two types of pointers. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-06 23:59 +0000 |
| Message-ID | <1788739198-5857@newsgrouper.org> |
| In reply to | #117800 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
> On 9/6/2026 9:58 AM, EricP wrote:
> > On 2026-Sep-06 10:56, Thomas Koenig wrote:
> >> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> >>
> >>> If programmers just used languages that checked array indexes
> >>> then 99.999% of memory access errors would disappear.
> >>
> >> Retrofitting memory safety onto C is an uphill battle. Address
> >> arithmetic stands in the way of that.
> >
> > It might be possible to do but no one is interested.
>
> Agreed.
>
> > Making arrays a first class type and distinct from pointers
> > would be the first step but would not be backwards compatible.
>
> Also agreed.
>
> > Have different kinds of pointers: object pointers
> > that may/may-not be NULL but don't allow pointer arithmetic,
> > array element pointers that only point inside a particular array
> > (so they can be bounds checked) and do allow pointer arithmetic.
>
> Would just disallowing arithmetic on pointers, thus forcing array
> references to use the existing subscript mechanism, be sufficient? Then
> you don't need two types of pointers.
On modern RISC ISAs:
for( i = 0; i < max; i++ )
p[i]
is often faster than:
for( i = 0; i < max; i++ )
*p++
Especially when there are more than 1 structure being accessed as an array.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-07 04:29 +0000 |
| Message-ID | <117lejp$2uhjg$5@dont-email.me> |
| In reply to | #117809 |
On Sun, 06 Sep 2026 23:59:58 GMT, MitchAlsup wrote: > On modern RISC ISAs: > > for( i = 0; i < max; i++ ) > p[i] > > is often faster than: > > for( i = 0; i < max; i++ ) > *p++ > > Especially when there are more than 1 structure being accessed as an > array. Dang. There goes all that old PDP-11 code. ;)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-07 10:40 +0200 |
| Message-ID | <117lta4$312k1$2@dont-email.me> |
| In reply to | #117809 |
On 07/09/2026 01:59, MitchAlsup wrote: > > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted: > >> On 9/6/2026 9:58 AM, EricP wrote: >>> On 2026-Sep-06 10:56, Thomas Koenig wrote: >>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb: >>>> >>>>> If programmers just used languages that checked array indexes >>>>> then 99.999% of memory access errors would disappear. >>>> >>>> Retrofitting memory safety onto C is an uphill battle. Address >>>> arithmetic stands in the way of that. >>> >>> It might be possible to do but no one is interested. >> >> Agreed. >> >>> Making arrays a first class type and distinct from pointers >>> would be the first step but would not be backwards compatible. >> >> Also agreed. >> >>> Have different kinds of pointers: object pointers >>> that may/may-not be NULL but don't allow pointer arithmetic, >>> array element pointers that only point inside a particular array >>> (so they can be bounds checked) and do allow pointer arithmetic. >> >> Would just disallowing arithmetic on pointers, thus forcing array >> references to use the existing subscript mechanism, be sufficient? Then >> you don't need two types of pointers. > > On modern RISC ISAs: > > for( i = 0; i < max; i++ ) > p[i] > > is often faster than: > > for( i = 0; i < max; i++ ) > *p++ > > Especially when there are more than 1 structure being accessed as an array. That is up to the compiler, and dependent on types and additional surrounding code. For "typical" usage - "i" and "p" as local variables, and "i" being either a signed integer type or a size_t (i.e., not a 32-bit unsigned int on a 64-bit machine), and using an optimising compiler, I would not expect any difference in the code. But if you can find a more complete example that can be tested on godbolt, it would be very interesting.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-07 18:25 +0000 |
| Message-ID | <1788805554-5857@newsgrouper.org> |
| In reply to | #117825 |
David Brown <david.brown@hesbynett.no> posted:
> On 07/09/2026 01:59, MitchAlsup wrote:
> >
> > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
> >
> >> On 9/6/2026 9:58 AM, EricP wrote:
> >>> On 2026-Sep-06 10:56, Thomas Koenig wrote:
> >>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> >>>>
> >>>>> If programmers just used languages that checked array indexes
> >>>>> then 99.999% of memory access errors would disappear.
> >>>>
> >>>> Retrofitting memory safety onto C is an uphill battle. Address
> >>>> arithmetic stands in the way of that.
> >>>
> >>> It might be possible to do but no one is interested.
> >>
> >> Agreed.
> >>
> >>> Making arrays a first class type and distinct from pointers
> >>> would be the first step but would not be backwards compatible.
> >>
> >> Also agreed.
> >>
> >>> Have different kinds of pointers: object pointers
> >>> that may/may-not be NULL but don't allow pointer arithmetic,
> >>> array element pointers that only point inside a particular array
> >>> (so they can be bounds checked) and do allow pointer arithmetic.
> >>
> >> Would just disallowing arithmetic on pointers, thus forcing array
> >> references to use the existing subscript mechanism, be sufficient? Then
> >> you don't need two types of pointers.
> >
> > On modern RISC ISAs:
> >
> > for( i = 0; i < max; i++ )
> > p[i]
> >
> > is often faster than:
> >
> > for( i = 0; i < max; i++ )
> > *p++
> >
> > Especially when there are more than 1 structure being accessed as an array.
>
> That is up to the compiler, and dependent on types and additional
> surrounding code. For "typical" usage - "i" and "p" as local variables,
> and "i" being either a signed integer type or a size_t (i.e., not a
> 32-bit unsigned int on a 64-bit machine), and using an optimising
> compiler, I would not expect any difference in the code.
The second has 2 ADDs {i++ and p++; i of 1 and p of 4} it takes a lot
of strength reduction to figure out that only 1 ADD is needed.
> But if you can find a more complete example that can be tested on
> godbolt, it would be very interesting.
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-07 23:10 +0200 |
| Message-ID | <117n97r$3khj3$1@dont-email.me> |
| In reply to | #117832 |
On 07/09/2026 20:25, MitchAlsup wrote:
>
> David Brown <david.brown@hesbynett.no> posted:
>
>> On 07/09/2026 01:59, MitchAlsup wrote:
>>>
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
>>>
>>>> On 9/6/2026 9:58 AM, EricP wrote:
>>>>> On 2026-Sep-06 10:56, Thomas Koenig wrote:
>>>>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>>>>>
>>>>>>> If programmers just used languages that checked array indexes
>>>>>>> then 99.999% of memory access errors would disappear.
>>>>>>
>>>>>> Retrofitting memory safety onto C is an uphill battle. Address
>>>>>> arithmetic stands in the way of that.
>>>>>
>>>>> It might be possible to do but no one is interested.
>>>>
>>>> Agreed.
>>>>
>>>>> Making arrays a first class type and distinct from pointers
>>>>> would be the first step but would not be backwards compatible.
>>>>
>>>> Also agreed.
>>>>
>>>>> Have different kinds of pointers: object pointers
>>>>> that may/may-not be NULL but don't allow pointer arithmetic,
>>>>> array element pointers that only point inside a particular array
>>>>> (so they can be bounds checked) and do allow pointer arithmetic.
>>>>
>>>> Would just disallowing arithmetic on pointers, thus forcing array
>>>> references to use the existing subscript mechanism, be sufficient? Then
>>>> you don't need two types of pointers.
>>>
>>> On modern RISC ISAs:
>>>
>>> for( i = 0; i < max; i++ )
>>> p[i]
>>>
>>> is often faster than:
>>>
>>> for( i = 0; i < max; i++ )
>>> *p++
>>>
>>> Especially when there are more than 1 structure being accessed as an array.
>>
>> That is up to the compiler, and dependent on types and additional
>> surrounding code. For "typical" usage - "i" and "p" as local variables,
>> and "i" being either a signed integer type or a size_t (i.e., not a
>> 32-bit unsigned int on a 64-bit machine), and using an optimising
>> compiler, I would not expect any difference in the code.
>
> The second has 2 ADDs {i++ and p++; i of 1 and p of 4} it takes a lot
> of strength reduction to figure out that only 1 ADD is needed.
>
The first one has two adds too - i++, and (p + i) for the array access.
(I'm assuming that there is more going on inside the loop in real code,
such as at least reading or writing from the array. Otherwise the
compiler can see that the whole thing is doing nothing and skip it.)
In both cases, optimisers are likely to generate code approximating :
q = &p[max];
while (p < q) {
p++;
}
(Again, I assume there's a read or write to be included inside the loop.)
Sometimes pointer / array accesses with increment cannot be optimised as
well if the index is an unsigned type smaller than size_t, because the
compiler can't rule out the possibility of the index wrapping. This is
not an issue with signed integer types, or a big enough unsigned type,
nor is it an issue here when the limits of the index are known. And it
is independent of the ISA.
>> But if you can find a more complete example that can be tested on
>> godbolt, it would be very interesting.
>>
Again, if you can give a more complete example, it would be easier to
see what you are getting at here, because I cannot yet see your point.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-07 21:58 +0000 |
| Message-ID | <1788818323-5857@newsgrouper.org> |
| In reply to | #117836 |
David Brown <david.brown@hesbynett.no> posted:
> On 07/09/2026 20:25, MitchAlsup wrote:
> >
> > David Brown <david.brown@hesbynett.no> posted:
> >
> >> On 07/09/2026 01:59, MitchAlsup wrote:
> >>>
> >>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
> >>>
> >>>> On 9/6/2026 9:58 AM, EricP wrote:
> >>>>> On 2026-Sep-06 10:56, Thomas Koenig wrote:
> >>>>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> >>>>>>
> >>>>>>> If programmers just used languages that checked array indexes
> >>>>>>> then 99.999% of memory access errors would disappear.
> >>>>>>
> >>>>>> Retrofitting memory safety onto C is an uphill battle. Address
> >>>>>> arithmetic stands in the way of that.
> >>>>>
> >>>>> It might be possible to do but no one is interested.
> >>>>
> >>>> Agreed.
> >>>>
> >>>>> Making arrays a first class type and distinct from pointers
> >>>>> would be the first step but would not be backwards compatible.
> >>>>
> >>>> Also agreed.
> >>>>
> >>>>> Have different kinds of pointers: object pointers
> >>>>> that may/may-not be NULL but don't allow pointer arithmetic,
> >>>>> array element pointers that only point inside a particular array
> >>>>> (so they can be bounds checked) and do allow pointer arithmetic.
> >>>>
> >>>> Would just disallowing arithmetic on pointers, thus forcing array
> >>>> references to use the existing subscript mechanism, be sufficient? Then
> >>>> you don't need two types of pointers.
> >>>
> >>> On modern RISC ISAs:
> >>>
> >>> for( i = 0; i < max; i++ )
> >>> p[i]
> >>>
> >>> is often faster than:
> >>>
> >>> for( i = 0; i < max; i++ )
> >>> *p++
> >>>
> >>> Especially when there are more than 1 structure being accessed as an array.
> >>
> >> That is up to the compiler, and dependent on types and additional
> >> surrounding code. For "typical" usage - "i" and "p" as local variables,
> >> and "i" being either a signed integer type or a size_t (i.e., not a
> >> 32-bit unsigned int on a 64-bit machine), and using an optimising
> >> compiler, I would not expect any difference in the code.
> >
> > The second has 2 ADDs {i++ and p++; i of 1 and p of 4} it takes a lot
> > of strength reduction to figure out that only 1 ADD is needed.
> >
>
> The first one has two adds too - i++, and (p + i) for the array access.
The p+i addition is part of AGEN and thus free for any ISA that has at
least [Rpointer+Rindex] addressing mode (everybody but RISC-V).
> (I'm assuming that there is more going on inside the loop in real code,
> such as at least reading or writing from the array. Otherwise the
> compiler can see that the whole thing is doing nothing and skip it.)
>
> In both cases, optimisers are likely to generate code approximating :
>
> q = &p[max];
> while (p < q) {
> p++;
> }
>
> (Again, I assume there's a read or write to be included inside the loop.)
>
> Sometimes pointer / array accesses with increment cannot be optimised as
> well if the index is an unsigned type smaller than size_t, because the
> compiler can't rule out the possibility of the index wrapping. This is
> not an issue with signed integer types, or a big enough unsigned type,
> nor is it an issue here when the limits of the index are known. And it
> is independent of the ISA.
>
>
> >> But if you can find a more complete example that can be tested on
> >> godbolt, it would be very interesting.
> >>
>
> Again, if you can give a more complete example, it would be easier to
> see what you are getting at here, because I cannot yet see your point.
for( i = 0; i < max; i++ )
a[i] = b[i] + c[i];
versus
for( i = 0; i < max; i++ )
*a++ = *b++ + *c++;
The former has 1 add per iteration, the later has 4.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-08 05:30 +0000 |
| Message-ID | <117o6ho$3t3l5$1@dont-email.me> |
| In reply to | #117838 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > > David Brown <david.brown@hesbynett.no> posted: >> Again, if you can give a more complete example, it would be easier to >> see what you are getting at here, because I cannot yet see your point. > > for( i = 0; i < max; i++ ) > a[i] = b[i] + c[i]; > > versus > > for( i = 0; i < max; i++ ) > *a++ = *b++ + *c++; > > The former has 1 add per iteration, the later has 4. https://godbolt.org/z/6h84fzYc1 shows that the generated code is identical. A lot of work has gone into optimizing strength reduction. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-08 11:20 +0200 |
| Message-ID | <117ok0n$3ui33$3@dont-email.me> |
| In reply to | #117838 |
On 07/09/2026 23:58, MitchAlsup wrote:
>
> David Brown <david.brown@hesbynett.no> posted:
>
>> On 07/09/2026 20:25, MitchAlsup wrote:
>>>
>>> David Brown <david.brown@hesbynett.no> posted:
>>>
>>>> On 07/09/2026 01:59, MitchAlsup wrote:
>>>>>
>>>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
>>>>>
>>>>>> On 9/6/2026 9:58 AM, EricP wrote:
>>>>>>> On 2026-Sep-06 10:56, Thomas Koenig wrote:
>>>>>>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>>>>>>>
>>>>>>>>> If programmers just used languages that checked array indexes
>>>>>>>>> then 99.999% of memory access errors would disappear.
>>>>>>>>
>>>>>>>> Retrofitting memory safety onto C is an uphill battle. Address
>>>>>>>> arithmetic stands in the way of that.
>>>>>>>
>>>>>>> It might be possible to do but no one is interested.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> Making arrays a first class type and distinct from pointers
>>>>>>> would be the first step but would not be backwards compatible.
>>>>>>
>>>>>> Also agreed.
>>>>>>
>>>>>>> Have different kinds of pointers: object pointers
>>>>>>> that may/may-not be NULL but don't allow pointer arithmetic,
>>>>>>> array element pointers that only point inside a particular array
>>>>>>> (so they can be bounds checked) and do allow pointer arithmetic.
>>>>>>
>>>>>> Would just disallowing arithmetic on pointers, thus forcing array
>>>>>> references to use the existing subscript mechanism, be sufficient? Then
>>>>>> you don't need two types of pointers.
>>>>>
>>>>> On modern RISC ISAs:
>>>>>
>>>>> for( i = 0; i < max; i++ )
>>>>> p[i]
>>>>>
>>>>> is often faster than:
>>>>>
>>>>> for( i = 0; i < max; i++ )
>>>>> *p++
>>>>>
>>>>> Especially when there are more than 1 structure being accessed as an array.
>>>>
>>>> That is up to the compiler, and dependent on types and additional
>>>> surrounding code. For "typical" usage - "i" and "p" as local variables,
>>>> and "i" being either a signed integer type or a size_t (i.e., not a
>>>> 32-bit unsigned int on a 64-bit machine), and using an optimising
>>>> compiler, I would not expect any difference in the code.
>>>
>>> The second has 2 ADDs {i++ and p++; i of 1 and p of 4} it takes a lot
>>> of strength reduction to figure out that only 1 ADD is needed.
>>>
>>
>> The first one has two adds too - i++, and (p + i) for the array access.
>
> The p+i addition is part of AGEN and thus free for any ISA that has at
> least [Rpointer+Rindex] addressing mode (everybody but RISC-V).
>
>> (I'm assuming that there is more going on inside the loop in real code,
>> such as at least reading or writing from the array. Otherwise the
>> compiler can see that the whole thing is doing nothing and skip it.)
>>
>> In both cases, optimisers are likely to generate code approximating :
>>
>> q = &p[max];
>> while (p < q) {
>> p++;
>> }
>>
>> (Again, I assume there's a read or write to be included inside the loop.)
>>
>> Sometimes pointer / array accesses with increment cannot be optimised as
>> well if the index is an unsigned type smaller than size_t, because the
>> compiler can't rule out the possibility of the index wrapping. This is
>> not an issue with signed integer types, or a big enough unsigned type,
>> nor is it an issue here when the limits of the index are known. And it
>> is independent of the ISA.
>>
>>
>>>> But if you can find a more complete example that can be tested on
>>>> godbolt, it would be very interesting.
>>>>
>>
>> Again, if you can give a more complete example, it would be easier to
>> see what you are getting at here, because I cannot yet see your point.
>
> for( i = 0; i < max; i++ )
> a[i] = b[i] + c[i];
>
> versus
>
> for( i = 0; i < max; i++ )
> *a++ = *b++ + *c++;
>
> The former has 1 add per iteration, the later has 4.
enum { max = 100 };
extern int a[max];
extern int b[max];
extern int c[max];
void foo(void) {
for (int i = 0; i < max; i++) {
a[i] = b[i] + c[i];
}
}
void bar(void) {
int * p = a;
int * q = b;
int * r = c;
for (int i = 0; i < max; i++) {
*p++ = *q++ + *r++;
}
}
I tried that with a half-dozen gcc targets on godbolt, all with -O2.
ARM 32-bit ARM 64-bit, x86 64-bit, RISC-V, Power. I also tried clang
and MSVC with various targets. Sometimes the clang code was too
unrolled to compare sensibly, but I could find no cases where the code
for "foo" and "bar" was different in any significant way. There were
minor changes to the ordering of the instructions or the choice of
registers, but otherwise the code was identical.
Compilers are smart enough to know that the two formulations do the same
thing. They have been able to do so for decades.
On x86, both functions use addressing modes that match "a + j", "b + j",
"c + j", and increment "j" by a stride value until it reaches 400 (so
"j" is "i * 4"). The stride depends on the SIMD vector width used, and
any unrolling.
On RISC cpus, both functions use addressing modes that match "*p++" -
where the post-increment is included in the instruction. No counter
variable is used at all, and the loop stops by comparing one of the
pointers to the end of the array.
Even if you have a RISC processor that does not have a "post-increment"
addressing operation, optimising compilers would still generate
approximately the same code for each formulation here.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-09 12:23 -0400 |
| Message-ID | <117sfml$1f6ka$1@dont-email.me> |
| In reply to | #117838 |
On 9/7/26 5:58 PM, MitchAlsup wrote:
>
> David Brown <david.brown@hesbynett.no> posted:
>
>> On 07/09/2026 20:25, MitchAlsup wrote:
>>>
>>> David Brown <david.brown@hesbynett.no> posted:
>>>
>>>> On 07/09/2026 01:59, MitchAlsup wrote:
[snip]
>>>>> On modern RISC ISAs:
>>>>>
>>>>> for( i = 0; i < max; i++ )
>>>>> p[i]
>>>>>
>>>>> is often faster than:
>>>>>
>>>>> for( i = 0; i < max; i++ )
>>>>> *p++
>>>>>
>>>>> Especially when there are more than 1 structure being accessed as an array.
[snip]
>>> The second has 2 ADDs {i++ and p++; i of 1 and p of 4} it takes a lot
>>> of strength reduction to figure out that only 1 ADD is needed.
>>>
>>
>> The first one has two adds too - i++, and (p + i) for the array access.
>
> The p+i addition is part of AGEN and thus free for any ISA that has at
> least [Rpointer+Rindex] addressing mode (everybody but RISC-V).
Itanium (not a RISC and probably most appropriate to use past
tense though it may not yet be exclusively a
collector's/museum's ISA) had even weaker address modes. If I
recall correctly post-increment by constant was the most
complex.
Itanium intended to avoid some load latency with this simple
addressing (presumably under the assumption that width was
"free"). Even the small shift amount seems likely to add a
bit of latency (the shift amount being provided by the
instruction might slightly reduce this), but two layers of
muxes (correct?) to shift by zero to three would not add that
much delay I guess. (My 66000 adds a tiny bit of extra delay
by supporting a third constant addend.)
(For loops, it seems to me that one could use a pre-shifted
index. This would reduce the range of short (e.g., 32-bit)
indexes (constant range comparisons) and require adding a
"shifted unit" to the index rather than one (possibly not
supported with a short increment instruction). Such is also
limited to the same member size of all arrays using the same
index and would be more challenging for the compiler. Such an
index would also have to be recognized as an array base offset
rather than a true index (when passed as an argument or stored
for later use).)
This delay would seem to affect the cycle time of all
instructions or force such loads to take an additional cycle or
require folding the delay into all loads (the latency difference
is presumably too small to be exactly compensated by a change in
cache size or associativity). With frequency binning (and the
smallness of the latency difference), such would presumably
actually just modestly affect the commonness of better bins.
For the MIPS R2000, providing a third source operand for stores
would have been problematic. (GPR loads and FPR memory accesses
could have been supported, though that complicates the
compiler.) Pushing the read of the stored register value into
the load delay slot might have worked, but that would have
limited load delay slot instructions to those with one register
operand. I think the lack of interlocks meant that a register
read hazard could not just stall the pipeline. Banking might
have allowed sufficient filling of the load delay slot (the
two sources in the load delay slot could not both be in the same
bank as the stored register), but banking would have complicated
register allocation even if limited to load delay slots for
indexed stores.
[I also feel that implementing the branch delay slot as a
"two-parcel" complex instruction fused with the branch
instruction would have been better for exception handling.
Avoiding delayed branches would have been better in the long
term, but I am not certain whether alternatives would have been
acceptable in terms of design time, area, and performance. For
(inner) loops, a single BTB entry might have sufficed; for
forward branches predict not taken might have sufficed, but
misprediction correction might not have played well with the
lack of interlocks. For unconditional jumps, I do not know
what could have been done without predecoding or scan ahead or
large BTBs. (I do not think scanning ahead was an option at the
time unless one had common 16-bit instructions. "Simple"
predecoding — a bit to indicate an immediate control flow
instruction and replacement of the immediate offset with an
inset, perhaps with a carry/borrow bit to allow full offset
range rather than comparing the two most significant bits of
the inset with the instruction address to determine an
"overflow" — would introduce aliasing issues unless code
pages were page colored or virtual tagging was used in the
instruction cache.)]
Besides probably not thinking of such at the time (FPR indexed
memory accesses were added later so not everything was
understood initially), borrowing operand read resources across
instructions would have complicated the pipeline. I _think_
this would not have added significant delay and I *guess* that
it would not add significant area. A banking requirement might
also be removed in later implementations (like the removal of
the load delay slot, such relaxing of requirements allows old
software to run on new systems though not necessarily all new
software to run on old systems). (Development delay was also
important for commercial MIPS, both of the hardware and the
compiler.)
[I *feel* that architectural banking, and other software
cooperation, is underexploited. Of course, I have never written
a compiler or even designed a paper ISA.]
Obviously, the tradeoffs are very different in 2026 than in
1986. The understanding of the tradeoffs among experts has
probably also increased.
I get the impression that RISC-V's design choice was urged by
the desire for teaching a simple implementation (with
"everything is an extension" 3-input instructions could have
been pushed to an extension, so a specialized processor would
not have had to pay for such). I wonder if a better teaching
tactic would have been to design a complete, sophisticated ISA
and either ignore the complex/difficult aspects (subsetting)
or provide exploration of the tradeoffs and means of moderating
those tradeoffs.
I guess using an implicit return address register would have
been an unavoidable complication of even simple subset
implementations. Sacrificing five bits of target immediate seems
a high price for such simplicity (especially for a destination
operand). Of course, the C extension then adds implicit sources
(for stack accesses) and different register field placements
(not just size reduction — though a 16-bit instruction could
only have two register fields if the fields were in the same
positions as in 32-bit instructions) and became standard for the
"application" profile. (Besides avoiding implicit registers,
there was also a desire to support different return address
registers for co-routines and otherwise to avoid return address
predictor pollution.)
RISC-V also suffers from its development/release schedule. The
lack of iterative and thorough development before design choices
were unalterable lead to inconsistencies and avoidable
complexity. There also seems to have been a conceptual bias
related to the extension focus where extensions are viewed as
fully independent. E.g., the extension for code density was
"compressed instructions" (duplicating 32-bit instructions,
which was partially for implementation/conceptual simplicity)
with no consideration for how 32-bit instructions could be
provided to improve code density.
This might also be influenced by the collaborative aspect of
RISC-V design. Component isolation reduces communication
overheads. Extreme isolation encourages fragmentation (aspects
not included in the original design mandate require a separate
component/extension), design limitation (an implementation
detail may benefit a possible feature insufficiently relative to
cost to justify the feature but be partially needed for features
in other components), and design conflict (where some costs are
transferred outside of the component's design concerns).
[Once more, my mind is wandering. Almost all of the above is
probably already understood by posters here, though perhaps a
lurker might learn something — hopefully nothing false.]
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-10 03:47 +0000 |
| Message-ID | <117t996$1lvto$3@dont-email.me> |
| In reply to | #117910 |
On Wed, 9 Sep 2026 12:23:31 -0400, Paul Clayton wrote: > Itanium (not a RISC and probably most appropriate to use past tense > though it may not yet be exclusively a collector's/museum's ISA) ... If the Linux kernel drops support for it, you know it can’t have much life left in it. ;)
[toc] | [prev] | [next] | [standalone]
| From | Josh Vanderhoof <x@y.z> |
|---|---|
| Date | 2026-09-07 18:22 -0400 |
| Message-ID | <ygn8q5c1z24.fsf@y.z> |
| In reply to | #117832 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> David Brown <david.brown@hesbynett.no> posted:
>
>> On 07/09/2026 01:59, MitchAlsup wrote:
>> > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
>> >> On 9/6/2026 9:58 AM, EricP wrote:
>> >>> On 2026-Sep-06 10:56, Thomas Koenig wrote:
>> >>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>> >>>>
>> >>>>> If programmers just used languages that checked array
>> >>>>> indexes then 99.999% of memory access errors would
>> >>>>> disappear.
>> >>>>
>> >>>> Retrofitting memory safety onto C is an uphill battle.
>> >>>> Address arithmetic stands in the way of that.
>> >>>
>> >>> It might be possible to do but no one is interested.
>> >>
>> >> Agreed.
>> >>
>> >>> Making arrays a first class type and distinct from pointers
>> >>> would be the first step but would not be backwards
>> >>> compatible.
>> >>
>> >> Also agreed.
>> >>
>> >>> Have different kinds of pointers: object pointers that
>> >>> may/may-not be NULL but don't allow pointer arithmetic,
>> >>> array element pointers that only point inside a particular
>> >>> array (so they can be bounds checked) and do allow pointer
>> >>> arithmetic.
>> >>
>> >> Would just disallowing arithmetic on pointers, thus forcing
>> >> array references to use the existing subscript mechanism, be
>> >> sufficient? Then you don't need two types of pointers.
>> > On modern RISC ISAs:
>> > for( i = 0; i < max; i++ )
>> > p[i]
>> > is often faster than:
>> > for( i = 0; i < max; i++ )
>> > *p++
>> > Especially when there are more than 1 structure being
>> > accessed as an array.
>> That is up to the compiler, and dependent on types and
>> additional surrounding code. For "typical" usage - "i" and
>> "p" as local variables, and "i" being either a signed integer
>> type or a size_t (i.e., not a 32-bit unsigned int on a 64-bit
>> machine), and using an optimising compiler, I would not expect
>> any difference in the code.
>
> The second has 2 ADDs {i++ and p++; i of 1 and p of 4} it takes
> a lot of strength reduction to figure out that only 1 ADD is
> needed.
It's identical for a good compiler.
Or even compilers that emit "mov esi, esi" ;)
x86-64 gcc 16.2 -O3
void clear_array(int *p, int max) {
int i; for (i = 0; i < max; i++)
p[i] = 0;
} void clear_postinc(int *p, int max) {
int i; for (i = 0; i < max; i++)
*p++ = 0;
}
"clear_array(int*, int)":
test esi, esi jle .L1 mov esi, esi lea rdx,
[0+rsi*4] xor esi, esi jmp "memset"
.L1:
ret
"clear_postinc(int*, int)":
test esi, esi jle .L4 mov esi, esi lea rdx,
[0+rsi*4] xor esi, esi jmp "memset"
.L4:
ret
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-07 13:28 -0400 |
| Message-ID | <_uCnS.41$Sh34.37@fx03.iad> |
| In reply to | #117800 |
On 2026-Sep-06 15:04, Stephen Fuld wrote:
> On 9/6/2026 9:58 AM, EricP wrote:
>> On 2026-Sep-06 10:56, Thomas Koenig wrote:
>>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>>
>>>> If programmers just used languages that checked array indexes
>>>> then 99.999% of memory access errors would disappear.
>>>
>>> Retrofitting memory safety onto C is an uphill battle. Address
>>> arithmetic stands in the way of that.
>>
>> It might be possible to do but no one is interested.
>
> Agreed.
>
>> Making arrays a first class type and distinct from pointers
>> would be the first step but would not be backwards compatible.
>
> Also agreed.
>
>> Have different kinds of pointers: object pointers
>> that may/may-not be NULL but don't allow pointer arithmetic,
>> array element pointers that only point inside a particular array
>> (so they can be bounds checked) and do allow pointer arithmetic.
>
> Would just disallowing arithmetic on pointers, thus forcing array references to use the existing subscript mechanism, be sufficient? Then you don't need two types of pointers.
I was thinking of something that programmers could easily
adopt which would assist them in detecting bugs.
Forcing them to rewrite their code to add a level of indirection
through integer indexes I think would pretty much guarantee
it would not be used.
The kind of thing I had in mind might be if "in" was a reserved word
so one could write
{
int vec1[32], vec2[64],
*ptr1a in vec1 = vec1[0],
*ptr1b in vec1 = vec1[0],
*ptr2 in vec2 = vec2[0];
would create three int pointers with distinct data types
different from *int and each other, such that assigning between
ptr1a or ptr1b and ptr2 or *int causes a type mismatch warning,
but assignment between ptr1a and ptr1b is allowed because
they both reference inside the same object vec1.
Bounded pointers ptr1a, ptr1b, ptr2 can be manipulated with
arithmetic expressions whereas object pointers cannot.
At runtime when a bounded pointer is dereferenced the address is
bounds checked against its array buffer lower and upper address limits.
Arrays are first class types and carry their element count
with them when passed as arguments as an invisible extra argument.
Zero element count or null arrays are possible.
A null array does not necessarily have an valid buffer address
and the element count must be tested first.
An array slice range is indicated with an ellipsis array[low_exp...upr_exp]
and zero/null slices of arrays are possible when the slice
lower bound > upper bound.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-07 18:33 +0000 |
| Subject | Addressing Shared Stuff |
| Message-ID | <1788805992-5857@newsgrouper.org> |
| In reply to | #117829 |
ASIDs came along in the late 1990s and early 2000s to better optimize
MMU resource consumption {fewer flushes, support nested paging, ...}.
With their advent, ASIDs were assigned to threads/processes.
Has anyone ever wanted to allow shared ASIDs in such a way that shared
memory or shared files have the ASID associated with the memory/file ?
So that multiple processes accessing the same shared resource co-optim-
ize themselves across cores and caches ??
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-08 15:48 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <g7WnS.2$e54.0@fx15.iad> |
| In reply to | #117833 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>ASIDs came along in the late 1990s and early 2000s to better optimize
>MMU resource consumption {fewer flushes, support nested paging, ...}.
>
>With their advent, ASIDs were assigned to threads/processes.
>
>Has anyone ever wanted to allow shared ASIDs in such a way that shared
>memory or shared files have the ASID associated with the memory/file ?
>So that multiple processes accessing the same shared resource co-optim-
>ize themselves across cores and caches ??
Consider that the ASID (and VMID generally speaking) must be present
in every TLB entry, so the size of the ASID (arm supports 8 or 16 bit ASIDS)
determines the overall size of the TLB (along with the entry count).
Even with 16-bit ASIDs, large systems with more than 64k processes (not
uncommon with 1000-thread processors) will suffer during ASID rollover
events. Associating ASIDs with other resources (such as memory objects)
complicates the ASID rollever and assignment functionality without
corresponding performance benefits. Using the G (Global) flag on those
architectures which support it often provides similar benefits where
applicable.
Additionally, for your suggestion to be viable, every use of the shared
object (memory, file pages) must be mapped at the same virtual address;
which is considered a defect (see System V shared libraries for example),
even with the larger (48-bit) virtual address space on modern CPUs.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-08 20:05 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <1788897922-5857@newsgrouper.org> |
| In reply to | #117870 |
scott@slp53.sl.home (Scott Lurndal) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >ASIDs came along in the late 1990s and early 2000s to better optimize
> >MMU resource consumption {fewer flushes, support nested paging, ...}.
> >
> >With their advent, ASIDs were assigned to threads/processes.
> >
> >Has anyone ever wanted to allow shared ASIDs in such a way that shared
> >memory or shared files have the ASID associated with the memory/file ?
> >So that multiple processes accessing the same shared resource co-optim-
> >ize themselves across cores and caches ??
>
> Consider that the ASID (and VMID generally speaking) must be present
> in every TLB entry, so the size of the ASID (arm supports 8 or 16 bit ASIDS)
> determines the overall size of the TLB (along with the entry count).
Known--also consider that TLB maps guest virtual to system physical
(under nested paging) so the bit pattern in TLB does not correspond
to the bit pattern in either PTE.
> Even with 16-bit ASIDs, large systems with more than 64k processes (not
> uncommon with 1000-thread processors) will suffer during ASID rollover
> events.
Known issue.
> Associating ASIDs with other resources (such as memory objects)
> complicates the ASID rollever and assignment functionality without
> corresponding performance benefits.
The perceived benefit is that every thread accessing a shared resource
ends up using the shared resource ASID, lowering the cache/MMU overheads
by allowing more sharing of the table-walk accelerators storage(s).
> Using the G (Global) flag on those
> architectures which support it often provides similar benefits where
> applicable.
Do you really WANT all shared resources to be under exactly 1 <special>
ASID {G} ??
Security would demand that each resource would want only those granted
access the ability to access--not something G does--unless you restrict
shared resources to privileged threads.
> Additionally, for your suggestion to be viable, every use of the shared
> object (memory, file pages) must be mapped at the same virtual address;
Only if one passes pointers within those spaces instead of passing offsets.
> which is considered a defect (see System V shared libraries for example),
> even with the larger (48-bit) virtual address space on modern CPUs.
That is why I brought this up, to use comp.arch's brain trust to spit
out the "other" important detains. Thanks.
[toc] | [prev] | [next] | [standalone]
Page 6 of 24 — ← Prev page 1 … 4 5 [6] 7 8 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web