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 4 of 24 — ← Prev page 1 2 3 [4] 5 6 … 24 Next page →
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-09-03 15:48 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <6a999585.3557140@news.eternal-september.org> |
| In reply to | #117746 |
On Wed, 2 Sep 2026 18:59:58 -0400, Paul Clayton <paaronclayton@gmail.com> wrote: >I have wondered why Motorola did not add a 24-bit address mode >(or even provide such with a hardwired configuration on earlier >implementations, knowing that the extra bits would be desired >for other uses to save memory). My immediate reaction would be that they didn't do that for the same reason they didn't provide a 23-bit address mode and a 25-bit address mode. But since, as you point out, the chip only had 24 address pins, your question indeed has a great deal of validity. I'm just not sure what a 24-bit address mode would entail. Instructions had 16 bit displacements in them, so a 24-bit address mode wouldn't make them any shorter. Not using the top eight bits in an address register doesn't save memory. But addresses stored in memory would be shorter as data! Yes, but now they would have to be fetched on byte boundaries instead of on word boundaries. And a multiplication by three would be required to fetch them from packed memory-saving arrays! So you might save a little memory, but you would lose time. John Savard
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <david.schultz@earthlink.net> |
|---|---|
| Date | 2026-09-03 12:07 -0500 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <XOhmS.2$ORN1.0@fx24.iad> |
| In reply to | #117753 |
On 9/3/26 10:48 AM, John Savard wrote: > But since, as you point out, the chip only had 24 address pins, your > question indeed has a great deal of validity. 23. The MC68000 had A1-A23. The upper and lower data strobes selected which byte(s) to access. -- http://davesrocketworks.com David Schultz "It's just this little chromium switch here..."
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-03 17:33 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <FbimS.3$NE2.2@fx20.iad> |
| In reply to | #117754 |
David Schultz <david.schultz@earthlink.net> writes: >On 9/3/26 10:48 AM, John Savard wrote: >> But since, as you point out, the chip only had 24 address pins, your >> question indeed has a great deal of validity. > >23. > >The MC68000 had A1-A23. The upper and lower data strobes selected which >byte(s) to access. Doesn't that mean that those strobes are effectively A0?
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-03 20:23 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1788467034-5857@newsgrouper.org> |
| In reply to | #117756 |
scott@slp53.sl.home (Scott Lurndal) posted: > David Schultz <david.schultz@earthlink.net> writes: > >On 9/3/26 10:48 AM, John Savard wrote: > >> But since, as you point out, the chip only had 24 address pins, your > >> question indeed has a great deal of validity. > > > >23. > > > >The MC68000 had A1-A23. The upper and lower data strobes selected which > >byte(s) to access. > > Doesn't that mean that those strobes are effectively A0? In unary, yes; or you can describe them as the decode of size and A<0>
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-03 16:44 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <9%kmS.2$MJ4f.0@fx17.iad> |
| In reply to | #117756 |
On 2026-Sep-03 13:33, Scott Lurndal wrote: > David Schultz <david.schultz@earthlink.net> writes: >> On 9/3/26 10:48 AM, John Savard wrote: >>> But since, as you point out, the chip only had 24 address pins, your >>> question indeed has a great deal of validity. >> >> 23. >> >> The MC68000 had A1-A23. The upper and lower data strobes selected which >> byte(s) to access. > > Doesn't that mean that those strobes are effectively A0? For a 16 bit bus it only matters a little. You can have an 16-bit aligned address and separate enables for each byte (the Motorola 68000 way), or a byte address and a wire High Byte Enable indicating whether the high byte is included/excluded, which you then have to decode with extra logic to get separate enables (the Intel 8086 way). For wider buses, say 32 bits, I'd want a 30 bit, 4-byte aligned address bus with 4 separate wires indicating which bytes are in the read/write operation as you can run those directly out onto the bus to the memory or device, Also works well if you want to include byte parity on the bus.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-03 17:32 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <JaimS.2$NE2.1@fx20.iad> |
| In reply to | #117753 |
quadibloc@invalid.com (John Savard) writes: >On Wed, 2 Sep 2026 18:59:58 -0400, Paul Clayton ><paaronclayton@gmail.com> wrote: > >>I have wondered why Motorola did not add a 24-bit address mode >>(or even provide such with a hardwired configuration on earlier >>implementations, knowing that the extra bits would be desired >>for other uses to save memory). > >My immediate reaction would be that they didn't do that for the same >reason they didn't provide a 23-bit address mode and a 25-bit address >mode. > >But since, as you point out, the chip only had 24 address pins, your >question indeed has a great deal of validity. The virtual address space[*] is still 32 bits. The number of pins on the package is a implementation detail, not an architectural limitation. [*] on the versions of the 68k with an MMU (68030+ or the MC68851).
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-03 14:43 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <hdjmS.2$4Fj3.0@fx21.iad> |
| In reply to | #117746 |
On 2026-Sep-02 18:59, Paul Clayton wrote: > > With many 64-bit systems limiting user space pointers to 47 bits > (one bit of the 48-bit address space differentiating system and > user space), it seems sad that programs would have to explicitly > mask/extract small pointers to use those extra bits. In those prior "24-bit address space" designs the MMU didn't look at the upper 8 address bits. That is why they had later software porting problems. In the current "48-bit address space" MMU's, all 64 address bits are validated. The 48-bits is a MMU model specfic VA sub-space translation limit set by the number of levels in the page table. Other MMU models can have different numbers of levels. x64 originally had 4 levels of page table (9-9-9-9-12 = 48 bits) and around 2017 added level 5 supporting a 57-bit virtual address sub-space within the ISA's 64-bit virtual address space.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-03 20:32 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1788467534-5857@newsgrouper.org> |
| In reply to | #117757 |
EricP <ThatWouldBeTelling@thevillage.com> posted: > On 2026-Sep-02 18:59, Paul Clayton wrote: > > > > With many 64-bit systems limiting user space pointers to 47 bits > > (one bit of the 48-bit address space differentiating system and > > user space), it seems sad that programs would have to explicitly > > mask/extract small pointers to use those extra bits. > > In those prior "24-bit address space" designs the MMU didn't > look at the upper 8 address bits. That is why they had later > software porting problems. > > In the current "48-bit address space" MMU's, all 64 address bits are validated. > The 48-bits is a MMU model specfic VA sub-space translation limit > set by the number of levels in the page table. I believe it is set by the used width of PA<63..12> in the PTE in conjunction to the number of address bits that are routed around the on-die interconnect. Using PA<63..48> as other than 12b'0 is asking for memory aliasing problem in the coherence protocol. > Other MMU models can have different numbers of levels. > x64 originally had 4 levels of page table (9-9-9-9-12 = 48 bits) and > around 2017 added level 5 supporting a 57-bit virtual address sub-space > within the ISA's 64-bit virtual address space. 5-levels and nested paging has a cost of 25 accesses when walking a complete 5×5 pair of mapping tables. Thus requiring several kinds of table-walk accelerators (top skippers) and (early outs). But even here, this is much better than a SW managed 1-level MMU doing the same kinds of translation.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-03 21:08 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <EllmS.3$4Fj3.1@fx21.iad> |
| In reply to | #117760 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >EricP <ThatWouldBeTelling@thevillage.com> posted: > >> On 2026-Sep-02 18:59, Paul Clayton wrote: >> > >> > With many 64-bit systems limiting user space pointers to 47 bits >> > (one bit of the 48-bit address space differentiating system and >> > user space), it seems sad that programs would have to explicitly >> > mask/extract small pointers to use those extra bits. >> >> In those prior "24-bit address space" designs the MMU didn't >> look at the upper 8 address bits. That is why they had later >> software porting problems. >> >> In the current "48-bit address space" MMU's, all 64 address bits are validated. >> The 48-bits is a MMU model specfic VA sub-space translation limit >> set by the number of levels in the page table. > >I believe it is set by the used width of PA<63..12> in the PTE in >conjunction to the number of address bits that are routed around >the on-die interconnect. Using PA<63..48> as other than 12b'0 >is asking for memory aliasing problem in the coherence protocol. On the VA side, for future compatibility the topmost defined bit is extended into the unused bits (to wit, sign extended to 64-bits). On the PA side, unused bits of the PA will be tied to a logical 0 (there is no need for unused wires in the design).
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-04 01:11 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1788484298-5857@newsgrouper.org> |
| In reply to | #117762 |
scott@slp53.sl.home (Scott Lurndal) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > > > >EricP <ThatWouldBeTelling@thevillage.com> posted: > > > >> On 2026-Sep-02 18:59, Paul Clayton wrote: > >> > > >> > With many 64-bit systems limiting user space pointers to 47 bits > >> > (one bit of the 48-bit address space differentiating system and > >> > user space), it seems sad that programs would have to explicitly > >> > mask/extract small pointers to use those extra bits. > >> > >> In those prior "24-bit address space" designs the MMU didn't > >> look at the upper 8 address bits. That is why they had later > >> software porting problems. > >> > >> In the current "48-bit address space" MMU's, all 64 address bits are validated. > >> The 48-bits is a MMU model specfic VA sub-space translation limit > >> set by the number of levels in the page table. > > > >I believe it is set by the used width of PA<63..12> in the PTE in > >conjunction to the number of address bits that are routed around > >the on-die interconnect. Using PA<63..48> as other than 12b'0 > >is asking for memory aliasing problem in the coherence protocol. > > On the VA side, for future compatibility the topmost defined bit is > extended into the unused bits (to wit, sign extended to 64-bits). AMD calls this feature "canonical". > On the PA side, unused bits of the PA will be tied to a logical 0 > (there is no need for unused wires in the design). Unused PRE.PA bits are checked for canonicality. Then discarded.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-05 01:08 +0000 |
| Message-ID | <1788570532-5857@newsgrouper.org> |
| In reply to | #117763 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: Looking forward:: a) What kind of distinction should architects make between pointers and addresses ?? 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | mas@a4.home |
|---|---|
| Date | 2026-09-06 03:56 +0000 |
| Message-ID | <slrn119pp3k.1iaid.mas@a4.home> |
| In reply to | #117764 |
On 2026-09-05, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > > Looking forward:: > > a) What kind of distinction should architects make between pointers > and addresses ?? > > 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. > > 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. Take a look at: https://github.com/pizlonator/fil-c It's software but has performance issues -- hardware assistance might make a big difference: Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space). Every fundamental C operation (as seen in LLVM IR) is checked against the capability. Fil-C has no unsafe statement and only limited FFI to unsafe code. Fil-C is special because: Fil-C achieves full safety with no escape hatches. There is no unsafe keyword in Fil-C that could be used to turn off protections. Linking to unsafe code is severely restricted. Fil-C's capability-based approach achieves a similar level of safety to hardware capabilities like CHERI, except that it runs on stock hardware (X86_64 or ARM64). Fil-C is engineered to prevent memory safety bugs from being used for exploitation rather than just simply flagging them often enough to find bugs. This makes Fil-C different from AddressSanitizer, HWAsan, or MTE, which can all be bypassed by attackers. The key difference that makes this possible is that Fil-C is capability based (so each pointer knows what range of memory it may access, and how it may access it) rather than tag based (where pointer accesses are allowed if they hit valid memory). From a language user standpoint, Fil-C is just C and C++ with GCC/clang extensions. It's more likely than not that your favorite C or C++ program or library compiles in Fil-C with zero changes. The Fil-C compiler is based on clang 20.1.8, so it supports C17 and C++20.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-06 13:51 +0000 |
| Message-ID | <vdenS.4266$Bn83.1011@fx12.iad> |
| In reply to | #117764 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >Looking forward:: > >a) What kind of distinction should architects make between pointers > and addresses ?? > >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. > >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. It's useful to start with an existing experimental project and look at the current status thereof: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[toc] | [prev] | [next] | [standalone]
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2026-09-10 04:11 +0000 |
| Message-ID | <117takt$1mmh3$1@dont-email.me> |
| In reply to | #117785 |
In article <vdenS.4266$Bn83.1011@fx12.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >>MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >>Looking forward:: >> >>a) What kind of distinction should architects make between pointers >> and addresses ?? >> >>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. >> >>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. > >It's useful to start with an existing experimental project and >look at the current status thereof: > >https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ CHERI summary: all pointers are now called capabilities and are 129 bits, so registers which can hold addresses become 129 bits. Capabilities in memory are also 129 bits, with 128 bits being in "normal" memory, and the "valid" bit being elsewhere (think of it as hidden in ECC bits). Any data write to memory or a register clears the "valid" bit, so software cannot forge a capability. All loads/stores use capabilities as their pointers. The capability basically stores a normal pointer in the low 64 bits, and encodes the base address of the capability and the size in the upper 64 bits, with other info. It encodes this by saying larger sized objects have to have some minimum base and size alignment (so, 16MB+ object must be 4KB aligned, or something like that). The problem is CHERI is trying to do much more than just provide bounds checking--they also have sealed and unsealed capabilities, and lots of rules about managing these extra fields. But: they neglect to actually explain what they intend to do with this, so it all made little sense to me. I THINK they were trying to make capabilities so that the OS could re-use user capabilities (or user code using kernel capabilities) and not be a security hole, but honestly it made my eyes glaze over and I didn't figure it out. If you just want to catch bad memory references, then a simplified CHERI capability could work fine. You don't even need the hidden valid bit since forgery is not really an issue for this case. But CHERI has some holes (just off the top of my head, I'm sure there's more): - It needs to disallow capabilities in shared memory from creating security holes. One process mmap()'s some memory, and stores capabilities pointing to its private memory. Then, another process mmaps the same shared memory, and now can use those valid capabilities to access the same addresses in it's address space, which it might not have access to! This is a tricky problem to solve since you want shared libraries to work. - ARM allows a user process to be big-endian. This similarly can break the capability security model through mmap() and other means. - There's a whole slew of DMA-related security issues which seem hard to fully plug. You need to allow paging of capabilities, and this creates attack surfaces, or just complexity for real use cases where you don't want to clear the valid bit. All DMA drivers become part of the attack surface for forging capabilities. Again, if you don't try to enforce kernel-level trust on these capabilities, these no longer are issues, and it's why I don't really like CHERI. A CHERI-lite just providing bounds checking could be useful. Kent
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-10 14:59 +0000 |
| Message-ID | <8BzoS.160$5X3.21@fx12.iad> |
| In reply to | #117923 |
kegs@provalid.com (Kent Dickey) writes: >In article <vdenS.4266$Bn83.1011@fx12.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>> >>>MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>> >>>Looking forward:: >>> >>>a) What kind of distinction should architects make between pointers >>> and addresses ?? >>> >>>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. >>> >>>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. >> >>It's useful to start with an existing experimental project and >>look at the current status thereof: >> >>https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ > >CHERI summary: all pointers are now called capabilities and are 129 bits, >so registers which can hold addresses become 129 bits. Capabilities in >memory are also 129 bits, with 128 bits being in "normal" memory, and the >"valid" bit being elsewhere (think of it as hidden in ECC bits). Any >data write to memory or a register clears the "valid" bit, so software cannot >forge a capability. All loads/stores use capabilities as their pointers. https://www.arm.com/architecture/cpu/morello
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-10 15:16 +0000 |
| Message-ID | <1789053379-5857@newsgrouper.org> |
| In reply to | #117923 |
kegs@provalid.com (Kent Dickey) posted: Thank you Kent ! > In article <vdenS.4266$Bn83.1011@fx12.iad>, > Scott Lurndal <slp53@pacbell.net> wrote: > >MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >> > >>MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >> > >>Looking forward:: > >> > >>a) What kind of distinction should architects make between pointers > >> and addresses ?? > >> > >>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. > >> > >>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. > > > >It's useful to start with an existing experimental project and > >look at the current status thereof: > > > >https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ > > CHERI summary: all pointers are now called capabilities and are 129 bits, > so registers which can hold addresses become 129 bits. Capabilities in > memory are also 129 bits, with 128 bits being in "normal" memory, and the > "valid" bit being elsewhere (think of it as hidden in ECC bits). Any > data write to memory or a register clears the "valid" bit, so software cannot > forge a capability. All loads/stores use capabilities as their pointers. > > The capability basically stores a normal pointer in the low 64 bits, and > encodes the base address of the capability and the size in the upper 64 bits, > with other info. It encodes this by saying larger sized objects have > to have some minimum base and size alignment (so, 16MB+ object must be 4KB > aligned, or something like that). > > The problem is CHERI is trying to do much more than just provide bounds > checking--they also have sealed and unsealed capabilities, and lots > of rules about managing these extra fields. But: they neglect to actually > explain what they intend to do with this, so it all made little sense to me. I tend to say it as "I understand how to make a capability "pointer", what I don't understand is how to make it C3-secure." > I THINK they were trying to make capabilities so that the OS could re-use > user capabilities (or user code using kernel capabilities) and not be a > security hole, but honestly it made my eyes glaze over and I didn't figure > it out. Whereas; most of use simply want solid base-bounds checking. S O L I D > If you just want to catch bad memory references, then a simplified CHERI > capability could work fine. You don't even need the hidden valid bit since > forgery is not really an issue for this case. Do you think that with a 63-bit VAS, one could put each root-capability into its own upper layer paging structure ?? WHere derived-capabilities simply point inside that root-capability ?? > But CHERI has some holes (just off the top of my head, I'm sure there's more): > > - It needs to disallow capabilities in shared memory from creating security > holes. One process mmap()'s some memory, and stores capabilities > pointing to its private memory. Then, another process mmaps the > same shared memory, and now can use those valid capabilities to > access the same addresses in it's address space, which it might > not have access to! This is a tricky problem to solve since you > want shared libraries to work. Sort-of defeaters the whole purpose, does it not ?? > - ARM allows a user process to be big-endian. This similarly can break > the capability security model through mmap() and other means. > > - There's a whole slew of DMA-related security issues which seem hard to > fully plug. You need to allow paging of capabilities, and this > creates attack surfaces, or just complexity for real use cases > where you don't want to clear the valid bit. All DMA drivers > become part of the attack surface for forging capabilities. This simply makes PCIe devices impossible as each "address plus size" has to be a capability. > Again, if you don't try to enforce kernel-level trust on these capabilities, s/kernel/hypervisor/ Or something like nested capabilities; where a guest capability is re-verified/re-translated by host capabilities. > these no longer are issues, and it's why I don't really like CHERI. My eyes glassed over, too. > A CHERI-lite just providing bounds checking could be useful. Indeed. > Kent
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-10 16:06 +0000 |
| Message-ID | <eAAoS.242$3vg8.225@fx37.iad> |
| In reply to | #117931 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >kegs@provalid.com (Kent Dickey) posted: > >> >> The problem is CHERI is trying to do much more than just provide bounds >> checking--they also have sealed and unsealed capabilities, and lots >> of rules about managing these extra fields. But: they neglect to actually >> explain what they intend to do with this, so it all made little sense to me. > >I tend to say it as "I understand how to make a capability "pointer", >what I don't understand is how to make it C3-secure." The out-of-band 'tag' bit which marks a valid capability makes it secure (likely at B level or better in orange book terminology). > >> I THINK they were trying to make capabilities so that the OS could re-use >> user capabilities (or user code using kernel capabilities) and not be a >> security hole, but honestly it made my eyes glaze over and I didn't figure >> it out. > >Whereas; most of use simply want solid base-bounds checking. S O L I D Which, when it applies to programming environments that include dynamically loaded code (which is pretty much all of them in these times). The capability, of course, provides additional valuable capabilities over simple bounds checking, such as the ability to mark a datum as read-only (without marking the entire page containing the datum). > >> If you just want to catch bad memory references, then a simplified CHERI >> capability could work fine. You don't even need the hidden valid bit since >> forgery is not really an issue for this case. > >Do you think that with a 63-bit VAS, one could put each root-capability >into its own upper layer paging structure ?? WHere derived-capabilities >simply point inside that root-capability ?? > >> But CHERI has some holes (just off the top of my head, I'm sure there's more): >> >> - It needs to disallow capabilities in shared memory from creating security >> holes. One process mmap()'s some memory, and stores capabilities >> pointing to its private memory. Then, another process mmaps the >> same shared memory, and now can use those valid capabilities to >> access the same addresses in it's address space, which it might >> not have access to! This is a tricky problem to solve since you >> want shared libraries to work. > >Sort-of defeaters the whole purpose, does it not ?? If that had been an accurate summarization of how CHERI interacts with mmap (and shared libraries in general), perhaps. However, if you think that the CHERI team hasn't given significant though to the issues of inter-thread and inter-process memory sharing; you might want to re-read the CHERI documentation. > >> - ARM allows a user process to be big-endian. This similarly can break >> the capability security model through mmap() and other means. I don't see how. A capability is opaque to software and completely independent of the endianness of the current thread. It must be 8-byte aligned (which reduces the number of tag bits to 1/8th). >> >> - There's a whole slew of DMA-related security issues which seem hard to >> fully plug. You need to allow paging of capabilities, and this >> creates attack surfaces, or just complexity for real use cases >> where you don't want to clear the valid bit. All DMA drivers >> become part of the attack surface for forging capabilities. > >This simply makes PCIe devices impossible as each "address plus size" >has to be a capability. Again, one must read the CHERI documentation before commenting on such things. "CHERI (Capability Hardware-Enhanced RISC Instructions) interacts with Direct Memory Access (DMA) by treating peripheral devices as capability-unaware entities and enforcing hardware tag-clearing mechanisms at the memory/interconnect level to protect capability integrity."
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-10 16:55 +0000 |
| Message-ID | <2026Sep10.185556@mips.complang.tuwien.ac.at> |
| In reply to | #117932 |
scott@slp53.sl.home (Scott Lurndal) writes: >Again, one must read the CHERI documentation before commenting on >such things. Nope. If the CHERI people don't manage to make their point in a decently short position paper, they will have to live with people commenting on CHERI without getting their point (if there actually is one). OTOH, Mitch Alsup missing a clearly-made point is not unheard-of, either. But they also failed to convince me in the paper I read from them. - 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 | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2026-09-10 21:43 -0400 |
| Message-ID | <117vmbt$2gesr$1@dont-email.me> |
| In reply to | #117932 |
On 2026-09-10 12:06 p.m., Scott Lurndal wrote: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >> kegs@provalid.com (Kent Dickey) posted: >> > >>> >>> The problem is CHERI is trying to do much more than just provide bounds >>> checking--they also have sealed and unsealed capabilities, and lots >>> of rules about managing these extra fields. But: they neglect to actually >>> explain what they intend to do with this, so it all made little sense to me. >> >> I tend to say it as "I understand how to make a capability "pointer", >> what I don't understand is how to make it C3-secure." > > The out-of-band 'tag' bit which marks a valid capability makes it > secure (likely at B level or better in orange book terminology). > >> >>> I THINK they were trying to make capabilities so that the OS could re-use >>> user capabilities (or user code using kernel capabilities) and not be a >>> security hole, but honestly it made my eyes glaze over and I didn't figure >>> it out. >> >> Whereas; most of use simply want solid base-bounds checking. S O L I D > > Which, when it applies to programming environments that include dynamically > loaded code (which is pretty much all of them in these times). The capability, > of course, provides additional valuable capabilities over simple bounds checking, > such as the ability to mark a datum as read-only (without marking the entire > page containing the datum). I wondered about adding read/write/execute access levels to the capability pointer instead of just having single bit for each. But it would add even more bits to the capability. Suppose one wanted the same capability pointer but with a different read access level to the data. When r/w/x bits are all that is available I think one has to map a new pointer with the MMU.> >> >>> If you just want to catch bad memory references, then a simplified CHERI >>> capability could work fine. You don't even need the hidden valid bit since >>> forgery is not really an issue for this case. >> >> Do you think that with a 63-bit VAS, one could put each root-capability >> into its own upper layer paging structure ?? WHere derived-capabilities >> simply point inside that root-capability ?? >> >>> But CHERI has some holes (just off the top of my head, I'm sure there's more): >>> >>> - It needs to disallow capabilities in shared memory from creating security >>> holes. One process mmap()'s some memory, and stores capabilities >>> pointing to its private memory. Then, another process mmaps the >>> same shared memory, and now can use those valid capabilities to >>> access the same addresses in it's address space, which it might >>> not have access to! This is a tricky problem to solve since you >>> want shared libraries to work. >> >> Sort-of defeaters the whole purpose, does it not ?? > > If that had been an accurate summarization of how CHERI interacts > with mmap (and shared libraries in general), perhaps. > > However, if you think that the CHERI team hasn't given significant > though to the issues of inter-thread and inter-process memory sharing; > you might want to re-read the CHERI documentation. > >> >>> - ARM allows a user process to be big-endian. This similarly can break >>> the capability security model through mmap() and other means. > > I don't see how. A capability is opaque to software and completely > independent of the endianness of the current thread. It must be 8-byte > aligned (which reduces the number of tag bits to 1/8th). > >>> >>> - There's a whole slew of DMA-related security issues which seem hard to >>> fully plug. You need to allow paging of capabilities, and this >>> creates attack surfaces, or just complexity for real use cases >>> where you don't want to clear the valid bit. All DMA drivers >>> become part of the attack surface for forging capabilities. >> >> This simply makes PCIe devices impossible as each "address plus size" >> has to be a capability. > > Again, one must read the CHERI documentation before commenting on > such things. > > "CHERI (Capability Hardware-Enhanced RISC Instructions) interacts > with Direct Memory Access (DMA) by treating peripheral devices as > capability-unaware entities and enforcing hardware tag-clearing > mechanisms at the memory/interconnect level to protect capability > integrity." > >
[toc] | [prev] | [next] | [standalone]
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2026-09-13 17:50 +0000 |
| Message-ID | <1186nor$qab6$2@dont-email.me> |
| In reply to | #117932 |
In article <eAAoS.242$3vg8.225@fx37.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >>kegs@provalid.com (Kent Dickey) posted: >>> But CHERI has some holes (just off the top of my head, I'm sure >there's more): >>> >>> - It needs to disallow capabilities in shared memory from creating security >>> holes. One process mmap()'s some memory, and stores capabilities >>> pointing to its private memory. Then, another process mmaps the >>> same shared memory, and now can use those valid capabilities to >>> access the same addresses in it's address space, which it might >>> not have access to! This is a tricky problem to solve since you >>> want shared libraries to work. >> >>Sort-of defeaters the whole purpose, does it not ?? > >If that had been an accurate summarization of how CHERI interacts >with mmap (and shared libraries in general), perhaps. > >However, if you think that the CHERI team hasn't given significant >though to the issues of inter-thread and inter-process memory sharing; >you might want to re-read the CHERI documentation. I've already stated my primary concern with CHERI: that it COULD be secure, but it pushes a lot of complexity into other parts of the system, and it needs to do that in a clear and open fashion. CHERI is NOT clear and open about how to do these things. It's obtuse and terse, and that's a trick used to hide problems. Could you explain to us how CHERI completely solves the mmap() aliasing issue? >> >>> - ARM allows a user process to be big-endian. This similarly can break >>> the capability security model through mmap() and other means. > >I don't see how. A capability is opaque to software and completely >independent of the endianness of the current thread. It must be 8-byte >aligned (which reduces the number of tag bits to 1/8th). Morello solved this with one line: Capabilities in memory are always little endian. I told them to fix this, and they did fix this one. >>> - There's a whole slew of DMA-related security issues which seem hard to >>> fully plug. You need to allow paging of capabilities, and this >>> creates attack surfaces, or just complexity for real use cases >>> where you don't want to clear the valid bit. All DMA drivers >>> become part of the attack surface for forging capabilities. >> >>This simply makes PCIe devices impossible as each "address plus size" >>has to be a capability. > >Again, one must read the CHERI documentation before commenting on >such things. > > "CHERI (Capability Hardware-Enhanced RISC Instructions) interacts > with Direct Memory Access (DMA) by treating peripheral devices as > capability-unaware entities and enforcing hardware tag-clearing > mechanisms at the memory/interconnect level to protect capability > integrity." CHERI creates new system requirements. You could have DMA maintain capabilities, and that has some nice properties, but then means you have to trust your DMA device. The CHERI documentation says whether DMA should be able to read/write capabilities is an open question, but that the current default is that DMA writes clear capabilities. So what's the hole with that? To support paging, it means you must have a mechanism to write in the page data to memory using DMA, then DMA in the tags elsewhere, and then write in the tags to be valid separately (probably done by a CPU using special instructions). And this lack of atomicity creates a security issue (which again, can be fixed, but you have to DOCUMENT it clearly to make sure it's handled). When allowing any DMA to user pages, the lack of atomicity means the OS must completely unmap the page from the use before doing any tag operations. Otherwise, the case that happens is there are 2 threads, a page is paged out, one thread touches that page, and starts in the page-in procedure. The OS is lazy and has let the second thread have access to the page (because this is NOT a security hole without CHERI, it's the process's private data page, if it wants to "corrupt" it, it's no concern of the OS's). DMA writes in the data, and then an OS task waits for DMA to finish, then it sets the tag bits. Meanwhile, the second thread could be aggressively writing to a pointer on the page, changing the bounds to be the whole memory space. Then the OS process sets the tag to validate the capability, and then we've let the user forge a capability. There's a similar race in paging out--if the OS copies the tags first, then does the DMA reads, and it's mapped in the second user thread still, it can similarly forge capabilities. If DMA is first and OS copies the tags second, the user could set up the page with a forged pointer that is not a valid capability, and then write in a dummy capability before the OS copies the tags. So the data is the forged pointer, and the tag is valid. When paged back in, the page has a valid forged capability. So, CHERI adds a requirement that any page being used for DMA must be fully unmapped from the user address space first. Again, some OS'es may do this by default, but this is a security problem with CHERI and it must be done properly. The whole idea of CXL is to allow DMA right into user space, and that's not very compatible with CHERI. If you think of valid tag bits as a virus that needs to be contained, you'll see there are MANY new requirements for how the OS needs to handle user data. There needs to be no path where the user creates a malicious capability, and then an OS operation copies what it thought was data as a capability. The OS must not accidentally create capabilities in the user space. Morello's all-new-instructions actually help solve this, by making normal integer instructions clear the tag always. But there are many possibilities here, and since I can find no discussion of how they think they've solved this, I'm doubtful they've covered everything. Kent
[toc] | [prev] | [next] | [standalone]
Page 4 of 24 — ← Prev page 1 2 3 [4] 5 6 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web