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 3 of 24 — ← Prev page 1 2 [3] 4 5 … 24 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-15 08:46 -0700 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <86pkyev7o0.fsf@linuxsc.com> |
| In reply to | #117928 |
scott@slp53.sl.home (Scott Lurndal) writes: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >> Paul Clayton <paaronclayton@gmail.com> posted: [...] >>> I do not understand how allowing software to limit its future >>> capabilities is an architectural flaw. >> >> When SW has used TBI often enough AND those same applications >> need 63-bit (or 64-bit) virtual addresses. > > Which will likely be _NEVER_. 2^64 is a, pardon my french, > shitload of virtual memory. [...] 64 bits is a fair amount of virtual address space. That is, until it starts being cut up into lots of pieces whose sizes are not known a priori, and moreso if (some or all of) the pieces are immovable.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-16 17:21 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <118ej5v$1vurp$1@paganini.bofh.team> |
| In reply to | #117928 |
Scott Lurndal <scott@slp53.sl.home> wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>
>>Paul Clayton <paaronclayton@gmail.com> posted:
>>
>>> On 9/2/26 9:50 PM, MitchAlsup wrote:
>>> >
>>> > Paul Clayton <paaronclayton@gmail.com> posted:
>>> [snip]
>>> >> I have wondered why Motorola did not add a 24-bit address mode
>>> >> (or even provide such with a hardwired configuration on earlier
>>> >> implementations, knowing that the extra bits would be desired
>>> >> for other uses to save memory).
>>> >
>>> > We realized our earlier mistake and did not want to repeat it.
>>>
>>> I think this would be more a case of "extend it" than repeat it,
>>> paying an incompatibility price to remove what was viewed as a
>>> mistake.
>>>
>>> [snip]
>>> >> AArch64 provides a means (Top Byte Ignore) of masking the most
>>> >> significant octet to allow it to be used by software.
>>> >
>>> > Sins of the present...
>>>
>>> I do not understand how allowing software to limit its future
>>> capabilities is an architectural flaw.
>>
>>When SW has used TBI often enough AND those same applications
>>need 63-bit (or 64-bit) virtual addresses.
>
> Which will likely be _NEVER_. 2^64 is a, pardon my french,
> shitload of virtual memory. Then there is the translation
> cost with up to perhaps seven or more levels of page table
> walk required. (Note that ARMv9 has support for 128-bit
> page table entries [FEAT_D128] which support up to 56-bits
> of PA and VA space).
>
2^24 was considerd huge, later 2^32. Simple observation is that
ie memory is available, then software will use it. Regardless
how much memory do you have. So the only question is if enough
memory will be available. Current semiconductor technology
is advancing slower than in the past. And one can doubt if
it ever can get close to 2^64. But IMO, one can not exlude this,
especially in biggest systems. OTOH I see no fundamental
obstacles to having 2^64 bytes of memory. Assuming that
memory cell plus various overheads need 1000 atoms, I get
smaller amount of matter than in a current hard drives and
comparable to current memory modules. Of course, aranging
atoms into useful memory configuration will require significant
technological breaktrough, but saying that this will never
happen looks foolish.
<snip>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-16 10:58 -0700 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <118elbp$3k4c4$1@dont-email.me> |
| In reply to | #118060 |
On 9/16/2026 10:21 AM, Waldek Hebisch wrote: > Scott Lurndal <scott@slp53.sl.home> wrote: >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>> >>> Paul Clayton <paaronclayton@gmail.com> posted: >>> >>>> On 9/2/26 9:50 PM, MitchAlsup wrote: >>>>> >>>>> Paul Clayton <paaronclayton@gmail.com> posted: >>>> [snip] >>>>>> I have wondered why Motorola did not add a 24-bit address mode >>>>>> (or even provide such with a hardwired configuration on earlier >>>>>> implementations, knowing that the extra bits would be desired >>>>>> for other uses to save memory). >>>>> >>>>> We realized our earlier mistake and did not want to repeat it. >>>> >>>> I think this would be more a case of "extend it" than repeat it, >>>> paying an incompatibility price to remove what was viewed as a >>>> mistake. >>>> >>>> [snip] >>>>>> AArch64 provides a means (Top Byte Ignore) of masking the most >>>>>> significant octet to allow it to be used by software. >>>>> >>>>> Sins of the present... >>>> >>>> I do not understand how allowing software to limit its future >>>> capabilities is an architectural flaw. >>> >>> When SW has used TBI often enough AND those same applications >>> need 63-bit (or 64-bit) virtual addresses. >> >> Which will likely be _NEVER_. 2^64 is a, pardon my french, >> shitload of virtual memory. Then there is the translation >> cost with up to perhaps seven or more levels of page table >> walk required. (Note that ARMv9 has support for 128-bit >> page table entries [FEAT_D128] which support up to 56-bits >> of PA and VA space). >> > > 2^24 was considerd huge, later 2^32. Simple observation is that > ie memory is available, then software will use it. Regardless > how much memory do you have. So the only question is if enough > memory will be available. Current semiconductor technology > is advancing slower than in the past. And one can doubt if > it ever can get close to 2^64. But IMO, one can not exlude this, > especially in biggest systems. OTOH I see no fundamental > obstacles to having 2^64 bytes of memory. Assuming that > memory cell plus various overheads need 1000 atoms, I get > smaller amount of matter than in a current hard drives and > comparable to current memory modules. Of course, aranging > atoms into useful memory configuration will require significant > technological breaktrough, but saying that this will never > happen looks foolish. While I agree with pretty much everything you say in the above post, note that the previous posts that you included above were talking about virtual memory size, not physical memory size. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-17 10:00 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <2026Sep17.120051@mips.complang.tuwien.ac.at> |
| In reply to | #118062 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >While I agree with pretty much everything you say in the above post, >note that the previous posts that you included above were talking about >virtual memory size, not physical memory size. Historically, once physical address space has approached virtual address size, problems made themselves felt that resulted in pressure to go for larger virtual addresses. Intel introduced PAE (36-bit physical addresses) with the Pentium Pro in 1995, Windows made use of that starting with Windows 2000. Linux with 2.3.23 in 1999, but the Linux developers had little love for using >1-2GB physical memories on 32-bit kernels and there are motions to remove support for them <https://lwn.net/Articles/813201/>. So, it looks like ideally VAs have at least one bit more tham PAs. HPPA/PowerPC-like segmentation may make for a larger difference if the OS uses these segments. AFAIK Linux just ignored the segments; I certainly never noticed them on my iBook G4 with 1.25GB RAM running Linux. - 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 | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-09-17 20:37 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <118hj31$1slu$1@gal.iecc.com> |
| In reply to | #118074 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>While I agree with pretty much everything you say in the above post, >>note that the previous posts that you included above were talking about >>virtual memory size, not physical memory size. > >Historically, once physical address space has approached virtual >address size, problems made themselves felt that resulted in pressure >to go for larger virtual addresses. ... Yes, that has happened many many times. S/370 had 24 bit virtual addresses, but a hack to allow 26 bit physical addresses for a while before they went to 31 bit for both in 370/XA. The original PDP-10 had an 18 bit 36 word physical and virtual address space. The KI10 added virtual memory still with the 18 bit virtual address but a 22 bit physical. Then the KL10 added an elegant kludge to expand virtual addresses to 30 bits. The PDP-11 had 16 bit addresses but soon the 11/45 had 18 bit and the 11/70 had 20 bit physical addresses, soon leading to 32 bit Vax. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-16 18:15 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <p1BqS.249305$ORN1.248658@fx24.iad> |
| In reply to | #118060 |
antispam@fricas.org (Waldek Hebisch) writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>> >>>Paul Clayton <paaronclayton@gmail.com> posted: >>> >>>> On 9/2/26 9:50 PM, MitchAlsup wrote: >>>> > >>>> > Paul Clayton <paaronclayton@gmail.com> posted: >>>> [snip] >>>> >> I have wondered why Motorola did not add a 24-bit address mode >>>> >> (or even provide such with a hardwired configuration on earlier >>>> >> implementations, knowing that the extra bits would be desired >>>> >> for other uses to save memory). >>>> > >>>> > We realized our earlier mistake and did not want to repeat it. >>>> >>>> I think this would be more a case of "extend it" than repeat it, >>>> paying an incompatibility price to remove what was viewed as a >>>> mistake. >>>> >>>> [snip] >>>> >> AArch64 provides a means (Top Byte Ignore) of masking the most >>>> >> significant octet to allow it to be used by software. >>>> > >>>> > Sins of the present... >>>> >>>> I do not understand how allowing software to limit its future >>>> capabilities is an architectural flaw. >>> >>>When SW has used TBI often enough AND those same applications >>>need 63-bit (or 64-bit) virtual addresses. >> >> Which will likely be _NEVER_. 2^64 is a, pardon my french, >> shitload of virtual memory. Then there is the translation >> cost with up to perhaps seven or more levels of page table >> walk required. (Note that ARMv9 has support for 128-bit >> page table entries [FEAT_D128] which support up to 56-bits >> of PA and VA space). >> > >2^24 was considerd huge, later 2^32. The curve here is exponential, not linear. > Simple observation is that >ie memory is available, then software will use it. That seems to be the microsoft philosophy, yes. However, that applies more to the physical address space not the virtual address space. > Regardless >how much memory do you have. So the only question is if enough >memory will be available. Current semiconductor technology >is advancing slower than in the past. And one can doubt if >it ever can get close to 2^64. It's not just memory that occupies pages in the physical or virtual address spaces. A PCI express device (particularly CXL) can have very large (64-bit) aperture sizes for the set architectural base address registers (BAR) which, in the CXL case, may actually be mapped into a process virtual address space. There are other ways to partition the physical address space (e.g. using the top bits as a NUMA node number, or in a distributed environment such as 3Leaf Systems had, the top eight bits identified another host on the memory bus). Even with that, 2^64 in the VA space is likely out of reach for a long, long time. > But IMO, one can not exlude this, >especially in biggest systems. OTOH I see no fundamental >obstacles to having 2^64 bytes of memory. Assuming that >memory cell plus various overheads need 1000 atoms, I get >smaller amount of matter than in a current hard drives and >comparable to current memory modules. Of course, aranging >atoms into useful memory configuration will require significant >technological breaktrough, but saying that this will never >happen looks foolish. > ><snip> >-- > Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-16 18:59 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1789585140-5857@newsgrouper.org> |
| In reply to | #118060 |
antispam@fricas.org (Waldek Hebisch) posted:
> Scott Lurndal <scott@slp53.sl.home> wrote:
> > MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >>
> >>Paul Clayton <paaronclayton@gmail.com> posted:
> >>
> >>> On 9/2/26 9:50 PM, MitchAlsup wrote:
> >>> >
> >>> > Paul Clayton <paaronclayton@gmail.com> posted:
> >>> [snip]
> >>> >> I have wondered why Motorola did not add a 24-bit address mode
> >>> >> (or even provide such with a hardwired configuration on earlier
> >>> >> implementations, knowing that the extra bits would be desired
> >>> >> for other uses to save memory).
> >>> >
> >>> > We realized our earlier mistake and did not want to repeat it.
> >>>
> >>> I think this would be more a case of "extend it" than repeat it,
> >>> paying an incompatibility price to remove what was viewed as a
> >>> mistake.
> >>>
> >>> [snip]
> >>> >> AArch64 provides a means (Top Byte Ignore) of masking the most
> >>> >> significant octet to allow it to be used by software.
> >>> >
> >>> > Sins of the present...
> >>>
> >>> I do not understand how allowing software to limit its future
> >>> capabilities is an architectural flaw.
> >>
> >>When SW has used TBI often enough AND those same applications
> >>need 63-bit (or 64-bit) virtual addresses.
> >
> > Which will likely be _NEVER_. 2^64 is a, pardon my french,
> > shitload of virtual memory. Then there is the translation
> > cost with up to perhaps seven or more levels of page table
> > walk required. (Note that ARMv9 has support for 128-bit
> > page table entries [FEAT_D128] which support up to 56-bits
> > of PA and VA space).
> >
>
> 2^24 was considerd huge, later 2^32. Simple observation is that
> ie memory is available, then software will use it. Regardless
> how much memory do you have. So the only question is if enough
> memory will be available. Current semiconductor technology
> is advancing slower than in the past. And one can doubt if
> it ever can get close to 2^64. But IMO, one can not exlude this,
> especially in biggest systems.
Consider a large server the size of a basketball stadium. Thousands
of racks each with dozens of systems and each motherboard maxed out
with DRAM. Suppose that each rack-board contains 2^44-bytes of DRAM.
Suppose HyperVisor/OS uses the high order PA bits to route DRAM
requests from this rack-board to any other board in the stadium,
emulating a coherent system with 2^58-bytes of available DRAM by
moving pages from rack-board to rack-board on demand (or better).
Each said rack-board would have its own Device address aperture
and configuration space aperture. The combined Device address
space would exceed ECAM PCIe available address space. So, by
routing device control register writes across the network, one
gets a FREE expansion of ECAM.
So, it seems to me that we already have the capability to build
systems of that scale. Whether we do or not depends on other
factors {like "we tried and it did not perform" or simply $$$}.
> OTOH I see no fundamental
> obstacles to having 2^64 bytes of memory. Assuming that
> memory cell plus various overheads need 1000 atoms, I get
> smaller amount of matter than in a current hard drives and
> comparable to current memory modules. Of course, aranging
> atoms into useful memory configuration will require significant
> technological breaktrough, but saying that this will never
> happen looks foolish.
>
> <snip>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-16 19:16 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <TVBqS.378705$bS3.70516@fx13.iad> |
| In reply to | #118064 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>antispam@fricas.org (Waldek Hebisch) posted:
>
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>> > MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>> >>
>> >>Paul Clayton <paaronclayton@gmail.com> posted:
>> >>
>> >>> On 9/2/26 9:50 PM, MitchAlsup wrote:
>> >>> >
>> >>> > Paul Clayton <paaronclayton@gmail.com> posted:
>> >>> [snip]
>> >>> >> I have wondered why Motorola did not add a 24-bit address mode
>> >>> >> (or even provide such with a hardwired configuration on earlier
>> >>> >> implementations, knowing that the extra bits would be desired
>> >>> >> for other uses to save memory).
>> >>> >
>> >>> > We realized our earlier mistake and did not want to repeat it.
>> >>>
>> >>> I think this would be more a case of "extend it" than repeat it,
>> >>> paying an incompatibility price to remove what was viewed as a
>> >>> mistake.
>> >>>
>> >>> [snip]
>> >>> >> AArch64 provides a means (Top Byte Ignore) of masking the most
>> >>> >> significant octet to allow it to be used by software.
>> >>> >
>> >>> > Sins of the present...
>> >>>
>> >>> I do not understand how allowing software to limit its future
>> >>> capabilities is an architectural flaw.
>> >>
>> >>When SW has used TBI often enough AND those same applications
>> >>need 63-bit (or 64-bit) virtual addresses.
>> >
>> > Which will likely be _NEVER_. 2^64 is a, pardon my french,
>> > shitload of virtual memory. Then there is the translation
>> > cost with up to perhaps seven or more levels of page table
>> > walk required. (Note that ARMv9 has support for 128-bit
>> > page table entries [FEAT_D128] which support up to 56-bits
>> > of PA and VA space).
>> >
>>
>> 2^24 was considerd huge, later 2^32. Simple observation is that
>> ie memory is available, then software will use it. Regardless
>> how much memory do you have. So the only question is if enough
>> memory will be available. Current semiconductor technology
>> is advancing slower than in the past. And one can doubt if
>> it ever can get close to 2^64. But IMO, one can not exlude this,
>> especially in biggest systems.
>
>Consider a large server the size of a basketball stadium. Thousands
>of racks each with dozens of systems and each motherboard maxed out
>with DRAM. Suppose that each rack-board contains 2^44-bytes of DRAM.
>
>Suppose HyperVisor/OS uses the high order PA bits to route DRAM
>requests from this rack-board to any other board in the stadium,
>emulating a coherent system with 2^58-bytes of available DRAM by
>moving pages from rack-board to rack-board on demand (or better).
That's basically what we developed at 3Leaf Systems two decades
ago. We designed and fabricated an ASIC that connected to
hypertransport and extended the AMD conherency domain over infiniband
to up to 64 (at the time) independent nodes. We used the top
8 bits of the physical address as the target node address.
Fred Weber was one of our advisors.
Two decades later PCIe CXL is close to being able to support
a similar configuration.
>So, it seems to me that we already have the capability to build
>systems of that scale. Whether we do or not depends on other
>factors {like "we tried and it did not perform" or simply $$$}.
Performance was an issue. At the time, DDR IB had cut-through
routing, so the round trip latency was about 800ns through the
switch for a non-posted request. Our Quickpath version for
Intel used QDR IB and had close to 200ns r/t latency in
simulation for a non-posted request. Unfortunately we got
caught up in the Bush recession - funding ran out and a
pending acquisition canceled.
We had a custom bare-metal hypervisor that could assign resources
from across the entire system to individual VMs. There was no
sharing of physical cores by multiple VMs, which simplified the
hypervisor somewhat. Linux could hot-plug/unplug CPUs and
memory dynamically.
Today with CXL 3.2 and GEN6 PCIe, the switching cost is significantly better.
There were also issues with cache line contention due to
spin locks (LLL had a particular test that hammered a single
lock across all CPUs), in part due to the AMD backstop
of using the global bus lock if it took to long to get exclusive
cache line access to guarantee forward progress.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-17 00:19 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1789604396-5857@newsgrouper.org> |
| In reply to | #118065 |
scott@slp53.sl.home (Scott Lurndal) posted:
Thank you Scott for what follows.
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >antispam@fricas.org (Waldek Hebisch) posted:
> >
> >> Scott Lurndal <scott@slp53.sl.home> wrote:
> >> > MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >> >>
> >> >>Paul Clayton <paaronclayton@gmail.com> posted:
> >> >>
> >> >>> On 9/2/26 9:50 PM, MitchAlsup wrote:
> >> >>> >
> >> >>> > Paul Clayton <paaronclayton@gmail.com> posted:
> >> >>> [snip]
> >> >>> >> I have wondered why Motorola did not add a 24-bit address mode
> >> >>> >> (or even provide such with a hardwired configuration on earlier
> >> >>> >> implementations, knowing that the extra bits would be desired
> >> >>> >> for other uses to save memory).
> >> >>> >
> >> >>> > We realized our earlier mistake and did not want to repeat it.
> >> >>>
> >> >>> I think this would be more a case of "extend it" than repeat it,
> >> >>> paying an incompatibility price to remove what was viewed as a
> >> >>> mistake.
> >> >>>
> >> >>> [snip]
> >> >>> >> AArch64 provides a means (Top Byte Ignore) of masking the most
> >> >>> >> significant octet to allow it to be used by software.
> >> >>> >
> >> >>> > Sins of the present...
> >> >>>
> >> >>> I do not understand how allowing software to limit its future
> >> >>> capabilities is an architectural flaw.
> >> >>
> >> >>When SW has used TBI often enough AND those same applications
> >> >>need 63-bit (or 64-bit) virtual addresses.
> >> >
> >> > Which will likely be _NEVER_. 2^64 is a, pardon my french,
> >> > shitload of virtual memory. Then there is the translation
> >> > cost with up to perhaps seven or more levels of page table
> >> > walk required. (Note that ARMv9 has support for 128-bit
> >> > page table entries [FEAT_D128] which support up to 56-bits
> >> > of PA and VA space).
> >> >
> >>
> >> 2^24 was considerd huge, later 2^32. Simple observation is that
> >> ie memory is available, then software will use it. Regardless
> >> how much memory do you have. So the only question is if enough
> >> memory will be available. Current semiconductor technology
> >> is advancing slower than in the past. And one can doubt if
> >> it ever can get close to 2^64. But IMO, one can not exlude this,
> >> especially in biggest systems.
> >
> >Consider a large server the size of a basketball stadium. Thousands
> >of racks each with dozens of systems and each motherboard maxed out
> >with DRAM. Suppose that each rack-board contains 2^44-bytes of DRAM.
> >
> >Suppose HyperVisor/OS uses the high order PA bits to route DRAM
> >requests from this rack-board to any other board in the stadium,
> >emulating a coherent system with 2^58-bytes of available DRAM by
> >moving pages from rack-board to rack-board on demand (or better).
>
> That's basically what we developed at 3Leaf Systems two decades
> ago. We designed and fabricated an ASIC that connected to
> hypertransport and extended the AMD conherency domain over infiniband
> to up to 64 (at the time) independent nodes. We used the top
> 8 bits of the physical address as the target node address.
> Fred Weber was one of our advisors.
>
> Two decades later PCIe CXL is close to being able to support
> a similar configuration.
>
>
>
> >So, it seems to me that we already have the capability to build
> >systems of that scale. Whether we do or not depends on other
> >factors {like "we tried and it did not perform" or simply $$$}.
>
> Performance was an issue. At the time, DDR IB had cut-through
> routing, so the round trip latency was about 800ns through the
> switch for a non-posted request. Our Quickpath version for
> Intel used QDR IB and had close to 200ns r/t latency in
> simulation for a non-posted request. Unfortunately we got
> caught up in the Bush recession - funding ran out and a
> pending acquisition canceled.
>
> We had a custom bare-metal hypervisor that could assign resources
> from across the entire system to individual VMs. There was no
> sharing of physical cores by multiple VMs, which simplified the
> hypervisor somewhat. Linux could hot-plug/unplug CPUs and
> memory dynamically.
>
> Today with CXL 3.2 and GEN6 PCIe, the switching cost is significantly better.
>
> There were also issues with cache line contention due to
> spin locks (LLL had a particular test that hammered a single
> lock across all CPUs), in part due to the AMD backstop
> of using the global bus lock if it took to long to get exclusive
> cache line access to guarantee forward progress.
>
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-16 12:24 -0700 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <118eqcj$3m4r5$1@dont-email.me> |
| In reply to | #118064 |
On 9/16/2026 11:59 AM, MitchAlsup wrote:
>
> antispam@fricas.org (Waldek Hebisch) posted:
snip
>> 2^24 was considerd huge, later 2^32. Simple observation is that
>> ie memory is available, then software will use it. Regardless
>> how much memory do you have. So the only question is if enough
>> memory will be available. Current semiconductor technology
>> is advancing slower than in the past. And one can doubt if
>> it ever can get close to 2^64. But IMO, one can not exlude this,
>> especially in biggest systems.
>
> Consider a large server the size of a basketball stadium. Thousands
> of racks each with dozens of systems and each motherboard maxed out
> with DRAM. Suppose that each rack-board contains 2^44-bytes of DRAM.
>
> Suppose HyperVisor/OS uses the high order PA bits to route DRAM
> requests from this rack-board to any other board in the stadium,
> emulating a coherent system with 2^58-bytes of available DRAM by
> moving pages from rack-board to rack-board on demand (or better).
>
> Each said rack-board would have its own Device address aperture
> and configuration space aperture. The combined Device address
> space would exceed ECAM PCIe available address space. So, by
> routing device control register writes across the network, one
> gets a FREE expansion of ECAM.
>
> So, it seems to me that we already have the capability to build
> systems of that scale. Whether we do or not depends on other
> factors {like "we tried and it did not perform" or simply $$$}.
Is this essentially a large NUMA system?
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-17 00:20 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1789604435-5857@newsgrouper.org> |
| In reply to | #118066 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
> On 9/16/2026 11:59 AM, MitchAlsup wrote:
> >
> > antispam@fricas.org (Waldek Hebisch) posted:
>
> snip
> >> 2^24 was considerd huge, later 2^32. Simple observation is that
> >> ie memory is available, then software will use it. Regardless
> >> how much memory do you have. So the only question is if enough
> >> memory will be available. Current semiconductor technology
> >> is advancing slower than in the past. And one can doubt if
> >> it ever can get close to 2^64. But IMO, one can not exlude this,
> >> especially in biggest systems.
> >
> > Consider a large server the size of a basketball stadium. Thousands
> > of racks each with dozens of systems and each motherboard maxed out
> > with DRAM. Suppose that each rack-board contains 2^44-bytes of DRAM.
> >
> > Suppose HyperVisor/OS uses the high order PA bits to route DRAM
> > requests from this rack-board to any other board in the stadium,
> > emulating a coherent system with 2^58-bytes of available DRAM by
> > moving pages from rack-board to rack-board on demand (or better).
> >
> > Each said rack-board would have its own Device address aperture
> > and configuration space aperture. The combined Device address
> > space would exceed ECAM PCIe available address space. So, by
> > routing device control register writes across the network, one
> > gets a FREE expansion of ECAM.
> >
> > So, it seems to me that we already have the capability to build
> > systems of that scale. Whether we do or not depends on other
> > factors {like "we tried and it did not perform" or simply $$$}.
>
> Is this essentially a large NUMA system?
Well, it not a UMA system ...
>
>
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-13 17:12 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <11898nb$1nc06$3@dont-email.me> |
| In reply to | #117917 |
On 9/9/26 7:25 PM, MitchAlsup wrote: I am going to split my responses into multiple posts. > Paul Clayton <paaronclayton@gmail.com> posted: > >> On 9/2/26 9:50 PM, MitchAlsup wrote: >>> >>> Paul Clayton <paaronclayton@gmail.com> posted: [snip] >> I do not understand how allowing software to limit its future >> capabilities is an architectural flaw. > > When SW has used TBI often enough AND those same applications > need 63-bit (or 64-bit) virtual addresses. I view that as the software developers problem. If the hardware interface clearly specifies the tradeoffs, the software developers have the responsibility (in my opinion) to make reasonable decisions and live with the consequences. Humans being human, there will be complaints like "Why did you let me shoot myself in the foot?" just as fixing space bar heating might ruin someone's workflow. [snip] > Yes, but You understand the difference between Architecture and > implementation. May designers do not (especially early in their > careers.) There are many compatibility layers. Socket compatibility matters less now for CPUs, but drop-in upgrades used to be a big deal. However, Socket 7 forever would not have been a good idea. (Of course, software does not care about that compatibility layer.) >> (This can reduce microarchitectural flexiblity if the software >> is considered critical enough and rewriting/retuning is not an >> option.) > > Which is why you should strive to eliminate those things before > SW gets written. Which then reduces software flexibility. TANSTAAFL Masking the high bits in software would also have compatibility issues (besides adding an instruction and using an extra register if the tag value it to be retained). (At least the convention of "positive" application space addresses avoids the need to sign extend the address. Sign extending from an arbitrary bit position does not seem to be commonly available as a single instruction, though masking upper bits may also be expensive in most ISAs.) If masking was going to be done, putting the tag in the least significant bits would allow a shift to generate the address. My 66000 has a 64-bit bit insert instruction (32-bit immediate) that could extract an address, allowing alignment bits to be used for the tag. (Two 6-bit immediates and three 5-bit register specifiers would mean using four major opcode slots for an uncommon operation to provide a 32-bit instruction. An explicit extract instruction could fit by assuming the zero register as the SRC1, but that also seems wasteful of the encoding space.) There is also the issue of what hardware optimizes. E.g., abysmally slow floating point denormals might encourage use of a flush-to-zero configuration option. Implementing slow denormals but not providing a flush-to-zero option seems likely to upset users, but not having the extra hardware to provide fast or only slightly slow denormals (in the 1980s) might have seemed justified. Software that uses flush-to-zero might behave noticeably differently (besides lacking bit identical results) when run on a system with just full-speed denormals. >> Software that chooses to use such address bits for tags will >> still run on newer designs with full 64-bit virtual addresses >> though limited to 56-bit virtual addresses. I think that most >> software will never need 64-bit virtual addresses. I also think >> that a lot of software would not bother using address tagging. > > Illustrating the small usage envelope of that mis-feature. I think the feature is likely to have a small amount of software that uses it, but a large amount of use. E.g., web browser javascript execution might use such a feature. There are not many javascript runtimes in use, but they are an important category of software. I view tagged addresses as something useful to software that hardware can provide cheaply. For some uses, class-based region allocation might be adequate at the cost of some sparsity. With only 48 bits being reliably available, using valid addresses for such tags might be difficult. This also introduces software fragility where the software cannot use all the address bits because some systems will not allow such addresses. (The use of the tags for detecting many accidental misuses of memory may also be significant. I am inclined to believe that use after free and buffer overruns would be better handled in software, but providing a little protection in a secondary layer — allowing poorly developed software to run a little more securely — may be valuable.) More posts to follow.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-13 17:26 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <11898nc$1nc06$4@dont-email.me> |
| In reply to | #117917 |
On 9/9/26 7:25 PM, MitchAlsup wrote: [snip] > So, send me an e-mail address and I can send you ISA-55 and SFT-55 I may well send you an email within a year asking for this. Right now my energy and attention levels seem to be unusually low and I want to be able to read with understanding and appreciation.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-13 18:27 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <11898nd$1nc06$5@dont-email.me> |
| In reply to | #117917 |
On 9/9/26 7:25 PM, MitchAlsup wrote: > > Paul Clayton <paaronclayton@gmail.com> posted: [big snip] >> Side note: I have felt some attraction to a virtual Harvard >> system, i.e., a separate virtual address space for instructions. > > Leads to problems for debuggers and for JIT. I am not certain why JIT would be that problematic. One would need the ability to store into instruction space, but making such stores explicit seems desirable (a bit like having pages that are thread-local and not needing external coherence). >> Besides making writing to code more explicit and slightly >> increasing the address space (less than a bit as code is rarely >> half of the used memory for larger systems), such might present >> opportunities to use the instruction pointer to generate data >> addresses that are not cluttered with instructions. > > Mc88110 had separatable Code and Data, nobody used it. > > The cache chips each had their own MMU+TLB so one could go full > Harvard is they choose. It was not clear from the little documentation I read if such was intended to be an architectural feature (i.e., would the software effort to exploit it be wasted in the next generation). The Fairchild Clipper had a similar C[A]MMU design. I thought both were attractive in providing set associative caches with modest pin counts and chip size limits. I did notice the possibility of having different page table pointers in the different CMMUs, but it was not clear if such was intentional or just a side effect of having independent interfaces for data and instructions. The Clipper CAMMU design also had some hardwired TLB entries, mainly to simplify boot-up; TLB entries with fixed virtual addresses and even fixed physical addresses (and other metadata) would be cheap. It is not clear that providing, e.g., one way of few (or zero) tag bits would have been useful; such would use less area but would also be of limited use. >> I thought of the possibility of using negative offsets from a >> masked instruction pointer to provide a cheap pointer usable >> with shorter offsets. Separate instruction and data address >> spaces would allow > > ??? Sorry, I either accidentally deleted the rest of that statement or (much more likely) looked at something else and forgot where I was. My point was that separate address spaces would allow positive offsets from a masked instruction pointer without the risk of running into code. I do think being able to use relatively short offsets from an IP-based address could be useful. However, I doubt most programs have a large number of static variables. I have also wondered about the even odder "feature" of potentially exploiting "pseudo-constants" that are hoisted into the front-end more like immediates. Although such could facilitate lower effective data access latency for some loads, I suspect such loads are to rare to justify the effort and forwarding updates (even if rare being pseudo-constants) would add complexity.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-13 20:29 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <11898nf$1nc06$6@dont-email.me> |
| In reply to | #117917 |
On 9/9/26 7:25 PM, MitchAlsup wrote:
>
> Paul Clayton <paaronclayton@gmail.com> posted:
[snip]
>> I do appreciate those features of My 66000 page tables. I do
>> wonder if using large pages in the page table itself might be
>> worth supporting (Andy Glew had suggested such).
>
> I expect that either Guest OS will be supplied with large pages
> from Host OS, or vice versa. One simplifies Guest OS MMU management;
> the other simplifies Host OS management. My philosophy, here, is to
> allow SW e-the-large to figure it out for themselves (over time).
I was referring to the later "clarified" level merging. For
dense address space use (but with enough absent pages or enough
address scattering that using large pages for leaf nodes/real
pages is impractical) having an 8 MiB (two level) node might
not cost more storage (possibly even saving a whopping 8 KiB!☺)
and provide on level shallower look-up.
>> With page level "merging" (large pages), one could (in theory)
>> have 5-bit levels that could support multiples of 32 in page
>> size while not requiring the page table depth to be doubled.
>> 256-KiB pages might be a useful option between 8 MiB and 8 KiB.
>
> A PTE mapping a large page in My 66000, uses the unused PTE.PA
> bits as a limit. So, while the large page still has large page
> alignment; it only needs to contain as many pages as required.
> So if you are using 23-bit large pages, you can use one PTE
> entry (in TLB) to access exactly 173 of those pages. ...
This is a very nice feature for sparse or partially used pages,
but it is distinct from using larger pages in the page table
itself.
>> Such also supports more flexible tradeoffs of depth versus
>> internal fragmentation. An application using a large address
>> space might have little sparsity in the upper address bits and
>> so benefit from merging top page table levels.
>
> The LVL field can be used to skip the top bits (to VAS size),
> then used to skip intermediate levels (sparse VAS), and then
> skip the lower levels (super pages). All in one set of bits.
Support for sparsity is very nice, but improving performance for
dense-ish high memory use also seems worth pursuing.
>> Level merging (really splitting) might also support more
>> flexible sharing of page tables. With 5-bit basic levels, an
>> aligned 256-byte section of a 8 KiB page table block could be
>> shared without sharing the rest of the translations or
>> permissions. (I have no idea if such would actually be useful
>> much less worthwhile, but it is possible.)
>
> Hard on the TLB.
The TLB proper already has to support multiple page sizes. While
doubling the number of page sizes supported would add
difficulties, it would also provide more flexibility in page
sizes. (My 66000's ability to disallow access to a part of a
large page does reduce the requirement for finer page
granularity at least somewhat, though having many huge pages
that are only 3% used seems sub-optimal. The added used size
indicator (if that applies to pages proper) presumably would
also complicate the TLB.)
Since some ISAs support an intermediate page size (via page
grouping, e.g.), TLBs would have to deal with that complication
(if the implementation supports that page size feature).
Splitting large pages is a straightforward mechanism, though it
has the complicated tradeoff about how much to prefetch into the
TLB.
For page table traversing and intermediate node caching, having
variably sized levels would add complexity. The traversal
complexity does not seem likely to be that much worse than for
skipping levels. The caching complexity seems substantially
worse and similar to TLB complexity.
Although one could trivially provide N cache entries for every
5-bit index-length-change level, this would obviously be
wasteful given that the utilization would not be balanced.
With hash-rehash it would be possible for the alternative
index to be used as a kind of victim cache/L2. The 32-fold
size difference is also small enough that with a large number of
sets André Seznec's method for supporting multiple page sizes in
TLBs could be used ("Concurrent Support of Multiple Page Sizes
On a Skewed Associative TLB", 2003); for two sizes one needs one
indexing bit that is shared by both sizes. Sharing entries does
cost some bits compared to dedicated size/level entries.
I _suspect_ the hardware complexity is not insurmountable and
that the question is whether the effort is justified.
Intermediate larger page sizes seem attractive.
Merging two 10-bit levels into one 20-bit level would not seem
to add much complexity to the node caching. The index and tag
bits would be the same as for the first of the 10-bit levels and
the data portion would have unused bits (being 8 MiB aligned
rather than 8 KiB aligned).
(Andy Glew had the idea of merging page table levels. Using a
smaller, e.g., 5-bit, indexing fragment was my own weirdness,
seeking to provide even more flexibility by exploiting level
merging.)
>> Level merging seems to be especially useful for nested page
>> tables in virtualization. The virtual-physical address space
>> is dense (I think). A virtual machine monitor might give huge
>> pages to a guest but could also benefit from a flatter upper
>> portion of the page table.
>
> There is currently a debate going on as to whether Guest OS should
> page its own pages or just have Host OS do it; Guest OS page fault
> handler just never gets control.
I think the Guest OS has potentially more knowledge of what
value the presence of its pages have, but the Host OS has more
knowledge of what system pressures are present. A particular
workload might be 10% slower with 25% less memory consumption
but 50% slower with 40% less memory consumption. Just like
compute can use priority to "buy" a larger fraction of work,
being able to communicate to resource managers (OS or hardware)
might be useful. Cache and memory capacities, energy/power,
cache/memory bandwidth, and core occupancy are obvious
resources.
I have mentioned before that a market-like system of resource
allocation might be useful. Unlike realworld economics, most
information asymmetries could be avoided (though communication
still has overhead the scales and responsiveness seem more
friendly to market-like regulation).
I do not have any idea how the complexity of the interaction of
value of timeliness and resource availability could be handled
well, but already implemented power management strategies give
some hint that a budget can be given and the system can adjust
reasonably well.
>> OS support would be a problem. I do not think any architecture
>> provides merging of page table levels.
>
> Not Much HW provides said feature.
I do not know of any hardware that supports page table level
merging.
>> One weird thought I had was to have multiple page table "bases"
>> loaded for a process. This would be a little like caching
>> directory entries with prefetching of such on context switches.
[snip]
>> Rather than having to traverse the page table three times to
>> load three specific node points into the translation cache (and
>> likely caching other less useful information until it ages out),
>> the necessary entries would be prefetched and "locked".
>
> ???
If a process has a large address space but two intermediate
level nodes are heavily used and/or densely populated,
installing these nodes at context switch avoids having to load
them from the general page table. (This is really just a
prefetch operation, but it also supports a certain from of
sparsity. If I understand correctly, with My 66000 if only
three entries are in the first (base) level of the page table,
at least that one indirection is initially required even if
each of those three entries can then skip an arbitrary number
of levels — which I did not have in mind, such is a neat trick.
With three base pointers, the dense regions would be preloaded.)
This (probably not worthwhile☹) concept is just prefetching of
page table nodes and locking them into the node cache while the
process is active.
>> Two obvious issues come to mind. First, context switches are
>> expected to be uncommon, so a modest savings becomes a trivial
>> savings. Second, this does not scale down or up to different
>> numbers of nodes.
>
> ???
The benefit of prefetching a few intermediate nodes when a
process activates shrunk if processes are rarely deactivated
and reactivated.
Different processes might want a different number of nodes
prefetched and locked, but forcing the cache to have N locked
entries for every thread has issues with utilization. If the
number of prefetched nodes can vary, how is the storage handled
(indirection cost to an overflow structure, internal
fragmentation, or some other cost). With support for a large N,
the costs increase. Of course, hardware could treat the lock as
a hint, but that seems problematic for processes using such for
a responsiveness constraint. Adding criticality metadata could
avoid such at the cost of further complexity.
[snip]
> My 66000 interrupt negotiator goes out and fetches the MSI-X
> message from its-core's interrupt table, then pre-fetches the
> PSL and registers while core continues running current thread.
> The Fetch message and fetch context delays are similar are run
> concurrently with current thread.
>
> Once MSI-X message verifies the core should take the interrupt,
> the new context is ready to install in core resources, while
> pushing our current state, saving latency at each step. While
> setting up the context, the first instruction is fetched, and
> the ISR is in control.
PSL? Paging Structure L??
It also seems that the execution aspects of a soon to be paused
thread might be adjusted. If the interrupted thread is near a
work type phase boundary (and the interrupt can tolerate some
delay), stopping immediately (saving some energy by not trying
to load a new working set into the cache) or continuing to the
phase change (possibly with a more liberal power budget) may be
useful. ESM provides a fine-grained phase boundary, but there
may be other phase boundaries that could be exploited. System
calls might sometimes be such a boundary.
I rather suspect that such flexible scheduling/resource use
would be far too complex to be worthwhile (the time between
interrupt awareness and interrupt thread readiness seems likely
to be rather small), but it seems interesting as a theoretical
possibility.
[I hope to write some comments on the Virtual Vector Method
soonish. If I take my computer to the library Monday, I will
send this and the five other posts then and probably not
post again before Tuesday.]
Thank you for sharing your insights. Even when I am not
convinced I at least get to think about the matter.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-16 18:03 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <118h4ck$fi2a$2@dont-email.me> |
| In reply to | #117917 |
On 9/9/26 7:25 PM, MitchAlsup wrote:
>
> Paul Clayton <paaronclayton@gmail.com> posted:
[snip]
>> I do not understand how the Virtual Vector Method would be
>> implemented efficiently. SIMD with its explicit pack and unpack
>> instructions seems likely to provide similar control. (Most SIMD
>> designs do not provide special support for short strides or
>> complete structure unpacking where all the data in a non-strided
>> stream is used but the data is scattered. GPUs might provide
>> special support for three and four color (un)packing.) However,
>> I am not a hardware designer (though I might understand a simple
>> flowchart ☺).
>
> SIMD is simply direct compiler management of multi-lane calculations.
Which makes it easy to understand how hardware would implement
such.
> vVM allows for the processor to utilize multi-lane calculations
> with flexibility SIMD can never do::
>
> word = word + half*byte;
Not directly, but most SIMD instruction sets provide pack and
unpack. Yes, that introduces substantial instruction overhead
(three unpack instructions for the above code, I think) and
contributes to the number of SIMD instructions in the
instruction set (one pack and unpack instruction pair for each
doubling in operand size), but it makes the implementation
straightforward. If unpacking is rare (or unpacked values are
heavily reused from registers), such might not hurt power-
performance-area.
On a size-related note, SIMD also has instruction number issues
with "overflow", e.g., requiring multiply high instructions.
(The Mill had the nice feature of specifying saturating,
overflow exception, wrapping, or doubling width.)
> And if the HW happens to have 256-bits of calculation width, then
> 8 of those can be performed in 1 pipelined clock, without any
> SW visible SIMD registers.
In theory, hardware knowing that one of the multiplicands is
smaller would allow the multiplier to have higher throughput.
If such was known at hardware design time to be a case worth
optimizing, I guess that doubling of throughput for such would
require less than 10% added hardware.
>> I do feel that VVM is a nice software interface. It avoids a
>> lot of SIMD issues and not just instruction diversity explosion.
>
> vVM is 2 instructions that provide the utility of thousands (based
> on typical SIMD ISA).
>
> vVM fails at the super luminary uses of SIMD (one lone SIMD inst
> without any containing loop structure)
If there is significant overhead in start-up, even two or three
SIMD instructions might have better performance.
I also got the impression that there was no way to exploit
blocking as in matrix multiplication. With SIMD, the extra
register context can be used as a first level of blocking.
Wide implementations of vVM would have extra storage that
(I think) could be used to repeat use (conceptually similar
to how vVM avoids splat instructions but supports vector-
scalar operations), but this microarchitectural aspect cannot
(I think) be exploited by software.
While not exactly SIMD/vector operations, I also like lane
crossing operations like count bytes (two-bytes) until zero,
which can find a zero terminated string length and find a
matching entry given a previous xor (which could be useful
with multiple hash table entries in a bucket; with a good
hash function producing a 64-bit result, there would not be
a need for splatting). Substantial hardware reuse may be
possible with find first/last set/unset bit hardware.
There are some operations that hardware can do much more
efficiently than software (like popcount), but it is not
obvious that such instructions are broadly useful or
otherwise important enough to provide.
Side note: I wonder if moving the LOOP instruction to the top of
the loop might be better. Such would seem to require adding an
early loop body-end instruction (or recognizing a jump to the
instruction after the end of the loop as such) when there is not
a single loop end. One possible advantage might be the ability
to fold loop counter preconditions into that instruction, but
having the word size of the loop body available at the start
might be useful. This would also add invisible architectural
context (loop end marker) to be saved on context switches.
I think some DSPs started loops with a such a special
instruction. (It is also kind of like a prepare-to-branch
instruction.)
>> I feel it does not exploit a few local, non-loop wide execution
>> cases, does not address blocking, and the loop length limits may
>> be introduce issues.
>
> When a LD (or ST) touches a cache line and HW can determine the
> access pattern is "dense"; HW reads out cache-width of data and
> accesses that buffer multiple times feeding the multi-lane calc-
> ulation. So, the wide buffering flip-flops are present (they have
> to be for perf) but each implementation gets to decide how many
> and how wide, and how many cache ports are "reasonable" for this
> implementation.
It might also be nice to optimize cases of short constant
strides (fewer cache tag accesses). While similar checks could
be performed for scalar loads, with a vector one can expect
more reuse of information. Reusing TLB probes is another obvious
optimization.
Being able to optimize array of structure accesses where
multiple structure members are accessed might be worthwhile.
Complex number and red-blue-green vectors are obvious examples,
but array of structures might have multiple members accessed
in a loop and benefit from reducing the number of cache
accesses.
> Those buffers are connected to the multi-lane calculation unit
> with lots of multiplexers (which perform the pack, unpack,
> width-changes, and forwarding). Those multiplexers take an
> extra cycle into and out of when considering latency.
Controlling all of that seems complex (to me). On the other
hand, it obviously provides microarchitectural scalability with
scalar execution semantics and without greatly increasing the
number of instructions in the instructions set. Avoiding merely
temporary context that needs to be saved and restored on context
switches is also a vVM advantage, but that advantage is related
to the disadvantage of not optimizing blocking.
>> Yet I also recognize that being ideal for
>> all use cases regardless of complexity is both unachievable
>> (not all tradeoffs are limited to design difficulty or even
>> implementation area) and impractical (aside from complexity
>> having a cost, different workloads benefit differently from
>> "effort" and the value of the benefit is uniform across all
>> workloads at all scales).
>
> While I agree that it is more complex, is it more complex than
> having 1,300 SIMD instructions ??? And when we have the capability
> of building 10-wide machines (Apple M5) does that really matter?
I do not think one needs to add instructions for different
execution widths except for load and store. I guess using
metadata preserved from loads is kind of like what vVM does
in setting up the operand routing controls. (This is also
kind of like sign extending short loads to use ordinary
operate instructions. A Load128 instruction in an architecture
supporting 512-bit SIMD registers would treat the "higher" 384
bits as not-present.)
I (and everyone else) would prefer something that provided
all the advantages of SIMD and vVM and none of the disadvantages
of either, but when defining an interface one must make a
decision (EEP!) about the importance of various uses.
[snip]
>> Microarchitecturally exploiting spatial locality (SRAM array
>> width, block size, and page size) to avoid redundant work seems
>> an obvious method toward power efficiency. Allowing software to
>> help seems reasonable to *me* (but I am excessively attracted by
>> hardware-software cooperation).
>
> I don't think I am putting anything in the way of SW doing what it
> wants, here.
Software can provide the base semantics to a My 66000
implementation, but My 66000 seems uninterested in software-
provided hints or pre-conditions. (Historically such have been
very fragile.)
I think AArch64's load register pair instruction requires 128-
bit alignment, such would allow hardware to know in advance that
a single 128-bit wide SRAM array access can satisfy this
operation. (This might not be useful information, but it might
facilitate scheduling before address generation.)
The hard part seems to be encoding information that is actually
useful. Implementation changes can make information useless
(like aligned SIMD load instructions which became useless once
unaligned load instructions were equally fast in the aligned
case).
There may be preconditions known to software that hardware can
exploit (a bit like vVM prohibits branches).
I suspect something like a signature buffer ("Signature Buffer:
Bridging Performance Gap between Registers and Caches", Lu Peng,
2004) which stores values accessed relative to a base pointer in
a special buffer/cache, might benefit from a hint about the
expected utility of such caching.
With an intermediate software distribution format, it might be
more practical to implement microarchitecture-specific (and
version-specific) optimizations while providing compatibility
for distributed software.
Not all information is worth storing/caching. Bloating the
instruction stream with all the information available to
software is obviously not a good idea, but I _feel_ that
software (compiler/developer) will have information that
could be useful to hardware.
[snip]
>> x86 had subregisters before MMX. Even some RISCs used register
>> pairs for double precision floating point, presenting the same
>> renaming/forwarding issues.
>
> There you go again blaming x86 as being something good in computer
> architecture.
I am not claiming such is good. I am claiming that MMX was not
the start of a register holding multiple values.
(I think for 8086, performing one 16-bit load and operating on
two 8-bit parts was much faster than using two loads. Having
the equivalent of AArch64's load pair of registers, which can
have 32-bit values, would have used a precious register in 8086.
At the time, such seems likely to have been a reasonable design
choice. Of course, people were often writing in assembly then,
so compiler use of this was not that important.)
Even bit vectors are actually multiple bit values; I would want
a compiler to pack 32 bools into a single 32-bit "integer"
rather than use 32 bytes.
The complementary issue of storing a single value in multiple
registers is also unpleasant for a compiler, but many RISCs
thought this was acceptable. While I think My 66000's DOUBLE
avoids the register allocation constraints of simple register
pairing, it does present a single "value" as occupying
multiple registers.
[snip]
> On the other hand, AI turned around and is consuming all available
> DRAM, so its a good thing SSDs are so fast.
Yes, this does facilitate extending the length of the refresh
cycle. The pain of paging memory in-and-out is not as great and
file caching and prefetch is not as critical. On the other hand,
such seems likely to increase wear on the flash.
I read that AI is also increasing the price of flash (and actual
disk drives since the raw scraped data requires storage as
well).
I probably missed commenting on some parts of the long response
to my long previous posting, but I am going to count this
sub-project as done.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-03 02:46 +0000 |
| Message-ID | <117an2n$3au5h$3@dont-email.me> |
| In reply to | #117746 |
On Wed, 2 Sep 2026 18:59:58 -0400, Paul Clayton wrote: > I have wondered why Motorola did not add a 24-bit address mode ... You mean in later chips? I guess it was considered unnecessary, given that external MMU-type hacks like the one Apple stuck in could, and did, solve the problem. The original 68000 (with a 16-bit bus) only supported 24-bit addressing. There was also the 68008 (with an 8-bit bus) that only looked at the bottom 20 bits of the address. That was used in the Sinclair QL machine. I wonder if that was the most expensive (i.e. least cheap) CPU chip that Sir Clive ever put into one of his machines ... > This would have introduced overhead for new OSes (having to > configure the bit), but would allow old software to run correctly > while allowing use of the 32-bit address space. Apple basically gave early Mac developers an ultimatum: stop assuming those top 8 bits could be used for non-address purposes, or else. The move to 32-bit cleanliness in the Mac world went quite quickly. Compare how it took about a decade for the DOS/Windows world to move from 16-bit software APIs to 32-bit. > If I recall correctly, 32-bit ARM provided a means to define the > size of the user address space such that a variable number of more > significant bits were used as system address bits (similar to the > negative addresses are system addresses of some OSes) with a > separate page table. This must have been later. The original ARM chip didn’t have anything resembling an MMU, as far as I know. That original chip was an absolute legend of advanced CPU design on a shoestring. I think this video <https://www.youtube.com/watch?v=t59EtDxpYmM> gives, at one point, an overview of how the chipset worked. There is a “memory-controller” chip (MEMC) and a “video-controller” chip (VIDC). To keep the pin count down, one of these sees the address bits but not the data bits, while the other sees the data bits but not the address bits! And also the addressing was kept to 26 bits. Why? So that the complete CPU state on an interrupt could be stored in 32 bits. > With many 64-bit systems limiting user space pointers to 47 bits > (one bit of the 48-bit address space differentiating system and user > space), it seems sad that programs would have to explicitly > mask/extract small pointers to use those extra bits. I wonder why 64-bit architectures didn’t reserve the bottom 3 bits for a bit offset within a byte. It would be nice to see some support for arbitrarily bit-aligned pointers to arbitrary-length bitfields ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-05 04:26 +0000 |
| Message-ID | <117g5m0$17j0d$1@dont-email.me> |
| In reply to | #117748 |
On Thu, 3 Sep 2026 02:46:48 -0000 (UTC), I wrote: > And also the addressing was kept to 26 bits. Why? So that the > complete CPU state on an interrupt could be stored in 32 bits. Of course I meant “CPU state apart from programmer-visible registers” ...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-03 14:40 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <DFfmS.228899$aK2e.41624@fx17.iad> |
| In reply to | #117746 |
Paul Clayton <paaronclayton@gmail.com> writes: >On 9/1/26 5:17 PM, Lawrence D’Oliveiro wrote: > >AArch64 provides a means (Top Byte Ignore) of masking the most >significant octet to allow it to be used by software. Many >consider this a serious architecture design mistake, citing >history where such has caused compatibility headaches. I _feel_ >that system software should be able to handle this extra >complexity without great difficulty, but I have never developed >even a task scheduler much less an OS. Since some OSes support >use of Top Byte Ignore, I am guessing this is not a huge >problem. This capability (TBI) is also leveraged by the PAC extensions (Pointer Authentication).
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-09-03 20:53 +0100 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <memo.20260903205306.33016P@jgd.cix.co.uk> |
| In reply to | #117751 |
In article <DFfmS.228899$aK2e.41624@fx17.iad>, scott@slp53.sl.home (Scott Lurndal) wrote: > Paul Clayton <paaronclayton@gmail.com> writes: > >AArch64 provides a means (Top Byte Ignore) of masking the most > >significant octet to allow it to be used by software. Many > >consider this a serious architecture design mistake, citing > >history where such has caused compatibility headaches. I _feel_ > >that system software should be able to handle this extra > >complexity without great difficulty, but I have never developed > >even a task scheduler much less an OS. Since some OSes support > >use of Top Byte Ignore, I am guessing this is not a huge > >problem. > > This capability (TBI) is also leveraged by the PAC > extensions (Pointer Authentication). I've implemented PAC in application software without any serious difficulty. TBI is optional. It may require ARM to move from ARM64 to a hypothetical ARM128 sooner than would otherwise have been the case, but PAC helps with today's security problems, which are fairly serious. John
[toc] | [prev] | [next] | [standalone]
Page 3 of 24 — ← Prev page 1 2 [3] 4 5 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web