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 7 of 24 — ← Prev page 1 … 5 6 [7] 8 9 … 24 Next page →
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-13 12:05 -0400 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <11898n8$1nc06$1@dont-email.me> |
| In reply to | #117833 |
On 9/7/26 2:33 PM, MitchAlsup wrote:
>
> 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 ??
I suspect something like this (but coarser-grained) was the
motivation for PowerPC's segments. Effectively each of 16
address regions (in the 32-bit "effective" address space) had an
ASID. (Virtual segment IDs were 24 bits.)
System libraries might naturally be placed in one virtual
segment ID (since a given ID could be placed in any of the
16 regions, there was a very limited ability to place shared
regions at different effective addresses).
This could provide a simple thread local storage pointer by
having each thread have one segment descriptor be different.
(This would incidentally slightly increase the address space
available to a single process without application-level action.)
16 fixed-size regions provides only moderate sharing
flexibility. The extension to 64-bit was problematic (it
effectively added a layer of look-up indirection that could
not be completely cached). The coarse granularity also used
up a lot of the address space (e.g., 64 MiB of shared libraries
would still use 256 MiB of address space).
Itanium had a similar concept in Regions. The three most
significant bits of the address identified a virtual Region.
The region register encoded a 24-bit ID (with 32 contiguous bits
reserved this could trivially have been expanded), a preferred
page size, a hardware page table walker enable bit, and an
additional reserved bit. The preferred page size might have been
useful for supporting multiple concurrent page sizes.
Itanium presumably had this to better support software ported
from HP PA-RISC (which had segments).
/*** Side comment ***
* Itanium also had the interesting feature of large PTEs that
* included a "key" such that different permissions could be
* provided for different threads/processes. The overhead of at
* least 16 protection key registers (which map the key value to
* potentially disabling read, write, or execute permissions)
* seems significant (and 128-bit PTEs also added overhead), but
* Itanium was not intended for microcontrollers.☺ Such allowed
* different permissions while sharing a page table and TLB
* entries.
*
* With special instructions to change such protection registers,
* it would be possible for a less trusted module to be scanned
* for such instructions to ensure it could not grant itself
* permissions. Having an instruction that would selectively
* (in)validate the protection keys using a bitmask would have
* allowed (I think) somewhat cheap permission revocation and
* restoration.
*/
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-09-16 23:11 +0100 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <memo.20260916231132.15112B@jgd.cix.co.uk> |
| In reply to | #118009 |
In article <11898n8$1nc06$1@dont-email.me>, paaronclayton@gmail.com (Paul Clayton) wrote: > I suspect something like this (but coarser-grained) was the > motivation for PowerPC's segments. Effectively each of 16 > address regions (in the 32-bit "effective" address space) had an > ASID. (Virtual segment IDs were 24 bits.) > software ported from HP PA-RISC (which had segments). Having had to fit large processes into those segments, on the 32-bit versions of both those architectures, they were a serious nuisance. They'd apparently been designed when physical memories were measured in small numbers of MB, with the idea that using any significant fraction of a 4GB virtual address space was never going to happen. John
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-17 00:26 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <1789604761-5857@newsgrouper.org> |
| In reply to | #118067 |
jgd@cix.co.uk (John Dallman) posted: > In article <11898n8$1nc06$1@dont-email.me>, paaronclayton@gmail.com (Paul > Clayton) wrote: > > > I suspect something like this (but coarser-grained) was the > > motivation for PowerPC's segments. Effectively each of 16 > > address regions (in the 32-bit "effective" address space) had an > > ASID. (Virtual segment IDs were 24 bits.) > > > software ported from HP PA-RISC (which had segments). > > Having had to fit large processes into those segments, on the 32-bit > versions of both those architectures, they were a serious nuisance. The always and obvious problem when the position of a segment is not "anywhere in PAS" and where the size of the segment cannot be "every thing possible in memory". Anytime one want segments as small as a word to as large as can fit in memory one runs into this problem. > They'd apparently been designed when physical memories were measured in > small numbers of MB, with the idea that using any significant fraction of > a 4GB virtual address space was never going to happen. Happened to 6800, 6502, PDP-8, PDP-11, VAX, ~IBM 3080, ... So, you would think that history would be showing them not to do that to themselves. > > John
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-17 09:32 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <2026Sep17.113215@mips.complang.tuwien.ac.at> |
| In reply to | #118067 |
jgd@cix.co.uk (John Dallman) writes: >In article <11898n8$1nc06$1@dont-email.me>, paaronclayton@gmail.com (Paul >Clayton) wrote: > >> I suspect something like this (but coarser-grained) was the >> motivation for PowerPC's segments. Effectively each of 16 >> address regions (in the 32-bit "effective" address space) had an >> ASID. (Virtual segment IDs were 24 bits.) > >> software ported from HP PA-RISC (which had segments). > >Having had to fit large processes into those segments, on the 32-bit >versions of both those architectures, they were a serious nuisance. > >They'd apparently been designed when physical memories were measured in >small numbers of MB, with the idea that using any significant fraction of >a 4GB virtual address space was never going to happen. At least not before 64-bit addresses are available. The interesting aspect is that the first 64-bit CPUs were the R4000 (1991) and the 21064 (1992) while the first 64-bit HPPA machine was introduced in November 1995 (and it probably took a while until it was delivered); the PowerPC620 only appeared in 1997. One would think that with these address-space restrictions the HPPA and Power architects would feel more pressure than the others to go 64-bit soon. We had an Alpha with 256MB RAM in 1995, and we were not into big machines (this Alpha only had one CPU). So the address-space limitations of HPPA and PowerPC probably made themselves felt strongly before the 64-bit variants were available. Ironically, Alpha was canceled before we reached 4GB RAM in our machines (and general-purpose MIPS CPUs, too). - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-09-17 13:32 +0100 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <memo.20260917133228.15112C@jgd.cix.co.uk> |
| In reply to | #118073 |
In article <2026Sep17.113215@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > The interesting aspect is that the first 64-bit CPUs were the R4000 > (1991) and the 21064 (1992) while the first 64-bit HPPA machine was > introduced in November 1995 (and it probably took a while until it > was delivered); the PowerPC620 only appeared in 1997. One would think > that with these address-space restrictions the HPPA and Power > architects would feel more pressure than the others to go 64-bit > soon. Do not underestimate the power of corporate conservatism and sectional interests. From 1995-2005 I regularly backstopped for technical support staff who were finding that customers felt they were locked into one particular commercial UNIX and could not change without vast disruptions. We felt this was weird, because the UNIXes of the era were all pretty similar. It gradually became clear that manufacturers' training courses on commercial UNIXes emphasised the differences and tried hard to give the impression that changing to a another supplier would be difficult and expensive. Human inertia meant that customers' sysadmins co-operated with that, giving the illusion that they were indispensable while acting against their employers' interests. This meant that well-established manufacturers like HP and IBM felt less urgency to move to 64-bit. Sun and SGI were a bit more dynamic, until they got into financial trouble, and DEC knew they needed Alpha to have a hope of survival. Meanwhile, we employed sysadmins who dealt with all of these UNIXes every week without difficulty. We also had to learn about things like POWER and PA-RISC segmentation to squeeze large 32-bit applications onto them. 64-bit was very welcome! John
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-18 01:08 +0300 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <20260918010802.00007414@yahoo.com> |
| In reply to | #118075 |
On Thu, 17 Sep 2026 13:32 +0100 (BST) jgd@cix.co.uk (John Dallman) wrote: > In article <2026Sep17.113215@mips.complang.tuwien.ac.at>, > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > > The interesting aspect is that the first 64-bit CPUs were the R4000 > > (1991) and the 21064 (1992) while the first 64-bit HPPA machine was > > introduced in November 1995 (and it probably took a while until it > > was delivered); the PowerPC620 only appeared in 1997. One would > > think that with these address-space restrictions the HPPA and Power > > architects would feel more pressure than the others to go 64-bit > > soon. > > Do not underestimate the power of corporate conservatism and sectional > interests. From 1995-2005 I regularly backstopped for technical > support staff who were finding that customers felt they were locked > into one particular commercial UNIX and could not change without vast > disruptions. > > > We felt this was weird, because the UNIXes of the era were all pretty > similar. It gradually became clear that manufacturers' training > courses on commercial UNIXes emphasised the differences and tried > hard to give the impression that changing to a another supplier would > be difficult and expensive. Human inertia meant that customers' > sysadmins co-operated with that, giving the illusion that they were > indispensable while acting against their employers' interests. This > meant that well-established manufacturers like HP and IBM felt less > urgency to move to 64-bit. Sun and SGI were a bit more dynamic, until > they got into financial trouble, and DEC knew they needed Alpha to > have a hope of survival. > > Meanwhile, we employed sysadmins who dealt with all of these UNIXes > every week without difficulty. We also had to learn about things like > POWER and PA-RISC segmentation to squeeze large 32-bit applications > onto them. 64-bit was very welcome! > > John HP introduced their first 64-bit PA-RISC CPU only 5 or 6 months behind Sun. IBM released the Cobra, their 1st 64-bit POWEER CPU, approximately at the same time as Sun. But it and its successors (Muskie, Apache, Northstar) were probably of little interest for you and your employer, because they were not intended for engineering applications. The first engineering-oriented 64-bit POWER (POWER3) came, indeed, significantly later - more than 3 years behind Sun.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-18 06:10 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <2026Sep18.081053@mips.complang.tuwien.ac.at> |
| In reply to | #118085 |
Michael S <already5chosen@yahoo.com> writes: >HP introduced their first 64-bit PA-RISC CPU only 5 or 6 months behind >Sun. According to Wikipedia: |The UltraSPARC [...] introduced in mid-1995 [...] is the first |microprocessor from Sun to implement the 64-bit SPARC V9 instruction |set But SPARC did not have the segments of HPPA and Power, and therefore had less pressure to extend virtual addresses early on. Yet they were earlier. Depending on which Wikipedia page you look at, PA-8000 and PA-RISC 2.0 was introduced on November 2, 1995 <https://en.wikipedia.org/wiki/PA-8000>, or in January 1996 <https://en.wikipedia.org/wiki/PA-RISC>. >IBM released the Cobra, their 1st 64-bit POWEER CPU, approximately at >the same time as Sun. But it and its successors (Muskie, Apache, >Northstar) were probably of little interest for you and your employer, >because they were not intended for engineering applications. >The first engineering-oriented 64-bit POWER (POWER3) came, indeed, >significantly later - more than 3 years behind Sun. The A10/Cobra was only released in AS/400 familt machines. However, the RS64 was also released in RS/6000 family machines, in 1997. IBM did not use the PowerPC 620, also released in 1997. Power3/PowerPC 630 was launched in 1998. Maybe the HP/UX and AIX developers implemented ways that worked around the 256MB segment size, e.g., several segments for the same virtual memory area, and I guess that the Linux developers did so, too. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-17 16:06 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <1789661180-5857@newsgrouper.org> |
| In reply to | #118073 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > jgd@cix.co.uk (John Dallman) writes: > >In article <11898n8$1nc06$1@dont-email.me>, paaronclayton@gmail.com (Paul > >Clayton) wrote: > > > >> I suspect something like this (but coarser-grained) was the > >> motivation for PowerPC's segments. Effectively each of 16 > >> address regions (in the 32-bit "effective" address space) had an > >> ASID. (Virtual segment IDs were 24 bits.) > > > >> software ported from HP PA-RISC (which had segments). > > > >Having had to fit large processes into those segments, on the 32-bit > >versions of both those architectures, they were a serious nuisance. > > > >They'd apparently been designed when physical memories were measured in > >small numbers of MB, with the idea that using any significant fraction of > >a 4GB virtual address space was never going to happen. > > At least not before 64-bit addresses are available. > > The interesting aspect is that the first 64-bit CPUs were the R4000 > (1991) and the 21064 (1992) while the first 64-bit HPPA machine was > introduced in November 1995 (and it probably took a while until it was > delivered); the PowerPC620 only appeared in 1997. One would think > that with these address-space restrictions the HPPA and Power > architects would feel more pressure than the others to go 64-bit soon. CRAY-1 1976 > We had an Alpha with 256MB RAM in 1995, and we were not into big > machines (this Alpha only had one CPU). So the address-space > limitations of HPPA and PowerPC probably made themselves felt strongly > before the 64-bit variants were available. Ironically, Alpha was > canceled before we reached 4GB RAM in our machines (and > general-purpose MIPS CPUs, too). > > - anton
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-17 17:26 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <epVqS.48724$mg2f.12522@fx23.iad> |
| In reply to | #118076 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> jgd@cix.co.uk (John Dallman) writes: >> >In article <11898n8$1nc06$1@dont-email.me>, paaronclayton@gmail.com (Paul >> >Clayton) wrote: >> > >> >> I suspect something like this (but coarser-grained) was the >> >> motivation for PowerPC's segments. Effectively each of 16 >> >> address regions (in the 32-bit "effective" address space) had an >> >> ASID. (Virtual segment IDs were 24 bits.) >> > >> >> software ported from HP PA-RISC (which had segments). >> > >> >Having had to fit large processes into those segments, on the 32-bit >> >versions of both those architectures, they were a serious nuisance. >> > >> >They'd apparently been designed when physical memories were measured in >> >small numbers of MB, with the idea that using any significant fraction of >> >a 4GB virtual address space was never going to happen. >> >> At least not before 64-bit addresses are available. >> >> The interesting aspect is that the first 64-bit CPUs were the R4000 >> (1991) and the 21064 (1992) while the first 64-bit HPPA machine was >> introduced in November 1995 (and it probably took a while until it was >> delivered); the PowerPC620 only appeared in 1997. One would think >> that with these address-space restrictions the HPPA and Power >> architects would feel more pressure than the others to go 64-bit soon. > >CRAY-1 1976 So one might subclassify 64-bit into: - 64-bit arithmetic operations - 64-bit addressing operations. The B3500 in 1965 did 400-bit arithmetic operations (100 digit), applications were limited to 500KB[*] (code + data - slightly less as a small amount was used by the MCP (OS)). Later machines increased the physical address space from 6 digits to 10 digits (500MB). [*] 1 million digits/nibbles.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-17 19:40 +0000 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <1789674055-5857@newsgrouper.org> |
| In reply to | #118079 |
scott@slp53.sl.home (Scott Lurndal) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > > > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > > > >> jgd@cix.co.uk (John Dallman) writes: > >> >In article <11898n8$1nc06$1@dont-email.me>, paaronclayton@gmail.com (Paul > >> >Clayton) wrote: > >> > > >> >> I suspect something like this (but coarser-grained) was the > >> >> motivation for PowerPC's segments. Effectively each of 16 > >> >> address regions (in the 32-bit "effective" address space) had an > >> >> ASID. (Virtual segment IDs were 24 bits.) > >> > > >> >> software ported from HP PA-RISC (which had segments). > >> > > >> >Having had to fit large processes into those segments, on the 32-bit > >> >versions of both those architectures, they were a serious nuisance. > >> > > >> >They'd apparently been designed when physical memories were measured in > >> >small numbers of MB, with the idea that using any significant fraction of > >> >a 4GB virtual address space was never going to happen. > >> > >> At least not before 64-bit addresses are available. > >> > >> The interesting aspect is that the first 64-bit CPUs were the R4000 > >> (1991) and the 21064 (1992) while the first 64-bit HPPA machine was > >> introduced in November 1995 (and it probably took a while until it was > >> delivered); the PowerPC620 only appeared in 1997. One would think > >> that with these address-space restrictions the HPPA and Power > >> architects would feel more pressure than the others to go 64-bit soon. > > > >CRAY-1 1976 > > So one might subclassify 64-bit into: > > - 64-bit arithmetic operations > - 64-bit addressing operations. I even thought about the Cray-1s 24-bit address space when writing the above. > The B3500 in 1965 did 400-bit arithmetic operations (100 digit), > applications were limited to 500KB[*] (code + data - slightly less > as a small amount was used by the MCP (OS)). Later machines > increased the physical address space from 6 digits to 10 digits > (500MB). > > [*] 1 million digits/nibbles.
[toc] | [prev] | [next] | [standalone]
| From | Andy Valencia <vandys@vsta.org> |
|---|---|
| Date | 2026-09-14 12:52 -0700 |
| Subject | Re: Addressing Shared Stuff |
| Message-ID | <178941554759.26035.17139834765826353877@media.vsta.org> |
| In reply to | #117833 |
> On 9/7/26 2:33 PM, MitchAlsup wrote: > > 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 ?? HP's Precision Architecture had this. TLB entries had a Access ID, and the process had a list of Protection ID's. For non-zero AID, you had to have its value in your PID list to access the page. Shared memory segments each got their own AID, and then each process which successfully attached received it in their PID. The PID list was bounded, and there was a fast path to swap in one which wasn't active when needed. Each shared memory object was accessed at the same 64-bit address in each process. Andy Valencia Home page: https://www.vsta.org/andy/ To contact me: https://www.vsta.org/contact/andy.html No AI was used in the composition of this message
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-06 20:25 +0000 |
| Message-ID | <117ki8a$2mdkc$1@dont-email.me> |
| In reply to | #117793 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> 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.
There are programming languages which do that, Fortran being
a prime example.
> 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.
Fortran has an interesting take on pointers: You can associate a
pointer with existing variables, but only if they have the TARGET
attribute, otherwise this must be diagnosed (it's a constraint).
You can also have multi-dimensional pointers, so something like
real, dimension(10,10), target :: a
real, dimension(:,:), pointer :: ap
ap => a(1:10:2,1:10:2)
After this, ap(1,2) is an alias to a(1,3), for example. ap is
then pointing to a sub-array. This will be handled with array
descriptors aka dope vectors.
No address arithmetic required, normal indexing will do.
You can also ALLOCATE pointers, after which they are associated with
an anonymous region. But this is usually not the best way because
Fortran also has ALLOCATABLE variables which are automatically
deallocated when they go out of scope (or are passed as actual
argument to an INTENT(OUT) dummy argument).
But these mechanisms are, by nature, rather heavy-weight and
not as well suited to a lower-level language like C.
>
>>> 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.
Assume the following C code:
#define N something
...
double *p = calloc(N, sizeof(double));
...
foo (p+2,i);
void foo(double *p, int i)
{
p[i] = 42.
}
This would require something like, generated from the code
above,
void foo(double *p, int i, double *p_from, double *p_to)
{
if (p + i < p_from)
range_error();
if (p + i > p_to)
range_error();
p[i] = 42.;
}
so each range-checked pointer would require three actual arguments.
Hardware could assist this with an instruction "trap if out of range",
which would combine the if statements above into one. This would be
an instruction which could be predicted to be a no-op with some
confidence.
But register (or argument) pressure would be high, which is why
I suspect that 32 registers might not be enough.
> 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.
Or Mitch's carry instruction, followed by a bne0.
> 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.
That would require both limits.
> For almost all array indexes the cost is a single reg-reg or reg-imm instruction.
... which should be moved outside the loops.
>
>> 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.
It seems to be quire common, see
https://cwe.mitre.org/data/definitions/416.html .
> 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.
That sounds like very good practice.
One reason why I like ALLOCATABLE variables in Fortran is that
a large fraction of that burden is taken off the programmer's
shoulders.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-07 00:02 +0000 |
| Message-ID | <1788739362-5857@newsgrouper.org> |
| In reply to | #117801 |
Thomas Koenig <tkoenig@netcologne.de> posted:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> > 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.
>
> There are programming languages which do that, Fortran being
> a prime example.
>
> > 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.
>
> Fortran has an interesting take on pointers: You can associate a
> pointer with existing variables, but only if they have the TARGET
> attribute, otherwise this must be diagnosed (it's a constraint).
> You can also have multi-dimensional pointers, so something like
>
> real, dimension(10,10), target :: a
> real, dimension(:,:), pointer :: ap
>
> ap => a(1:10:2,1:10:2)
>
> After this, ap(1,2) is an alias to a(1,3), for example. ap is
> then pointing to a sub-array. This will be handled with array
> descriptors aka dope vectors.
>
> No address arithmetic required, normal indexing will do.
>
> You can also ALLOCATE pointers, after which they are associated with
> an anonymous region. But this is usually not the best way because
> Fortran also has ALLOCATABLE variables which are automatically
> deallocated when they go out of scope (or are passed as actual
> argument to an INTENT(OUT) dummy argument).
>
> But these mechanisms are, by nature, rather heavy-weight and
> not as well suited to a lower-level language like C.
Perhaps the fault is with C than with Fortran !!!
> >
> >>> First make array index checks simple and cheap.
And OBVIOUS !
> >>> 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.
>
> Assume the following C code:
>
> #define N something
>
> ...
> double *p = calloc(N, sizeof(double));
>
> ...
>
> foo (p+2,i);
>
> void foo(double *p, int i)
> {
> p[i] = 42.
> }
>
> This would require something like, generated from the code
> above,
>
> void foo(double *p, int i, double *p_from, double *p_to)
> {
> if (p + i < p_from)
> range_error();
> if (p + i > p_to)
> range_error();
> p[i] = 42.;
> }
>
> so each range-checked pointer would require three actual arguments.
>
> Hardware could assist this with an instruction "trap if out of range",
> which would combine the if statements above into one. This would be
> an instruction which could be predicted to be a no-op with some
> confidence.
>
> But register (or argument) pressure would be high, which is why
> I suspect that 32 registers might not be enough.
>
> > 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.
>
> Or Mitch's carry instruction, followed by a bne0.
>
> > 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.
>
> That would require both limits.
>
> > For almost all array indexes the cost is a single reg-reg or reg-imm instruction.
>
> ... which should be moved outside the loops.
>
> >
> >> 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.
>
> It seems to be quire common, see
> https://cwe.mitre.org/data/definitions/416.html .
>
> > 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.
>
> That sounds like very good practice.
>
> One reason why I like ALLOCATABLE variables in Fortran is that
> a large fraction of that burden is taken off the programmer's
> shoulders.
>
>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-07 00:09 +0000 |
| Message-ID | <1788739751-5857@newsgrouper.org> |
| In reply to | #117801 |
Thomas Koenig <tkoenig@netcologne.de> posted:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> > 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.
>
> There are programming languages which do that, Fortran being
> a prime example.
>
> > 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.
>
> Fortran has an interesting take on pointers: You can associate a
> pointer with existing variables, but only if they have the TARGET
> attribute, otherwise this must be diagnosed (it's a constraint).
> You can also have multi-dimensional pointers, so something like
>
> real, dimension(10,10), target :: a
> real, dimension(:,:), pointer :: ap
>
> ap => a(1:10:2,1:10:2)
>
> After this, ap(1,2) is an alias to a(1,3), for example. ap is
> then pointing to a sub-array. This will be handled with array
> descriptors aka dope vectors.
>
> No address arithmetic required, normal indexing will do.
>
> You can also ALLOCATE pointers, after which they are associated with
> an anonymous region. But this is usually not the best way because
> Fortran also has ALLOCATABLE variables which are automatically
> deallocated when they go out of scope (or are passed as actual
> argument to an INTENT(OUT) dummy argument).
>
> But these mechanisms are, by nature, rather heavy-weight and
> not as well suited to a lower-level language like C.
Perhaps the fault is with C than with Fortran !!!
> >
> >>> First make array index checks simple and cheap.
And OBVIOUS !
> >>> 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.
>
> Assume the following C code:
>
> #define N something
>
> ...
> double *p = calloc(N, sizeof(double));
>
> ...
>
> foo (p+2,i);
>
> void foo(double *p, int i)
> {
> p[i] = 42.
> }
>
> This would require something like, generated from the code
> above,
>
> void foo(double *p, int i, double *p_from, double *p_to)
> {
> if (p + i < p_from)
> range_error();
> if (p + i > p_to)
> range_error();
> p[i] = 42.;
> }
Whereas::
double p[N] = calloc(N, sizeof(double));
...
foo (&p[2],i);
...
void foo(double p[*], int i)
{
p[i] = 42.
}
does not!!
> so each range-checked pointer would require three actual arguments.
>
> Hardware could assist this with an instruction "trap if out of range",
> which would combine the if statements above into one. This would be
> an instruction which could be predicted to be a no-op with some
> confidence.
>
> But register (or argument) pressure would be high, which is why
> I suspect that 32 registers might not be enough.
>
> > 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.
>
> Or Mitch's carry instruction, followed by a bne0.
Mitches MUL checks Overflow at either 64-bit boundaries when enabled. So,
all we need is BNE0
> > 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.
>
> That would require both limits.
CMP Rd,Rnormalixed_index,array_limit
BCIN Rd,where_ever
Does both the <0 and >=array_limit checks in one inst.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-07 06:17 +0000 |
| Message-ID | <117lktv$30f78$1@dont-email.me> |
| In reply to | #117811 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
>
> Thomas Koenig <tkoenig@netcologne.de> posted:
>> But these mechanisms are, by nature, rather heavy-weight and
>> not as well suited to a lower-level language like C.
>
> Perhaps the fault is with C than with Fortran !!!
I would tend to concur, but of course I am biased in
favor of Fortran :-)
>> Assume the following C code:
>>
>> #define N something
>>
>> ...
>> double *p = calloc(N, sizeof(double));
>>
>> ...
>>
>> foo (p+2,i);
>>
>> void foo(double *p, int i)
>> {
>> p[i] = 42.
>> }
>>
>> This would require something like, generated from the code
>> above,
>>
>> void foo(double *p, int i, double *p_from, double *p_to)
>> {
>> if (p + i < p_from)
>> range_error();
>> if (p + i > p_to)
>> range_error();
>> p[i] = 42.;
>> }
>
> Whereas::
>
> double p[N] = calloc(N, sizeof(double));
Either double p[N] or double *p = ...
> ...
> foo (&p[2],i);
> ...
> void foo(double p[*], int i)
> {
> p[i] = 42.
> }
>
> does not!!
This would still be legal for
foo (&p[2],-2)
so both bounds checks would be needed to avoid a false positive.
But, looking back at Fortran, there are also the case of
lower bounds unequal to one, like
subroutine foo(a,m,n)
real, dimension(3:n)
a(m) = 42.
so a check would require that m be between 3 and n.
[...]
>> That would require both limits.
>
> CMP Rd,Rnormalixed_index,array_limit
> BCIN Rd,where_ever
>
> Does both the <0 and >=array_limit checks in one inst.
Both are needed, unfortunately.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-06 23:46 +0000 |
| Message-ID | <1788738411-5857@newsgrouper.org> |
| In reply to | #117793 |
EricP <ThatWouldBeTelling@thevillage.com> posted:
> 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.
Some of us are.....
> Making arrays a first class type and distinct from pointers
> would be the first step but would not be backwards compatible.
I proposed a few years back to allow compilers to use one kind
of checking with p[i] and another when using *(p+i); so long as
in that scope, there are no p++ calculations.
> 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.
THat is nadda gonna fly.
> >> 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.
I agree, since 96% of subroutines* use fewer than 32 registers anyway.
(*) LLVM source and all the source code I can find.
> Use an ADDFS Add Fault Signed Overflow or ADDFU Add Fault Unsigned wrap
> instead of the unchecked ADD.
My 66000 already uses the sign bit of pointers and compares it to the
sign bit of VA and raises a fault when the 63-bit VAS boundary is stepped
over. Its not enough, but better than ignoring the problem.
> 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.
My 66000 does this and takes the exception when IOverflow is enabled.
> So 1 extra instruction to check each multiply for overflow.
0 more instructions when done right.
> 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.
(index - lower_bound) > 0
is
ADD Ri,Rindex,-Rlob
BLE Ri,.....
> For almost all array indexes the cost is a single reg-reg or reg-imm instruction
Low cost when the lower bound is 0 (or 1).
> > 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.
My programming style does not use free() in any sense that would require
garbage collection. So, this problem does not exist in my code.
> 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.
Occasionally, when I need to free() and the afterwards malloc() again,
I will fork off a task, have it do its think, return its result, and
the exit(0) saving all the GC code.
> 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.
All good.
> Consequently if such programming error did happen, my code should
> immediately detect it itself and throw a fatal exception.
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-09-06 20:21 +0300 |
| Message-ID | <ng5lo0Fejs2U1@mid.individual.net> |
| In reply to | #117790 |
On 2026-09-06 17: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. > >> 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. As described by mas@a4.home in their earlier post, Fil-C does seem able to solve much of the address-arithmetic and use-after-free problems: "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)." So capabilities are protected from user modification, and "free" is probably a no-op because of garbage collection. The remaining question is performance, but many applications are not performance-sensitive.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-08 15:08 +0000 |
| Message-ID | <117p8dq$3f0og$1@paganini.bofh.team> |
| In reply to | #117790 |
Thomas Koenig <tkoenig@netcologne.de> 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.
I think that any hardware solution compatible with legacy
C practices will fail. Reasonably modern C allows VMT-s
and using them one can track sizes. C standard is rather
unhelpful here, because it says that size info is
essentially ignored in prototypes, but compilers could
implement checking as an extra option. So there is at
least potential way to incrementally improve C code base
and switch from legacy C to a checked one.
>> 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.
GCC twenty years ago was good enough. GNU Pascal for several years
did no bound checking. Slightly more than twenty years ago it
added bounds checking. Trials on several programs showed that
typical impact was rather small, that is less than 10% overhead.
In many cases there were no _new_ checks in object code: normal
program logic ensured that accesses were in bound and GCC was
able to infer that bounds checks were redundant. In other
cases GCC moved accesses outside inner loop, making them quite
cheap. And that was on i386 with its 8 register and Amd64
with its 16 registers.
I wonder, did you try to add bound checking to gfortran?
ANd if yes did you measure performance impact?
>> Then see what's left to address.
>
> Use after free will still be a problem, but maybe INVALIDATE
> can help there.
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-08 20:11 +0000 |
| Message-ID | <117pq4r$gi10$1@dont-email.me> |
| In reply to | #117868 |
Waldek Hebisch <antispam@fricas.org> schrieb:
> I wonder, did you try to add bound checking to gfortran?
It has been there for a long time, and not by me :-)
> ANd if yes did you measure performance impact?
I haven't run benchmarks, but analysis can be interesting.
Consider
subroutine foo(a,b,c,n)
integer, intent(in) :: n
real, dimension(n), intent(in) :: a,b
real, dimension(n), intent(out) :: c
integer :: i
do i=1,n
c(i) = a(i) + b(i)
end do
end subroutine foo
Using gfortran, this is translated by the front end into a loop
where every possible condition is checked on every iteration.
Optimization passes convert this into a single check against
INT_MAX, which inhibits vectorization.
Interestingly, if both n and i are converted to 64-bit
integers, the check is removed, and vectorization restored.
Using Fortran's array syntax removes the checks completely, so
c = a + b
has no checks left. It also iserts all checks before the
scalarizer-generated loops.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-09 00:35 +0000 |
| Message-ID | <1788914109-5857@newsgrouper.org> |
| In reply to | #117884 |
Thomas Koenig <tkoenig@netcologne.de> posted:
--------------
> Using Fortran's array syntax removes the checks completely, so
>
> c = a + b
>
> has no checks left.
Given that the compiler can see the precise shapes of {a,b,c}
the are no needs for checks. And that is one of the great
benefits of higher-level expressions.
> It also iserts all checks before the
> scalarizer-generated loops.
When the precise shapes are not (or cannot be) known at compile
time.
[toc] | [prev] | [next] | [standalone]
Page 7 of 24 — ← Prev page 1 … 5 6 [7] 8 9 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web