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 2 of 24 — ← Prev page 1 [2] 3 4 … 24 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-10 03:45 +0000 |
| Message-ID | <117t94v$1lvto$2@dont-email.me> |
| In reply to | #117918 |
On Wed, 09 Sep 2026 23:28:39 GMT, MitchAlsup wrote: > On Wed, 9 Sep 2026 21:45:07 -0000 (UTC), Lawrence D’Oliveiro wrote: > >> On Wed, 09 Sep 2026 18:41:52 GMT, MitchAlsup wrote: >> >>> Originally, paravirtualization was to speed up full virtualization. >> >> Still is. It’s common to have drivers for block devices (disks, >> SSDs), in particular, in the guest, that are written to work >> through custom APIs provided by the host, rather than believe they >> are talking directly to actual (virtualized) hardware. You get >> better performance that way. > > Is that prior to PCIe device virtualization or after or from > something else ? It’s a current thing. I looked around, and found a good overview here <https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum>: * In the beginning, before there was proper hardware support for virtualization, there was paravirtualization (PV), which required a specially-patched kernel. * Then there came full virtualization of all the hardware (HVM), which allowed using the same kernels that ran on actual physical hardware. * And then there was a recognition that virtualizing some low-level, performance-critical things -- network interfaces, block devices (disks, SSDs) was inefficient. So special drivers were created to allow more direct access through the host -- HVM with PV drivers. The kernel itself doesn’t need to know it’s running virtualized, just those drivers do. * Then, taking this a step further, low-level interrupt control was the next performance bottleneck identified in virtualized mode. So a special API was introduced to coordinate that between host and guest -- hence PVHVM. * And then there was this discussion we were having about whether to virtualize paging or not. And so there is this new thing called “PVH” (or maybe some other name).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-10 14:57 +0000 |
| Message-ID | <8zzoS.159$5X3.89@fx12.iad> |
| In reply to | #117921 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >On Wed, 09 Sep 2026 23:28:39 GMT, MitchAlsup wrote: > >> On Wed, 9 Sep 2026 21:45:07 -0000 (UTC), Lawrence D’Oliveiro wrote: >> >>> On Wed, 09 Sep 2026 18:41:52 GMT, MitchAlsup wrote: >>> >>>> Originally, paravirtualization was to speed up full virtualization. >>> >>> Still is. It’s common to have drivers for block devices (disks, >>> SSDs), in particular, in the guest, that are written to work >>> through custom APIs provided by the host, rather than believe they >>> are talking directly to actual (virtualized) hardware. You get >>> better performance that way. >> >> Is that prior to PCIe device virtualization or after or from >> something else ? > >It’s a current thing. Not in my experience. PCIe device virtualization has been preferred by customers for several years now, and is used in all but the lowest-end (consumer grade) hardware. > >I looked around, and found a good overview here ><https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum>: XEN[*] was designed more than two decades ago using 32-bit intel architecture processors. Times have changed radically since. [*] We partnered with them in 2005 to do some hypervisor work. Yes, you'll find PV drivers to access low-end slow hardware in desktop systems. From the server side, storage and networking are using PCIe SRIOV (e.g. NVMe and network accelerators).
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-23 22:08 -0400 |
| Message-ID | <1198s9h$l0ap$2@dont-email.me> |
| In reply to | #117909 |
On 9/9/26 2:41 PM, MitchAlsup wrote: > > antispam@fricas.org (Waldek Hebisch) posted: [snip] >> Once you have paravirtualization, there is nasty question how >> guest and host should divide the work and what is the best >> interface. > > Host OS needs an entry point to Guest OS to ask for resources back > while allowing Guest OS to determine which resources to return. > Guest OS needs an entry point in Host OS to ask for more resources > while allowing Host OS to determine which resources to send. I wonder if it would make sense for a hardware architecture to define an interface to its own hypervisor (vaguely reminiscent to Alpha's PALcode?) to make at least a limited form of paravirtualization natural. (I am thinking of page tables and some resource management.) I have a personal dislike of nested page tables and some resource management decisions are less suited to software (power and cache capacity use seem to have been moved to hardware in terms of mechanism in many implementations). For a new architecture without legacy OSes, this _might_ be possible (though the difference would increase porting effort, which would significantly discourage porting). On a vaguely related note, something like the Mill's unbacked memory (kind of like zero pages with hardware copy on write) might fit with this kind of design. From what I remember/ understood the Mill would have had a demon-like process to manage the free list used to allocate real memory to unbacked memory when it would be evicted from cache. This is kind of like part of a hypervisor and the "hardware" part that assigns the memory does OS-work in changing a translation from a zero page/unbacked to a physical address. (I liked the idea of such dynamic resource allocation without bothering the core.) > Nested Paging has won. Guest OS virtualizes applications and its own > worker threads, while Host OS virtualized multiple Guest OSs. Nested paging potentially doubles the page table depth, which seems unattractive to me. (I am aware that caching intermediate page table nodes and using large pages can avoid much of this overhead. I almost certainly undervalue virtualization and my sense of ickiness for nested paging is not deeply informed.) On the other hand, with a multiple address space OS and traditional page table entries, sharing between processes (address spaces) requires replication of address entries when only permissions might be different. (Multiple address spaces does reduce the virtual address space pressure and PTEs having permissions does mean a single fetch gets the translation and the permissions (and other metadata).)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-28 15:24 +0000 |
| Message-ID | <oEvuS.13$MN2.12@fx45.iad> |
| In reply to | #118234 |
Paul Clayton <paaronclayton@gmail.com> writes: >On 9/9/26 2:41 PM, MitchAlsup wrote: >> >> antispam@fricas.org (Waldek Hebisch) posted: >[snip] >>> Once you have paravirtualization, there is nasty question how >>> guest and host should divide the work and what is the best >>> interface. >> >> Host OS needs an entry point to Guest OS to ask for resources back >> while allowing Guest OS to determine which resources to return. >> Guest OS needs an entry point in Host OS to ask for more resources >> while allowing Host OS to determine which resources to send. > >I wonder if it would make sense for a hardware architecture to >define an interface to its own hypervisor (vaguely reminiscent >to Alpha's PALcode?) to make at least a limited form of >paravirtualization natural. (I am thinking of page tables and >some resource management.) That is generally done at the API level in modern systems. For example, there is a defined specification on ARM systems for the interface between the OS and the hardware/firmware (e.g. PSCI). > >I have a personal dislike of nested page tables and some Care to elaborate? As someone who worked with hypervisors both before and after AMD introduced nested page tables, I have nothing good to say about the alternatives to NPT. ) > >> Nested Paging has won. Guest OS virtualizes applications and its own >> worker threads, while Host OS virtualized multiple Guest OSs. > >Nested paging potentially doubles the page table depth, which >seems unattractive to me. (I am aware that caching intermediate >page table nodes and using large pages can avoid much of this >overhead. I almost certainly undervalue virtualization and my >sense of ickiness for nested paging is not deeply informed.) Indeed, the table walks can be expensive; but as you point out, intermediate caching and using large pages are de riguour in modern implementations. The performance and security of the alternatives (e.g. XEN pre NPT) were significantly poorer.
[toc] | [prev] | [next] | [standalone]
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-09-02 01:31 +0000 |
| Message-ID | <6a977c4c.4368656@news.eternal-september.org> |
| In reply to | #117715 |
On Tue, 1 Sep 2026 11:55:50 -0700, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote: >I think you may be confusing two different things. TSS/360 was a full >OS ran only on the 360/67, which included dynamic address calculation. >TSO/360 was IBM's software that ran under OS/360 and implemented "clunky >timesharing" but didn't require special software. It implemented >"swapping" of TSO user programs within its own address space. Yes, thank you for correcting my mistake. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-02 02:44 +0000 |
| Message-ID | <11782hh$2bobr$3@dont-email.me> |
| In reply to | #117714 |
On Tue, 01 Sep 2026 18:01:52 GMT, John Savard wrote: > ... IBM's clunky timesharing operating system ... ... but you repeat yourself.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-02 07:45 +0000 |
| Message-ID | <1178k6f$2iuo2$1@dont-email.me> |
| In reply to | #117704 |
John Levine <johnl@taugh.com> schrieb: > A famous paper in the IBM Systems Journal on the architecture of S/360 > had a lot to say about that choice, and the need to have compact > addresses in instructions since small systems only had 8K or 16K of > memory. That made addresses in instructions only 16 bits without > segmenting or otherwise screwing up the flat address space. 12 bit + base + index register. Those missing four bits hurt. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-31 22:32 +0000 |
| Message-ID | <1174ve6$1aljd$3@dont-email.me> |
| In reply to | #117702 |
On Mon, 31 Aug 2026 17:35 +0100 (BST), John Dallman wrote: > Even the 64-bit Stretch was limited to 18 address bits. STRETCH was just one in a long line of examples of IBM overpromising and underdelivering. Was it the first? Somehow I doubt it. > The 360 introduced word-sized address registers, which meant that > address space became a key feature of a computer. It had, > theoretically, 32-bit addresses, although only 24 bits were > implemented at first. It only went up to 31 later, as I recall.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-01 00:12 +0000 |
| Message-ID | <1788221556-5857@newsgrouper.org> |
| In reply to | #117707 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > On Mon, 31 Aug 2026 17:35 +0100 (BST), John Dallman wrote: > > > Even the 64-bit Stretch was limited to 18 address bits. > > STRETCH was just one in a long line of examples of IBM overpromising > and underdelivering. > > Was it the first? Somehow I doubt it. > > > The 360 introduced word-sized address registers, which meant that > > address space became a key feature of a computer. It had, > > theoretically, 32-bit addresses, although only 24 bits were > > implemented at first. > > It only went up to 31 later, as I recall. IIRC; 360/67 had 32-bit VAS, but 370 shrunk it to 31-bit VAS. Does anyone remember this from inside IBM ??
[toc] | [prev] | [next] | [standalone]
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-09-01 05:24 +0000 |
| Message-ID | <6a96605c.5295125@news.eternal-september.org> |
| In reply to | #117708 |
On Tue, 01 Sep 2026 00:12:36 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: >> It only went up to 31 later, as I recall. >IIRC; 360/67 had 32-bit VAS, but 370 shrunk it to 31-bit VAS. >Does anyone remember this from inside IBM ?? I'm not from inside IBM. But I think there's an obvious explanation for this. Basically, the 360/67 was an experimental machine aimed at a specialized market, while the 370 series was aimed generally at all of IBM's customers, including those within its core business. So as a general rule, one shouldn't be surprised if IBM was more cautious with the 370 series. But what possible benefit could come from shrinking the address space by one bit? Well, there was one element of IBM's calling conventions that took advantage of addresses being only 24 bits by, under some circumstances, changing the first byte of a particular 32-bit word that contained an address from all zeroes to all ones. Limiting the address size to 31 bits meant that they could change the first bit to a 1 to accomplish the same purpose - with less change to the design of the code involved with that. John Savard
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-09-01 16:05 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1176t3n$ehn$1@gal.iecc.com> |
| In reply to | #117709 |
It appears that John Savard <quadibloc@invalid.com> said: >On Tue, 01 Sep 2026 00:12:36 GMT, MitchAlsup ><user5857@newsgrouper.org.invalid> wrote: >>Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > >>> It only went up to 31 later, as I recall. > >>IIRC; 360/67 had 32-bit VAS, but 370 shrunk it to 31-bit VAS. >>Does anyone remember this from inside IBM ?? >But what possible benefit could come from shrinking the address space >by one bit? >Well, there was one element of IBM's calling conventions that took >advantage of addresses being only 24 bits by, under some >circumstances, changing the first byte of a particular 32-bit word >that contained an address from all zeroes to all ones. Kind of, but it was worse than that. It sounds like you're referring to the convention that in variable length subroutine argument lists, you set the high bit on the last one to mark the end. The worse part is that OS (and probably DOS, I haven't looked) is full of data structures where they used the high bit of address words for flags and other small items to save space. They had to redo all of those to handle 31 bit addresses. >Limiting the address size to 31 bits meant that they could change the >first bit to a 1 to accomplish the same purpose - with less change to >the design of the code involved with that. That's not it. If the high bit of an address was 1, it was a 31 bit address, if not it was a 24 bit address. The system could run in either 24 or 31 bit address mode. For many years, probably still today, 360 systems had a mix of 24 and 31 bit code. 370/XA added BASSM and BSM instructions that did a call or return and set the address mode from the high bit of the address. That made it somewhat easier to mix 24 and 31 bit code, although you still had to be careful not to pass a 31 bit address to a 24 bit routine. -- 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 | Andy Valencia <vandys@vsta.org> |
|---|---|
| Date | 2026-09-01 10:07 -0700 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <178828243428.4937.12466578110806999872@media.vsta.org> |
| In reply to | #117709 |
John Levine <johnl@taugh.com> writes: > Kind of, but it was worse than that. It sounds like you're referring to the > convention that in variable length subroutine argument lists, you set the high > bit on the last one to mark the end. The worse part is that OS (and probably > DOS, I haven't looked) is full of data structures where they used the high bit > of address words for flags and other small items to save space. They had to > redo all of those to handle 31 bit addresses. Certainly this happened with Stanford University's homebrew DBMS, SPIRES. My father-in-law told me of the immense work needed to free up the address bits to permit extended addressing. He said when they did the original code, nobody imagined that they'd ever need those upper bits for addressing. But he was a hacker of the old school. They made it happen, and SPIRES served Stanford well until it was finally retired in favor of a commercial SQL DBMS. I wish they'd done a full conversion to C; it was a pretty amazing "not SQL" database system. https://slac.stanford.edu/spires/about/ Andy Valencia Home page: https://www.vsta.org/andy/ To contact me: https://www.vsta.org/contact/andy.html No AI was used in the composition of this message
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-01 21:17 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1177fdi$26ea4$1@dont-email.me> |
| In reply to | #117713 |
On Tue, 01 Sep 2026 10:07:14 -0700, Andy Valencia wrote: > Certainly this happened with Stanford University's homebrew DBMS, > SPIRES. My father-in-law told me of the immense work needed to free > up the address bits to permit extended addressing. He said when they > did the original code, nobody imagined that they'd ever need those > upper bits for addressing. The original Apple MacOS went through this in the 1980s. The 68000-family instruction set allowed for 32-bit addresses, but the original 68000 processor only looked at the bottom 24 bits. So the Mac system used those top 8 bits for various memory-management purposes. Even when they brought out the Mac II, the first with a 68020 processor that *did* pay attention to all 32 bits of the address, they stuck in a stub MMU on the motherboard that removed those top 8 bits before actually accessing memory. Then, by about 1990, they introduced models with “32-bit clean” ROMs, that didn’t make any such odd uses of those top 8 bits internally, and could address more than 16MiB of RAM.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-02 18:59 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <117a9ph$37j48$1@dont-email.me> |
| In reply to | #117722 |
On 9/1/26 5:17 PM, Lawrence D’Oliveiro wrote: > On Tue, 01 Sep 2026 10:07:14 -0700, Andy Valencia wrote: > >> Certainly this happened with Stanford University's homebrew DBMS, >> SPIRES. My father-in-law told me of the immense work needed to free >> up the address bits to permit extended addressing. He said when they >> did the original code, nobody imagined that they'd ever need those >> upper bits for addressing. > > The original Apple MacOS went through this in the 1980s. > > The 68000-family instruction set allowed for 32-bit addresses, but the > original 68000 processor only looked at the bottom 24 bits. So the Mac > system used those top 8 bits for various memory-management purposes. > > Even when they brought out the Mac II, the first with a 68020 > processor that *did* pay attention to all 32 bits of the address, they > stuck in a stub MMU on the motherboard that removed those top 8 bits > before actually accessing memory. > > Then, by about 1990, they introduced models with “32-bit clean” ROMs, > that didn’t make any such odd uses of those top 8 bits internally, and > could address more than 16MiB of RAM. 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). 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. (Determining when software can use 32-bit mode might be difficult. User pointers in system calls would also need to be masked, but I think an OS already needs to prevent OS-privilege access to arbitrary user-provided addresses.) 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. Interestingly, Stanford MIPS used the extra bits for an address space number and had a variable length mask. («The size of the process virtual address space is defined by a bit mask in a special register. When masking is enabled for normal operations, a process identifier from another special register is substituted for the high order bits of the machine address. These two special registers are accessible only to processes running in supervisor state. The masking unit also detects attempts to access outside the legal segment and raises an exception to the master pipeline control. Although the virtual address is a full 32 bits, the package constraint only permits 24 address pins. With word addressing, however, this gives an address space of 64 megabytes.», "Design of a High-Performance VLSI Processor", John Hennessey et al., 1983) The masking in Stanford MIPS did not allow software flags but did allow some process isolation even without a permission table. Such also allowed the ASID to vary in size without requiring more address bits if some processes were compact. 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 did not allow software use of the extra bits, but provided some flexibility in page tables (the number of levels for the user page table could be decreased and the entire system address space page table could be shared rather than duplicating the root "page" in each process) and PTEs would not need a global bit to indicate preservation across processes. (32-bit PowerPC segments were vaguely similar in allowing 16 segments with separate virtual address spaces. In theory, this might support somewhat flexible sharing. HP PA-RISC provided fewer segments but more flexible/complex use. [I think encoding the segment bits in the least significant bits would have been better than using the high bits; it would have made the change to 64-bit simpler and allowed full-space dynamic segment addresses at the cost of having to encode segment numbers in the instruction for byte and half-word aligned pointers and disallowing alignment traps based on such bits.]) Implicit hardware masking of tags can be useful, though I do wonder if such could be usefully generalized to better support multiple data in a single load. (32-bit paired loads in AArch64 do this to some degree, but it might be practical to exploit the alignment network for loads to parse a load into two pieces at byte granularity. An unaligned address could indicate the split point.) With x86 one can perform a full-register-size load and access sub-sections (for some registers). Providing denser register storage use has advantages when memory is slow, but using subregisters complicates renaming (and forwarding, which is kind of renaming). (Like CMOV, out-of-order execution complicates use of subregisters.) It might be possible (practical even) to support a restrained use of subregisters (less restrained than SIMD that defines a single size and divides the register into lanes of that size), but it seems likely that such would not be *worthwhile*. Even without address masking, part of addresses can be used to hold type information at the cost of sparser use of the address space. (This introduces a possible performance compatibility concern. Software may seek to minimize translation overhead from sparsity, but that ties software performance to specifics of address translation (like which bits are used for table levels). Even using a tag to indicate a leaf pointer might be useful with a tracing garbage collector.) 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 better send this before my mind wanders even farther.]
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-03 01:50 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1788400223-5857@newsgrouper.org> |
| In reply to | #117746 |
Paul Clayton <paaronclayton@gmail.com> posted:
> On 9/1/26 5:17 PM, Lawrence D’Oliveiro wrote:
> > On Tue, 01 Sep 2026 10:07:14 -0700, Andy Valencia wrote:
> >
> >> Certainly this happened with Stanford University's homebrew DBMS,
> >> SPIRES. My father-in-law told me of the immense work needed to free
> >> up the address bits to permit extended addressing. He said when they
> >> did the original code, nobody imagined that they'd ever need those
> >> upper bits for addressing.
> >
> > The original Apple MacOS went through this in the 1980s.
> >
> > The 68000-family instruction set allowed for 32-bit addresses, but the
> > original 68000 processor only looked at the bottom 24 bits. So the Mac
> > system used those top 8 bits for various memory-management purposes.
Sins of the past...
> > Even when they brought out the Mac II, the first with a 68020
> > processor that *did* pay attention to all 32 bits of the address, they
> > stuck in a stub MMU on the motherboard that removed those top 8 bits
> > before actually accessing memory.
> >
> > Then, by about 1990, they introduced models with “32-bit clean” ROMs,
> > that didn’t make any such odd uses of those top 8 bits internally, and
> > could address more than 16MiB of RAM.
>
> 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.
> 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.
> (Determining when software can use 32-bit mode might be
> difficult. User pointers in system calls would also need
> to be masked, but I think an OS already needs to prevent
> OS-privilege access to arbitrary user-provided addresses.)
>
> 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...
> 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.
>
> Interestingly, Stanford MIPS used the extra bits for an address
> space number and had a variable length mask. («The size of the
> process virtual address space is defined by a bit mask in a
> special register.
My 66000 has a 3-bit LVL field in the Root pointer (in all MMU
pointers). LVL in root tells you the VAS size (and PA==VA).
A process==thread can have VAS as small as 23-bits (cat) and
use 1 page as the page table. Saving all those unnecessary
MMU accesses.
LVL in PTPs allows for level skipping (sparse spaces). LVL in
the pointer pointing at a PTE tells you size of the (super)page.
No need for a control register field to specify what the natural
organization of the table structure provides.
> When masking is enabled for normal operations,
> a process identifier from another special register is
> substituted for the high order bits of the machine address.
My 66000 assigns ASID as Address<79..64> and also drags priority
around the on-die interconnect to allow memory to decide on the
order of near-identical-timing interfering ATOMIC accesses (higher
wins).
> These two special registers are accessible only to processes
> running in supervisor state. The masking unit also detects
> attempts to access outside the legal segment and raises an
> exception to the master pipeline control. Although the virtual
> address is a full 32 bits, the package constraint only permits
> 24 address pins. With word addressing, however, this gives an
> address space of 64 megabytes.», "Design of a High-Performance
> VLSI Processor", John Hennessey et al., 1983)
>
> The masking in Stanford MIPS did not allow software flags but
> did allow some process isolation even without a permission
> table. Such also allowed the ASID to vary in size without
> requiring more address bits if some processes were compact.
A valid design point in 1983, not so much today--unless vastly
extended.
> 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 did not allow software use of
> the extra bits, but provided some flexibility in page tables
> (the number of levels for the user page table could be decreased
> and the entire system address space page table could be shared
> rather than duplicating the root "page" in each process) and
> PTEs would not need a global bit to indicate preservation across
> processes.
Since My 66000 Core-State has 4 contexts installed at all times,
there are 4 {ASIDs, priorities, privileges, and threads} iden-
tified at all times, allowing greater privilege threads to access
lesser privileged threads without any "global" bit in PTE/PTP/TLB.
Basically ASID does this cleaner. HV can reach into Host OS, while
Host OS can reach into Guest OS. Guest OS can reach into application
without any of them overusing/overspecifying the concept of 'global'
and there can be as many as desired 'global' spaces--all specified
in the MMU tables.
I, personally, do not see a single 'global' bit being "all that
useful" when there are 27 Guest OSs running simultaneously, all
27 thinking they are the only OSs running at that instant in
time. These Guest OSs might be running under 10 Host OSs which
might be running under 3 HyperVisors.
Handing out unique ASIDs is a very easy job for HV.
> (32-bit PowerPC segments were vaguely similar in
> allowing 16 segments with separate virtual address spaces. In
> theory, this might support somewhat flexible sharing. HP PA-RISC
> provided fewer segments but more flexible/complex use. [I think
> encoding the segment bits in the least significant bits would
> have been better than using the high bits; it would have made
> the change to 64-bit simpler and allowed full-space dynamic
> segment addresses at the cost of having to encode segment
> numbers in the instruction for byte and half-word aligned
> pointers and disallowing alignment traps based on such bits.])
More sins of the past...
> Implicit hardware masking of tags can be useful, though I do
> wonder if such could be usefully generalized to better support
> multiple data in a single load. (32-bit paired loads in AArch64
> do this to some degree, but it might be practical to exploit the
> alignment network for loads to parse a load into two pieces at
> byte granularity. An unaligned address could indicate the
> split point.)
Looking forward, loading 128-256 bits per access might be useful
in the not so distant future, if only used for complex types
{real, imag} with 64-bit and 128-bit element sizes.
> With x86 one can perform a full-register-size load and access
> sub-sections (for some registers). Providing denser register
> storage use has advantages when memory is slow, but using
> subregisters complicates renaming (and forwarding, which is
> kind of renaming).
The understatement of the month award winner.
> (Like CMOV, out-of-order execution
> complicates use of subregisters.)
For 70 years, a register would contain a single value, then
MMX ruined the game...prior was the model compilers are good
at using.
> It might be possible
> (practical even) to support a restrained use of subregisters
> (less restrained than SIMD that defines a single size and
> divides the register into lanes of that size), but it seems
> likely that such would not be *worthwhile*.
SIMD is bad for your architecture and for your thinking processes.
> Even without address masking, part of addresses can be used
> to hold type information at the cost of sparser use of the
> address space.
The only thing your architecture cannot survive (over time)
is lack of address bits. Do not give them away before your 4th
generation implementations have sold 100M chips.
> (This introduces a possible performance
> compatibility concern. Software may seek to minimize translation
> overhead from sparsity, but that ties software performance to
> specifics of address translation (like which bits are used for
> table levels). Even using a tag to indicate a leaf pointer might
> be useful with a tracing garbage collector.)
Simply a symptom of poor MMU table design.
On the other hand, I have used a strategy where when I need some
structure that can become garbage, I fork off a process, have it
create the structure, then distill a result, then have it return
the result and terminate itself. Almost always faster, always
safer.
> 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.
With ECAM based on PCIe 4.0+, your device address space consumes
up to 40-bits. And then there is the configuration space, and the
interrupt table aperture space, and other system spaces--all vying
for those 47-bits. I suspect 47 will not be sufficient very long.
My 66000's solution is to provide a complete 64-bit VAS that can be
translated into a 66-bit universal address space consisting of four
64-bit spaces {DRAM, device, config, ROM}. I don't want any of these
spaces to cause issues while I remain alive. Both cores and devices
use the 66-bit UAS.
Using MSI-X interrupts, allows interrupt tables to perform DPC/softIRQ
queueing without normally associated SW overheads. Cores can send cores
interrupts using the same mechanisms as devices. Since there is an
unlimited number of interrupt tables (My 66000) and since the are
constructed with a DAG structure, anything that can touch the interrupt
aperture can send interrupts to any virtual core. When that virtual
core has control, those interrupts are 'processed'.
> [I better send this before my mind wanders even farther.]
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-09 16:30 -0400 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <117sfmo$1f6ka$2@dont-email.me> |
| In reply to | #117747 |
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.
Some software is highly optimized for a specific implementation
(e.g., cache sizes) such that a microarchitectural change could
require substantial rewriting/retuning. I feel the software
developers should be allowed to make such fragile optimizations
with the understanding that the microarchitecture is not
guaranteed to continue even if the architecture does. (Some
embedded chip vendors do provide product longevity guarantees.)
(This can reduce microarchitectural flexiblity if the software
is considered critical enough and rewriting/retuning is not an
option.)
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.
Address space constrains actual capability of software rather
than "merely" performance, but some software developers (and
some developers of the ARM architecture) have concluded that the
benefit of having tags is worth the cost of a reduced address
space as an option.
I would also note that the canonical address scheme also
introduces a software incompatibility aspect. Software using
a non-canonical address to generate an exception and assuming
the OS will not provide addresses outside the current limit
(as of the 2024 man page I have Linux mmap does not provide a
flag to limit the address range other than MAP_32BIT, so other
than using fixed allocations, an application cannot force the
OS to honor its wishes to limit the virtual address range).
This is not a useful technique given how slow exceptions are,
but I think it is a hole in "compatibility" (and more
significant than space bar heating, https://xkcd.com/1172/ ).
[snip]
>> Interestingly, Stanford MIPS used the extra bits for an address
>> space number and had a variable length mask. («The size of the
>> process virtual address space is defined by a bit mask in a
>> special register.
>
> My 66000 has a 3-bit LVL field in the Root pointer (in all MMU
> pointers). LVL in root tells you the VAS size (and PA==VA).
> A process==thread can have VAS as small as 23-bits (cat) and
> use 1 page as the page table. Saving all those unnecessary
> MMU accesses.
>
> LVL in PTPs allows for level skipping (sparse spaces). LVL in
> the pointer pointing at a PTE tells you size of the (super)page.
> No need for a control register field to specify what the natural
> organization of the table structure provides.
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).
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.
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.
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.)
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.
OS support would be a problem. I do not think any architecture
provides merging of page table levels.
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.
The advantage, such as it is, would be in supporting sparse
use with a limited number of roots for faster context switches.
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".
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.
If the prefetching was optional, then a means would be required
to load missing entries. This seems to require either a full
page table (one node address from which all the other actually
used/valid nodes can be found) — which uses extra storage and
look-up layers — or something like a hash table (like software
TLBs) that hold the information — which also has storage use
overhead (though it might be limited by only storing entries
greater than a default value, e.g., four nodes might be
automatically prefetched and any other nodes would need to
access the hash table) and look-up overhead (number of hash
table probes, at least the parallelism of such allows
tradeoffs of bandwidth versus latency). Since the prefetched
nodes could be broadened to spaces covering multiple previous
nodes, I think hash table misses might be avoidable by
construction at the cost of deeper page tables.
This was just a wild and crazy thought. The unconventionality
alone probably makes such impractical even if it would be
technically possible and perhaps even slightly useful.
[snip]
> A valid design point in 1983, not so much today--unless vastly
> extended.
I just thought it was a neat little design choice.
[snip My 66000 avoidance of global bit]
How close do you think you are to version 1.0?
You sent me the Principles of Operation from January 2020 and
your posts on comp.arch indicate that a substantial amount has
changed since then. (I think the DOUBLE prefix has been added,
dropped, and reinstated. CARRY was not present in 2020)
I get the impression that a lot of your work recently has been
on system (and implementation) aspects rather than "instruction
set" aspects.
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 ☺).
I do feel that VVM is a nice software interface. It avoids a
lot of SIMD issues and not just instruction diversity explosion.
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. 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).
[snip]
>> (32-bit PowerPC segments were vaguely similar in
>> allowing 16 segments with separate virtual address spaces. In
>> theory, this might support somewhat flexible sharing. HP PA-RISC
>> provided fewer segments but more flexible/complex use. [I think
>> encoding the segment bits in the least significant bits would
>> have been better than using the high bits; it would have made
>> the change to 64-bit simpler and allowed full-space dynamic
>> segment addresses at the cost of having to encode segment
>> numbers in the instruction for byte and half-word aligned
>> pointers and disallowing alignment traps based on such bits.])
>
> More sins of the past...
I am not sure. Segments based on the most significant bits
certainly have issues with respect to increasing the base
address space size, but I am not certain that segments as
address space extensions are necessarily a bad thing. Simple
address spaces are nicer, but the cost of doubling address size
for a few uses that could be handled reasonably with segments
(because of data locality even at that large scale).
Maybe rather than segments (or large flat virtual address
spaces) future huge memory applications might use multiple
address spaces (program/code-connected segmentation) to
support an effectively larger address space. Given the
desirability of code and data physical locality and the
latency and power issues of a large physical flat memory,
such seems reasonable. Current warehouse-scale compute
uses program partitioning (microservices) largely to provide
usage scalability and availability, but sharding of databases
does target the memory capacity issue (which is currently a
tighter constraint than virtual address space size).
[snip]
> Looking forward, loading 128-256 bits per access might be useful
> in the not so distant future, if only used for complex types
> {real, imag} with 64-bit and 128-bit element sizes.
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).
>
>> With x86 one can perform a full-register-size load and access
>> sub-sections (for some registers). Providing denser register
>> storage use has advantages when memory is slow, but using
>> subregisters complicates renaming (and forwarding, which is
>> kind of renaming).
>
> The understatement of the month award winner.
Surely that is a more temporally local understatement.☺ (Maybe
limited to comp.arch?)
A two-size renaming (like IBM zSeries [s/360 descendant]) would
seem to only double the number of registers and the number of
sources. There might even be techniques to simplify the hardware
at the cost of storage utilization and/or extra data movement.
Checkpoint-only values can be more readily copied to a different
namespace (only a single pointer needs to be updated and the
update is not on a critical path). Perhaps an operation might
store two or more values — the result to be stored in quick
storage and one or more source operands to be stored in slower
checkpoint storage — avoiding an excessive read for the move and
generally keeping the move out of the forwarding network.
I _suspect_ subregisters have potential (certainly for in-order
with "same lane" usage), but developing a reasonable design
would probably require many person-years of research and by
then tradeoffs would have changed and any modest benefit would
likely be of limited application.
>> (Like CMOV, out-of-order execution
>> complicates use of subregisters.)
>
> For 70 years, a register would contain a single value, then
> MMX ruined the game...prior was the model compilers are good
> at using.
x86 had subregisters before MMX. Even some RISCs used register
pairs for double precision floating point, presenting the same
renaming/forwarding issues.
[snip]
> SIMD is bad for your architecture and for your thinking processes.
I disagree. Vectors are Single Instruction Multiple Data. Fixed
work unit size per instruction does seem architecturally
problematic, but it is not clear that such is much more
problematic for thinking than fixed cache block size.
(Fixed cache block size does affect thinking. In-cache
compression, especially "lossy" compression where part of the
nominal cache block is stored in outer storage, will affect
understanding of capacity. Prefetch/false sharing assumptions
will affect performance.)
[snip]
> The only thing your architecture cannot survive (over time)
> is lack of address bits. Do not give them away before your 4th
> generation implementations have sold 100M chips.
The length of time between address space doubling doubles, and
the delay is longer if cost-per-bit does not halve regularly
and/or capacity demand is worse than linear with price. I think
the speed of solid state storage reduced DRAM demand (cheaper
indirectly addressed storage was good enough for many uses),
lengthening the 64-bit generation. Process scaling issues also
seem to be slowing demand for large memory single systems. The
move toward scale out rather than scale up also reduces the
address space pressure. I also suspect that many of the large
virtual address space use cases are also relatively dense in
mapping, which might buy a few bits of address space compared
with "general" programs.
Address tagging also only applies to software that chooses to
use such. I get the impression that such tag use is rather
niche and even then contained within a subsystem of the program.
Having to rewrite a subsystem may be a huge pain, but
It may be physically possible for a memory technology
breakthrough to make Moore's Law look slow (for a while), but
I would be willing to bet that virtual address space capacity
demand will not accelerate and even that such will continue
to decelerate (though not as much as from the one-time sold
state storage effect or the, hopefully temporary, AI causes
memory price increases).
[snip]
> With ECAM based on PCIe 4.0+, your device address space consumes
> up to 40-bits. And then there is the configuration space, and the
> interrupt table aperture space, and other system spaces--all vying
> for those 47-bits. I suspect 47 will not be sufficient very long.
Interesting, but the applications using tagged addresses are not
likely to be interacting so directly with I/O (I think).
> My 66000's solution is to provide a complete 64-bit VAS that can be
> translated into a 66-bit universal address space consisting of four
> 64-bit spaces {DRAM, device, config, ROM}. I don't want any of these
> spaces to cause issues while I remain alive. Both cores and devices
> use the 66-bit UAS.
Side note: I have felt some attraction to a virtual Harvard
system, i.e., a separate virtual address space for instructions.
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.
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
> Using MSI-X interrupts, allows interrupt tables to perform DPC/softIRQ
> queueing without normally associated SW overheads. Cores can send cores
> interrupts using the same mechanisms as devices. Since there is an
> unlimited number of interrupt tables (My 66000) and since the are
> constructed with a DAG structure, anything that can touch the interrupt
> aperture can send interrupts to any virtual core. When that virtual
> core has control, those interrupts are 'processed'.
I like the orientation toward "an agent is an agent". That is
just one more indication of My 66000 being a *design* and not
merely a collection of useful ideas. I am not up to the task of
designing a paper ISA, but I can still appreciate engineering.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-09 20:50 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <4EjoS.1973$XsT2.694@fx01.iad> |
| In reply to | #117911 |
Paul Clayton <paaronclayton@gmail.com> writes: >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. > >Some software is highly optimized for a specific implementation >(e.g., cache sizes) such that a microarchitectural change could >require substantial rewriting/retuning. I feel the software >developers should be allowed to make such fragile optimizations >with the understanding that the microarchitecture is not >guaranteed to continue even if the architecture does. (Some >embedded chip vendors do provide product longevity guarantees.) Recalling that most modern chips support a 48/9-bit virtual address space, the high eight bits of the virtual address won't be needed for addressing for likely several decades. Thus the use of the TBI setting for a specific address space is not a significant issue for future compatability. Noting that the top byte is also used by the Pointer Authentication instructions, it seems an useful and portable mechanism even without specific application support (other than compiling with PAC enabled). Even with the 56/7-bit VAS supported by high end xeon chips, the top byte is unused. Now on the physical side, the high order 2, 4 or 8 bits are sometimes used as a NUMA node index.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-09 23:25 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <1788996341-5857@newsgrouper.org> |
| In reply to | #117911 |
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.
> Some software is highly optimized for a specific implementation
> (e.g., cache sizes) such that a microarchitectural change could
> require substantial rewriting/retuning. I feel the software
> developers should be allowed to make such fragile optimizations
> with the understanding that the microarchitecture is not
> guaranteed to continue even if the architecture does. (Some
> embedded chip vendors do provide product longevity guarantees.)
Yes, but You understand the difference between Architecture and
implementation. May designers do not (especially early in their
careers.)
> (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.
> 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.
> Address space constrains actual capability of software rather
> than "merely" performance, but some software developers (and
> some developers of the ARM architecture) have concluded that the
> benefit of having tags is worth the cost of a reduced address
> space as an option.
My 66000 allows for many sizes of VAS by using the LVL field in
PTPs. You can say "all he did was move the control bit elsewhere"
but I consider that it is the MMUs job do manage address space
stuff. A 66000 single VAS can be {13, 23, 33, 43, 53, 63}-bits.
and each privilege level gets 2 independent VASs. This DRAM VAS
does not overlap with {ROM, config, device} address spaces (no
apertures in PAS).
> I would also note that the canonical address scheme also
> introduces a software incompatibility aspect. Software using
> a non-canonical address to generate an exception and assuming
> the OS will not provide addresses outside the current limit
> (as of the 2024 man page I have Linux mmap does not provide a
> flag to limit the address range other than MAP_32BIT, so other
> than using fixed allocations, an application cannot force the
> OS to honor its wishes to limit the virtual address range).
In My 66000, the high order bit of VA has to match the high order
bit of Rbase of we throw an address exception. So, while one has
2×63-bit VASs one cannot start in one VAS and access in the other.
Both VASs can be any combination of {13,23,33,43,53,63}-bit spaces.
> This is not a useful technique given how slow exceptions are,
> but I think it is a hole in "compatibility" (and more
> significant than space bar heating, https://xkcd.com/1172/ ).
>
> [snip]
> >> Interestingly, Stanford MIPS used the extra bits for an address
> >> space number and had a variable length mask. («The size of the
> >> process virtual address space is defined by a bit mask in a
> >> special register.
> >
> > My 66000 has a 3-bit LVL field in the Root pointer (in all MMU
> > pointers). LVL in root tells you the VAS size (and PA==VA).
> > A process==thread can have VAS as small as 23-bits (cat) and
> > use 1 page as the page table. Saving all those unnecessary
> > MMU accesses.
> >
> > LVL in PTPs allows for level skipping (sparse spaces). LVL in
> > the pointer pointing at a PTE tells you size of the (super)page.
> > No need for a control register field to specify what the natural
> > organization of the table structure provides.
>
> 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).
> 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. ...
> 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.
> 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.
> 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.
> OS support would be a problem. I do not think any architecture
> provides merging of page table levels.
Not Much HW provides said feature.
> 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.
Basically My 66000 does this. Each core has a CoreStack, and each
CoreStack contains 4 contexts. Each context contains a pointer to
a runnable thread (.v=1). Each thread contains its "program Status
Line" along with its register file.
There is a 3-bit variable in CoreStack::
000 = HyperVisor
001 = Host OS
010 = Guest OS
011 = Application
1xx = idle
cs indexes CoreStack.context[], and by examining the context.v[] bits
one can determine which privilege model is in place that instant,
and which VASs can be accesses through the 2 available translation
tables.
> The advantage, such as it is, would be in supporting sparse
> use with a limited number of roots for faster context switches.
Each Root pointer is associated with its own ASID..
And privilege switches need alter no control registers to receive
control. The Guest OS context switch involves nothing more than
writing the application context in CoreStack then SVRing.
> 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".
???
> 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.
???
> If the prefetching was optional, then a means would be required
> to load missing entries. This seems to require either a full
> page table (one node address from which all the other actually
> used/valid nodes can be found) — which uses extra storage and
> look-up layers — or something like a hash table (like software
> TLBs) that hold the information — which also has storage use
> overhead (though it might be limited by only storing entries
> greater than a default value, e.g., four nodes might be
> automatically prefetched and any other nodes would need to
> access the hash table) and look-up overhead (number of hash
> table probes, at least the parallelism of such allows
> tradeoffs of bandwidth versus latency). Since the prefetched
> nodes could be broadened to spaces covering multiple previous
> nodes, I think hash table misses might be avoidable by
> construction at the cost of deeper page tables.
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.
> This was just a wild and crazy thought. The unconventionality
> alone probably makes such impractical even if it would be
> technically possible and perhaps even slightly useful.
>
> [snip]
> > A valid design point in 1983, not so much today--unless vastly
> > extended.
>
> I just thought it was a neat little design choice.
>
> [snip My 66000 avoidance of global bit]
>
> How close do you think you are to version 1.0?
> You sent me the Principles of Operation from January 2020 and
> your posts on comp.arch indicate that a substantial amount has
> changed since then. (I think the DOUBLE prefix has been added,
> dropped, and reinstated. CARRY was not present in 2020)
Mid 2025 I rearranged the instruction format so that <essentially>
all instructions have {Size}×{Sign}. {Size} determines the width
of the calculation {[byte,half,word,dble];[FP8,FP16,FP32,FP64]}.
{Sign} is mainly used to determine the non-exceptional range of
a result, and often used as "just another OpCode bit" for those
instructions where {Size} has no real meaning {branches,...}
Read one way, I still have only 63 "instructions"; read another
we have 350-ish "instructions", and there is still more than
1/3 of major left available.
> I get the impression that a lot of your work recently has been
> on system (and implementation) aspects rather than "instruction
> set" aspects.
Yes, I worked out System Binary Interface, control register addressing,
Multiprecison arithmetic, virtual Vector Method,Exotic Synchronization
Method, and To-Memory calculations.
> 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.
vVM allows for the processor to utilize multi-lane calculations
with flexibility SIMD can never do::
word = word + half*byte;
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.
> 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)
> 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.
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.
> 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?
> [snip]
> >> (32-bit PowerPC segments were vaguely similar in
> >> allowing 16 segments with separate virtual address spaces. In
> >> theory, this might support somewhat flexible sharing. HP PA-RISC
> >> provided fewer segments but more flexible/complex use. [I think
> >> encoding the segment bits in the least significant bits would
> >> have been better than using the high bits; it would have made
> >> the change to 64-bit simpler and allowed full-space dynamic
> >> segment addresses at the cost of having to encode segment
> >> numbers in the instruction for byte and half-word aligned
> >> pointers and disallowing alignment traps based on such bits.])
> >
> > More sins of the past...
>
> I am not sure. Segments based on the most significant bits
> certainly have issues with respect to increasing the base
> address space size, but I am not certain that segments as
> address space extensions are necessarily a bad thing. Simple
s/Simple/Flat/
> address spaces are nicer, but the cost of doubling address size
> for a few uses that could be handled reasonably with segments
> (because of data locality even at that large scale).
Segments are a poor man's capability. Go all the way or stop now.
> Maybe rather than segments (or large flat virtual address
> spaces) future huge memory applications might use multiple
> address spaces (program/code-connected segmentation) to
> support an effectively larger address space.
As long as the smallest segment is at least 1 page, then My
66000 PTE limit bits go a long way to providing much of what
general segments provide.
> Given the
> desirability of code and data physical locality and the
> latency and power issues of a large physical flat memory,
> such seems reasonable.
There is no rational for code and data to be within 2^40
bits of each other. Code can go wherever it wants, data
wherever it wants/needs. Over in PA space, code and data
can be in back-to-back pages (this is virtual memory's job)
> Current warehouse-scale compute
> uses program partitioning (microservices) largely to provide
> usage scalability and availability, but sharding of databases
> does target the memory capacity issue (which is currently a
> tighter constraint than virtual address space size).
Imagine using the top 16-bits of PA to route accesses over
2^16 racks in a server farm.
> [snip]
> > Looking forward, loading 128-256 bits per access might be useful
> > in the not so distant future, if only used for complex types
> > {real, imag} with 64-bit and 128-bit element sizes.
>
> 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.
> >> With x86 one can perform a full-register-size load and access
> >> sub-sections (for some registers). Providing denser register
> >> storage use has advantages when memory is slow, but using
> >> subregisters complicates renaming (and forwarding, which is
> >> kind of renaming).
> >
> > The understatement of the month award winner.
>
> Surely that is a more temporally local understatement.☺ (Maybe
> limited to comp.arch?)
>
> A two-size renaming (like IBM zSeries [s/360 descendant]) would
> seem to only double the number of registers and the number of
> sources. There might even be techniques to simplify the hardware
> at the cost of storage utilization and/or extra data movement.
vVM renames once and then uses that rename across multi-width
calculations and multiple iterations of the loop. Saving rename
power. Scalar registers and constants are loaded once and then
used over all loop iterations. VEC annotates which registers
are live-out, saving register writes along the way.
> Checkpoint-only values can be more readily copied to a different
> namespace (only a single pointer needs to be updated and the
> update is not on a critical path). Perhaps an operation might
> store two or more values — the result to be stored in quick
> storage and one or more source operands to be stored in slower
> checkpoint storage — avoiding an excessive read for the move and
> generally keeping the move out of the forwarding network.
You lost me...
> I _suspect_ subregisters have potential (certainly for in-order
> with "same lane" usage), but developing a reasonable design
> would probably require many person-years of research and by
> then tradeoffs would have changed and any modest benefit would
> likely be of limited application.
vVM tracks the LD-width and St-width to setup the buffer multiplexers.
No need for each calculation to annotate that which is already known.
> >> (Like CMOV, out-of-order execution
> >> complicates use of subregisters.)
> >
> > For 70 years, a register would contain a single value, then
> > MMX ruined the game...prior was the model compilers are good
> > at using.
>
> 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.
>
> [snip]
>
> > SIMD is bad for your architecture and for your thinking processes.
>
> I disagree. Vectors are Single Instruction Multiple Data. Fixed
> work unit size per instruction does seem architecturally
> problematic, but it is not clear that such is much more
> problematic for thinking than fixed cache block size.
The programmer wrote the sequence as a loop. Thus you should
vectorize loops and not instructions. vVm does. vVm leverages
other instruction scheduling mechanics in your implementation
unlike vector-instructions.
> (Fixed cache block size does affect thinking. In-cache
> compression, especially "lossy" compression where part of the
> nominal cache block is stored in outer storage, will affect
> understanding of capacity. Prefetch/false sharing assumptions
> will affect performance.)
Fixed block caching has certain hilarious consequences if
the cache on THIS core has multiple lines that cannot hold
data {either from locking or from bad cells in the cache}
> [snip]
> > The only thing your architecture cannot survive (over time)
> > is lack of address bits. Do not give them away before your 4th
> > generation implementations have sold 100M chips.
>
> The length of time between address space doubling doubles, and
> the delay is longer if cost-per-bit does not halve regularly
> and/or capacity demand is worse than linear with price. I think
> the speed of solid state storage reduced DRAM demand (cheaper
> indirectly addressed storage was good enough for many uses),
Yes, SSD took some demand out of DRAM size requirements, by
shrinking 10ms rotational latency into 50µs access delay;
and by raising the data gat from 4GBs into the 30GB/s range.
On the other hand, AI turned around and is consuming all available
DRAM, so its a good thing SSDs are so fast.
> lengthening the 64-bit generation. Process scaling issues also
> seem to be slowing demand for large memory single systems. The
> move toward scale out rather than scale up also reduces the
> address space pressure. I also suspect that many of the large
> virtual address space use cases are also relatively dense in
> mapping, which might buy a few bits of address space compared
> with "general" programs.
>
> Address tagging also only applies to software that chooses to
> use such. I get the impression that such tag use is rather
> niche and even then contained within a subsystem of the program.
Way back in 2006, the number of server-class chips AMD produced
was measured as "an afternoon in the FAB" compared to the general
PC market. So, we as designers were encouraged to add as much
server stuff onto the die that would "fit" in an afternoon of
designer work ...
> Having to rewrite a subsystem may be a huge pain, but
>
> It may be physically possible for a memory technology
> breakthrough to make Moore's Law look slow (for a while), but
> I would be willing to bet that virtual address space capacity
> demand will not accelerate and even that such will continue
> to decelerate (though not as much as from the one-time sold
> state storage effect or the, hopefully temporary, AI causes
> memory price increases).
The laptop and desktop PCs are rarely memory limited these days.
Gamers may be different. Servers ARE different, and Data Base
is even different than that.
> [snip]
> > With ECAM based on PCIe 4.0+, your device address space consumes
> > up to 40-bits. And then there is the configuration space, and the
> > interrupt table aperture space, and other system spaces--all vying
> > for those 47-bits. I suspect 47 will not be sufficient very long.
>
> Interesting, but the applications using tagged addresses are not
> likely to be interacting so directly with I/O (I think).
>
> > My 66000's solution is to provide a complete 64-bit VAS that can be
> > translated into a 66-bit universal address space consisting of four
> > 64-bit spaces {DRAM, device, config, ROM}. I don't want any of these
> > spaces to cause issues while I remain alive. Both cores and devices
> > use the 66-bit UAS.
>
> 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.
> 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.
> 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
???
> > Using MSI-X interrupts, allows interrupt tables to perform DPC/softIRQ
> > queueing without normally associated SW overheads. Cores can send cores
> > interrupts using the same mechanisms as devices. Since there is an
> > unlimited number of interrupt tables (My 66000) and since the are
> > constructed with a DAG structure, anything that can touch the interrupt
> > aperture can send interrupts to any virtual core. When that virtual
> > core has control, those interrupts are 'processed'.
>
> I like the orientation toward "an agent is an agent". That is
> just one more indication of My 66000 being a *design* and not
> merely a collection of useful ideas. I am not up to the task of
> designing a paper ISA, but I can still appreciate engineering.
So, send me an e-mail address and I can send you ISA-55 and SFT-55
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-10 14:53 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <rvzoS.158$5X3.132@fx12.iad> |
| In reply to | #117917 |
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). <big snip> >> >> The length of time between address space doubling doubles, and >> the delay is longer if cost-per-bit does not halve regularly >> and/or capacity demand is worse than linear with price. I think >> the speed of solid state storage reduced DRAM demand (cheaper >> indirectly addressed storage was good enough for many uses), > >Yes, SSD took some demand out of DRAM size requirements, by >shrinking 10ms rotational latency into 50µs access delay; >and by raising the data gat from 4GBs into the 30GB/s range. > >On the other hand, AI turned around and is consuming all available >DRAM, so its a good thing SSDs are so fast. AI is mostly using HBM, not SSDs.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-10 16:36 +0000 |
| Subject | Re: 370 address sizes, Styles of addressing |
| Message-ID | <2026Sep10.183641@mips.complang.tuwien.ac.at> |
| In reply to | #117928 |
scott@slp53.sl.home (Scott Lurndal) writes: >MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>When SW has used TBI often enough AND those same applications >>need 63-bit (or 64-bit) virtual addresses. > >Which will likely be _NEVER_. I agree. >2^64 is a, pardon my french, >shitload of virtual memory. That's not the reason. With the larger machines needing maybe 44 bits for physical addresses, and the old pattern of 1 bit every 18 months or two years, we would exceed 56/57 bits in 18-26 years and exceed 64 bits in 30-40 years. But the growth has slowed down substantially, and I expect it to slow down even more, so that we will never reach physical memories that require 64 bits, and probably not 56 bits, either. And if we don't have that much physical memory, do we need VAs with more than 56 bits? Yes, one can do cool things with address space even if physical memories are not that large, but one can also do cool things with bits that are ignored. >Then there is the translation >cost with up to perhaps seven or more levels of page table >walk required. With 4KB pages and 8-byte page-table entries, 6 levels of page tables are good for 6*9+12=66 bits. With larger pages, you need even fewer levels (all assuming 8-byte PTEs): Page size levels bits 4KB 6 66 8KB 6 73 (63bits with 5 levels) 16KB 5 69 32KB 5 75 (63 bits with 4 levels) 64KB 4 68 And anyway, make the TLBs large enough, and full table walks will be rare. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 2 of 24 — ← Prev page 1 [2] 3 4 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web