Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111650 > unrolled thread
| Started by | quadibloc <quadibloc@gmail.com> |
|---|---|
| First post | 2025-05-19 19:15 +0000 |
| Last post | 2025-06-19 01:03 +0000 |
| Articles |
20 on this page of 1000+
— 49 participants
Thread has 1028 articles; only the first 1000 are indexed. |
Back to article view | Back to comp.arch | Browse in flat view
Thread has 1028 articles; showing the first 1000 in depth-first order. Use the flat group view to see the rest.
Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-05-19 19:15 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-05-19 21:26 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-05-21 15:07 +0000
Re: Why I've Dropped In David Chmelik <dchmelik@gmail.com> - 2025-05-22 06:51 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-05-22 17:42 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-05-22 18:03 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 12:37 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 13:24 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-26 05:57 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-26 06:14 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-10 21:45 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-10 22:45 -0500
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-08-01 04:42 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-08-01 05:03 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-08-01 18:07 -0500
Re: Why I've Dropped In MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-27 01:01 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 17:19 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 12:16 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 02:11 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-12 11:48 -0700
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-15 17:26 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 08:00 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-10 22:53 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 05:56 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-11 04:42 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 16:37 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-11 14:47 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 19:13 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-12 16:30 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 00:00 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-15 13:21 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-15 18:42 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-15 16:42 -0500
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-11 16:51 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 19:08 +0000
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-11 18:00 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 23:01 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-12 08:38 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 18:44 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-20 05:56 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 19:55 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-11 16:28 -0500
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-12 07:05 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-12 15:27 -0500
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 15:30 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 15:59 +0000
Re: Why I've Dropped In moi <findlaybill@blueyonder.co.uk> - 2025-06-20 17:12 +0100
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 19:46 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-23 16:03 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 14:12 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 16:49 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 17:34 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 19:16 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-14 14:22 -0500
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-16 12:17 -0400
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-17 01:07 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 18:26 -0700
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 17:45 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-17 11:09 -0700
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-17 16:43 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 21:18 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-17 18:14 -0400
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-18 07:31 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-18 11:50 -0400
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-19 08:56 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-18 15:37 -0500
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-18 00:47 -0700
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-18 11:22 -0400
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-19 21:45 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 17:05 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 15:00 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-12 08:44 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 03:09 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-12 20:36 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 06:03 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 11:14 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 08:23 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 17:40 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 10:57 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 18:11 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 18:18 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 18:42 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 20:31 -0700
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-15 15:55 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 11:55 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:15 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 12:17 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 19:44 +0000
Re: base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-15 20:09 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 21:02 -0700
Re: base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 14:37 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 07:55 -0700
Re: base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-16 17:42 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 10:56 -0700
Re: base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 21:52 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 15:04 -0700
Re: base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 18:11 +0000
Re: base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 14:25 +0000
Re: base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 14:45 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 14:39 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-16 02:33 +0000
Re: base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 14:22 +0000
Re: big pages, base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-16 16:42 +0000
Re: big pages, base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 16:52 +0000
Re: Why I've Dropped In Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-06-13 19:49 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 18:37 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 21:09 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 20:27 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 10:48 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 09:45 -0700
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-14 13:56 -0400
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 12:23 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 21:26 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 14:37 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 21:49 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 20:34 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 03:52 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 04:04 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 04:09 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 04:38 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 07:37 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 07:00 -0700
Re: swapping pain, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:39 +0000
Re: swapping pain, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 12:23 -0700
Re: base hackery, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:22 +0000
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-15 09:48 -0400
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 18:51 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 12:33 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 20:06 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 19:29 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 09:55 -0700
Re: more addressing, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-18 18:19 +0000
Re: more addressing, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 12:07 -0700
Re: more addressing, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 06:13 +0000
Re: more addressing, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 23:39 -0700
Re: more addressing, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 07:46 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 13:14 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 11:52 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 08:15 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 19:50 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 13:50 -0700
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 22:01 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 23:10 -0700
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 09:26 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 10:44 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 15:40 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 09:24 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 16:49 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 16:39 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-15 01:07 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-15 07:10 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-15 16:01 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-15 16:53 +0000
Re: static linked libraries, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:54 +0000
Re: Why I've Dropped In Robert Swindells <rjs@fdy2.co.uk> - 2025-06-15 19:24 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 14:15 +0000
Re: static libraries, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:00 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-24 10:47 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 16:56 +0000
Re: Why I've Dropped In Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-06-14 12:42 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 15:53 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 17:02 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 21:19 +0000
Re: fitting programs in Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-14 22:12 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 20:51 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 18:08 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 12:38 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 20:20 +0000
Re: old and slow base and bounds, Why I've Dropped In Al Kossow <aek@bitsavers.org> - 2025-06-15 18:48 -0700
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 10:35 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-18 19:51 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 15:30 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 01:23 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 19:41 -0700
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-19 05:36 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 23:10 -0700
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-19 09:35 -0400
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 15:11 +0000
Re: Fortran, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 18:03 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-19 18:53 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 23:18 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-20 15:13 -0400
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 20:35 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:27 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:09 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:48 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-21 14:57 -0400
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 23:36 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 01:32 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 13:45 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 17:19 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 18:06 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 18:31 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-20 12:27 -0700
Re: emulation, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 20:16 +0000
Re: emulation, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 20:47 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 21:26 +0000
Re: old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-21 14:33 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:34 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 23:57 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 00:06 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 00:13 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-20 23:20 -0700
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 07:40 +0000
Killer Micros (was: old and slow base and bounds) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-21 09:56 +0000
Re: old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-21 14:25 +0000
Re: old and slow base and bounds, Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-21 11:39 -0400
Re: old and slow base and bounds, Why I've Dropped In Vir Campestris <vir.campestris@invalid.invalid> - 2025-06-21 16:50 +0100
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-21 17:59 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-21 18:26 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-21 19:37 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-06-21 20:27 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-21 20:31 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-21 20:36 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-21 14:27 -0700
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-24 09:45 +0200
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-22 06:34 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Andreas Eder <a_eder_muc@web.de> - 2025-06-22 11:52 +0200
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-22 00:55 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Vir Campestris <vir.campestris@invalid.invalid> - 2025-07-01 14:22 +0100
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-07-01 17:39 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-07-01 18:00 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-22 20:23 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Lynn Wheeler <lynn@garlic.com> - 2025-06-22 12:15 -1000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-22 22:44 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-23 09:23 -0400
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-23 20:04 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-23 23:16 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Al Kossow <aek@bitsavers.org> - 2025-06-23 17:02 -0700
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-24 00:25 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-24 00:53 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-24 02:49 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-24 06:21 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-24 09:59 +0200
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-24 06:16 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-24 14:12 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Al Kossow <aek@bitsavers.org> - 2025-06-24 07:43 -0700
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-24 14:53 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-24 14:48 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-24 13:01 -0400
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 17:49 +0000
Re: old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-21 14:36 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 13:37 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 17:52 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-19 19:00 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-20 07:42 -0700
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds John Levine <johnl@taugh.com> - 2025-06-20 18:40 +0000
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-20 17:15 -0400
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 21:30 +0000
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds John Levine <johnl@taugh.com> - 2025-06-21 17:21 +0000
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-21 15:46 -0400
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-21 22:42 -0700
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-24 10:58 -0700
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds John Levine <johnl@taugh.com> - 2025-06-24 19:31 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-19 12:36 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 21:45 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-19 16:05 -0700
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 23:45 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 14:51 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 15:55 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 20:25 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 12:12 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-19 10:32 -0400
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 14:54 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-19 20:36 -0400
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 01:10 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 01:15 +0000
Re: old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-21 12:04 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-21 20:32 +0000
Re: old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-22 01:26 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-22 01:36 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-22 08:57 +0000
Re: linking and sortiing, old and slow base and bounds, John Levine <johnl@taugh.com> - 2025-06-22 17:52 +0000
Re: linking and sortiing, old and slow base and bounds, mitchalsup@aol.com (MitchAlsup1) - 2025-06-22 18:25 +0000
Re: linking and sortiing, old and slow base and bounds, scott@slp53.sl.home (Scott Lurndal) - 2025-06-22 20:29 +0000
Re: tape hacks, linking and sortiing John Levine <johnl@taugh.com> - 2025-06-22 22:44 +0000
Re: linking and sortiing, old and slow base and bounds, Thomas Koenig <tkoenig@netcologne.de> - 2025-06-23 06:07 +0000
Re: linking and sortiing, old and slow base and bounds, quadibloc <quadibloc@gmail.com> - 2025-06-23 09:56 +0000
Re: linking and sortiing, old and slow base and bounds, quadibloc <quadibloc@gmail.com> - 2025-06-23 10:01 +0000
Re: linking and sortiing, old and slow base and bounds, Thomas Koenig <tkoenig@netcologne.de> - 2025-06-23 17:13 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-22 01:31 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 17:00 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-28 23:18 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-07-28 22:56 -0500
Re: Why I've Dropped In MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-26 21:46 +0000
VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-29 08:45 +0000
Re: VAX (was: Why I've Dropped In) John Levine <johnl@taugh.com> - 2025-07-29 16:44 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-30 05:59 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-07-30 04:02 -0500
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-07-30 16:24 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-07-30 13:24 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-01 17:02 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-01 15:24 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-02 15:33 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-02 15:15 -0500
Re: VAX BGB <cr88192@gmail.com> - 2025-08-02 18:55 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 16:33 +0000
Re: VAX MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-25 00:56 +0000
Re: VAX MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-31 18:04 +0000
What is more important MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-09-04 15:23 +0000
Re: What is more important Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-09-04 10:25 -0700
Re: What is more important MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-09-04 21:00 +0000
Re: What is more important BGB <cr88192@gmail.com> - 2025-09-04 16:54 -0500
Re: What is more important anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-05 15:03 +0000
Re: What is more important BGB <cr88192@gmail.com> - 2025-09-05 14:26 -0500
Re: What is more important BGB <cr88192@gmail.com> - 2025-09-05 14:38 -0500
Re: What is more important Robert Finch <robfi680@gmail.com> - 2025-09-05 21:56 -0400
Re: What is more important Thomas Koenig <tkoenig@netcologne.de> - 2025-09-10 13:31 +0000
Re: VAX (was: Why I've Dropped In) Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-07-30 17:17 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-01 17:16 +0000
Re: VAX (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-08-01 18:11 +0000
Re: VAX (was: Why I've Dropped In) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-01 20:41 +0000
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-02 09:07 +0000
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:21 +0000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-02 23:10 -0400
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-03 09:14 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-03 07:41 -0700
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 10:24 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:40 +0000
Re: VAX John Ames <commodorejohn@gmail.com> - 2025-08-04 08:32 -0700
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 11:47 -0500
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 17:20 +0000
Re: 32 vs 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-04 18:17 +0000
Re: 32 vs 64 bits, was VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:17 +0300
Re: 32 vs 64 bits, was VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:36 +0000
Re: 32 vs 64 bits, was VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 20:00 +0000
Re: IBM's 32 vs 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-04 21:04 +0000
Re: IBM's 32 vs 64 bits, was VAX Lynn Wheeler <lynn@garlic.com> - 2025-08-07 07:32 -1000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-04 15:40 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 16:34 +0000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-31 16:43 -0400
Re: VAX Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:26 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-01 06:07 +0000
Re: VAX Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-01 06:57 +0000
Debian on AMD64 (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-01 07:40 +0000
Re: Debian on AMD64 Stefan Monnier <monnier@iro.umontreal.ca> - 2025-09-01 12:15 -0400
Re: Debian on AMD64 BGB <cr88192@gmail.com> - 2025-09-01 11:33 -0500
Re: Debian on AMD64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-01 20:34 +0000
Re: VAX Marco Moock <mm@dorfdsl.de> - 2025-09-21 16:20 +0200
Re: VAX Nuno Silva <nunojsilva@invalid.invalid> - 2025-09-21 15:45 +0100
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-09-21 17:54 +0300
Re: VAX Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-04 14:06 -0700
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 00:21 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 21:51 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:38 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:39 +0000
Re: VAX "Kerr-Mudd, John" <admin@127.0.0.1> - 2025-08-05 09:25 +0100
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-05 17:24 +0200
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-05 15:41 +0000
System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 07:32 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 15:03 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 16:10 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 18:15 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 19:40 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 19:25 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 21:23 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-14 07:58 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-14 13:28 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 15:14 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 15:25 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-14 15:32 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 15:44 +0000
Re: System calls David Brown <david.brown@hesbynett.no> - 2025-08-14 19:15 +0200
Re: System calls Thomas Koenig <tkoenig@netcologne.de> - 2025-08-14 17:43 +0000
Re: System calls David Brown <david.brown@hesbynett.no> - 2025-08-15 17:49 +0200
Re: System calls cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 21:44 +0000
Re: System calls David Brown <david.brown@hesbynett.no> - 2025-08-15 17:49 +0200
Re: System calls cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-15 18:33 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 18:51 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 20:28 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-13 19:35 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 00:49 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 13:48 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:24 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:41 +0000
Re: VAX vallor <vallor@cultnix.org> - 2025-08-05 05:56 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:34 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-01 20:06 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 03:37 +0000
Re: VAX ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2025-08-02 04:14 +0000
Re: VAX "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-01 21:35 -0700
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-02 08:07 +0000
Re: VAX Al Kossow <aek@bitsavers.org> - 2025-08-02 01:48 -0700
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:45 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:08 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-03 16:51 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-04 00:04 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-03 21:07 -0500
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-03 20:39 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-04 04:50 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 12:35 +0300
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 11:59 -0500
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 12:19 +0300
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 12:09 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 14:51 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 18:28 +0300
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-04 09:53 -0700
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 16:58 +0000
Re: VAX "Brian G. Lucas" <bagel99@gmail.com> - 2025-08-05 13:03 -0500
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:03 +0300
Re: VAX James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-04 15:25 -0400
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:40 +0300
Re: VAX "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-04 12:44 -0700
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-04 22:21 -0700
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-05 21:25 +0000
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-05 19:14 -0700
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-06 04:31 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-06 11:48 +0300
Re: VAX James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-06 11:56 -0400
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-05 21:13 +0000
Re: VAX James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-06 11:54 -0400
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-06 13:58 -0700
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-05 21:08 +0000
Re: VAX Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 20:18 +0200
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-17 22:18 -0700
Re: VAX Richard Heathfield <rjh@cpax.org.uk> - 2025-08-18 08:02 +0100
Re: VAX David Brown <david.brown@hesbynett.no> - 2025-08-18 11:34 +0200
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-18 21:57 -0700
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 15:11 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 19:00 +0300
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 19:04 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-04 22:49 +0200
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 00:14 +0300
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 01:43 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-05 17:31 +0200
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 19:49 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-05 22:17 +0200
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-06 00:21 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-06 16:19 +0200
3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-06 20:43 +0300
Re: 3-way long addition Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-07 15:15 +0200
3-way long addition (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-19 05:47 +0000
Re: 3-way long addition (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-19 07:09 +0000
Re: 3-way long addition Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-19 12:11 +0200
Re: 3-way long addition anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-19 17:43 +0000
Re: 3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-19 17:20 +0300
Re: 3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-19 17:24 +0300
Re: 3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-19 23:03 +0300
Re: 3-way long addition Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-20 10:50 +0200
Re: 3-way long addition Michael S <already5chosen@yahoo.com> - 2025-08-20 14:16 +0300
Intel ADX (was: 3-way long addition) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-20 14:08 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 18:25 +0300
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 12:56 -0500
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 14:22 +0000
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-04 16:46 +0200
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 15:05 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 18:07 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 15:32 +0000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-04 15:09 -0400
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:31 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 20:29 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 00:08 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 21:23 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 06:46 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-05 03:14 -0500
Re: VAX Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-05 11:52 -0700
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-06 05:37 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 06:20 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 12:12 -0500
I32LP64 vs. ILP64 (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 11:28 +0000
Re: I32LP64 vs. ILP64 antispam@fricas.org (Waldek Hebisch) - 2025-08-06 15:55 +0000
Re: I32LP64 vs. ILP64 BGB <cr88192@gmail.com> - 2025-08-06 12:47 -0500
Re: I32LP64 vs. ILP64 BGB <cr88192@gmail.com> - 2025-08-06 12:00 -0500
Re: I32LP64 vs. ILP64 (was: VAX) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:34 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 05:38 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 11:05 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-06 12:12 -0500
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 18:22 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 10:32 +0000
Re: 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-06 17:25 +0000
Re: 64 bits, was VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-06 12:11 -0700
Re: individual 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-06 19:50 +0000
Re: individual 64 bits, was VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 20:30 +0000
Re: 64 bits, was VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:36 +0000
Re: 64 bits, was VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-07 15:44 +0200
Re: 64 bits, was VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-07 07:34 -0700
Re: 64 bits, S/360 was VAX John Levine <johnl@taugh.com> - 2025-08-07 20:54 +0000
Re: 64 bits, was VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-08 03:51 +0000
Bit addressing (was: 64 bits) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 14:57 +0000
Re: Bit addressing drb@ihatespam.msu.edu (Dennis Boone) - 2025-08-07 15:54 +0000
Re: Bit addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-07 13:01 -0700
Re: Bit addressing (was: 64 bits) Al Kossow <aek@bitsavers.org> - 2025-08-07 13:34 -0700
Re: VAX Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-08-06 23:12 +0000
Re: VAX John Levine <johnl@taugh.com> - 2025-08-06 23:15 +0000
Re: VAX Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-08-06 23:32 +0000
Re: word lengths in C, was VAX John Levine <johnl@taugh.com> - 2025-08-07 02:56 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 11:21 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-07 13:34 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:38 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 12:42 +0300
Re: VAX Al Kossow <aek@bitsavers.org> - 2025-08-04 03:32 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 05:37 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 13:42 +0000
Re: VAX Andy Burns <usenet@andyburns.uk> - 2025-08-04 16:50 +0100
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:52 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 05:35 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-05 01:31 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-05 13:46 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-05 17:21 +0000
ILP32 code on 64-bit substrate (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-12 15:28 +0000
Re: ILP32 code on 64-bit substrate (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-12 16:08 +0000
Re: ILP32 code on 64-bit substrate BGB <cr88192@gmail.com> - 2025-08-12 11:53 -0500
Re: ILP32 code on 64-bit substrate aph@littlepinkcloud.invalid - 2025-08-12 17:57 +0000
Re: ILP32 code on 64-bit substrate John Levine <johnl@taugh.com> - 2025-08-12 19:09 +0000
Re: ILP32 code on 64-bit substrate OrangeFish <OrangeFish@invalid.invalid> - 2025-08-15 11:42 -0400
Re: ILP32 code on 64-bit substrate anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 06:11 +0000
Re: ILP32 code on 64-bit substrate scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 14:24 +0000
Re: ILP32 code on 64-bit substrate anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 18:13 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-02 09:28 +0000
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-02 15:29 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-02 15:33 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:17 +0000
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:20 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 17:23 +0000
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 18:16 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-04 14:39 -0400
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 19:59 +0000
Re: VAX (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 18:59 +0000
Re: VAX (was: Why I've Dropped In) Michael S <already5chosen@yahoo.com> - 2025-08-04 22:12 +0300
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 20:13 +0000
Re: VAX (was: Why I've Dropped In) Michael S <already5chosen@yahoo.com> - 2025-08-04 23:54 +0300
Re: VAX (was: Why I've Dropped In) Al Kossow <aek@bitsavers.org> - 2025-08-04 14:41 -0700
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 17:18 -0500
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:53 +0000
Re: VAX "Brian G. Lucas" <bagel99@gmail.com> - 2025-08-05 13:04 -0500
O.T. Where is Mitch? Was: VAX Michael S <already5chosen@yahoo.com> - 2025-08-07 23:48 +0300
Re: O.T. Where is Mitch? Was: VAX "Brian G. Lucas" <bagel99@gmail.com> - 2025-08-07 16:01 -0500
Re: O.T. Where is Mitch? Was: VAX BGB <cr88192@gmail.com> - 2025-08-08 01:41 -0500
Re: O.T. Where is Mitch? Was: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-08 11:58 +0200
Re: O.T. Where is Mitch? Was: VAX Michael S <already5chosen@yahoo.com> - 2025-08-08 13:20 +0300
Re: O.T. Where is Mitch? Was: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-08 14:22 +0000
Re: O.T. Where is Mitch? Was: VAX Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-08-08 18:34 +0300
Re: O.T. Where is Mitch? Was: VAX George Neuner <gneuner2@comcast.net> - 2025-08-08 19:07 -0400
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-05 21:01 +0000
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 00:59 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-05 20:15 -0700
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-06 05:50 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 07:28 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-06 10:48 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-06 16:35 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-08 01:57 +0000
Re: VAX (was: Why I've Dropped In) John Ames <commodorejohn@gmail.com> - 2025-08-06 08:28 -0700
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:45 +0000
Re: VAX (was: Why I've Dropped In) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-08-07 01:49 +0000
Re: VAX (was: Why I've Dropped In) John Ames <commodorejohn@gmail.com> - 2025-08-07 08:28 -0700
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 09:37 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 08:22 +0000
Re: VAX (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 14:26 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 17:50 +0000
Re: VAX drb@ihatespam.msu.edu (Dennis Boone) - 2025-08-14 17:12 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-14 15:22 -0400
Re: VAX Al Kossow <aek@bitsavers.org> - 2025-08-14 12:59 -0700
Re: VAX (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 14:44 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 17:46 +0000
Re: VAX (was: Why I've Dropped In) ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2025-08-13 18:26 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-13 12:09 -0700
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:47 +0000
Re: VAX (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-08-05 13:58 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 16:47 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-06 12:12 -0700
Re: VAX Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-08-07 01:36 +0000
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-07 05:29 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-07 07:26 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-08 03:57 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-08 11:43 +0300
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 14:00 +0000
Re: VAX (was: Why I've Dropped In) Al Kossow <aek@bitsavers.org> - 2025-08-06 10:20 -0700
Re: VAX (was: Why I've Dropped In) Robert Swindells <rjs@fdy2.co.uk> - 2025-08-06 22:30 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-06 20:21 -0400
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-07 02:22 +0000
Re: VAX John Ames <commodorejohn@gmail.com> - 2025-08-07 08:38 -0700
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-07 17:52 +0200
Re: VAX George Neuner <gneuner2@comcast.net> - 2025-08-07 21:53 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-08 06:16 +0000
Re: VAX George Neuner <gneuner2@comcast.net> - 2025-08-08 19:48 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 10:27 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-07 11:06 +0000
Re: VAX (was: Why I've Dropped In) Al Kossow <aek@bitsavers.org> - 2025-08-04 12:27 -0700
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:46 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 16:21 +0000
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:43 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-01 23:41 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-03 16:42 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-05 00:55 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-05 05:44 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-12 15:02 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-13 14:40 -0400
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-15 03:20 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-15 15:10 +0000
Re: VAX pages John Levine <johnl@taugh.com> - 2025-08-15 16:53 +0000
Re: VAX pages BGB <cr88192@gmail.com> - 2025-08-15 13:19 -0500
Re: VAX pages Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-15 12:03 -0700
Re: VAX pages scott@slp53.sl.home (Scott Lurndal) - 2025-08-15 19:19 +0000
Re: VAX and other pages John Levine <johnl@taugh.com> - 2025-08-15 20:40 +0000
Re: VAX and other pages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-15 21:22 +0000
Re: VAX and other pages John Levine <johnl@taugh.com> - 2025-08-16 01:22 +0000
Re: VAX and other pages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-16 05:09 +0000
Re: VAX and other pages Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-16 10:00 -0700
Re: VAX and other pages John Levine <johnl@taugh.com> - 2025-08-16 17:06 +0000
Re: VAX and other pages antispam@fricas.org (Waldek Hebisch) - 2025-08-20 01:49 +0000
Re: VAX and other pages John Levine <johnl@taugh.com> - 2025-08-20 02:49 +0000
Re: VAX pages BGB <cr88192@gmail.com> - 2025-08-16 03:17 -0500
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-07-31 04:26 +0000
Re: VAX John Levine <johnl@taugh.com> - 2025-07-31 16:05 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-07-31 19:01 +0000
Re: VAX John Levine <johnl@taugh.com> - 2025-07-31 19:57 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-07-31 21:24 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-01 02:18 +0000
Re: VAX encoding John Levine <johnl@taugh.com> - 2025-08-01 15:30 +0000
Re: VAX encoding antispam@fricas.org (Waldek Hebisch) - 2025-08-01 18:08 +0000
Re: VAX encoding scott@slp53.sl.home (Scott Lurndal) - 2025-08-01 18:33 +0000
Re: VAX encoding antispam@fricas.org (Waldek Hebisch) - 2025-08-01 21:24 +0000
Re: VAX encoding Thomas Koenig <tkoenig@netcologne.de> - 2025-08-01 19:13 +0000
Re: VAX encoding MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-28 15:10 +0000
Re: VAX encoding EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-29 10:34 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-02 09:02 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-05 01:43 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-05 05:48 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-05 14:13 +0000
Re: VAX George Neuner <gneuner2@comcast.net> - 2025-08-05 17:41 -0400
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-06 10:23 -0400
Re: VAX George Neuner <gneuner2@comcast.net> - 2025-08-08 21:43 -0400
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-05 13:56 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-05 16:44 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-06 05:53 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-06 11:10 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-06 20:06 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-06 17:00 -0400
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 21:14 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 11:59 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-07 15:03 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-06 17:57 -0400
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-07 11:29 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 11:38 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-16 15:26 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-17 06:16 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-17 11:29 -0500
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-17 10:00 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-17 15:21 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-17 19:10 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-17 15:08 -0500
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-18 11:03 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-18 15:35 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-18 17:19 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-20 14:36 -0400
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-20 16:41 -0400
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-21 16:21 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-17 12:53 -0500
Re: VAX Robert Swindells <rjs@fdy2.co.uk> - 2025-08-06 23:43 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 10:47 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-08 10:08 -0400
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-09 08:07 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-09 10:03 -0400
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-09 20:54 +0000
Re: VAX Al Kossow <aek@bitsavers.org> - 2025-08-09 14:57 -0700
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-13 14:18 -0400
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-13 20:23 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-17 13:35 -0400
Re: VAX BGB <cr88192@gmail.com> - 2025-08-17 18:56 -0500
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-20 19:17 -0400
Re: VAX BGB <cr88192@gmail.com> - 2025-08-20 23:50 -0500
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-06 20:41 -0400
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-07 11:16 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-09 09:04 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-09 10:00 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-10 12:06 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-10 15:18 +0000
Re: byte me, PDP-10 edition, was VAX John Levine <johnl@taugh.com> - 2025-08-10 19:55 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-11 08:17 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-11 14:51 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-11 17:27 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-10 21:01 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 11:25 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-15 05:07 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-15 12:57 +0000
Re: VAX Robert Swindells <rjs@fdy2.co.uk> - 2025-08-15 13:36 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-18 05:48 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-05 20:34 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-12 15:59 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-20 03:47 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-21 19:26 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-22 16:36 +0000
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-22 17:21 +0000
Re: VAX John Levine <johnl@taugh.com> - 2025-08-22 16:45 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-23 16:38 +0000
Re: 360/91, was VAX John Levine <johnl@taugh.com> - 2025-08-23 19:36 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-01 17:25 +0000
Re: VAX MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-27 00:56 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-28 07:49 +0000
Re: VAX (was: Why I've Dropped In) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-27 00:35 +0000
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-27 05:12 +0000
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-27 10:56 -0400
Re: VAX EricP <ThatWouldBeTelling@thevillage.com> - 2025-08-28 13:39 -0400
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-27 17:19 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 17:30 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 18:39 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 17:42 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 11:00 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 16:04 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 16:12 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 16:50 +0000
Re: base registers and addres size, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-14 22:02 +0000
Re: base registers and addres size, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 22:58 +0000
Re: base registers and addres size, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 01:08 +0000
Re: Why I've Dropped In Lynn Wheeler <lynn@garlic.com> - 2025-06-17 16:47 -1000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-18 13:48 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-13 17:52 -0500
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 04:04 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 10:45 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-11 17:33 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 18:14 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 12:30 -0700
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 12:31 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 02:17 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-12 11:55 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 03:30 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 20:40 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-15 16:56 -0700
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 21:26 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-12 06:30 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 07:57 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 14:06 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-12 13:43 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-13 07:31 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 14:48 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-13 15:38 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 17:10 +0000
Re: Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-17 11:44 +0000
Re: Why I've Dropped In David Brown <david.brown@hesbynett.no> - 2025-06-17 16:00 +0200
Code density (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-17 14:17 +0000
Re: Code density (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-06-17 15:11 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 18:01 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-17 23:55 -0400
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-18 06:22 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-18 09:32 -0400
Re: Code density "Kerr-Mudd, John" <admin@127.0.0.1> - 2025-06-18 16:19 +0100
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-18 18:27 +0000
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-19 09:21 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-22 10:05 -0400
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-22 17:35 +0000
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-06-22 20:26 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-26 01:12 +0000
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-06-26 15:17 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-27 07:48 -0400
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-27 08:33 -0400
Re: Code density Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-27 22:41 -0700
Re: Code density Thomas Koenig <tkoenig@netcologne.de> - 2025-06-28 07:45 +0000
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-28 11:11 +0000
Re: Code density Thomas Koenig <tkoenig@netcologne.de> - 2025-06-28 12:00 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-28 16:01 +0000
Re: Code density Thomas Koenig <tkoenig@netcologne.de> - 2025-06-29 14:54 +0000
Re: Code density Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-29 18:01 +0200
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-29 20:50 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-29 13:21 -0400
Re: Code density Thomas Koenig <tkoenig@netcologne.de> - 2025-06-29 20:41 +0000
Re: Code density George Neuner <gneuner2@comcast.net> - 2025-06-28 08:05 -0400
Re: Code density "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-28 21:29 -0700
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-06-27 13:55 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-27 15:09 -0400
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-06-27 21:01 +0000
Re: Code density Thomas Koenig <tkoenig@netcologne.de> - 2025-06-28 09:07 +0000
Re: Code density John Levine <johnl@taugh.com> - 2025-06-28 16:30 +0000
Re: errno, Code density John Levine <johnl@taugh.com> - 2025-06-27 21:44 +0000
Re: errno, Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-29 14:02 -0400
Re: errno, Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-30 06:21 +0000
Re: errno, Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-30 12:51 -0400
Re: errno, Code density scott@slp53.sl.home (Scott Lurndal) - 2025-06-30 17:13 +0000
Re: errno, Code density Michael S <already5chosen@yahoo.com> - 2025-07-01 13:11 +0300
Re: errno, Code density scott@slp53.sl.home (Scott Lurndal) - 2025-07-01 13:18 +0000
Re: errno, Code density Michael S <already5chosen@yahoo.com> - 2025-07-01 16:21 +0300
Re: errno, Code density Michael S <already5chosen@yahoo.com> - 2025-07-01 16:28 +0300
Re: errno, Code density scott@slp53.sl.home (Scott Lurndal) - 2025-07-01 14:08 +0000
Re: errno, Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-01 11:09 -0400
Re: assemblers, errno, Code density John Levine <johnl@taugh.com> - 2025-07-01 17:41 +0000
Re: errno, Code density mitchalsup@aol.com (MitchAlsup1) - 2025-06-30 17:11 +0000
Re: errno, Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-02 08:06 -0400
Re: errno, Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-02 15:38 +0000
Re: errno, Code density Michael S <already5chosen@yahoo.com> - 2025-06-30 13:55 +0300
Re: Code density George Neuner <gneuner2@comcast.net> - 2025-06-28 07:02 -0400
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-30 16:08 +0000
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-01 16:08 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-01 20:03 +0000
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-07-01 21:07 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-01 23:20 +0000
Re: Code density John Levine <johnl@taugh.com> - 2025-07-02 17:14 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-02 15:38 -0400
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-03 08:41 -0400
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 01:18 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-18 13:23 -0400
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-18 19:54 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-20 13:05 -0400
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-20 17:33 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-20 20:09 +0000
Re: compacting branches, was Code density John Levine <johnl@taugh.com> - 2025-07-21 09:01 +0000
Re: compacting branches, was Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-21 12:33 +0000
Re: compacting branches, was Code density Terje Mathisen <terje.mathisen@tmsw.no> - 2025-07-21 17:01 +0200
Re: compacting branches, was Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-21 15:26 +0000
Re: compacting branches, was Code density Terje Mathisen <terje.mathisen@tmsw.no> - 2025-07-21 18:06 +0200
Re: compacting branches, was Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-21 17:26 +0000
Re: compacting branches, was Code density Terje Mathisen <terje.mathisen@tmsw.no> - 2025-07-21 19:31 +0200
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-21 10:50 -0400
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-21 15:28 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-21 17:08 -0400
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-02 05:25 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-01 21:49 +0000
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-07-01 23:26 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-02 00:04 +0000
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-02 05:18 +0000
Re: Code density EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-02 11:20 -0400
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-02 15:45 +0000
Re: Code density scott@slp53.sl.home (Scott Lurndal) - 2025-07-02 16:56 +0000
Re: Code density mitchalsup@aol.com (MitchAlsup1) - 2025-07-02 17:06 +0000
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-18 06:26 +0000
Re: Code density BGB <cr88192@gmail.com> - 2025-07-01 01:16 -0500
Re: Code density anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-01 15:23 +0000
Re: Code density BGB <cr88192@gmail.com> - 2025-07-01 10:53 -0500
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-11 14:56 -0400
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 19:37 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 19:01 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 20:12 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 20:50 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 21:17 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-11 21:35 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 23:13 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-12 13:41 +0000
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-12 09:38 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 19:19 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-12 12:25 -0700
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-12 12:27 -0700
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-13 07:03 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 20:01 +0000
Re: Why I've Dropped In Robert Finch <robfi680@gmail.com> - 2025-06-14 04:35 -0400
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 15:22 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 17:30 +0000
Re: Why I've Dropped In Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-20 17:11 +0200
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-20 12:43 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 17:38 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-20 13:48 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 20:46 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-20 18:13 -0400
Re: Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-21 01:48 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-21 02:51 +0000
Re: Why I've Dropped In Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-24 08:15 +0200
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-12 12:06 -0700
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-12 09:12 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 18:55 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 20:50 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 15:29 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 17:22 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-23 03:43 +0000
The Third Wish quadibloc <quadibloc@gmail.com> - 2025-06-23 12:43 +0000
Re: The Third Wish quadibloc <quadibloc@gmail.com> - 2025-06-23 12:47 +0000
Re: The Third Wish quadibloc <quadibloc@gmail.com> - 2025-06-24 17:19 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-06-24 21:57 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-06-25 07:31 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-06-27 05:28 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-02 05:16 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-02 07:04 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-03 05:52 +0000
Re: The Third Wish Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-02 22:57 -0700
Re: The Third Wish Thomas Koenig <tkoenig@netcologne.de> - 2025-07-03 06:59 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-03 09:43 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-03 11:24 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-03 11:35 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 01:11 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 01:08 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 18:22 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 23:36 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 23:58 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 03:42 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 04:01 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 04:10 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 04:24 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 15:16 +0000
Register windows (was: The Third Wish) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-07-17 12:20 -0400
Re: Register windows mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 16:53 +0000
Re: Register windows (was: The Third Wish) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-17 17:38 +0000
Re: Register windows (was: The Third Wish) scott@slp53.sl.home (Scott Lurndal) - 2025-07-17 19:17 +0000
Re: Register windows mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 19:38 +0000
Re: Register windows Stefan Monnier <monnier@iro.umontreal.ca> - 2025-07-17 16:18 -0400
Re: Register windows Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-07-18 18:11 +0300
Re: Register windows Stefan Monnier <monnier@iro.umontreal.ca> - 2025-07-18 11:29 -0400
Re: Register windows Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-07-18 23:17 +0300
Re: Register windows mitchalsup@aol.com (MitchAlsup1) - 2025-07-20 17:28 +0000
Re: Register windows George Neuner <gneuner2@comcast.net> - 2025-07-20 22:27 -0400
Re: Register windows Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-07-21 12:11 +0300
Re: Register windows John Savard <quadibloc@invalid.invalid> - 2025-07-21 15:42 +0000
Re: Register windows MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-21 21:48 +0000
Re: Register windows Thomas Koenig <tkoenig@netcologne.de> - 2025-08-23 08:51 +0000
Re: Register windows Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-29 17:07 -0400
Re: Register windows BGB <cr88192@gmail.com> - 2025-08-30 01:47 -0500
Re: Register windows antispam@fricas.org (Waldek Hebisch) - 2025-08-30 15:36 +0000
Re: Register windows BGB <cr88192@gmail.com> - 2025-08-30 13:19 -0500
Re: Register windows Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-30 14:22 -0400
Re: Register windows BGB <cr88192@gmail.com> - 2025-08-30 13:46 -0500
Re: Register windows MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-31 16:21 +0000
Re: Register windows Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 17:47 +0000
Re: Register windows MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-09-12 19:02 +0000
Re: Register windows scott@slp53.sl.home (Scott Lurndal) - 2025-09-14 15:16 +0000
Re: Register windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-17 05:55 +0000
Re: Register windows scott@slp53.sl.home (Scott Lurndal) - 2025-09-17 13:58 +0000
Re: Register windows anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-31 05:36 +0000
Where's Ivan was Re: Register windows Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-20 22:27 -0700
Re: Where's Ivan was Re: Register windows John Savard <quadibloc@invalid.invalid> - 2025-07-21 15:45 +0000
Re: Where's Ivan was Re: Register windows Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-21 12:05 -0700
Re: Where's Ivan was Re: Register windows scott@slp53.sl.home (Scott Lurndal) - 2025-07-21 19:56 +0000
Re: Where's Ivan was Re: Register windows Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-21 22:02 -0700
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 15:02 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 14:59 +0000
Re: The Third Wish anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-17 16:28 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 19:21 +0000
Re: The Third Wish EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-18 12:29 -0400
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 14:49 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 18:03 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 18:27 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 20:04 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 21:00 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 21:26 +0000
Re: The Third Wish Thomas Koenig <tkoenig@netcologne.de> - 2025-07-18 19:47 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-19 02:51 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 21:29 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 21:45 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 21:58 +0000
Re: The Third Wish antispam@fricas.org (Waldek Hebisch) - 2025-07-18 15:39 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-18 17:08 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-18 19:38 +0000
Re: The Third Wish Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-17 12:20 -0700
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 19:52 +0000
PRF size (was: The Third Wish) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-07-17 16:34 -0400
Re: PRF size mitchalsup@aol.com (MitchAlsup1) - 2025-07-17 21:38 +0000
Re: PRF size EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-20 11:47 -0400
Re: PRF size mitchalsup@aol.com (MitchAlsup1) - 2025-07-20 17:34 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-17 20:32 +0000
Re: The Third Wish Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-17 21:35 -0700
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-18 11:18 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-18 11:28 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-18 11:33 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-18 15:12 +0000
Re: The Third Wish Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-18 08:46 -0700
Re: The Third Wish scott@slp53.sl.home (Scott Lurndal) - 2025-07-18 16:25 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-18 17:14 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-18 19:39 +0000
Re: The Third Wish anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-18 16:24 +0000
Re: The Third Wish Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-07-18 11:40 -0700
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-18 19:45 +0000
Re: The Third Wish EricP <ThatWouldBeTelling@thevillage.com> - 2025-07-18 14:07 -0400
Re: The Third Wish antispam@fricas.org (Waldek Hebisch) - 2025-07-18 16:10 +0000
Re: The Third Wish anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-17 17:06 +0000
Re: The Third Wish antispam@fricas.org (Waldek Hebisch) - 2025-07-18 16:37 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 18:09 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-15 22:24 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 00:00 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 00:22 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 01:49 +0000
Re: The Third Wish Thomas Koenig <tkoenig@netcologne.de> - 2025-07-16 17:33 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 23:24 +0000
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 23:26 +0000
Re: The Third Wish mitchalsup@aol.com (MitchAlsup1) - 2025-07-16 18:06 +0000
Re: The Third Wish "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-07-16 14:55 -0700
Re: The Third Wish John Savard <quadibloc@invalid.invalid> - 2025-07-16 12:26 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 10:43 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-22 04:30 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-22 16:29 +0000
Satisfaction John Savard <quadibloc@invalid.invalid> - 2025-07-24 11:07 +0000
Re: Satisfaction John Savard <quadibloc@invalid.invalid> - 2025-07-24 16:45 +0000
Re: Satisfaction John Savard <quadibloc@invalid.invalid> - 2025-07-24 20:04 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 03:46 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 15:38 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 19:24 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 00:11 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-16 17:14 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-16 23:37 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-17 01:20 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 17:41 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-17 17:59 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-17 14:04 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 21:19 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-18 01:16 -0500
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-17 23:35 -0700
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-18 02:10 -0500
Re: Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-25 22:24 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-25 23:00 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-18 16:09 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-17 12:45 -0700
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-08-01 04:31 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-17 16:51 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 21:11 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-18 06:58 +0000
Re: Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-18 14:45 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-17 01:28 -0500
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-17 12:58 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-17 13:12 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 17:52 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-17 18:14 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-18 14:10 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-18 15:14 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-18 18:16 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-18 22:00 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-18 23:20 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 01:03 +0000
Page 19 of 50 — ← Prev page 1 … 17 18 [19] 20 21 … 50 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-08-14 15:32 +0000 |
| Subject | Re: System calls (was: VAX) |
| Message-ID | <sknnQ.168942$Bui1.63359@fx10.iad> |
| In reply to | #113135 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <2025Aug13.232334@mips.complang.tuwien.ac.at>, >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>In article <2025Aug13.181010@mips.complang.tuwien.ac.at>, >>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>For lseek(2): >>>> >>>>| Upon successful completion, lseek() returns the resulting offset >>>>| location as measured in bytes from the beginning of the file. >>>> >>>>Given that off_t is signed, lseek(2) can only return positive values. >>> >>>This is incorrect; or rather, it's accidentally correct now, but >>>was not previously. The 1990 POSIX standard did not explicitly >>>forbid a file that was so large that the offset couldn't >>>overflow, hence why in 1990 POSIX you have to be careful about >>>error handling when using `lseek`. >>> >>>It is true that POSIX 2024 _does_ prohibit seeking so far that >>>the offset would become negative, however. >> >>I don't think that this is accidental. In 1990 signed overlow had >>reliable behaviour on common 2s-complement hardware with the C >>compilers of the day. > >This is simply not true. If anything, there was more variety of >hardware supported by C90, and some of those systems were 1's >complement or sign/mag, not 2's complement. Consequently, >signed integer overflow has _always_ had undefined behavior in >ANSI/ISO C. Both Burroughs Large Systems (48-bit stack machine) and the Sperry 1100/2200 (36-bit) systems had (have, in emulation today) C compilers.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-14 15:44 +0000 |
| Subject | Re: System calls (was: VAX) |
| Message-ID | <107l092$r4t$1@reader1.panix.com> |
| In reply to | #113137 |
In article <sknnQ.168942$Bui1.63359@fx10.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <2025Aug13.232334@mips.complang.tuwien.ac.at>, >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>>In article <2025Aug13.181010@mips.complang.tuwien.ac.at>, >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>For lseek(2): >>>>> >>>>>| Upon successful completion, lseek() returns the resulting offset >>>>>| location as measured in bytes from the beginning of the file. >>>>> >>>>>Given that off_t is signed, lseek(2) can only return positive values. >>>> >>>>This is incorrect; or rather, it's accidentally correct now, but >>>>was not previously. The 1990 POSIX standard did not explicitly >>>>forbid a file that was so large that the offset couldn't >>>>overflow, hence why in 1990 POSIX you have to be careful about >>>>error handling when using `lseek`. >>>> >>>>It is true that POSIX 2024 _does_ prohibit seeking so far that >>>>the offset would become negative, however. >>> >>>I don't think that this is accidental. In 1990 signed overlow had >>>reliable behaviour on common 2s-complement hardware with the C >>>compilers of the day. >> >>This is simply not true. If anything, there was more variety of >>hardware supported by C90, and some of those systems were 1's >>complement or sign/mag, not 2's complement. Consequently, >>signed integer overflow has _always_ had undefined behavior in >>ANSI/ISO C. > >Both Burroughs Large Systems (48-bit stack machine) and the >Sperry 1100/2200 (36-bit) systems had (have, in emulation today) >C compilers. Yup. The 1100-series machines were (are) 1's complement. Those are the ones I usually think of when cursing that signed integer overflow is UB in C. I don't think anyone is compiling C23 code for those machines, but back in the late 1980s, they were still enough of a going concern that they could influence the emerginc C standard. Not so much anymore. Regardless, signed integer overflow remains UB in the current C standard, nevermind definitionally following 2s complement semantics. Usually this is done on the basis of performance arguments: some seemingly-important loop optimizations can be made if the compiler can assert that overflow Cannot Happen. And of course, even today, C still targets oddball platforms like DSPs and custom chips, where assumptions about the ubiquity of 2's comp may not hold. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-08-14 19:15 +0200 |
| Subject | Re: System calls |
| Message-ID | <107l5ju$k78a$1@dont-email.me> |
| In reply to | #113138 |
On 14.08.2025 17:44, Dan Cross wrote: > In article <sknnQ.168942$Bui1.63359@fx10.iad>, > Scott Lurndal <slp53@pacbell.net> wrote: >> Both Burroughs Large Systems (48-bit stack machine) and the >> Sperry 1100/2200 (36-bit) systems had (have, in emulation today) >> C compilers. > > Yup. The 1100-series machines were (are) 1's complement. Those > are the ones I usually think of when cursing that signed integer > overflow is UB in C. > > I don't think anyone is compiling C23 code for those machines, > but back in the late 1980s, they were still enough of a going > concern that they could influence the emerginc C standard. Not > so much anymore. > They would presumably have been part of the justification for supporting multiple signed integer formats at the time. UB on signed integer arithmetic overflow is a different matter altogether. > Regardless, signed integer overflow remains UB in the current C > standard, nevermind definitionally following 2s complement > semantics. Usually this is done on the basis of performance > arguments: some seemingly-important loop optimizations can be > made if the compiler can assert that overflow Cannot Happen. > The justification for "signed integer arithmetic overflow is UB" is in the C standards 6.5p5 under "Expressions" : """ If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined. """ It actually has absolutely nothing to do with signed integer representation, or machine hardware. It doesn't even have much to do with integers at all. It is simply that if the calculation can't give a correct answer, then then the C standards don't say anything about the results or effects. The point is that there when the results of an integer computation are too big, there is no way to get the correct answer in the types used. Two's complement wrapping is /not/ correct. If you add two real-world positive integers, you don't get a negative integer. > And of course, even today, C still targets oddball platforms > like DSPs and custom chips, where assumptions about the ubiquity > of 2's comp may not hold. > Modern C and C++ standards have dropped support for signed integer representation other than two's complement, because they are not in use in any modern hardware (including any DSP's) - at least, not for general-purpose integers. Both committees have consistently voted to keep overflow as UB.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-08-14 17:43 +0000 |
| Subject | Re: System calls |
| Message-ID | <107l78m$ko4o$1@dont-email.me> |
| In reply to | #113140 |
David Brown <david.brown@hesbynett.no> schrieb: > The point is that there when the results of an integer computation are > too big, there is no way to get the correct answer in the types used. > Two's complement wrapping is /not/ correct. If you add two real-world > positive integers, you don't get a negative integer. I believe it was you who wrote "If you add enough apples to a pile, the number of apples becomes negative", so there is clerly a defined physical meaning to overflow. :-) -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-08-15 17:49 +0200 |
| Subject | Re: System calls |
| Message-ID | <107nkv6$1753a$2@dont-email.me> |
| In reply to | #113141 |
On 14.08.2025 19:43, Thomas Koenig wrote: > David Brown <david.brown@hesbynett.no> schrieb: > >> The point is that there when the results of an integer computation are >> too big, there is no way to get the correct answer in the types used. >> Two's complement wrapping is /not/ correct. If you add two real-world >> positive integers, you don't get a negative integer. > > I believe it was you who wrote "If you add enough apples to a > pile, the number of apples becomes negative", so there is > clerly a defined physical meaning to overflow. > > :-) Yes, I did say something along those lines - but perhaps not /exactly/ those words!
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-14 21:44 +0000 |
| Subject | Re: System calls |
| Message-ID | <107llca$c9c$1@reader1.panix.com> |
| In reply to | #113140 |
In article <107l5ju$k78a$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 14.08.2025 17:44, Dan Cross wrote: >> In article <sknnQ.168942$Bui1.63359@fx10.iad>, >> Scott Lurndal <slp53@pacbell.net> wrote: >>> Both Burroughs Large Systems (48-bit stack machine) and the >>> Sperry 1100/2200 (36-bit) systems had (have, in emulation today) >>> C compilers. >> >> Yup. The 1100-series machines were (are) 1's complement. Those >> are the ones I usually think of when cursing that signed integer >> overflow is UB in C. >> >> I don't think anyone is compiling C23 code for those machines, >> but back in the late 1980s, they were still enough of a going >> concern that they could influence the emerginc C standard. Not >> so much anymore. > >They would presumably have been part of the justification for supporting >multiple signed integer formats at the time. C90 doesn't have much to say about this at all, other than saying that the actual representation and ranges of the integer types are implementation defined (G.3.5 para 1). C90 does say that, "The representations of integral types shall define values by use of a pure binary numeration system" (sec 6.1.2.5). C99 tightens this up and talks about 2's comp, 1's comp, and sign/mag as being the permissible representations (J.3.5, para 1). >UB on signed integer >arithmetic overflow is a different matter altogether. I disagree. >> Regardless, signed integer overflow remains UB in the current C >> standard, nevermind definitionally following 2s complement >> semantics. Usually this is done on the basis of performance >> arguments: some seemingly-important loop optimizations can be >> made if the compiler can assert that overflow Cannot Happen. > >The justification for "signed integer arithmetic overflow is UB" is in >the C standards 6.5p5 under "Expressions" : Not in ANSI/ISO 9899-1990. In that revision of the standard, sec 6.5 covers declarations. >""" >If an exceptional condition occurs during the evaluation of an >expression (that is, if the result is not mathematically defined or not >in the range of representable values for its type), the behavior is >undefined. >""" In C90, this language appears in sec 6.3 para 5. Note, however, that they do not define what an exception _is_, only a few things that _may_ cause one. See below. >It actually has absolutely nothing to do with signed integer >representation, or machine hardware. Consider this language from the (non-normative) example 4 in sec 5.1.2.3: |On a machine in which overflows produce an exception and in |which the range of values representable by an *int* is |[-32768,+32767], the implementation cannot rewrite this |expression as [continues with the specifics of the example].... That seems pretty clear that they're thinking about machines that actually generate a hardware trap of some kind on overflow. >It doesn't even have much to do >with integers at all. It is simply that if the calculation can't give a >correct answer, then then the C standards don't say anything about the >results or effects. > >The point is that there when the results of an integer computation are >too big, there is no way to get the correct answer in the types used. >Two's complement wrapping is /not/ correct. If you add two real-world >positive integers, you don't get a negative integer. Sorry, but I don't buy this argument as anything other than a justification after the fact. We're talking about history and motivation here, not the behavior described in the standard. In particular, C is a programming language for actual machines, not a mathematical notation; the language is free to define the behavior of arithmetic expressions in any way it chooses, though one presumes it would do so in a way that makes sense for the machines that it targets. Thus, it could have formalized the result of signed integer overflow to follow 2's complement semantics had the committee so chosen, in which case the result would not be "incorrect", it would be well-defined with respect to the semantics of the language. Java, for example, does this, as does C11 (and later) atomic integer operations. Indeed, the C99 rationale document makes frequent reference to twos complement, where overflow and modular behavior are frequently equivalent, being the common case. But aside from the more recent atomics support, C _chose_ not to do this. Also, consider that _unsigned_ arithmetic is defined as having wrap-around semantics similar to modular arithmetic, and thus incapable of overflow. But that's simply a fiction invented for the abstract machine described informally in the standard: it requires special handling one machines like the 1100 series, because those machines might trap on overflow. The C committee could just as well have said that the unsigned arithmetic _could_ overflow and that the result was UB. So why did C chose this way? The only logical reason is that there were machines at the time that where a) integer overflow caused machine exceptions, and b) the representation of signed integers was not well-defined, so that the actual value resulting from overflow could not be rigorously defined. Given that C90 mandated a binary representation for integers and so the representation of of unsigned integers is basically common, there was no need to do that for unsigned arithmetic. >> And of course, even today, C still targets oddball platforms >> like DSPs and custom chips, where assumptions about the ubiquity >> of 2's comp may not hold. > >Modern C and C++ standards have dropped support for signed integer >representation other than two's complement, because they are not in use >in any modern hardware (including any DSP's) - at least, not for >general-purpose integers. Both committees have consistently voted to >keep overflow as UB. Yes. As I said, performance is often the justification. I'm not convinced that there are no custom chips and/or DSPs that are not manufactured today. They may not be common, their mere existence is certainly dumb and offensive, but that does not mean that they don't exist. Note that the survey in, e.g., https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm only mentions _popular_ DSPs, not _all_ DSPs. Of course, if such machines exist, I will certainly concede that I doubt very much that anyone is targeting them with C code written to a modern standard. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-08-15 17:49 +0200 |
| Subject | Re: System calls |
| Message-ID | <107nkv2$1753a$1@dont-email.me> |
| In reply to | #113144 |
On 14.08.2025 23:44, Dan Cross wrote: > In article <107l5ju$k78a$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 14.08.2025 17:44, Dan Cross wrote: >>> In article <sknnQ.168942$Bui1.63359@fx10.iad>, >>> Scott Lurndal <slp53@pacbell.net> wrote: >>>> Both Burroughs Large Systems (48-bit stack machine) and the >>>> Sperry 1100/2200 (36-bit) systems had (have, in emulation today) >>>> C compilers. >>> >>> Yup. The 1100-series machines were (are) 1's complement. Those >>> are the ones I usually think of when cursing that signed integer >>> overflow is UB in C. >>> >>> I don't think anyone is compiling C23 code for those machines, >>> but back in the late 1980s, they were still enough of a going >>> concern that they could influence the emerginc C standard. Not >>> so much anymore. >> >> They would presumably have been part of the justification for supporting >> multiple signed integer formats at the time. > > C90 doesn't have much to say about this at all, other than > saying that the actual representation and ranges of the integer > types are implementation defined (G.3.5 para 1). > > C90 does say that, "The representations of integral types shall > define values by use of a pure binary numeration system" (sec > 6.1.2.5). > > C99 tightens this up and talks about 2's comp, 1's comp, and > sign/mag as being the permissible representations (J.3.5, para > 1). Yes. Early C didn't go into the details, then C99 described the systems that could realistically be used. And now in C23 only two's complement is allowed. > >> UB on signed integer >> arithmetic overflow is a different matter altogether. > > I disagree. > You have overflow when the mathematical result of an operation cannot be expressed accurately in the type - regardless of the representation format for the numbers. Your options, as a language designer or implementer, of handling the overflow are the same regardless of the representation. You can pick a fixed value to return, or saturate, or invoke some kind of error handler mechanism, or return a "don't care" unspecified value of the type, or perform a specified algorithm to get a representable value (such as reduction modulo 2^n), or you can simply say the program is broken if this happens (it is UB). I don't see where the representation comes into it - overflow is a matter of values and the ranges that can be stored in a type, not how those values are stored in the bits of the data. >>> Regardless, signed integer overflow remains UB in the current C >>> standard, nevermind definitionally following 2s complement >>> semantics. Usually this is done on the basis of performance >>> arguments: some seemingly-important loop optimizations can be >>> made if the compiler can assert that overflow Cannot Happen. >> >> The justification for "signed integer arithmetic overflow is UB" is in >> the C standards 6.5p5 under "Expressions" : > > Not in ANSI/ISO 9899-1990. In that revision of the standard, > sec 6.5 covers declarations. > >> """ >> If an exceptional condition occurs during the evaluation of an >> expression (that is, if the result is not mathematically defined or not >> in the range of representable values for its type), the behavior is >> undefined. >> """ > > In C90, this language appears in sec 6.3 para 5. Note, however, > that they do not define what an exception _is_, only a few > things that _may_ cause one. See below. > It's basically the same in C90 onwards, with just small changes to the wording. And it /does/ define what is meant by an "exceptional condition" (or just "exception" in C90) - that is done by the part in parentheses. >> It actually has absolutely nothing to do with signed integer >> representation, or machine hardware. > > Consider this language from the (non-normative) example 4 in sec > 5.1.2.3: > > |On a machine in which overflows produce an exception and in > |which the range of values representable by an *int* is > |[-32768,+32767], the implementation cannot rewrite this > |expression as [continues with the specifics of the example].... > > That seems pretty clear that they're thinking about machines > that actually generate a hardware trap of some kind on overflow. > They are thinking about that possibility, yes. In C90, the term "exception" here was not clearly defined - and it is definitely not the same as the term "exception" in 6.3p5. The wording was improved in C99 without changing the intended meaning - there the term in the paragraph under "Expressions" is "exceptional condition" (defined in that paragraph), while in the example in "Execution environments", it says "On a machine in which overflows produce an explicit trap". (C11 further clarifies what "performs a trap" means.) But this is about re-arrangements the compiler is allowed to make, or barred from making - it can't make re-arrangements that would mean execution failed when the direct execution of the code according to the C abstract machine would have worked correctly (without ever having encountered an "exceptional condition" or other UB). Representation is not relevant here - there is nothing about two's complement, ones' complement, sign-magnitude, or anything else. Even the machine hardware is not actually particularly important, given that most processors support non-trapping integer arithmetic instructions and for those that don't have explicit trap instructions, a compiler could generate "jump if overflow flag set" or similar instructions to emulate traps reasonably efficiently. (Many compilers support that kind of thing as an option to aid debugging.) >> It doesn't even have much to do >> with integers at all. It is simply that if the calculation can't give a >> correct answer, then then the C standards don't say anything about the >> results or effects. >> >> The point is that there when the results of an integer computation are >> too big, there is no way to get the correct answer in the types used. >> Two's complement wrapping is /not/ correct. If you add two real-world >> positive integers, you don't get a negative integer. > > Sorry, but I don't buy this argument as anything other than a > justification after the fact. We're talking about history and > motivation here, not the behavior described in the standard. It is a fair point that I am describing a rational and sensible reason for UB on arithmetic overflow - and I do not know the motivation of the early C language designers, compiler implementers, and authors of the first C standard. I do know, however, that the principle of "garbage in, garbage out" was well established long before C was conceived. And programmers of that time were familiar with the concept of functions and operations being defined for appropriate inputs, and having no defined behaviour for invalid inputs. C is full of other things where behaviour is left undefined when no sensible correct answer can be specified, and that is not just because the behaviour of different hardware could vary. It seems perfectly reasonable to me to suppose that signed integer arithmetic overflow is just another case, no different from dereferencing an invalid pointer, dividing by zero, or any one of the other UB's in the standards. > > In particular, C is a programming language for actual machines, > not a mathematical notation; the language is free to define the > behavior of arithmetic expressions in any way it chooses, though > one presumes it would do so in a way that makes sense for the > machines that it targets. Yes, that is true. It is, however, also important to remember that it was based on a general abstract machine, not any particular hardware, and that the operations were intended to follow standard mathematics as well as practically possible - operations and expressions in C were not designed for any particular hardware. (Though some design choices were biased by particular hardware.) > Thus, it could have formalized the > result of signed integer overflow to follow 2's complement > semantics had the committee so chosen, in which case the result > would not be "incorrect", it would be well-defined with respect > to the semantics of the language. Java, for example, does this, > as does C11 (and later) atomic integer operations. Indeed, the > C99 rationale document makes frequent reference to twos > complement, where overflow and modular behavior are frequently > equivalent, being the common case. But aside from the more > recent atomics support, C _chose_ not to do this. > It could have made signed integer overflow defined behaviour, but it did not. The C standards committee have explicitly chosen not to do that, even after deciding that two's complement is the only supported representation for signed integers in C23 onwards. It is fine to have two's complement representation, and fine to have modulo arithmetic in some circumstances, while leaving other arithmetic overflow undefined. Unsigned integer operations in C have always been defined as modulo arithmetic - addition of unsigned values is a different operation from addition of signed values. Having some modulo behaviour does not in any way imply that signed arithmetic should be modulo. In Java, the language designers decided that integer arithmetic operations would be modulo operations. Wrapping therefore gives the correct answer for those operations - it does not give the correct answer for mathematical integer operations. And Java loses common mathematical identities which C retains - such as the identity that adding a positive integer to another integer will increase its value. Something always has to be lost when approximating unbounded mathematical integers in a bounded implementation - I think C made the right choices here about what to keep and what to lose, and Java made the wrong choices. (Others may of course have different opinions.) In Zig, unsigned integer arithmetic overflow is also UB as these operations are not defined as modulo. I think that is a good natural choice too - but it is useful for a language to have a way to do wrapping arithmetic on the occasions you need it. > Also, consider that _unsigned_ arithmetic is defined as having > wrap-around semantics similar to modular arithmetic, and thus > incapable of overflow. Yes. Unsigned arithmetic operations are different operations from signed arithmetic operations in C. > But that's simply a fiction invented for > the abstract machine described informally in the standard: it > requires special handling one machines like the 1100 series, > because those machines might trap on overflow. The C committee > could just as well have said that the unsigned arithmetic > _could_ overflow and that the result was UB. > They could have done that (as the Zig folk did). > So why did C chose this way? The only logical reason is that > there were machines at the time that where a) integer overflow > caused machine exceptions, and b) the representation of signed > integers was not well-defined, so that the actual value > resulting from overflow could not be rigorously defined. Given > that C90 mandated a binary representation for integers and so > the representation of of unsigned integers is basically common, > there was no need to do that for unsigned arithmetic. > Not at all. Usually when someone says "the only logical reason is...", they really mean "the only logical reason /I/ can think of is...", or "the only reason that /I/ can think of that /I/ think is logical is...". For a language that can be used as a low-level systems language, it is important to be able to do modulo arithmetic efficiently. It is needed for a number of low-level tasks, including the implementation of large arithmetic operations, handling timers, counters, and other bits and pieces. So it was definitely a useful thing to have in C. For a language that can be used as a fast and efficient application language, it must have a reasonable approximation to mathematical integer arithmetic. Implementations should not be forced to have behaviours beyond the mathematically sensible answers - if a calculation can't be done correctly, there's no point in doing it. Giving nonsense results does not help anyone - C programmers or toolchain implementers, so the language should not specify any particular result. More sensible defined overflow behaviour - saturation, error values, language exceptions or traps, etc., would be very inefficient on most hardware. So UB is the best choice - and implementations can do something different if they like. Too many options make a language bigger - harder to implement, harder to learn, harder to use. So it makes sense to have modulo arithmetic for unsigned types, and normal arithmetic for signed types. I am not claiming to know that this is the reasoning made by the C language pioneers. But it is definitely an alternative logical reason for C being the way it is. >>> And of course, even today, C still targets oddball platforms >>> like DSPs and custom chips, where assumptions about the ubiquity >>> of 2's comp may not hold. >> >> Modern C and C++ standards have dropped support for signed integer >> representation other than two's complement, because they are not in use >> in any modern hardware (including any DSP's) - at least, not for >> general-purpose integers. Both committees have consistently voted to >> keep overflow as UB. > > Yes. As I said, performance is often the justification. > > I'm not convinced that there are no custom chips and/or DSPs > that are not manufactured today. They may not be common, their > mere existence is certainly dumb and offensive, but that does > not mean that they don't exist. Note that the survey in, e.g., > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm > only mentions _popular_ DSPs, not _all_ DSPs. > I think you might have missed a few words in that paragraph, but I believe I know what you intended. There are certainly DSPs and other cores that have strong support for alternative overflow behaviour - saturation is very common in DSPs, and it is also common to have a "sticky overflow" flag so that you can do lots of calculations in a tight loop, and check for problems once you are finished. I think it is highly unlikely that you'll find a core with something other than two's complement as the representation for signed integer types, though I can't claim that I know /all/ devices! (I do know a bit about more cores than would be considered popular or common.) > Of course, if such machines exist, I will certainly concede that > I doubt very much that anyone is targeting them with C code > written to a modern standard. > Modern C is definitely used on DSPs with strong saturation support. (Even ARM cores have saturated arithmetic instructions.) But they can also handle two's complement wrapped signed integer arithmetic if the programmer wants that - after all, it's exactly the same in the hardware as modulo unsigned arithmetic (except for division). That doesn't mean that wrapping signed integer overflow is useful or desired behaviour.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-15 18:33 +0000 |
| Subject | Re: System calls |
| Message-ID | <107nuh3$4q1$1@reader1.panix.com> |
| In reply to | #113151 |
In article <107nkv2$1753a$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 14.08.2025 23:44, Dan Cross wrote:
>> In article <107l5ju$k78a$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> [snip]
>>> UB on signed integer
>>> arithmetic overflow is a different matter altogether.
>>
>> I disagree.
>
>You have overflow when the mathematical result of an operation cannot be
>expressed accurately in the type - regardless of the representation
>format for the numbers. Your options, as a language designer or
>implementer, of handling the overflow are the same regardless of the
>representation. You can pick a fixed value to return, or saturate, or
>invoke some kind of error handler mechanism, or return a "don't care"
>unspecified value of the type, or perform a specified algorithm to get a
>representable value (such as reduction modulo 2^n), or you can simply
>say the program is broken if this happens (it is UB).
>
>I don't see where the representation comes into it - overflow is a
>matter of values and the ranges that can be stored in a type, not how
>those values are stored in the bits of the data.
I understood your point. But we are talking about the history of
the language here, not the presently defined behavior.
We do, in fact, have historical source materials we can draw
from when discussing this; there's little need to guess. Here,
we know that the earliest C implementations simply ignored the
posibility of overflow. In K&R1, chap 2, sec 2.5 ("Arithmetic
Operators") on page 38, the authors write, "the action taken on
overflow or underflow depends on the machine at hand." In
Appendix A, sec 7 ("Expressions"), page 185, the authors write:
"The handling of overflow and divide check in expression
evaluation is machine-dependent. All existing implements of C
ignore integer overflows; treatment of division by 0, and all
floating point exceptions, varies between machines, and is
usually adjustable by a library function."
In other words, different machines give different results; some
will trap, others will differ due to representation issues. No
where here does it suggest that the language designers were
worried about getting the "wrong" result, as you have asserted.
>>>> Regardless, signed integer overflow remains UB in the current C
>>>> standard, nevermind definitionally following 2s complement
>>>> semantics. Usually this is done on the basis of performance
>>>> arguments: some seemingly-important loop optimizations can be
>>>> made if the compiler can assert that overflow Cannot Happen.
>>>
>>> The justification for "signed integer arithmetic overflow is UB" is in
>>> the C standards 6.5p5 under "Expressions" :
>>
>> Not in ANSI/ISO 9899-1990. In that revision of the standard,
>> sec 6.5 covers declarations.
>>
>>> """
>>> If an exceptional condition occurs during the evaluation of an
>>> expression (that is, if the result is not mathematically defined or not
>>> in the range of representable values for its type), the behavior is
>>> undefined.
>>> """
>>
>> In C90, this language appears in sec 6.3 para 5. Note, however,
>> that they do not define what an exception _is_, only a few
>> things that _may_ cause one. See below.
>
>It's basically the same in C90 onwards, with just small changes to the
>wording.
Did I suggest otherwise?
>And it /does/ define what is meant by an "exceptional
>condition" (or just "exception" in C90) - that is done by the part in
>parentheses.
That is an interpretation.
>>> It actually has absolutely nothing to do with signed integer
>>> representation, or machine hardware.
>>
>> Consider this language from the (non-normative) example 4 in sec
>> 5.1.2.3:
>>
>> |On a machine in which overflows produce an exception and in
>> |which the range of values representable by an *int* is
>> |[-32768,+32767], the implementation cannot rewrite this
>> |expression as [continues with the specifics of the example]....
>>
>> That seems pretty clear that they're thinking about machines
>> that actually generate a hardware trap of some kind on overflow.
>
>They are thinking about that possibility, yes. In C90, the term
>"exception" here was not clearly defined - and it is definitely not the
>same as the term "exception" in 6.3p5. The wording was improved in C99
>without changing the intended meaning - there the term in the paragraph
>under "Expressions" is "exceptional condition" (defined in that
>paragraph), while in the example in "Execution environments", it says
>"On a machine in which overflows produce an explicit trap". (C11
>further clarifies what "performs a trap" means.)
>
>But this is about re-arrangements the compiler is allowed to make, or
>barred from making - it can't make re-arrangements that would mean
>execution failed when the direct execution of the code according to the
>C abstract machine would have worked correctly (without ever having
>encountered an "exceptional condition" or other UB). Representation is
>not relevant here - there is nothing about two's complement, ones'
>complement, sign-magnitude, or anything else. Even the machine hardware
>is not actually particularly important, given that most processors
>support non-trapping integer arithmetic instructions and for those that
>don't have explicit trap instructions, a compiler could generate "jump
>if overflow flag set" or similar instructions to emulate traps
>reasonably efficiently. (Many compilers support that kind of thing as
>an option to aid debugging.)
>
>>> It doesn't even have much to do
>>> with integers at all. It is simply that if the calculation can't give a
>>> correct answer, then then the C standards don't say anything about the
>>> results or effects.
>>>
>>> The point is that there when the results of an integer computation are
>>> too big, there is no way to get the correct answer in the types used.
>>> Two's complement wrapping is /not/ correct. If you add two real-world
>>> positive integers, you don't get a negative integer.
>>
>> Sorry, but I don't buy this argument as anything other than a
>> justification after the fact. We're talking about history and
>> motivation here, not the behavior described in the standard.
>
>It is a fair point that I am describing a rational and sensible reason
>for UB on arithmetic overflow - and I do not know the motivation of the
>early C language designers, compiler implementers, and authors of the
>first C standard.
Then there's really nothing more to discuss. The intent here is
to understand the motivation of those folks.
Early C didn't even have unsigned; Dennis Ritchie's paper for
the History of Programming Languages conference said that it
came around 1977
(https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html;
see the section on "portability"), and in pre-ANSI C, struct
fields of `int` type were effectively unsigned (K&R1,
pp.138,197). I mentioned the quote from K&R1 about overflow
above, but we see some other hints about signed overflow
becoming negative in other documents. For instance, K&R2, p 118
gives the example of a hash function followed by the sentence,
"unsigned arithmetic ensures that the hash value is
non-negative." This does not suggest to me that the authors
thought that the wrapping behavior of twos-complement arithemtic
was "incorrect".
>I do know, however, that the principle of "garbage in, garbage out" was
>well established long before C was conceived. And programmers of that
>time were familiar with the concept of functions and operations being
>defined for appropriate inputs, and having no defined behaviour for
>invalid inputs. C is full of other things where behaviour is left
>undefined when no sensible correct answer can be specified, and that is
>not just because the behaviour of different hardware could vary. It
>seems perfectly reasonable to me to suppose that signed integer
>arithmetic overflow is just another case, no different from
>dereferencing an invalid pointer, dividing by zero, or any one of the
>other UB's in the standards.
Indeed; this is effectively what I've been saying: signed
integer overflow is UB because the behavior of overflow varied
between the machines of the day, so C could not make assumptions
about what value would result, in part because of representation
issues: at the hardware level, signed overflow of the largest
representable positive integer yields different _values_ between
1s comp and 2s comp machines. Who is to say which is correct?
>> In particular, C is a programming language for actual machines,
>> not a mathematical notation; the language is free to define the
>> behavior of arithmetic expressions in any way it chooses, though
>> one presumes it would do so in a way that makes sense for the
>> machines that it targets.
>
>Yes, that is true. It is, however, also important to remember that it
>was based on a general abstract machine, not any particular hardware,
>and that the operations were intended to follow standard mathematics as
>well as practically possible - operations and expressions in C were not
>designed for any particular hardware. (Though some design choices were
>biased by particular hardware.)
This is historically inaccurate.
C was developed by and for the PDP-11 initially, targeting Unix,
building from Martin Richards's BCPL (which Ritchie and Thompson
had used under Multics on the GE-645 machine, and GCOS on the
635) and Ken Thompson's B language, which he had implemented as
a chopped-down BCPL to be a systems programming language for
_very_ early Unix on the PDP-7. B was typeless, as the PDP-7
was word-oriented, and we see vestages of this ancestral DNA in
C today. See Ritchie's C history paper for details.
Concerns for protability, leading to the development of the
abstract machine informally described by the C standard, came
much, much later in its evolutionary development.
>> Thus, it could have formalized the
>> result of signed integer overflow to follow 2's complement
>> semantics had the committee so chosen, in which case the result
>> would not be "incorrect", it would be well-defined with respect
>> to the semantics of the language. Java, for example, does this,
>> as does C11 (and later) atomic integer operations. Indeed, the
>> C99 rationale document makes frequent reference to twos
>> complement, where overflow and modular behavior are frequently
>> equivalent, being the common case. But aside from the more
>> recent atomics support, C _chose_ not to do this.
>
>It could have made signed integer overflow defined behaviour, but it did
>not. The C standards committee have explicitly chosen not to do that,
>even after deciding that two's complement is the only supported
>representation for signed integers in C23 onwards. It is fine to have
>two's complement representation, and fine to have modulo arithmetic in
>some circumstances, while leaving other arithmetic overflow undefined.
>Unsigned integer operations in C have always been defined as modulo
>arithmetic - addition of unsigned values is a different operation from
>addition of signed values. Having some modulo behaviour does not in any
>way imply that signed arithmetic should be modulo.
>
>In Java, the language designers decided that integer arithmetic
>operations would be modulo operations. Wrapping therefore gives the
>correct answer for those operations - it does not give the correct
>answer for mathematical integer operations. And Java loses common
>mathematical identities which C retains - such as the identity that
>adding a positive integer to another integer will increase its value.
>Something always has to be lost when approximating unbounded
>mathematical integers in a bounded implementation - I think C made the
>right choices here about what to keep and what to lose, and Java made
>the wrong choices. (Others may of course have different opinions.)
>
>In Zig, unsigned integer arithmetic overflow is also UB as these
>operations are not defined as modulo. I think that is a good natural
>choice too - but it is useful for a language to have a way to do
>wrapping arithmetic on the occasions you need it.
None of this seems relevant to understanding the motivations of
the members of the committee that produced the 1990 C standard,
other than agreeing that the decision could have been different.
I would add that very early C treated signed and unsigned
arithmetic as more or less equivalent. It wasn't until they
started porting C to machines other than the PDP-11 that it
started to matter.
>> Also, consider that _unsigned_ arithmetic is defined as having
>> wrap-around semantics similar to modular arithmetic, and thus
>> incapable of overflow.
>
>Yes. Unsigned arithmetic operations are different operations from
>signed arithmetic operations in C.
This is the second time you have mentioned this. Did I say
something that led you believe that I suggested otherwise, or
am somehow unaware of this fact?
>> But that's simply a fiction invented for
>> the abstract machine described informally in the standard: it
>> requires special handling one machines like the 1100 series,
>> because those machines might trap on overflow. The C committee
>> could just as well have said that the unsigned arithmetic
>> _could_ overflow and that the result was UB.
>
>They could have done that (as the Zig folk did).
Or the SML folks before the Zig folks.
>> So why did C chose this way? The only logical reason is that
>> there were machines at the time that where a) integer overflow
>> caused machine exceptions, and b) the representation of signed
>> integers was not well-defined, so that the actual value
>> resulting from overflow could not be rigorously defined. Given
>> that C90 mandated a binary representation for integers and so
>> the representation of of unsigned integers is basically common,
>> there was no need to do that for unsigned arithmetic.
>
>Not at all. Usually when someone says "the only logical reason is...",
>they really mean "the only logical reason /I/ can think of is...", or
>"the only reason that /I/ can think of that /I/ think is logical is...".
I probably should have said that I'm also drawing from direct
references, as well as hints and inferences from other
historical documents; both editions of K&R as well as early Unix
source code and the "C Reference Manual" from 6th and 7th
Edition Unix (the language described in 7th Ed is quite
different from the language in 6th Ed; most of this was driven
by the a) portability, and b) the need to support
phototypesetters, hence why the C implemented in 7th Ed and PCC
is sometimes called "Typesetter C"). This is complemented with
direct conversations with some of the original players, though
admittedly those were quite a while ago.
>For a language that can be used as a low-level systems language, it is
>important to be able to do modulo arithmetic efficiently. It is needed
>for a number of low-level tasks, including the implementation of large
>arithmetic operations, handling timers, counters, and other bits and
>pieces. So it was definitely a useful thing to have in C.
>
>For a language that can be used as a fast and efficient application
>language, it must have a reasonable approximation to mathematical
>integer arithmetic. Implementations should not be forced to have
>behaviours beyond the mathematically sensible answers - if a calculation
>can't be done correctly, there's no point in doing it. Giving nonsense
>results does not help anyone - C programmers or toolchain implementers,
>so the language should not specify any particular result. More sensible
>defined overflow behaviour - saturation, error values, language
>exceptions or traps, etc., would be very inefficient on most hardware.
>So UB is the best choice - and implementations can do something
>different if they like.
This is where we differ: you keep asserting notions of
"correctness", without acknowledging that a) correctness differs
in this context, and b) the notion of what is "correct" has
itself differed over time as C has evolved.
Moreover, when you say, "if a calculation can't be done
correctly, there's no point in doing it" that's seems highly
specific and reliant on your definition of correctness. My
Here's an example:
char foo = 128;
int x = foo + 1;
printf("%d\n", x);
What is printed? (Note: that's rhetorical)
On the systems I just tested, x86_64, ARM64 and RISCV64, I get
-127 for the first two, and 129 for the last.
Of course, we all know that this relies on implementation
defined behavior around whether `char` is treated as signed or
unsigned (and resultingly conversion from an unsigned constant
to signed), but if what you say were true about GIGO, why is
this not _undefined_ behavior?
>Too many options make a language bigger - harder to implement, harder to
>learn, harder to use. So it makes sense to have modulo arithmetic for
>unsigned types, and normal arithmetic for signed types.
>
>I am not claiming to know that this is the reasoning made by the C
>language pioneers. But it is definitely an alternative logical reason
>for C being the way it is.
But we _can_ see what those pioneers were thinking by reading
the artifacts they left behind, which we know, again based on
primary sources, had an impact on the standards committee.
>>>> And of course, even today, C still targets oddball platforms
>>>> like DSPs and custom chips, where assumptions about the ubiquity
>>>> of 2's comp may not hold.
>>>
>>> Modern C and C++ standards have dropped support for signed integer
>>> representation other than two's complement, because they are not in use
>>> in any modern hardware (including any DSP's) - at least, not for
>>> general-purpose integers. Both committees have consistently voted to
>>> keep overflow as UB.
>>
>> Yes. As I said, performance is often the justification.
>>
>> I'm not convinced that there are no custom chips and/or DSPs
>> that are not manufactured today. They may not be common, their
>> mere existence is certainly dumb and offensive, but that does
>> not mean that they don't exist. Note that the survey in, e.g.,
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm
>> only mentions _popular_ DSPs, not _all_ DSPs.
>
>I think you might have missed a few words in that paragraph, but I
>believe I know what you intended. There are certainly DSPs and other
>cores that have strong support for alternative overflow behaviour -
>saturation is very common in DSPs, and it is also common to have a
>"sticky overflow" flag so that you can do lots of calculations in a
>tight loop, and check for problems once you are finished. I think it is
>highly unlikely that you'll find a core with something other than two's
>complement as the representation for signed integer types, though I
>can't claim that I know /all/ devices! (I do know a bit about more
>cores than would be considered popular or common.)
I was referring specifically to integer representation here, not
saturating (or other) operations, but sure.
>> Of course, if such machines exist, I will certainly concede that
>> I doubt very much that anyone is targeting them with C code
>> written to a modern standard.
>
>Modern C is definitely used on DSPs with strong saturation support.
>(Even ARM cores have saturated arithmetic instructions.) But they can
>also handle two's complement wrapped signed integer arithmetic if the
>programmer wants that - after all, it's exactly the same in the hardware
>as modulo unsigned arithmetic (except for division). That doesn't mean
>that wrapping signed integer overflow is useful or desired behaviour.
So again, the context here is understanding the initial
motivation. I've mentioned reasons why they don't change it now
(there _are_ arguments about correctness, but compiler writers
also argue strongly that making signed integer overflow well
defined would prohibit them from implementing what they consider
to be important optimizations).
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-08-13 18:51 +0000 |
| Subject | Re: System calls (was: VAX) |
| Message-ID | <107imr3$jc5$1@reader1.panix.com> |
| In reply to | #113115 |
In article <MO1nQ.2$Bui1.0@fx10.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>[snip]
>>errno, but at the actual system call level, the error is indicated in
>>an architecture-specific way, and the ones I have looked at before
>>today use the sign of the result register or the carry flag. On those
>>architectures, where the sign is used, mmap(2) cannot return negative
>>addresses, or must have a special wrapper.
>
>Why would the wrapper care if the system call failed? The
>return value from the kernel should be passed through to
>the application as per the POSIX language binding requirements.
For the branch to `cerror`. That is, the usual reason is (was?)
to convert from the system call interface to the C ABI,
specifically, to populate the (userspace, now thread-local)
`errno` variable if there was an error. (I know you know this,
Scott, but others reading the discussion may not.)
Looking at the 32v code for VAX and 7th Edition on the PDP-11,
on error the kernel returns a non-zero value and sets the carry
bit in the PSW. The stub checks whether the C bit is set, and
if so, copies R0 to `errno` and then sets R0 to -1. On the
PDP-11, `as` supports the non-standard "bec" mnemonic as an
alias for "bcc" and the stub is actually something like:
/ Do sys call....land in the kernel `trap` in m40.s
bec 1f
jmp cerror
1f:
rts pc
cerror:
mov r0, _errno
mov $-1, r0
rts pc
In other words, if the carry bit is not set, there system call
was successful, so just return whatever it returned. Otherwise,
the kernel is returning an error to the user, so do the dance of
setting up `errno` and returning -1.
(There's some fiddly bits with popping R5, which Unix used as
the frame pointer, but I omitted those for brevity).
>lseek(2) and mmap(2) both require the return of arbitrary 32-bit
>or 64-bit values, including those which when interpreted as signed
>values are negative.
At last for lseek, that was true in the 1990 POSIX standard,
where the programmer was expected to (maybe save and then) clear
`errno`, invoke `lseek`, and then check the value of `errno`
after return to see if there was an error, but has been relaxed
in subsequent editions (include POSIX 2024) where `lseek` now
must return `EINVAL` if the offset is negative for a regular
file, directory, or block-special file.
(https://pubs.opengroup.org/onlinepubs/9799919799/functions/lseek.html;
see "ERRORS")
For mmap, at least the only documented error return value is
`MAP_FAILED`, and programmers must check for that explicitly.
It strikes me that this implies that the _value_ of `MAP_FAILED`
need not be -1; on x86_64, for instance, it _could_ be any
non-canonical address.
>Clearly POSIX defines the interfaces and the underlying OS and/or
>library functions implement the interfaces. The kernel interface
>to the language library (e.g. libc) is irrelevent to typical programmers,
>except in the case where it doesn't provide the correct semantics.
Certainly, these are hidden by the system call stubs in the
libraries for language-specific bindings, and workaday
programmers should not be trying to side-step those!
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-08-13 20:28 +0000 |
| Subject | Re: System calls (was: VAX) |
| Message-ID | <xz6nQ.13916$M2W2.3791@fx06.iad> |
| In reply to | #113124 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <MO1nQ.2$Bui1.0@fx10.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>>scott@slp53.sl.home (Scott Lurndal) writes: >For mmap, at least the only documented error return value is >`MAP_FAILED`, and programmers must check for that explicitly. > >It strikes me that this implies that the _value_ of `MAP_FAILED` >need not be -1; on x86_64, for instance, it _could_ be any >non-canonical address. And in the very unlikely case that a C compiler was developed for the Burroughs B4900, MAP_FAILED could be 0xC0EEEEEE (which is how the NULL pointer was encoded in the hardware). Because all the data was BCD, undigits (a-f) in an address were unconditionally illegal. There were instructions to search linked lists, so the hardware needed to understand the concept of a NULL pointer (as well as deal with the possibility of a loop, using a timer while the search instruction was executing).
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-08-13 19:35 +0000 |
| Subject | Re: VAX |
| Message-ID | <107ipdb$iqq1$1@paganini.bofh.team> |
| In reply to | #112955 |
In comp.arch Scott Lurndal <scott@slp53.sl.home> wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>Stephen Fuld wrote:
>>> On 8/4/2025 8:32 AM, John Ames wrote:
>>>=20
>>> snip
>>>=20
>>>> This notion that the only advantage of a 64-bit architecture is a larg=
>>e
>>>> address space is very curious to me. Obviously that's *one* advantage,=
>>
>>>> but while I don't know the in-the-field history of heavy-duty business=
>>/
>>>> scientific computing the way some folks here do, I have not gotten the=
>>
>>>> impression that a lot of customers were commonly running up against th=
>>e
>>>> 4 GB limit in the early '90s;
>>>=20
>>> Not exactly the same, but I recall an issue with Windows NT where it=20
>>> initially divided the 4GB address space in 2 GB for the OS, and 2GB for=
>>=20
>>> users.=C2=A0 Some users were "running out of address space", so Microso=
>>ft=20
>>> came up with an option to reduce the OS space to 1 GB, thus allowing up=
>>=20
>>> to 3 GB for users.=C2=A0 I am sure others here will know more details.
>>
>>Any program written to Microsoft/Windows spec would work transparently=20
>>with a 3:1 split, the problem was all the programs ported from unix=20
>>which assumed that any negative return value was a failure code.
>
> The only interfaces that I recall this being an issue for were
> mmap(2) and lseek(2). The latter was really related to maximum
> file size (although it applied to /dev/[k]mem and /proc/<pid>/mem
> as well). The former was handled by the standard specifying
> MAP_FAILED as the return value.
>
> That said, Unix generally defined -1 as the return value for all
> other system calls, and code that checked for "< 0" instead of
> -1 when calling a standard library function or system call was fundamentally
> broken.
I remeber RIM. When I compiled it on Linux and tried it I got error
due to check for "< 0". Change to '== -1" fixed it. Possibly there
were similar troubles in other programs that I do not remember.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-08-06 00:49 +0000 |
| Subject | Re: VAX |
| Message-ID | <106u8qh$336o5$1@dont-email.me> |
| In reply to | #112953 |
On Tue, 5 Aug 2025 17:24:34 +0200, Terje Mathisen wrote: > ... the problem was all the programs ported from unix which assumed > that any negative return value was a failure code. If the POSIX API spec says a negative return for a particular call is an error, then a negative return for that particular call is an error. I can’t imagine this kind of thing blithely being carried over to any non- POSIX API calls.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-08-06 13:48 +0000 |
| Subject | Re: VAX |
| Message-ID | <B2JkQ.60291$7z3.26195@fx09.iad> |
| In reply to | #112975 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >On Tue, 5 Aug 2025 17:24:34 +0200, Terje Mathisen wrote: > >> ... the problem was all the programs ported from unix which assumed >> that any negative return value was a failure code. > >If the POSIX API spec says a negative return for a particular call is an >error, then a negative return for that particular call is an error. Please find a single POSIX API that says a negative return is an error. You won't have much success. POSIX explicitly states in most cases that the API returns -1 on error (mmap returns MAP_FAILED, which happens to be -1 on most implementations; regardless a POSIX application _must_ check for MAP_FAILED, not a negative return value). More misinformation from LDO.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-08-04 23:24 +0000 |
| Subject | Re: VAX |
| Message-ID | <106rfet$1tua1$1@paganini.bofh.team> |
| In reply to | #112875 |
In comp.arch John Ames <commodorejohn@gmail.com> wrote:
> On Sat, 02 Aug 2025 23:10:56 -0400
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> > And what a waste of a 64-bit architecture, to run it in 32-bit-only
>> > mode ...
>>
>> What do you mean by that? IIUC, the difference between 32bit and
>> 64bit (in terms of cost of designing and producing the CPU) was very
>> small. MIPS happily designed their R4000 as 64bit while knowing that
>> most of them would never get a chance to execute an instruction that
>> makes use of the upper 32bits.
>
> This notion that the only advantage of a 64-bit architecture is a large
> address space is very curious to me. Obviously that's *one* advantage,
> but while I don't know the in-the-field history of heavy-duty business/
> scientific computing the way some folks here do, I have not gotten the
> impression that a lot of customers were commonly running up against the
> 4 GB limit in the early '90s; meanwhile, the *other* advantage - higher
> performance for the same MIPS on a variety of compute-bound tasks - is
> being overlooked entirely, it seems.
Well, as log as an app fits into 32-bit address space, all other
factors being equal one can expect 10-20% better performance
from 32-bit addresses. Due to this customers had motivation
to stay with 32-bits as log as possible.
But matter is somewhat different for OS vendor: once machine
gets more than 1GB memory 64-bit addressing in the kernel avoids
various troubles.
Concerning applications: server with multiple process sharing
memory use may operate with several gigabytes using 32-bit
addresses for applications.
But for numeric work 512 MB of real memory and more than 3 GB
virtual (with swapping to disc) may give adequate performance.
But it is quite inconvenient for 32-bit OS to provide more than
3 GB of address space to applications.
Also heaviliy multithread application with some threads needing
large stacks is inconvenient in 32-bit address space.
Of course software developers wanting to develop for 64-bit
systems need 64-bit system interfaces.
So, supporting 32-bit applications is natural and one could expect
for some (possibly quite long) time that 32-bit applications
will be majority. But supporting 64-bit operation was also
important, both for customers and for OS itself.
BTW: AMD-64 was a special case: since 64-bit mode was bundled
with increasing number of GPR-s, with PC-relative addressing
and with register-based call convention on average 64-bit
code was faster than 32-bit code. And since AMD-64 was
relatively late in 64-bit game there was limited motivation
to develop mode using 32-bit addressing and 64-bit instructions.
It works in compilers and in Linux, but support is much worse
than for using 64-bit addressing.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-08-05 01:41 +0000 |
| Subject | Re: VAX |
| Message-ID | <106rnfq$2g4u3$4@dont-email.me> |
| In reply to | #112921 |
On Mon, 4 Aug 2025 23:24:15 -0000 (UTC), Waldek Hebisch wrote: > BTW: AMD-64 was a special case: since 64-bit mode was bundled with > increasing number of GPR-s, with PC-relative addressing and with > register-based call convention on average 64-bit code was faster than > 32-bit code. And since AMD-64 was relatively late in 64-bit game there > was limited motivation to develop mode using 32-bit addressing and > 64-bit instructions. It works in compilers and in Linux, but support is > much worse than for using 64-bit addressing. Intel was trying to promote this in the form of the “X32” ABI. The Linux kernel and some distros did include support for this. I don’t think it was very popular, and it may be extinct now.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2025-08-05 05:56 +0000 |
| Subject | Re: VAX |
| Message-ID | <106s6et$2gmuq$1@dont-email.me> |
| In reply to | #112930 |
On Tue, 5 Aug 2025 01:41:15 -0000 (UTC), Lawrence D'Oliveiro wrote: > On Mon, 4 Aug 2025 23:24:15 -0000 (UTC), Waldek Hebisch wrote: > >> BTW: AMD-64 was a special case: since 64-bit mode was bundled with >> increasing number of GPR-s, with PC-relative addressing and with >> register-based call convention on average 64-bit code was faster than >> 32-bit code. And since AMD-64 was relatively late in 64-bit game there >> was limited motivation to develop mode using 32-bit addressing and >> 64-bit instructions. It works in compilers and in Linux, but support is >> much worse than for using 64-bit addressing. > > Intel was trying to promote this in the form of the “X32” ABI. The Linux > kernel and some distros did include support for this. I don’t think it was > very popular, and it may be extinct now. It's still in the Linux kernel, but off by default. arch/x86/Kconfig I went to an O'Reilly "Foo Camp" where AMD was showing off their new 64-bit processor. Found it fascinating, if a little over my head. But I did gather that the instruction set made sense for transitioning from 32-bit software, and I think Intel missed the boat with their IA-64. (And I have memories of when Intel started making "EM64T" processors...) -- -Scott System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G OS: Linux 6.16.0 D: Mint 22.1 DE: Xfce 4.18 NVIDIA: 575.64.05 Mem: 258G "Excuse me for butting in, but I'm interrupt-driven."
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-08-05 01:34 +0000 |
| Subject | Re: VAX |
| Message-ID | <106rn28$2g4u3$1@dont-email.me> |
| In reply to | #112875 |
On Mon, 4 Aug 2025 08:32:19 -0700, John Ames wrote: > This notion that the only advantage of a 64-bit architecture is a large > address space is very curious to me. That is basically it. > Obviously that's *one* advantage, but while I don't know the > in-the-field history of heavy-duty business/ scientific computing > the way some folks here do, I have not gotten the impression that a > lot of customers were commonly running up against the 4 GB limit in > the early '90s ... By the latter 1990s, as GPUs became popular in the consumer market, the amount of VRAM on them kept growing, and taking up more and more significant chunks of a 32-bit address space. So that was one of the drivers towards 64-bit addressing. > ... meanwhile, the *other* advantage - higher performance for the > same MIPS on a variety of compute-bound tasks - is being overlooked > entirely, it seems. I don’t think there is one. A lot of computation involves floating point, and the floating-point formats mostly remain the same ones defined by IEEE-754 back in the 1980s. In the x86 world, there is the performance boost in the switch from the old register-poor 32-bit 80386 instruction set to the larger register pool available in AMD’s 64-bit extensions.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2025-08-01 20:06 -0700 |
| Subject | Re: VAX |
| Message-ID | <106jvc3$qan0$1@dont-email.me> |
| In reply to | #112807 |
On 8/1/25 11:11, Scott Lurndal wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> Lars Poulsen <lars@cleo.beagle-ears.com> writes: >>> In the days of VAX-11/780, it was "obvious" that operating systems would >>> be written in assembler in order to be efficient, and the instruction >>> set allowed high productivity for writing systems programs in "native" >>> code. >> >> Yes. I don't think that the productivity would have suffered from a >> load/store architecture, though. >> >>> As for a RISC-VAX: To little old naive me, it seems that it would have >>> been possible to create an alternative microcode load that would be able >>> to support a RISC ISA on the same hardware, if the idea had occured to a >>> well-connected group of graduate students. How good a RISC might have >>> been feasible? >> >> Did the VAX 11/780 have writable microcode? > > Yes. > >> >> Given that the VAX 11/780 was not (much) pipelined, I don't expect >> that using an alternative microcode that implements a RISC ISA would >> have performed well. > > A new ISA also requires development of the complete software > infrastructure for building applications (compilers, linkers, > assemblers); updating the OS, rebuilding existing applications > for the new ISA, field and customer training, etc. > > Digital eventually did move VMS to Alpha, but it was neither > cheap, nor easy. Most alpha customers were existing VAX > customers - it's not clear that DEC actually grew the customer > base by switching to Alpha. > Wasn't PRISM/MICA supposed to solve this problem, or am I confusing it with something else?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-08-02 03:37 +0000 |
| Subject | Re: VAX |
| Message-ID | <106k15u$qgip$6@dont-email.me> |
| In reply to | #112818 |
On Fri, 1 Aug 2025 20:06:43 -0700, Peter Flass wrote: > Wasn't PRISM/MICA supposed to solve this problem, or am I confusing it > with something else? PRISM was going to be a new hardware architecture, and MICA the OS to run on it. Yes, they were supposed to solve the problem of where DEC was going to go since the VAX architecture was clearly being left in the dust by RISC. I think the MICA kernel was going to support the concept of “personalities”, so that a VMS-compatible environment could be implemented by one set of upper layers, while another set could provide Unix functionality. I think the project was taking too long, and not making enough progress. So DEC management cancelled the whole thing, and brought out a MIPS-based machine instead. The guy in charge got annoyed at the killing of his pet project and left in a huff. He took some of those ideas with him to his new employer, to create a new OS for them. The new employer was Microsoft. The guy in question was Dave Cutler. The OS they brought out was called “Windows NT”.
[toc] | [prev] | [next] | [standalone]
| From | ted@loft.tnolan.com (Ted Nolan <tednolan>) |
|---|---|
| Date | 2025-08-02 04:14 +0000 |
| Subject | Re: VAX |
| Message-ID | <mf5hlnF38ueU1@mid.individual.net> |
| In reply to | #112821 |
In article <106k15u$qgip$6@dont-email.me>, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >On Fri, 1 Aug 2025 20:06:43 -0700, Peter Flass wrote: > >> Wasn't PRISM/MICA supposed to solve this problem, or am I confusing it >> with something else? > >PRISM was going to be a new hardware architecture, and MICA the OS to run >on it. Yes, they were supposed to solve the problem of where DEC was going >to go since the VAX architecture was clearly being left in the dust by >RISC. > >I think the MICA kernel was going to support the concept of >“personalities”, so that a VMS-compatible environment could be implemented >by one set of upper layers, while another set could provide Unix >functionality. > >I think the project was taking too long, and not making enough progress. >So DEC management cancelled the whole thing, and brought out a MIPS-based >machine instead. > >The guy in charge got annoyed at the killing of his pet project and left >in a huff. He took some of those ideas with him to his new employer, to >create a new OS for them. > >The new employer was Microsoft. The guy in question was Dave Cutler. The >OS they brought out was called “Windows NT”. And it's *still* not finished! -- columbiaclosings.com What's not in Columbia anymore..
[toc] | [prev] | [next] | [standalone]
Page 19 of 50 — ← Prev page 1 … 17 18 [19] 20 21 … 50 Next page →
Back to top | Article view | comp.arch
csiph-web