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 14 of 24 — ← Prev page 1 … 12 13 [14] 15 16 … 24 Next page →
| From | Andy Valencia <vandys@vsta.org> |
|---|---|
| Date | 2026-10-13 09:09 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <179190779286.25645.14465927900754526737@media.vsta.org> |
| In reply to | #118558 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > hex \ change to base #16 > add \ is this a dictionary word, or a number? > > The classic ways to avoid this has been to > > 1) prefix hex numbers with 0 if they would otherwise start with a > letter. Dictionary words rarely start with digits, and when they > do, they don't conflict with hex numbers. Alternately, Forth could adopt practices which have become broad, de facto standards. So, referencing above, instead hex numbers have a 0xadd prefix, and you don't switch the base of the system. While you're at it, start the transition to "//" as the comment token. From memory, who's holding out? Only Forth, Smalltalk, and COBOL come to mind. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-13 16:31 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Oct13.183123@mips.complang.tuwien.ac.at> |
| In reply to | #118584 |
Andy Valencia <vandys@vsta.org> writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> hex \ change to base #16 >> add \ is this a dictionary word, or a number? >> >> The classic ways to avoid this has been to >> >> 1) prefix hex numbers with 0 if they would otherwise start with a >> letter. Dictionary words rarely start with digits, and when they >> do, they don't conflict with hex numbers. > >Alternately, Forth could adopt practices which have become broad, >de facto standards. So, referencing above, instead hex numbers >have a 0xadd prefix, and you don't switch the base of the system. I don't change the base for inputting numbers, and use the standardized prefix $ instead ($add), as mentioned. A number of systems recognize numbers with the prefix 0x as hex numbers, too. Finally, you can add user-defined recognizers in a number of Forth systems, and recognize 0x-prefixed numbers on these systems. >While you're at it, start the transition to "//" as the comment >token. You can define that yourself if you want: : // 0 parse 2drop ; immediate But unlike for the 0x prefix, few Forth systems have implemented // comments, so demand for that is low. And why should there be demand for it? For the 0x prefix, the demand comes from interoperating with C-oriented tools that output hex numbers with a 0x prefix. But comments have no such interoperability issues. >From memory, who's holding out? Only Forth, Smalltalk, and >COBOL come to mind. Most programming languages use something else for comments: Unix shells, Lisp, Makefiles, assembly language, Postscript and Ada come to my mind. Maybe some of them also accept //, but I have yet to see a program in one of these languages that uses such a comment. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-13 18:12 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <swuzS.464504$U_e2.393311@fx24.iad> |
| In reply to | #118585 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Andy Valencia <vandys@vsta.org> writes: >>From memory, who's holding out? Only Forth, Smalltalk, and >>COBOL come to mind. > >Most programming languages use something else for comments: Unix >shells, Lisp, Makefiles, assembly language, Postscript and Ada come to >my mind. Maybe some of them also accept //, but I have yet to see a >program in one of these languages that uses such a comment. And one can simply pipe them through cpp before sending the source to the compiler to remove comments starting with '//'.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-10-13 20:02 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <nj76h5FnesuU2@mid.individual.net> |
| In reply to | #118584 |
On 2026-10-13 19:09, Andy Valencia wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> hex \ change to base #16 >> add \ is this a dictionary word, or a number? >> >> The classic ways to avoid this has been to >> >> 1) prefix hex numbers with 0 if they would otherwise start with a >> letter. Dictionary words rarely start with digits, and when they >> do, they don't conflict with hex numbers. > > Alternately, Forth could adopt practices which have become broad, > de facto standards. So, referencing above, instead hex numbers > have a 0xadd prefix, and you don't switch the base of the system. > > While you're at it, start the transition to "//" as the comment > token. From memory, who's holding out? Only Forth, Smalltalk, and > COBOL come to mind. Ada uses "--".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-13 19:50 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11alr1n$ophm$1@dont-email.me> |
| In reply to | #118587 |
On 13/10/2026 19:02, Niklas Holsti wrote: > On 2026-10-13 19:09, Andy Valencia wrote: >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> hex \ change to base #16 >>> add \ is this a dictionary word, or a number? >>> >>> The classic ways to avoid this has been to >>> >>> 1) prefix hex numbers with 0 if they would otherwise start with a >>> letter. Dictionary words rarely start with digits, and when they >>> do, they don't conflict with hex numbers. >> >> Alternately, Forth could adopt practices which have become broad, >> de facto standards. So, referencing above, instead hex numbers >> have a 0xadd prefix, and you don't switch the base of the system. 0x prefixes for hex is certainly common, but $ prefixes for hex have been around for a long time too and are used in Pascal. Some languages use a suffix, like 0addH. Ada has 16#add#, while VHDL has x"add". Some BASICs use &. So again, there are plenty of options from existing practice. >> >> While you're at it, start the transition to "//" as the comment >> token. From memory, who's holding out? Only Forth, Smalltalk, and >> COBOL come to mind. > > Ada uses "--". > As does Lua, VHDL, Haskell, and SQL. And lots of languages use #, TeX has %, several languages use ; and there are many others. <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)#Comments>
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-10-13 23:24 -0400 |
| Subject | Comment delimiters (was: Optimization by programmers) |
| Message-ID | <jwvjynl2cg0.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118584 |
> While you're at it, start the transition to "//" as the comment > token. From memory, who's holding out? Only Forth, Smalltalk, and > COBOL come to mind. There are many many more, including a little known language named after something like a snake or some British comedy. In that language `//` is the integer division operation. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-14 09:56 +0200 |
| Subject | Re: Comment delimiters |
| Message-ID | <11anck4$16fmd$2@dont-email.me> |
| In reply to | #118601 |
On 14/10/2026 05:24, Stefan Monnier wrote: >> While you're at it, start the transition to "//" as the comment >> token. From memory, who's holding out? Only Forth, Smalltalk, and >> COBOL come to mind. > > There are many many more, including a little known language named after > something like a snake or some British comedy. In that language `//` is > the integer division operation. > The language was named for the comedy group. The group in question does not have an explanation for the name, and just like the sound of it.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-10-14 12:14 -0400 |
| Subject | Re: Comment delimiters (was: Optimization by programmers) |
| Message-ID | <808vclt9i2mso89n1itvnvos5j88g1mopl@4ax.com> |
| In reply to | #118601 |
On Tue, 13 Oct 2026 23:24:50 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Andy Valencia wrote: >> While you're at it, start the transition to "//" as the comment >> token. From memory, who's holding out? Only Forth, Smalltalk, and >> COBOL come to mind. @Andy Seriously, no thoughts on block comments? Shouldn't every language be forced to use /* */ >There are many many more, ... Indeed. https://gist.github.com/dk949/88b2652284234f723decaeb84db2576c I saw a few examples that were wrong (some addressed by replies), and a couple I know to be implementation dependent, but this looks to be a reasonable start on a survey. MMV but I think too many people in this forum assume that C is the only language that matters.
[toc] | [prev] | [next] | [standalone]
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-10-14 18:07 +0000 |
| Subject | Re: Comment delimiters (was: Optimization by programmers) |
| Message-ID | <6acfc2b2.1547984@news.eternal-september.org> |
| In reply to | #118613 |
On Wed, 14 Oct 2026 12:14:30 -0400, George Neuner <gneuner2@comcast.net> wrote: >Seriously, no thoughts on block comments? Shouldn't every language be >forced to use /* */ Using pairs of special characters for *any* purpose, from ** for exponentiation in FORTRAN onwards, and including <= and >= as relational operators, vastly complicates the syntax decoding of languages. Of course, even at http://www.quadibloc.com/comp/lngint.htm I couldn't _entirely_ avoid compounds of special characters. So what I did was adopt systematic rules: Only ?, @, and & can begin multi-character strings which are to be treated as a single character. @" is used for //, and @< and @> are used for /* and */. (The @ sign is generally used only for tokens which are "outside" of actual statements, at the upper level of the syntax.) &LE and &GE are used for <= and >=. Incidentally, C didn't invent /* and */; it got them from PL/I, although no doubt PL/I got them from some representation or other of ALGOL. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-14 18:50 +0000 |
| Subject | Re: Comment delimiters (was: Optimization by programmers) |
| Message-ID | <11aoitb$1okgh$1@dont-email.me> |
| In reply to | #118614 |
John Savard <quadibloc@invalid.com> schrieb: > On Wed, 14 Oct 2026 12:14:30 -0400, George Neuner ><gneuner2@comcast.net> wrote: > >>Seriously, no thoughts on block comments? Shouldn't every language be >>forced to use /* */ > > Using pairs of special characters for *any* purpose, from ** for > exponentiation in FORTRAN onwards, and including <= and >= as > relational operators, vastly complicates the syntax decoding of > languages. Do learn a bit about regular expressions and how they are implemented using state machines. Knowing about state machines is also fundamental when thinking about computer architectures and how to iplement them. -- 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-14 15:45 -0400 |
| Subject | Re: Comment delimiters |
| Message-ID | <HZQzS.6$TYg.3@fx21.iad> |
| In reply to | #118614 |
On 2026-Oct-14 14:07, John Savard wrote:
> On Wed, 14 Oct 2026 12:14:30 -0400, George Neuner
> <gneuner2@comcast.net> wrote:
>
>> Seriously, no thoughts on block comments? Shouldn't every language be
>> forced to use /* */
>
> Using pairs of special characters for *any* purpose, from ** for
> exponentiation in FORTRAN onwards, and including <= and >= as
> relational operators, vastly complicates the syntax decoding of
> languages.
>
> Of course, even at
> http://www.quadibloc.com/comp/lngint.htm
> I couldn't _entirely_ avoid compounds of special characters. So what I
> did was adopt systematic rules:
> Only ?, @, and & can begin multi-character strings which are to be
> treated as a single character. @" is used for //, and @< and @> are
> used for /* and */. (The @ sign is generally used only for tokens
> which are "outside" of actual statements, at the upper level of the
> syntax.) &LE and &GE are used for <= and >=.
>
> Incidentally, C didn't invent /* and */; it got them from PL/I,
> although no doubt PL/I got them from some representation or other of
> ALGOL.
>
> John Savard
Most languages are not as bad as pre-FORTRAN-90.
Lexing ** into a single token is a 1 character lookahead.
Old FORTRAN is difficult to parse because
a) it did not separate the language into lexical and syntax levels
b) it was white space oblivious except in quoted strings
c) there were no reserved words - keywords were statement
position and sometimes semantic context dependent.
d) statements were based on punch cards BUT because
continuation cards used the absence of a C in column 6
to indicate the start of a new statement, parsers have to
always look ahead to see in the next card has a C and
then "unget" the card if not.
The classic ambiguous parsing example being
DO I = 1,100
DOI = 1.100
depends on the presence or absence of a "naked comma" later in the
statement to decide whether there is a keyword DO and a variable I,
or a variable DOI. A "naked comma" is a comma not enclosed inside
a quoted character or string, or inside a possibly nested parenthesis.
There are other examples like keywords in FORMAT statements.
People learned a lot of what not to do in language design
from old FORTRAN.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-15 06:17 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <2026Oct15.081750@mips.complang.tuwien.ac.at> |
| In reply to | #118619 |
EricP <ThatWouldBeTelling@thevillage.com> writes: >Old FORTRAN is difficult to parse because >a) it did not separate the language into lexical and syntax levels >b) it was white space oblivious except in quoted strings >c) there were no reserved words - keywords were statement > position and sometimes semantic context dependent. >d) statements were based on punch cards BUT because > continuation cards used the absence of a C in column 6 > to indicate the start of a new statement, parsers have to > always look ahead to see in the next card has a C and > then "unget" the card if not. Given that the original FORTRAN worked on an IBM 704, I think that the designers made it as easy (and with as little memory) to parse as they could, given the state of the art at the time. Concerning the points: a) I guess that the division into lexical and syntax levels had not been developed at the time; and even later, e.g., Wirth does not make this distinction in his language definitions, using EBNF down to the lexical level (although he does define reserved words). b) Without this distinction, if you ignore white space at all, you either ignore it everywhere, or give it a special role in your syntax. Ignoring is probably simpler. c) The programming language community took quite a while until it arrived at reserved words. E.g., while Algol 60 was specified in BNF, being modern in that regard, it does not have reserved words, just symbols that are distinct from all identifiers; i.e., you could have an identifier like IF in Algol 60, distinct from the symbol 'IF', and it's up to the implementation how to distinguish them. Anyway, without a) reserved words make no sense. d) Does the original FORTRAN support continuation cards? >The classic ambiguous parsing example being > > DO I = 1,100 > DOI = 1.100 > >depends on the presence or absence of a "naked comma" later in the >statement to decide whether there is a keyword DO and a variable I, >or a variable DOI. A "naked comma" is a comma not enclosed inside >a quoted character or string, or inside a possibly nested parenthesis. 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. >People learned a lot of what not to do in language design >from old FORTRAN. And probably also what to do. Backus was on the Algol-60 committee, and the B in BNF stands for his name. I would not be surprised if the structure of the parser in the FORTRAN compiler gave him ideas for BNF. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-16 06:35 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <11asgjl$328d5$1@dont-email.me> |
| In reply to | #118633 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > EricP <ThatWouldBeTelling@thevillage.com> writes: >>Old FORTRAN is difficult to parse because >>a) it did not separate the language into lexical and syntax levels >>b) it was white space oblivious except in quoted strings >>c) there were no reserved words - keywords were statement >> position and sometimes semantic context dependent. >>d) statements were based on punch cards BUT because >> continuation cards used the absence of a C in column 6 >> to indicate the start of a new statement, parsers have to >> always look ahead to see in the next card has a C and >> then "unget" the card if not. > > Given that the original FORTRAN worked on an IBM 704, I think that the > designers made it as easy (and with as little memory) to parse as they > could, given the state of the art at the time. Concerning the points: > > a) I guess that the division into lexical and syntax levels had not > been developed at the time; They did not even have recursive descent parsing, and nobody had parsed formulas with operator precedence before. See https://en.wikipedia.org/wiki/Operator-precedence_parser#Full_parenthesization . > and even later, e.g., Wirth does not > make this distinction in his language definitions, using EBNF down > to the lexical level (although he does define reserved words). Also in modern language definition. Separating lexing and parsing is a matter of convenience, especially since regular expressions have been introduced, and speed. > b) Without this distinction, if you ignore white space at all, you > either ignore it everywhere, or give it a special role in your > syntax. Ignoring is probably simpler. The added complication of separate handling of whitespace is minor. For the original FORTRAN, they skipped them because card punch operators often made mistakes with spaces. > c) The programming language community took quite a while until it > arrived at reserved words. Reserved words make the compiler writer's job easier (somewhat, but not tremendously), but not having them is a solved problem. Users are left holding the bag if a new version of the language introduces new keywords. Same with intrinsics (or standard functions, or whatever...) if a new version of the language introduces new ones, users can run into problems. >E.g., while Algol 60 was specified in > BNF, being modern in that regard, it does not have reserved words, > just symbols that are distinct from all identifiers; i.e., you > could have an identifier like IF in Algol 60, distinct from the > symbol 'IF', and it's up to the implementation how to distinguish > them. Anyway, without a) reserved words make no sense. > > d) Does the original FORTRAN support continuation cards? Yes, it would have extremely restricted otherwise. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-16 17:10 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <2026Oct16.191024@mips.complang.tuwien.ac.at> |
| In reply to | #118647 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> and even later, e.g., Wirth does not >> make this distinction in his language definitions, using EBNF down >> to the lexical level (although he does define reserved words). > >Also in modern language definition. Separating lexing and parsing >is a matter of convenience, especially since regular expressions >have been introduced, and speed. Speed, yes, but it is also a matter of differences in handling of ambiguities. Scanning resolves ambiguities with longest input match, whereas parsing tends to avoid ambiguities, with only few exceptions (like the dangling else in some languages, but not, e.g., Algol 60, which is the first language that used BNF). As for convenience, for various compilers I read that either the scanner or the parser (or both) were hand-written (I don't remember which one was more frequent). It certainly does not seem much work to write a scanner for a typical programming language by hand (you recognize keywords by table lookup of things that will be classified as identifiers if they are not in the table). For the parser of a language that is not LL(1), it's more work, but writing it by hand allows you to do various things that, e.g., bison does not support (ANTLR has support for "syntactic predicates" and "semantic predicates", which probably is good enough for a lot of cases; it was written with C++ in mind). >> b) Without this distinction, if you ignore white space at all, you >> either ignore it everywhere, or give it a special role in your >> syntax. Ignoring is probably simpler. > >The added complication of separate handling of whitespace is minor. >For the original FORTRAN, they skipped them because card punch operators >often made mistakes with spaces. That's a good reason, but it seems to have disappeared with the next generation of programming languages. Were programmers later punching their own cards, or were they writing programs in a way that made spaces obvious? >> c) The programming language community took quite a while until it >> arrived at reserved words. > >Reserved words make the compiler writer's job easier (somewhat, >but not tremendously), but not having them is a solved problem. >Users are left holding the bag if a new version of the language >introduces new keywords. I don't think they worried about program maintainence across several Fortran versions when they worked on the original Fortran. It does not contain subroutines. >> d) Does the original FORTRAN support continuation cards? > >Yes, it would have extremely restricted otherwise. The original FORTRAN was extremely restricted. When I used Microsoft BASIC on the C64, where Commodore's line editor prevented lines longer than 80 characters, including line numbers, I did not find that particularly restrictive, especially given all the other limitations of that version of BASIC, such as no graphics or sound support apart from POKE and SYS. BASIC itself supported lines up to 252 bytes or so, and IIRC the keywords were already tokenized there, but you could not input such long lines on Commodore computers. What in FORTRAN makes single 66-char lines (plus line number) extremely restricted? - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-16 18:55 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <1792176936-5857@newsgrouper.org> |
| In reply to | #118655 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> Thomas Koenig <tkoenig@netcologne.de> writes:
> >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
------------
> What in FORTRAN makes single 66-char lines (plus line number)
> extremely restricted?
You just setup the key-punch so tab skips the first 6 characters
<to the continuation indicator> and have the key-punch eject the
card when you get to character 72.
{{There was a machine where it would punch the sequence number
in col[73-80] so you did not have to worry about that until the
program was in good shape.}}
> - anton
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-10-16 18:57 -0400 |
| Subject | Re: Comment delimiters |
| Message-ID | <1c65dltft4kmmi33gt0cshb2tbhmrari4b@4ax.com> |
| In reply to | #118655 |
On Fri, 16 Oct 2026 17:10:24 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >As for convenience, for various compilers I read that either the >scanner or the parser (or both) were hand-written (I don't remember >which one was more frequent). Scanners. Parser are a lot of work. > It certainly does not seem much work to >write a scanner for a typical programming language by hand (you >recognize keywords by table lookup of things that will be classified >as identifiers if they are not in the table). For the parser of a >language that is not LL(1), it's more work, but writing it by hand >allows you to do various things that, e.g., bison does not support Bison is limited to single (token) lookahead, but since it can backtrack, and also create LR(1), SLR(1), and GLR(1) parsers as well as the (yacc-alike) LALR(1) ... well, I've never actually encountered a situation that Bison couldn't be contorted into handling. [Of course the contortions required can make the grammar feel unnatural.] And Bison doesn't generate lexers (scanners) so they have to be provided separately. >(ANTLR has support for "syntactic predicates" and "semantic >predicates", which probably is good enough for a lot of cases; it was >written with C++ in mind). Again, I've never encountered any situation ANTLR can't handle. ANTLR can generate both parsers and lexers (scanners), and because they are recursive descent they tend to be easier to debug (when necessary) than are Bison/Flex state machines. Early versions of ANTLR were LL(k): you had to specify the maximum lookahead required by any rule in your grammar else the parser would not work correctly [if it could be generated at all]. Starting from version 3, ANTLR became LL(*) which has per-rule lookahead figured out by the tool. LL(*) is easier to use, but its grammars are incompatible with the earlier LL(k) versions. The LL(*) versions support parser AND lexer in a single grammar file, whereas the early versions required them to be separate. Also starting from version 3, ANTLR is written in Java. It can generate code for different target languages (and there are runtime libraries available for the various targets), but the tool itself requires a JVM to execute. Current version is 4.13.2. I keep 2.7.7 around for Windows and Linux specifically because it was NOT written in Java. Being LL(k), it is a bit harder to use, and it targets only C or C++, but AFAIK it is the last version of ANTLR to be available as a simple executable rather than a jar. [I am aware that Java programs (at least theoretically) can be compiled directly to executable. B ut I don't know offhand what Java compilers can do that, and AFAICT nobody has done it for any modern versions of ANTLR. If anybody knows differently, I'm happy to hear that I'm mistaken.]
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-17 04:01 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <11aurud$2b0g$3@gal.iecc.com> |
| In reply to | #118655 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >As for convenience, for various compilers I read that either the >scanner or the parser (or both) were hand-written (I don't remember >which one was more frequent). ... Lexers are usually much slower than parsers because they're O(N) in the number of characters in the source code while parsers are O(N) in the number of tokens the lexer returned. So they're worth some effort to speed up. There are also tools like re2c which turns regular expressions into C code which tends to run a lot faster than the table lookup loop in flex parsers. -- 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-15 15:42 -0400 |
| Subject | Re: Comment delimiters |
| Message-ID | <jwv8q3yycp6.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118633 |
> Given that the original FORTRAN worked on an IBM 704, I think that the > designers made it as easy (and with as little memory) to parse as they > could, given the state of the art at the time. Concerning the points: Indeed, the issue being that the "state of the art" (in terms of parsing knowledge) was very primitive. It's actually in part in response to the painful experience of Fortran that BNF appeared. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-16 12:46 -0400 |
| Subject | Re: Comment delimiters |
| Message-ID | <9ysAS.182538$QPx3.16043@fx17.iad> |
| In reply to | #118633 |
On 2026-Oct-15 02:17, Anton Ertl wrote: > EricP <ThatWouldBeTelling@thevillage.com> writes: >> Old FORTRAN is difficult to parse because >> a) it did not separate the language into lexical and syntax levels >> b) it was white space oblivious except in quoted strings >> c) there were no reserved words - keywords were statement >> position and sometimes semantic context dependent. >> d) statements were based on punch cards BUT because >> continuation cards used the absence of a C in column 6 >> to indicate the start of a new statement, parsers have to >> always look ahead to see in the next card has a C and >> then "unget" the card if not. > > Given that the original FORTRAN worked on an IBM 704, I think that the > designers made it as easy (and with as little memory) to parse as they > could, given the state of the art at the time. Concerning the points: > > a) I guess that the division into lexical and syntax levels had not > been developed at the time; and even later, e.g., Wirth does not > make this distinction in his language definitions, using EBNF down > to the lexical level (although he does define reserved words). > > b) Without this distinction, if you ignore white space at all, you > either ignore it everywhere, or give it a special role in your > syntax. Ignoring is probably simpler. > > c) The programming language community took quite a while until it > arrived at reserved words. E.g., while Algol 60 was specified in > BNF, being modern in that regard, it does not have reserved words, > just symbols that are distinct from all identifiers; i.e., you > could have an identifier like IF in Algol 60, distinct from the > symbol 'IF', and it's up to the implementation how to distinguish > them. Anyway, without a) reserved words make no sense. > > d) Does the original FORTRAN support continuation cards? Yes. Fortran's continuation card is LL(1) and behaves the same as an ISA with start bits - you have to look ahead to find out that you didn't need to look ahead, and unget the card. Statement terminators like ; act like ISA stop bits and don't need lookahead. >> The classic ambiguous parsing example being >> >> DO I = 1,100 >> DOI = 1.100 >> >> depends on the presence or absence of a "naked comma" later in the >> statement to decide whether there is a keyword DO and a variable I, >> or a variable DOI. A "naked comma" is a comma not enclosed inside >> a quoted character or string, or inside a possibly nested parenthesis. > > 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. 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 first thing a Fortran compiler does is scan ahead loading card statements into a card buffer array from the (possibly nested INCLUDE) source files until it sees a non-continue card, which it ungets. Then it checks the format of the cards is ok and extracts things like a label from columns 2:5. Compacting out comments and white space is unnecessary - the hand written lexer knows to skip over them. 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. The parser knows which statement it is working on so can tell the lexer what options it should handle at the point. There could be a post pass over the AST to patch up ambiguous constructs that require semantic context to fix. 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. >> People learned a lot of what not to do in language design >>from old FORTRAN. > > And probably also what to do. Backus was on the Algol-60 committee, > and the B in BNF stands for his name. I would not be surprised if the > structure of the parser in the FORTRAN compiler gave him ideas for > BNF. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-16 17:56 +0000 |
| Subject | Re: Comment delimiters |
| Message-ID | <2026Oct16.195605@mips.complang.tuwien.ac.at> |
| In reply to | #118654 |
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>) >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. - 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 14 of 24 — ← Prev page 1 … 12 13 [14] 15 16 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web