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 15 of 24 — ← Prev page 1 … 13 14 [15] 16 17 … 24 Next page →
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-17 03:56 +0000 |
| Subject | Re: FORTRAN, was Comment delimiters |
| Message-ID | <11aurl9$2b0g$2@gal.iecc.com> |
| In reply to | #118657 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >The reason why I think of a backtracking parser is that it seems the >easiest way to be able to handle both > >DO101I=1.100 > >and > >DO101I=1,100 At least when I did it, backtracking parsers were big and ugly compared to little yacc parsers. I used Sale's algorithm although I didn't know that's what it was called when I reinvented it. >>There is a method called "Sale's Algorithm" which was published >>in CACM in the 1960's which describes how to lex up to Fortran 77. > >Interesting, but did the FORTRAN team come up with that? I think we can assume they did since it's by far the easiest way to parse card image FORTRAN. If anyone really cares I believe the assembler source of some early compilers is available online. R's, John -- 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 | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-10-17 11:09 -0400 |
| Subject | Re: FORTRAN, was Comment delimiters |
| Message-ID | <jwvik30uzz8.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118667 |
John Levine [2026-10-17 03:56:25] wrote: > According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >> Interesting, but did the FORTRAN team come up with that? > I think we can assume they did since it's by far the easiest way to > parse card image FORTRAN. If anyone really cares I believe the > assembler source of some early compilers is available online. Does make one wonder, tho: why didn't they adjust the syntax to avoid those ambiguities, instead of spending all that effort to try and resolve them in the compiler? === Stefan
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-17 10:06 -0400 |
| Subject | Re: Comment delimiters |
| Message-ID | <zhLAS.37514$1l6.27878@fx42.iad> |
| In reply to | #118657 |
On 2026-Oct-16 13:56, Anton Ertl wrote: > EricP <ThatWouldBeTelling@thevillage.com> writes: >> On 2026-Oct-15 02:17, Anton Ertl wrote: >>> My guess as to how this stuff was parsed: >>> >>> Deal with the first columns as appropriate. For the rest: Remove any >>> white space. Use a backtracking parser that tries to match a rule at >>> a time; for the DO statement, simply compare the start with "DO". If >>> a rule does not match, look at the next rule. >>> >>> The result is messy, especially when you want to extend the language. >> >> A backtracking parser sounds like way overkill. > > A backtracking parser is relatively easy and the memory needs for > parsing just a single statement are small, too. For an example of how > short a parser generator for a backtracking parser framework can be, > look at the second example in > <https://bernd-paysan.de/screenful.html>. > >> I am under the impression that many Fortran 77 compilers used >> hand written lexer and a recursive decent parser. >> The parser passes some local context to the lexer to let it know, >> for example, which set of keywords are active at that point. >> Anyway, that is how I would do it. > > The reason why I think of a backtracking parser is that it seems the > easiest way to be able to handle both > > DO101I=1.100 > > and > > DO101I=1,100 > > (examples given on > <https://en.wikipedia.org/wiki/Fortran#Fixed_layout_and_punched_cards>) F77 already had structured IF THEN ELSE IF THEN ELSE END IF. DEC F77 enhanced DO drops the loop end statement number and used END DO instead, and added DO WHILE END DO. (This one change alone de-rats-nests the source tremendously by eliminating all the loop label numbers so that label numbers were only used for unstructured GOTO and FORMAT statements which are infrequent.) DEC F77 had a number of enhancements which made the language more friendly, like tab in column 1 skips to the start of a statement or ! anywhere is a comment to end of line. These were adopted by many other F77 compiler vendors presumably because they wanted to get their customers. Later many became ANSI standard. >> There is a method called "Sale's Algorithm" which was published >> in CACM in the 1960's which describes how to lex up to Fortran 77. > > Interesting, but did the FORTRAN team come up with that? According to > <https://fortran-lang.discourse.group/t/has-anyone-played-with-sales-fortran-classification-algorithm-lately/7802> > the algorithm was published in 1971. > >> After that it is pretty standard AST processing. >> The only semantic difference I can think of immediately is >> Fortran's parenthesis rule that forces an order of evaluation >> and would interact with optimizations like common subexpressions. > > Searching around, I found little about "order of evaluation" when it > comes to parenthesis in FORTRAN, although I remember hearing or > reading about the significance of parentheses in FORTRAN several > times. But does it have any relevance beyond determining that a+(b+c) > is evalutated as > > t=b+c > r=a+t > > rather than > > t=a+b > r=t+c > > If not, that rule just disallows reassociation, but reassociation is > not something I have seen in common subexpression elimination (or, > more generally, partial redundancy elimination) algorithms anyway. Parenthesis can be used to force an order of execution. The parenthesis ordering rule is also data type dependent. It applies to integer, logical (also integer) and real but not strings. #1 a + b + c Unordered #2 (a+b) + c a+b before +c #3 a + (b+c) b+c before +a This would interact with common subexpression elimination. Above would not be able to optimize all 3 expressions to 1. It can replace #1 with #2 or #3, but not both. I'm not sure but I think parenthesis also could block optimizations like a*b+a*c => a*(b+c) but (a*b)+(a*c) might not be optimized.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-17 14:58 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <11b02fd$9e1u$1@dont-email.me> |
| In reply to | #118672 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb: > DEC F77 had a number of enhancements which made the language > more friendly, like tab in column 1 skips to the start of a > statement That didn't make it into the language, and also makes calculation of the line length a bit awkward. When should the line end? Remember, collumn 73-80 are ignored. > or ! anywhere is a comment to end of line. Was that a DEC extension? At least it was adapted in Fortran 90. > These were adopted by many other F77 compiler vendors > presumably because they wanted to get their customers. They are a rat's nest. Yes, many were convenient, but compilers more or less have to keep supporting them for legacy code. gfortran has -fdec, which in turn enables around ten extensions, but not everything is implemented, for example variable formats or the infamous Q format descriptor. And, of course, the (in)famous PARAMETER X=20 snafu. > Parenthesis can be used to force an order of execution. > The parenthesis ordering rule is also data type dependent. > It applies to integer, logical (also integer) and real but not strings. Not sure what use they would be for strings... but where did you get that information from? >#1 a + b + c Unordered >#2 (a+b) + c a+b before +c >#3 a + (b+c) b+c before +a > > This would interact with common subexpression elimination. > Above would not be able to optimize all 3 expressions to 1. > It can replace #1 with #2 or #3, but not both. > > I'm not sure but I think parenthesis also could block optimizations > like a*b+a*c => a*(b+c) but (a*b)+(a*c) might not be optimized. The rule is simple: In Fortran, parameters have to be honored, otherwise the rules of standard mathematics apply. So, a + b - a can be optimized to b. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-18 10:55 -0400 |
| Subject | Re: Comment delimiters |
| Message-ID | <465BS.66342$ACx3.13820@fx15.iad> |
| In reply to | #118674 |
On 2026-Oct-17 10:58, Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>
>> DEC F77 had a number of enhancements which made the language
>> more friendly, like tab in column 1 skips to the start of a
>> statement
>
> That didn't make it into the language, and also makes calculation
> of the line length a bit awkward. When should the line end?
> Remember, collumn 73-80 are ignored.
That shouldn't be a problem.
A tab in columns 1 to 6 meant jump to column 7, the statement start.
DEC also optionally allowed lines up to 132 characters -
the full width of a VT100 in widescreen mode!
>> or ! anywhere is a comment to end of line.
>
> Was that a DEC extension? At least it was adapted in Fortran 90.
Yes
There were lots more. 32 character variables (up from the standard 8).
DEC F77 used a stack and allowed recursion if you were careful
whereas IBM F77 did not (it used static allocation for all local
variables so recursion stomped on their values).
>> These were adopted by many other F77 compiler vendors
>> presumably because they wanted to get their customers.
>
> They are a rat's nest. Yes, many were convenient, but compilers
> more or less have to keep supporting them for legacy code.
> gfortran has -fdec, which in turn enables around ten extensions,
> but not everything is implemented, for example variable formats
> or the infamous Q format descriptor.
>
> And, of course, the (in)famous PARAMETER X=20 snafu.
I don't know that one. Do tell...
>> Parenthesis can be used to force an order of execution.
>> The parenthesis ordering rule is also data type dependent.
>> It applies to integer, logical (also integer) and real but not strings.
>
> Not sure what use they would be for strings... but where did you get
> that information from?
I have a 1988 copy of the DEC Fortran manual.
I was looking at it for a specific set of parenthesis rules
but no such luck. But it did say that parenthesis do not affect
the value of a character string.
My point being that whereas in many languages the parser can
toss parenthesis, in F77 expressions they may be significant,
and that significance may be semantic dependent.
>> #1 a + b + c Unordered
>> #2 (a+b) + c a+b before +c
>> #3 a + (b+c) b+c before +a
>>
>> This would interact with common subexpression elimination.
>> Above would not be able to optimize all 3 expressions to 1.
>> It can replace #1 with #2 or #3, but not both.
>>
>> I'm not sure but I think parenthesis also could block optimizations
>> like a*b+a*c => a*(b+c) but (a*b)+(a*c) might not be optimized.
>
> The rule is simple: In Fortran, parameters have to be honored,
> otherwise the rules of standard mathematics apply. So,
> a + b - a can be optimized to b.
>
Yes but determining if two expressions are equivalent
and therefore candidates for elimination can require
some massaging first.
#4 a + ((b+c))
the first ( is significant, the second ( is redundant,
and #4 should match #3 and not #2.
But the following string expressions are all equivalent
#5 ('ABC')//('DE')//'F'
#6 'ABC'//('DE'//'F')
#7 'ABC'//'DE'//'F'
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-18 17:56 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <1792346172-5857@newsgrouper.org> |
| In reply to | #118686 |
EricP <ThatWouldBeTelling@thevillage.com> posted:
> On 2026-Oct-17 10:58, Thomas Koenig wrote:
> > EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> >
> >> DEC F77 had a number of enhancements which made the language
> >> more friendly, like tab in column 1 skips to the start of a
> >> statement
> >
> > That didn't make it into the language, and also makes calculation
> > of the line length a bit awkward. When should the line end?
> > Remember, collumn 73-80 are ignored.
>
> That shouldn't be a problem.
> A tab in columns 1 to 6 meant jump to column 7, the statement start.
>
> DEC also optionally allowed lines up to 132 characters -
> the full width of a VT100 in widescreen mode!
>
> >> or ! anywhere is a comment to end of line.
> >
> > Was that a DEC extension? At least it was adapted in Fortran 90.
>
> Yes
>
> There were lots more. 32 character variables (up from the standard 8).
> DEC F77 used a stack and allowed recursion if you were careful
> whereas IBM F77 did not (it used static allocation for all local
> variables so recursion stomped on their values).
>
> >> These were adopted by many other F77 compiler vendors
> >> presumably because they wanted to get their customers.
> >
> > They are a rat's nest. Yes, many were convenient, but compilers
> > more or less have to keep supporting them for legacy code.
> > gfortran has -fdec, which in turn enables around ten extensions,
> > but not everything is implemented, for example variable formats
> > or the infamous Q format descriptor.
> >
> > And, of course, the (in)famous PARAMETER X=20 snafu.
>
> I don't know that one. Do tell...
>
> >> Parenthesis can be used to force an order of execution.
> >> The parenthesis ordering rule is also data type dependent.
> >> It applies to integer, logical (also integer) and real but not strings.
> >
> > Not sure what use they would be for strings... but where did you get
> > that information from?
>
> I have a 1988 copy of the DEC Fortran manual.
> I was looking at it for a specific set of parenthesis rules
> but no such luck. But it did say that parenthesis do not affect
> the value of a character string.
>
> My point being that whereas in many languages the parser can
> toss parenthesis, in F77 expressions they may be significant,
> and that significance may be semantic dependent.
>
> >> #1 a + b + c Unordered
> >> #2 (a+b) + c a+b before +c
> >> #3 a + (b+c) b+c before +a
> >>
> >> This would interact with common subexpression elimination.
> >> Above would not be able to optimize all 3 expressions to 1.
> >> It can replace #1 with #2 or #3, but not both.
> >>
> >> I'm not sure but I think parenthesis also could block optimizations
> >> like a*b+a*c => a*(b+c) but (a*b)+(a*c) might not be optimized.
> >
> > The rule is simple: In Fortran, parameters have to be honored,
> > otherwise the rules of standard mathematics apply. So,
> > a + b - a can be optimized to b.
> >
>
> Yes but determining if two expressions are equivalent
> and therefore candidates for elimination can require
> some massaging first.
>
> #4 a + ((b+c))
>
> the first ( is significant, the second ( is redundant,
> and #4 should match #3 and not #2.
>
> But the following string expressions are all equivalent
>
> #5 ('ABC')//('DE')//'F'
> #6 'ABC'//('DE'//'F')
> #7 'ABC'//'DE'//'F'
>
I remember concatenation as || not //.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-19 18:09 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <11b5mdi$2a843$1@dont-email.me> |
| In reply to | #118686 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> On 2026-Oct-17 10:58, Thomas Koenig wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>
>>> DEC F77 had a number of enhancements which made the language
>>> more friendly, like tab in column 1 skips to the start of a
>>> statement
>>
>> That didn't make it into the language, and also makes calculation
>> of the line length a bit awkward. When should the line end?
>> Remember, collumn 73-80 are ignored.
>
> That shouldn't be a problem.
> A tab in columns 1 to 6 meant jump to column 7, the statement start.
As long as your editor shows this correctly, and does not indent
up to column 8...
> DEC also optionally allowed lines up to 132 characters -
> the full width of a VT100 in widescreen mode!
Nice way to get vendor lock-in. But it made it into Fortran 90,
but only in free format. Fixed format stayed at the limits of the
IBM 704, which could only read 72 characters from a punched card
because thy used the accumulator and their MQ register for it to
read a line.
>
>>> or ! anywhere is a comment to end of line.
>>
>> Was that a DEC extension? At least it was adapted in Fortran 90.
>
> Yes
>
> There were lots more. 32 character variables (up from the standard 8).
Six, actually - the 704 strikes again. But when Fortran 77
was defined, 36-bit machines with six-bit characters still were
still around, so it was handy to have one word as a symbol
(for compiler writers, not so much for users...)
> DEC F77 used a stack and allowed recursion if you were careful
> whereas IBM F77 did not (it used static allocation for all local
> variables so recursion stomped on their values).
OS/360 calling conventions is one thing they got wrong.
>>> These were adopted by many other F77 compiler vendors
>>> presumably because they wanted to get their customers.
>>
>> They are a rat's nest. Yes, many were convenient, but compilers
>> more or less have to keep supporting them for legacy code.
>> gfortran has -fdec, which in turn enables around ten extensions,
>> but not everything is implemented, for example variable formats
>> or the infamous Q format descriptor.
>>
>> And, of course, the (in)famous PARAMETER X=20 snafu.
>
> I don't know that one. Do tell...
A pre-version of FORTRAN 77 had PARAMETER X = 20, and DEC
pre-implemented this. The committee then settled on
PARAMETER (X=20) .
Can't blame them too much, I sort of made the same mistake again.
>
>>> Parenthesis can be used to force an order of execution.
>>> The parenthesis ordering rule is also data type dependent.
>>> It applies to integer, logical (also integer) and real but not strings.
>>
>> Not sure what use they would be for strings... but where did you get
>> that information from?
>
> I have a 1988 copy of the DEC Fortran manual.
> I was looking at it for a specific set of parenthesis rules
> but no such luck. But it did say that parenthesis do not affect
> the value of a character string.
>
> My point being that whereas in many languages the parser can
> toss parenthesis, in F77 expressions they may be significant,
> and that significance may be semantic dependent.
They are significant, especially in floating point. Assume (a -
b) + c, where a + c can overflow or cause cancellation.
This allows the progammer control over association where it is
important.
>
>>> #1 a + b + c Unordered
>>> #2 (a+b) + c a+b before +c
>>> #3 a + (b+c) b+c before +a
>>>
>>> This would interact with common subexpression elimination.
>>> Above would not be able to optimize all 3 expressions to 1.
>>> It can replace #1 with #2 or #3, but not both.
>>>
>>> I'm not sure but I think parenthesis also could block optimizations
>>> like a*b+a*c => a*(b+c) but (a*b)+(a*c) might not be optimized.
>>
>> The rule is simple: In Fortran, parameters have to be honored,
>> otherwise the rules of standard mathematics apply. So,
>> a + b - a can be optimized to b.
>>
>
> Yes but determining if two expressions are equivalent
> and therefore candidates for elimination can require
> some massaging first.
>
>#4 a + ((b+c))
>
> the first ( is significant, the second ( is redundant,
> and #4 should match #3 and not #2.
>
> But the following string expressions are all equivalent
>
>#5 ('ABC')//('DE')//'F'
>#6 'ABC'//('DE'//'F')
>#7 'ABC'//'DE'//'F'
This should actually be the same. But today's Fortran does
not specia-case strings anyway:
10.1.8
Integrity of parentheses
1 The rules for evaluation specified in 10.1.5 state certain
conditions under which a processor can evaluate an expres- sion
that is different from the one specified by applying the rules
given in 10.1.2 and the rules for interpretation specified in
10.1.5. However, any expression in parentheses shall be treated
as a data entity.
NOTE
For example, in evaluating the expression A + (B – C) where A, B, and
C are of numeric types, the difference of B and C shall be evaluated
before the addition operation is performed; the processor shall not
evaluate the mathematically equivalent expression (A + B) – C.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-20 03:50 +0000 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <11b6odq$5g5$1@gal.iecc.com> |
| In reply to | #118726 |
According to Thomas Koenig <tkoenig@netcologne.de>: >> DEC F77 used a stack and allowed recursion if you were careful >> whereas IBM F77 did not (it used static allocation for all local >> variables so recursion stomped on their values). > >OS/360 calling conventions is one thing they got wrong. My PDP-11 Unix F77 used the C compiler's back end, so recursion worked fine. I made variables automatic (stack) unless you used a SAVE statement, which made sense in the PDP-11's limited address space. It is quite possible to do recursion with the OS/360 calling convention. Their PL/I compilers did it and I believe the various ALGOL compilers, which had to support recursion, also used the standard calling sequence. -- 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 | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2026-10-20 20:53 +0100 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <njpv6jFodo8U1@mid.individual.net> |
| In reply to | #118738 |
On 20/10/2026 04:50, John Levine wrote: > According to Thomas Koenig <tkoenig@netcologne.de>: >>> DEC F77 used a stack and allowed recursion if you were careful >>> whereas IBM F77 did not (it used static allocation for all local >>> variables so recursion stomped on their values). >> >> OS/360 calling conventions is one thing they got wrong. > > My PDP-11 Unix F77 used the C compiler's back end, so recursion > worked fine. I made variables automatic (stack) unless you used > a SAVE statement, which made sense in the PDP-11's limited address space. > > It is quite possible to do recursion with the OS/360 calling convention. > Their PL/I compilers did it and I believe the various ALGOL compilers, > which had to support recursion, also used the standard calling sequence. > Brian Wichmann (of Whetstone Benchmark fame) gives the following figures for Ackermann's function, a stress test for recursion. ALGOL 60, by architecture, mean orders/call, * = estimate RMCS, VAX 12.5 XALGOL, B6700 16.0 RMCS, PE 3200 17.5 XALGOL B5500 19.5 ICL, ICL 2900 Series 19.5 Manchester Uni., ICL 1900 Series 33.5 System/3?0, by language and compiler ALGOL 60, Edinburgh Uni. /360 21.0 PL/I OPT v1.2.1, IBM /360 61 * ALGOL W, Stanford Uni. /360 74 * ALGOL 60, Delft Uni. /360 142 * PL/I F level v5.4, IBM /360 212 * ALGOL 60, IBM F level /360 820 * Make of that what you will. And for amusement: DEC VAX: Language, Compiler Ada, York Ada global function 8 C optimised 9 C 10 Ada, York Ada nested function 11 Ada, RMCS compiler 12.5
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-20 20:15 +0000 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <11b8i5k$3bj1q$1@dont-email.me> |
| In reply to | #118750 |
Bill Findlay <findlaybill@blueyonder.co.uk> schrieb: > On 20/10/2026 04:50, John Levine wrote: >> According to Thomas Koenig <tkoenig@netcologne.de>: >>>> DEC F77 used a stack and allowed recursion if you were careful >>>> whereas IBM F77 did not (it used static allocation for all local >>>> variables so recursion stomped on their values). >>> >>> OS/360 calling conventions is one thing they got wrong. >> >> My PDP-11 Unix F77 used the C compiler's back end, so recursion >> worked fine. I made variables automatic (stack) unless you used >> a SAVE statement, which made sense in the PDP-11's limited address space. >> >> It is quite possible to do recursion with the OS/360 calling convention. >> Their PL/I compilers did it and I believe the various ALGOL compilers, >> which had to support recursion, also used the standard calling sequence. >> > > Brian Wichmann (of Whetstone Benchmark fame) gives the following > figures for Ackermann's function, a stress test for recursion. > > ALGOL 60, by architecture, mean orders/call, * = estimate I understand "ALGOL 60", but not the rest. What orders? -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-20 20:44 +0000 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <1pQBS.93248$Q3f.61262@fx05.iad> |
| In reply to | #118752 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Bill Findlay <findlaybill@blueyonder.co.uk> schrieb: >> On 20/10/2026 04:50, John Levine wrote: >>> According to Thomas Koenig <tkoenig@netcologne.de>: >>>>> DEC F77 used a stack and allowed recursion if you were careful >>>>> whereas IBM F77 did not (it used static allocation for all local >>>>> variables so recursion stomped on their values). >>>> >>>> OS/360 calling conventions is one thing they got wrong. >>> >>> My PDP-11 Unix F77 used the C compiler's back end, so recursion >>> worked fine. I made variables automatic (stack) unless you used >>> a SAVE statement, which made sense in the PDP-11's limited address space. >>> >>> It is quite possible to do recursion with the OS/360 calling convention. >>> Their PL/I compilers did it and I believe the various ALGOL compilers, >>> which had to support recursion, also used the standard calling sequence. >>> >> >> Brian Wichmann (of Whetstone Benchmark fame) gives the following >> figures for Ackermann's function, a stress test for recursion. >> >> ALGOL 60, by architecture, mean orders/call, * = estimate > >I understand "ALGOL 60", but not the rest. > >What orders? Archaic terminology for "instructions". The early Burroughs systems (Electrodata 220, Burroughs 300, B3500) all called them 'orders' rather than instructions. In fact, the processor test suite for the B3500 and successors was called all-orders.
[toc] | [prev] | [next] | [standalone]
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-10-20 22:49 +0000 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <6ad7efb5.44632250@news.eternal-september.org> |
| In reply to | #118753 |
On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Archaic terminology for "instructions". > >The early Burroughs systems (Electrodata 220, Burroughs 300, >B3500) all called them 'orders' rather than instructions. > >In fact, the processor test suite for the B3500 and successors >was called all-orders. At one time, the _instruction set_ of a computer was instead referred to as its "order code". John Savard
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2026-10-21 23:06 +0100 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <njsradF8l83U1@mid.individual.net> |
| In reply to | #118754 |
On 20/10/2026 23:49, John Savard wrote: > On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote: > >> Archaic terminology for "instructions". >> >> The early Burroughs systems (Electrodata 220, Burroughs 300, >> B3500) all called them 'orders' rather than instructions. >> >> In fact, the processor test suite for the B3500 and successors >> was called all-orders. > > At one time, the _instruction set_ of a computer was instead referred > to as its "order code". The US-centrism is strong in these replies. Sigh. (I have taken that over from Nick.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-22 00:02 +0000 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <locCS.127036$DN.108183@fx45.iad> |
| In reply to | #118767 |
Bill Findlay <findlaybill@blueyonder.co.uk> writes: >On 20/10/2026 23:49, John Savard wrote: >> On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) >> wrote: >> >>> Archaic terminology for "instructions". >>> >>> The early Burroughs systems (Electrodata 220, Burroughs 300, >>> B3500) all called them 'orders' rather than instructions. >>> >>> In fact, the processor test suite for the B3500 and successors >>> was called all-orders. >> >> At one time, the _instruction set_ of a computer was instead referred >> to as its "order code". >The US-centrism is strong in these replies. >Sigh. (I have taken that over from Nick.) Perhaps you might, then, enlighten your yank cousins by providing the UK viewpoint.
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2026-10-22 23:43 +0100 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <njvhs3Fm5vtU2@mid.individual.net> |
| In reply to | #118768 |
On 22/10/2026 01:02, Scott Lurndal wrote: > Bill Findlay <findlaybill@blueyonder.co.uk> writes: >> On 20/10/2026 23:49, John Savard wrote: >>> On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) >>> wrote: >>> >>>> Archaic terminology for "instructions". >>>> >>>> The early Burroughs systems (Electrodata 220, Burroughs 300, >>>> B3500) all called them 'orders' rather than instructions. >>>> >>>> In fact, the processor test suite for the B3500 and successors >>>> was called all-orders. >>> >>> At one time, the _instruction set_ of a computer was instead referred >>> to as its "order code". >> The US-centrism is strong in these replies. >> Sigh. (I have taken that over from Nick.) > > Perhaps you might, then, enlighten your yank > cousins by providing the UK viewpoint. I do, from time to time, and am generally ignored.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-23 00:27 +0000 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <1792715227-5857@newsgrouper.org> |
| In reply to | #118777 |
Bill Findlay <findlaybill@blueyonder.co.uk> posted: > On 22/10/2026 01:02, Scott Lurndal wrote: > > Bill Findlay <findlaybill@blueyonder.co.uk> writes: > >> On 20/10/2026 23:49, John Savard wrote: > >>> On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) > >>> wrote: > >>> > >>>> Archaic terminology for "instructions". > >>>> > >>>> The early Burroughs systems (Electrodata 220, Burroughs 300, > >>>> B3500) all called them 'orders' rather than instructions. > >>>> > >>>> In fact, the processor test suite for the B3500 and successors > >>>> was called all-orders. > >>> > >>> At one time, the _instruction set_ of a computer was instead referred > >>> to as its "order code". > >> The US-centrism is strong in these replies. > >> Sigh. (I have taken that over from Nick.) > > > > Perhaps you might, then, enlighten your yank > > cousins by providing the UK viewpoint. > > I do, from time to time, and am generally ignored. That is ALMOST the Casandra Syndrome:: "always tell the truth, nobody ever believes"
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2026-10-23 03:46 +0100 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <nk003nFo9odU1@mid.individual.net> |
| In reply to | #118779 |
On 23/10/2026 01:27, MitchAlsup wrote: > Bill Findlay <findlaybill@blueyonder.co.uk> posted: > >> On 22/10/2026 01:02, Scott Lurndal wrote: >>> Bill Findlay <findlaybill@blueyonder.co.uk> writes: >>>> On 20/10/2026 23:49, John Savard wrote: >>>>> On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) >>>>> wrote: >>>>> >>>>>> Archaic terminology for "instructions". >>>>>> >>>>>> The early Burroughs systems (Electrodata 220, Burroughs 300, >>>>>> B3500) all called them 'orders' rather than instructions. >>>>>> >>>>>> In fact, the processor test suite for the B3500 and successors >>>>>> was called all-orders. >>>>> >>>>> At one time, the _instruction set_ of a computer was instead referred >>>>> to as its "order code". >>>> The US-centrism is strong in these replies. >>>> Sigh. (I have taken that over from Nick.) >>> >>> Perhaps you might, then, enlighten your yank >>> cousins by providing the UK viewpoint. >> >> I do, from time to time, and am generally ignored. > > That is ALMOST the Casandra Syndrome:: "always tell the truth, > nobody ever believes" Quite so. However, it all goes into an archive and will continue being available to those with curiosity and broad minds.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-23 11:21 +0300 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <20261023112115.0000530b@yahoo.com> |
| In reply to | #118781 |
On Fri, 23 Oct 2026 03:46:14 +0100 Bill Findlay <findlaybill@blueyonder.co.uk> wrote: > On 23/10/2026 01:27, MitchAlsup wrote: > > Bill Findlay <findlaybill@blueyonder.co.uk> posted: > > > >> On 22/10/2026 01:02, Scott Lurndal wrote: > >>> Bill Findlay <findlaybill@blueyonder.co.uk> writes: > >>>> On 20/10/2026 23:49, John Savard wrote: > >>>>> On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott > >>>>> Lurndal) wrote: > >>>>> > >>>>>> Archaic terminology for "instructions". > >>>>>> > >>>>>> The early Burroughs systems (Electrodata 220, Burroughs 300, > >>>>>> B3500) all called them 'orders' rather than instructions. > >>>>>> > >>>>>> In fact, the processor test suite for the B3500 and successors > >>>>>> was called all-orders. > >>>>> > >>>>> At one time, the _instruction set_ of a computer was instead > >>>>> referred to as its "order code". > >>>> The US-centrism is strong in these replies. > >>>> Sigh. (I have taken that over from Nick.) > >>> > >>> Perhaps you might, then, enlighten your yank > >>> cousins by providing the UK viewpoint. > >> > >> I do, from time to time, and am generally ignored. > > > > That is ALMOST the Casandra Syndrome:: "always tell the truth, > > nobody ever believes" > > Quite so. > However, it all goes into an archive and will continue > being available to those with curiosity and broad minds. > Archives? Google's usenet archives became very unpleasant to use in recent months. Are there alternatives?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-23 12:49 +0200 |
| Subject | Re: more Fortran, Comment delimiters |
| Message-ID | <11bfe31$1jkb5$7@dont-email.me> |
| In reply to | #118781 |
On 23/10/2026 04:46, Bill Findlay wrote: > On 23/10/2026 01:27, MitchAlsup wrote: >> Bill Findlay <findlaybill@blueyonder.co.uk> posted: >> >>> On 22/10/2026 01:02, Scott Lurndal wrote: >>>> Bill Findlay <findlaybill@blueyonder.co.uk> writes: >>>>> On 20/10/2026 23:49, John Savard wrote: >>>>>> On Tue, 20 Oct 2026 20:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) >>>>>> wrote: >>>>>> >>>>>>> Archaic terminology for "instructions". >>>>>>> >>>>>>> The early Burroughs systems (Electrodata 220, Burroughs 300, >>>>>>> B3500) all called them 'orders' rather than instructions. >>>>>>> >>>>>>> In fact, the processor test suite for the B3500 and successors >>>>>>> was called all-orders. >>>>>> >>>>>> At one time, the _instruction set_ of a computer was instead referred >>>>>> to as its "order code". >>>>> The US-centrism is strong in these replies. >>>>> Sigh. (I have taken that over from Nick.) >>>> >>>> Perhaps you might, then, enlighten your yank >>>> cousins by providing the UK viewpoint. >>> >>> I do, from time to time, and am generally ignored. >> >> That is ALMOST the Casandra Syndrome:: "always tell the truth, >> nobody ever believes" > > Quite so. > However, it all goes into an archive and will continue > being available to those with curiosity and broad minds. > What do you think is going in the archives here? All I see is an unsubstantiated claim of "US centrism" for something that doesn't really matter very much anyway. I have no idea what terms were used at that time, so I have no idea if you are right or not - but you should justify your accusations with verifiable facts, or at the very least, anecdotes and personal experience. I am quite confident that our friends across the pond are not being intentionally US-centric about their history, but it is natural that their own experiences and what they have heard is somewhat biased - just like it is for the rest of us. I occasionally get corrected for my UK bias of history, and I appreciate such corrections - I think most people appreciate corrections more than unhelpful accusations.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-21 03:28 +0000 |
| Subject | Re: Algol, was more Fortran, Comment delimiters |
| Message-ID | <11b9bhc$28tm$1@gal.iecc.com> |
| In reply to | #118750 |
According to Bill Findlay <findlaybill@blueyonder.co.uk>: >System/3?0, by language and compiler > >ALGOL 60, Edinburgh Uni. /360 21.0 >PL/I OPT v1.2.1, IBM /360 61 * >ALGOL W, Stanford Uni. /360 74 * >ALGOL 60, Delft Uni. /360 142 * >PL/I F level v5.4, IBM /360 212 * >ALGOL 60, IBM F level /360 820 * That looks about right. PL/I F was the original compiler which generated lousy code, later replaced by PL/I OPT. ALGOL F seems to have been written with the attitude, you want an Algol compiler? Here's an Algol compiler, suck it up. It did GETMAIN and FREEMAIN system calls to allocate storage whenever it entered or left a block. Someone at Princeton patched it to do what PL/I did, allocate large blocks and suballocate within them, which vastly improved its performance. -- 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]
Page 15 of 24 — ← Prev page 1 … 13 14 [15] 16 17 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web