Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #109362 > unrolled thread
| Started by | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| First post | 2024-10-01 19:02 +0000 |
| Last post | 2024-10-03 00:30 +0000 |
| Articles | 20 on this page of 456 — 31 participants |
Back to article view | Back to comp.arch
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-01 19:02 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-01 20:00 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-01 21:04 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-01 23:38 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 00:31 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-03 01:26 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 06:28 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Brown <david.brown@hesbynett.no> - 2024-10-03 09:21 +0200
Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 09:39 +0000
Re: Byte ordering (was: Whether something is RISC or not) David Brown <david.brown@hesbynett.no> - 2024-10-03 14:34 +0200
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 22:17 +0000
Re: Byte ordering Lynn Wheeler <lynn@garlic.com> - 2024-10-03 15:33 -1000
Re: Byte ordering (was: Whether something is RISC or not) David Brown <david.brown@hesbynett.no> - 2024-10-04 11:23 +0200
Re: Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 17:30 +0000
Re: Byte ordering BGB <cr88192@gmail.com> - 2024-10-04 14:05 -0500
Re: Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2024-10-04 23:06 +0000
Re: Byte ordering BGB <cr88192@gmail.com> - 2024-10-04 19:44 -0500
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:35 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:34 +0000
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:31 +0000
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-05 17:52 +0000
Re: Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-05 18:11 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-05 22:53 +0300
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-06 22:07 +0200
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-06 21:53 +0000
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:29 +0000
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-07 16:16 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-07 19:57 +0300
Re: Byte ordering Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-07 16:00 -0400
Re: Byte ordering Michael S <already5chosen@yahoo.com> - 2024-10-08 00:11 +0300
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:46 +0000
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-08 10:40 +0200
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-06 11:58 +0200
Re: Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-06 13:04 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-06 16:34 +0100
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:32 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-08 22:28 +0100
Re: Byte ordering EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-09 13:37 -0400
VMS/NT memory management (was: Byte ordering) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-09 16:01 -0400
Re: VMS/NT memory management (was: Byte ordering) scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 23:16 +0000
Re: VMS/NT memory management EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-11 15:21 -0400
Re: VMS/NT memory management scott@slp53.sl.home (Scott Lurndal) - 2024-10-12 15:20 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:55 +0000
Re: Byte ordering Michael S <already5chosen@yahoo.com> - 2024-10-15 11:16 +0300
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-15 18:40 +0100
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:56 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-15 18:40 +0100
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2024-10-15 18:57 +0000
Re: Byte ordering George Neuner <gneuner2@comcast.net> - 2024-10-15 19:51 -0400
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-16 07:36 +0200
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-16 09:17 +0200
Re: Byte ordering George Neuner <gneuner2@comcast.net> - 2024-10-16 21:19 -0400
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-17 14:39 +0200
Re: clouds, not Byte ordering John Levine <johnl@taugh.com> - 2024-10-17 02:35 +0000
Re: clouds, not Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-17 14:41 +0200
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:57 +0000
Re: Byte ordering "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-16 11:34 -0400
Re: Microkernels & Capabilities (was Re: Byte ordering) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:54 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:51 +0000
Re: Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:17 +0000
80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-07 07:33 +0000
Re: 80286 protected mode Lars Poulsen <lars@cleo.beagle-ears.com> - 2024-10-07 12:42 +0000
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-07 15:17 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-07 17:45 +0300
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:55 +0000
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-08 10:44 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-07 16:32 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-07 20:03 +0300
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-07 17:40 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:52 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-07 23:13 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-08 06:16 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-08 20:53 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 08:48 +0200
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:46 +0000
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-08 07:28 +0000
Re: 80286 protected mode Robert Finch <robfi680@gmail.com> - 2024-10-08 07:28 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 10:24 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 16:28 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 16:42 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 22:20 +0200
Re: 80286 protected mode Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-10-09 14:52 -0700
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 00:33 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:30 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:24 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-11 08:15 -0700
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-15 17:26 -0400
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 21:55 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-15 22:05 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 00:24 +0000
Re: C and turtles, 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-16 01:08 +0000
Re: C and turtles, 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 02:48 +0000
Re: C and turtles, 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-16 03:09 +0000
Re: C and turtles, 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-17 19:49 +0000
Re: C and turtles, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 21:03 +0000
Re: C and turtles, 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-20 07:08 +0000
Re: C and turtles, 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-20 15:49 -0400
Re: C and turtles, 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-21 18:19 -0700
Re: C and turtles, 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-22 17:28 -0400
Re: C and turtles, 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 10:04 +0200
Re: C and turtles, 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-16 15:07 -0400
Re: C and turtles, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-16 19:41 +0000
Re: C and turtles, 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:13 +0200
Re: C and turtles, 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-20 07:07 +0000
Re: C and turtles, 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-20 12:14 -0400
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-16 15:38 +0000
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-16 23:06 -0400
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 03:16 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:16 +0200
Re: 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-16 20:00 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 22:18 +0000
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 01:18 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 00:40 -0700
Re: fine points of dynamic memory allocation, not 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-17 18:31 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 19:01 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-17 19:32 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 21:01 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 07:12 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 02:48 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 09:38 +0200
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-16 23:32 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:25 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 03:17 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 09:21 +0200
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-16 11:18 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 19:57 +0200
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-21 14:04 -0400
Re: 80286 protected mode Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-18 17:38 +0100
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-18 21:45 +0200
Re: 80286 protected mode Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 21:51 +0100
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-21 08:58 +0200
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-21 09:21 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-21 18:32 -0700
Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-22 08:27 +0200
Re: Retirement hobby (was Re: 80286 protected mode) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-23 07:25 -0700
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-23 18:11 +0000
Re: Retirement hobby (was Re: 80286 protected mode) scott@slp53.sl.home (Scott Lurndal) - 2024-10-23 18:27 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:12 +0200
Re: Retirement hobby (was Re: 80286 protected mode) Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-27 20:45 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:11 +0200
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-23 21:01 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-24 07:39 +0200
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-24 18:32 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-28 11:39 +0100
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-28 16:30 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-10-28 10:12 -0700
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-28 18:14 +0000
Re: Retirement hobby (was Re: 80286 protected mode) EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-28 15:24 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 06:33 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-29 08:07 +0100
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 19:57 +0000
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-29 20:21 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 21:27 +0000
Re: Retirement hobby (was Re: 80286 protected mode) scott@slp53.sl.home (Scott Lurndal) - 2024-10-29 20:30 +0000
Re: Retirement hobby (was Re: 80286 protected mode) EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-29 14:29 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-29 14:19 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:09 +0200
Re: Retirement hobby (was Re: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-24 06:55 +0000
Re: Retirement hobby (was Re: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-24 10:00 +0200
Re: Retirement hobby (was Re: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-24 16:34 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-21 23:17 +0000
Re: portable malloc mitchalsup@aol.com (MitchAlsup1) - 2024-10-21 23:52 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-22 01:09 +0000
Re: portable malloc George Neuner <gneuner2@comcast.net> - 2024-10-22 17:26 -0400
Re: portable malloc Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-27 20:42 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-27 21:04 +0000
Re: portable malloc David Schultz <david.schultz@earthlink.net> - 2024-10-27 17:55 -0500
Re: tiny portable malloc John Levine <johnl@taugh.com> - 2024-10-27 23:58 +0000
Re: 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-09 18:10 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 22:22 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 21:37 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:31 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 18:38 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 21:21 +0200
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-10 20:00 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-10 23:54 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-10 21:03 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-10 16:19 -0500
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 13:37 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-11 15:13 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 16:54 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 12:00 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 14:10 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 21:30 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 14:10 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-11 18:55 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-12 00:02 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-11 23:32 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-12 17:16 +0200
Re: 80286 protected mode Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> - 2024-10-12 19:26 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 12:57 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-13 19:36 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-13 19:43 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 23:01 +0300
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 18:33 +0000
Re: 80286 protected mode Niklas Holsti <niklas.holsti@tidorum.invalid> - 2024-10-13 10:31 +0300
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 12:26 +0300
Re: 80286 protected mode Niklas Holsti <niklas.holsti@tidorum.invalid> - 2024-10-13 13:33 +0300
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-13 15:32 -0500
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 13:58 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 05:06 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-12 12:36 -0500
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 18:17 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:37 +0000
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-13 01:25 +0000
Re: 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-12 23:09 -0400
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:32 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 10:56 +0300
Re: 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-13 13:32 -0400
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-13 21:21 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 15:19 +0200
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-14 16:40 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 17:19 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-14 19:08 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 10:53 +0200
memcpy and friend (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2024-10-15 13:12 +0300
Re: memcpy and friend (was: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-15 13:20 +0200
Re: memcpy and friend (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2024-10-15 14:55 +0300
Re: memcpy and friend (was: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-15 14:03 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 06:00 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 05:39 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-12 05:11 -0700
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-13 15:45 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 17:04 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-14 19:02 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-14 22:20 +0300
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:14 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 10:41 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-14 19:39 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:15 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-18 12:47 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-18 14:06 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-18 17:34 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-18 16:19 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-19 19:46 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 12:38 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 14:22 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 14:09 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-15 19:46 +0000
Re: 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-08 16:00 +0000
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-08 16:23 +0000
Re: 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-08 21:03 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-15 05:20 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 11:59 +0300
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 07:01 +0000
Re: Byte ordering antispam@fricas.org (Waldek Hebisch) - 2025-01-03 03:37 +0000
Re: Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-03 08:38 +0000
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-03 18:11 +0000
Re: Byte ordering antispam@fricas.org (Waldek Hebisch) - 2025-01-04 22:40 +0000
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-05 08:54 +0100
80286 protected mode (was: Byte ordering) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-05 11:10 +0000
Re: 80286 protected mode (was: Byte ordering) Robert Swindells <rjs@fdy2.co.uk> - 2025-01-05 18:30 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2025-01-05 16:38 -0500
Re: 80286 protected mode antispam@fricas.org (Waldek Hebisch) - 2025-01-05 21:49 +0000
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2025-01-05 23:01 -0500
Segments (was: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 08:24 +0000
Re: Segments (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2025-01-06 14:41 +0200
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-06 16:05 +0100
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 16:36 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 19:49 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 19:41 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-07 11:45 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-06 22:02 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 22:57 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 11:05 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 14:43 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-07 17:04 +0200
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 15:28 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 16:41 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 20:16 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 21:26 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 22:01 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 23:16 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-08 11:53 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-11 22:31 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 17:46 -0800
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 07:09 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-15 14:00 +0200
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 18:00 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-15 22:28 +0200
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 20:59 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 12:36 +0100
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-16 14:35 +0200
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 13:59 +0100
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-16 16:46 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-16 18:12 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 18:30 +0000
Re: Stacks, was Segments John Levine <johnl@taugh.com> - 2025-01-18 03:08 +0000
Re: Stacks, was Segments Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-01-18 10:59 +0200
Re: Stacks, was Segments John Levine <johnl@taugh.com> - 2025-01-18 19:41 +0000
Re: Stacks, was Segments David Brown <david.brown@hesbynett.no> - 2025-01-19 17:33 +0100
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-19 18:28 +0000
Re: Stacks, was Segments Michael S <already5chosen@yahoo.com> - 2025-01-20 12:55 +0200
Re: Stacks, was Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-20 11:12 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-20 22:05 +0000
Re: Stacks, was Segments Michael S <already5chosen@yahoo.com> - 2025-01-21 01:25 +0200
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-21 00:17 +0000
Re: Stacks, was Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-21 06:21 +0000
Re: Stacks, was Segments Bill Findlay <findlaybill@blueyonder.co.uk> - 2025-01-21 10:36 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-21 17:49 +0000
Re: Stacks, was Segments Stefan Monnier <monnier@iro.umontreal.ca> - 2025-02-03 14:09 -0500
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 21:13 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-03 21:23 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 22:47 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-03 23:11 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-05 12:11 -0500
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-05 14:55 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-05 23:36 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 11:41 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-06 17:13 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 13:51 -0500
Re: Stacks, was Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-02-06 12:06 -0800
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 16:53 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 02:53 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-09 15:45 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-09 21:03 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 02:39 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-07 13:57 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 18:25 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-07 20:32 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-08 22:19 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-10 20:18 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-10 23:40 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 14:04 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-11 20:19 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 20:49 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-11 23:29 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-12 00:34 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-13 16:42 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-13 18:12 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-13 21:48 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-13 22:23 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-14 19:13 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-14 19:51 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-14 21:50 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-15 15:31 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-15 23:28 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-16 19:56 +0000
Re: Stacks, was Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-02-11 09:30 -0800
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 18:19 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-06 20:49 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-05 21:31 +0000
Re: Stacks, was Segments Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-01-19 23:37 +0200
Re: Stacks, was Segments David Brown <david.brown@hesbynett.no> - 2025-01-20 09:00 +0100
Re: Stacks, was Segments Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:26 -0800
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-18 16:30 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-18 17:40 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-16 20:46 +0200
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-16 20:34 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-16 21:02 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 22:16 +0100
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-16 21:40 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 10:20 +0100
Re: Segments "Brian G. Lucas" <bagel99@gmail.com> - 2025-01-17 10:08 -0500
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-17 15:17 +0000
Re: Segments jgd@cix.co.uk (John Dallman) - 2025-01-19 18:49 +0000
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-17 02:22 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 19:52 -0800
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 15:52 +0100
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 15:30 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-17 16:42 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 18:21 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-17 20:08 +0000
Re: Segments George Neuner <gneuner2@comcast.net> - 2025-01-21 20:30 -0500
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 02:19 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 14:58 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 17:45 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 20:00 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 22:25 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 22:44 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 01:39 +0200
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 01:00 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 11:52 +0200
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 17:41 +0200
Re: Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-01-23 14:22 -0500
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 08:14 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 12:23 +0200
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 12:39 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:04 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:31 +0000
Re: Segments Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:18 -0800
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-23 14:02 -0800
Re: Segments George Neuner <gneuner2@comcast.net> - 2025-01-23 11:50 -0500
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 17:18 +0000
Re: stack sizes, Segments John Levine <johnl@taugh.com> - 2025-01-22 02:54 +0000
Re: stack sizes, Segments Michael S <already5chosen@yahoo.com> - 2025-01-22 15:25 +0200
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 15:01 +0000
Re: stack sizes, Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 01:45 +0200
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 01:07 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 02:47 +0000
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:00 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 17:49 +0000
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 19:45 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 20:04 +0000
Re: stack sizes, Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-24 08:11 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-24 14:50 +0000
Re: stack sizes, Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 07:24 +0000
Re: stack sizes, Segments George Neuner <gneuner2@comcast.net> - 2025-01-22 20:28 -0500
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 11:43 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-15 13:42 -0800
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 22:39 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 10:11 +0100
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 13:11 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 13:10 -0800
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 22:23 +0100
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-16 09:15 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 17:24 +0000
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-16 09:55 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 18:23 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 20:22 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-16 19:14 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 20:12 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 15:18 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 23:39 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 17:04 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-17 02:10 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 16:15 +0100
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-17 18:02 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 10:55 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-17 19:27 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 21:05 -0800
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-20 12:29 -0800
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-22 14:15 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-22 18:44 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 23:41 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 10:53 +0000
Re: Segments Andy Valencia <vandys@vsta.org> - 2025-01-11 13:59 -0800
Re: what's a segment, 80286 protected mode John Levine <johnl@taugh.com> - 2025-01-06 18:58 +0000
Re: what's a segment, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 19:45 +0000
Re: what's a segment, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 19:48 +0000
Re: what's a segment, 80286 protected mode Lynn Wheeler <lynn@garlic.com> - 2025-01-06 17:28 -1000
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-05 15:20 +0000
Re: the 286, Byte ordering John Levine <johnl@taugh.com> - 2025-01-05 02:56 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 03:55 +0000
Re: the 286, Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-05 15:15 +0000
Re: the 286, Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-05 15:23 +0000
Re: the 286, Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-05 17:51 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 19:40 +0000
Re: the 286, Byte ordering John Levine <johnl@taugh.com> - 2025-01-05 20:01 +0000
Re: the 286, Byte ordering Brett <ggtgp@yahoo.com> - 2025-01-05 20:46 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 20:55 +0000
Re: the 286, Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-05 22:01 +0100
Re: the 286, Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-06 00:35 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 03:02 +0000
Re: the 286, Byte ordering Michael S <already5chosen@yahoo.com> - 2025-01-06 15:19 +0200
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-05 14:48 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-06 18:50 +0300
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:33 +0000
Re: Byte ordering (was: Whether something is RISC or not) jgd@cix.co.uk (John Dallman) - 2024-10-03 23:49 +0100
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-02 20:23 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 10:07 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-02 16:08 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 13:51 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-02 21:34 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 18:55 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 00:30 +0000
Page 8 of 23 — ← Prev page 1 … 6 7 [8] 9 10 … 23 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-23 21:01 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <58fcd0a722acd8a6e2426596e006d86c@www.novabbs.org> |
| In reply to | #109862 |
On Wed, 23 Oct 2024 19:11:59 +0000, Terje Mathisen wrote: > MitchAlsup1 wrote: >> On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>>> My wife and I will both go on "permanent vacation" starting a week >>>> before Christmas. :-) >>> >>> I'm guessing that permanent vacation will be some mixture of actual >>> vacation and self-chosen "work". In any case I hope you both enjoy >>> the time. >> >> Just remember, retirement does not mean you "stop working" >> it means you "stop working for HIM". > > Exactly! > > I have unlimited amounts of potential/available mapping work, and I do > want to get back to NTP Hackers. > > We recently started (officially) on the 754-2029 revision. Are you going to put in something equivalent to quires ?? > I'm still connected to Mill Computing as well. > > Terje
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-24 07:39 +0200 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfcmj9$2h0pg$1@dont-email.me> |
| In reply to | #109865 |
MitchAlsup1 wrote: > On Wed, 23 Oct 2024 19:11:59 +0000, Terje Mathisen wrote: > >> MitchAlsup1 wrote: >>> On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: >>> >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> >>>>> My wife and I will both go on "permanent vacation" starting a week >>>>> before Christmas. :-) >>>> >>>> I'm guessing that permanent vacation will be some mixture of actual >>>> vacation and self-chosen "work". In any case I hope you both enjoy >>>> the time. >>> >>> Just remember, retirement does not mean you "stop working" >>> it means you "stop working for HIM". >> >> Exactly! >> >> I have unlimited amounts of potential/available mapping work, and I do >> want to get back to NTP Hackers. >> >> We recently started (officially) on the 754-2029 revision. > > Are you going to put in something equivalent to quires ?? I don't know that usage, I thought quires was a typesetting/printing measure? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-24 18:32 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <11a33395baec9abee86a556c799f5318@www.novabbs.org> |
| In reply to | #109868 |
On Thu, 24 Oct 2024 5:39:52 +0000, Terje Mathisen wrote: > MitchAlsup1 wrote: >> On Wed, 23 Oct 2024 19:11:59 +0000, Terje Mathisen wrote: >> >>> MitchAlsup1 wrote: >>>> On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: >>>> >>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>> >>>>>> My wife and I will both go on "permanent vacation" starting a week >>>>>> before Christmas. :-) >>>>> >>>>> I'm guessing that permanent vacation will be some mixture of actual >>>>> vacation and self-chosen "work". In any case I hope you both enjoy >>>>> the time. >>>> >>>> Just remember, retirement does not mean you "stop working" >>>> it means you "stop working for HIM". >>> >>> Exactly! >>> >>> I have unlimited amounts of potential/available mapping work, and I do >>> want to get back to NTP Hackers. >>> >>> We recently started (officially) on the 754-2029 revision. >> >> Are you going to put in something equivalent to quires ?? In posits, a quire is an accumulator with as many binary digits as to cover max-exponent to min-exponent; so one can accumulate an essentially unbounded number of sums without loss of precision --to obtain a sum with a single rounding. > I don't know that usage, I thought quires was a typesetting/printing > measure? > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-28 11:39 +0100 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfnplu$v3e1$1@dont-email.me> |
| In reply to | #109872 |
MitchAlsup1 wrote: > On Thu, 24 Oct 2024 5:39:52 +0000, Terje Mathisen wrote: > >> MitchAlsup1 wrote: >>> On Wed, 23 Oct 2024 19:11:59 +0000, Terje Mathisen wrote: >>> >>>> MitchAlsup1 wrote: >>>>> On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: >>>>> >>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>>> >>>>>>> My wife and I will both go on "permanent vacation" starting a week >>>>>>> before Christmas. :-) >>>>>> >>>>>> I'm guessing that permanent vacation will be some mixture of actual >>>>>> vacation and self-chosen "work". In any case I hope you both >>>>>> enjoy >>>>>> the time. >>>>> >>>>> Just remember, retirement does not mean you "stop working" >>>>> it means you "stop working for HIM". >>>> >>>> Exactly! >>>> >>>> I have unlimited amounts of potential/available mapping work, and I do >>>> want to get back to NTP Hackers. >>>> >>>> We recently started (officially) on the 754-2029 revision. >>> >>> Are you going to put in something equivalent to quires ?? > > In posits, a quire is an accumulator with as many binary digits > as to cover max-exponent to min-exponent; so one can accumulate > an essentially unbounded number of sums without loss of precision > --to obtain a sum with a single rounding. OK, I have seen and used "Super-accumulator" as the term for those, I have thought about implementing one in carry-save redundant form, but that might be more redundancy than really needed? Having a carry bit for every byte should still make it possible to handle several additions/cycle, right? I'm assuming the real cost is in the alignment network needed to route incoming addends into the right slice. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-28 16:30 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfoe7m$12m27$1@dont-email.me> |
| In reply to | #109872 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > In posits, a quire is an accumulator with as many binary digits > as to cover max-exponent to min-exponent; so one can accumulate > an essentially unbounded number of sums without loss of precision > --to obtain a sum with a single rounding. Not restricted to posits, I believe (but the term may differ). At university, I had my programming courses on a Pascal compiler which implemented https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , a hardware implementation was on the 4361 as an option https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2024-10-28 10:12 -0700 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfogl9$hndf$1@dont-email.me> |
| In reply to | #109894 |
On 10/28/2024 9:30 AM, Thomas Koenig wrote: > MitchAlsup1 <mitchalsup@aol.com> schrieb: > >> In posits, a quire is an accumulator with as many binary digits >> as to cover max-exponent to min-exponent; so one can accumulate >> an essentially unbounded number of sums without loss of precision >> --to obtain a sum with a single rounding. > > Not restricted to posits, I believe (but the term may differ). > > At university, I had my programming > courses on a Pascal compiler which implemented > https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , > a hardware implementation was on the 4361 as an option > https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility Another newer alternative. This came up on my news feed. I haven't looked at the details at all, so I can't comment on it. https://arxiv.org/abs/2410.03692 -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-28 18:14 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfok9s$13uvb$1@dont-email.me> |
| In reply to | #109895 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb: > On 10/28/2024 9:30 AM, Thomas Koenig wrote: >> MitchAlsup1 <mitchalsup@aol.com> schrieb: >> >>> In posits, a quire is an accumulator with as many binary digits >>> as to cover max-exponent to min-exponent; so one can accumulate >>> an essentially unbounded number of sums without loss of precision >>> --to obtain a sum with a single rounding. >> >> Not restricted to posits, I believe (but the term may differ). >> >> At university, I had my programming >> courses on a Pascal compiler which implemented >> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >> a hardware implementation was on the 4361 as an option >> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility > > Another newer alternative. This came up on my news feed. I haven't > looked at the details at all, so I can't comment on it. > > https://arxiv.org/abs/2410.03692 That is about another number representation for AI, trying to squeeze more AI performance out of few bits. Personally, I like the approach of doing analog calculation for the low-accuracy dot products that they do, followed by an A/D converter. There is a company doing that, but I forget its name.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2024-10-28 15:24 -0400 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <fyRTO.738628$_o_3.579395@fx17.iad> |
| In reply to | #109894 |
Thomas Koenig wrote: > MitchAlsup1 <mitchalsup@aol.com> schrieb: > >> In posits, a quire is an accumulator with as many binary digits >> as to cover max-exponent to min-exponent; so one can accumulate >> an essentially unbounded number of sums without loss of precision >> --to obtain a sum with a single rounding. > > Not restricted to posits, I believe (but the term may differ). > > At university, I had my programming > courses on a Pascal compiler which implemented > https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , > a hardware implementation was on the 4361 as an option > https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility These would be very large registers. You'd need some way to store and load the these for register spills, fills and task switch, as well as move and manage them. Karlsruhe above has a link to http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf which describes their large accumulators as residing in memory, which avoids the spill/fill/switch issue but with an obvious performance hit: "A floating-point accumulator occupies a 168-byte storage area that is aligned on a 256-byte boundary. An accumulator consists of a four-byte status area on the left, followed by a 164-byte numeric area." The operands are specified by virtual address of their in-memory accumulator. Of course, once you have 168-byte registers people are going to think of new uses for them.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-29 06:33 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfpvke$1f0j6$1@dont-email.me> |
| In reply to | #109899 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb: > Thomas Koenig wrote: >> MitchAlsup1 <mitchalsup@aol.com> schrieb: >> >>> In posits, a quire is an accumulator with as many binary digits >>> as to cover max-exponent to min-exponent; so one can accumulate >>> an essentially unbounded number of sums without loss of precision >>> --to obtain a sum with a single rounding. >> >> Not restricted to posits, I believe (but the term may differ). >> >> At university, I had my programming >> courses on a Pascal compiler which implemented >> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >> a hardware implementation was on the 4361 as an option >> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility > > These would be very large registers. You'd need some way to store and load > the these for register spills, fills and task switch, as well as move > and manage them. > > Karlsruhe above has a link to > http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf > > which describes their large accumulators as residing in memory, which > avoids the spill/fill/switch issue but with an obvious performance hit: > > "A floating-point accumulator occupies a 168-byte storage area that is > aligned on a 256-byte boundary. An accumulator consists of a four-byte > status area on the left, followed by a 164-byte numeric area." > > The operands are specified by virtual address of their in-memory accumulator. Makes sense, given the time this was implemented. This was also a mid-range machine, not a number cruncher. I do not find the number of cycles that the instructions took. But this was also for hex floating point. A similar scheme for IEEE double would need a bit more than 2048 bits, so five AVX-512 registers. > Of course, once you have 168-byte registers people are going to > think of new uses for them. SIMD from hell? Pretend that a CPU is a graphics card? :-)
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-29 08:07 +0100 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfq1k6$1fabu$1@dont-email.me> |
| In reply to | #109902 |
Thomas Koenig wrote: > EricP <ThatWouldBeTelling@thevillage.com> schrieb: >> Thomas Koenig wrote: >>> MitchAlsup1 <mitchalsup@aol.com> schrieb: >>> >>>> In posits, a quire is an accumulator with as many binary digits >>>> as to cover max-exponent to min-exponent; so one can accumulate >>>> an essentially unbounded number of sums without loss of precision >>>> --to obtain a sum with a single rounding. >>> >>> Not restricted to posits, I believe (but the term may differ). >>> >>> At university, I had my programming >>> courses on a Pascal compiler which implemented >>> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >>> a hardware implementation was on the 4361 as an option >>> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility >> >> These would be very large registers. You'd need some way to store and load >> the these for register spills, fills and task switch, as well as move >> and manage them. >> >> Karlsruhe above has a link to >> http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf >> >> which describes their large accumulators as residing in memory, which >> avoids the spill/fill/switch issue but with an obvious performance hit: >> >> "A floating-point accumulator occupies a 168-byte storage area that is >> aligned on a 256-byte boundary. An accumulator consists of a four-byte >> status area on the left, followed by a 164-byte numeric area." >> >> The operands are specified by virtual address of their in-memory accumulator. > > Makes sense, given the time this was implemented. This was also a > mid-range machine, not a number cruncher. I do not find the > number of cycles that the instructions took. At the time, memory was just a few clock cycles away from the CPU, so not really that problematic. Today, such a super-accumulator would stay in $L1 most of the time, or at least the central, in-use cache line of it, would do so. > > But this was also for hex floating point. A similar scheme for IEEE > double would need a bit more than 2048 bits, so five AVX-512 registers. With 1312 bits of storage, their fp inputs (hex fp?) must have had a smaller exponent range than ieee double. If I was implementing this I would probably want some redundant storage to limit carry propagation, so maybe 48 bits per 64-bit chunk, in which case I would need about 2800 bits or 6 of those 512-bit SIMD regs. > SIMD from hell? Pretend that a CPU is a graphics card? :-) Writing this as a throughput task could make it fit better within a GPU? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-29 19:57 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfren5$1mnvr$1@dont-email.me> |
| In reply to | #109903 |
Terje Mathisen <terje.mathisen@tmsw.no> schrieb: > Thomas Koenig wrote: >> EricP <ThatWouldBeTelling@thevillage.com> schrieb: >>> Thomas Koenig wrote: >>>> MitchAlsup1 <mitchalsup@aol.com> schrieb: >>>> >>>>> In posits, a quire is an accumulator with as many binary digits >>>>> as to cover max-exponent to min-exponent; so one can accumulate >>>>> an essentially unbounded number of sums without loss of precision >>>>> --to obtain a sum with a single rounding. >>>> >>>> Not restricted to posits, I believe (but the term may differ). >>>> >>>> At university, I had my programming >>>> courses on a Pascal compiler which implemented >>>> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >>>> a hardware implementation was on the 4361 as an option >>>> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility >>> >>> These would be very large registers. You'd need some way to store and load >>> the these for register spills, fills and task switch, as well as move >>> and manage them. >>> >>> Karlsruhe above has a link to >>> http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf >>> >>> which describes their large accumulators as residing in memory, which >>> avoids the spill/fill/switch issue but with an obvious performance hit: >>> >>> "A floating-point accumulator occupies a 168-byte storage area that is >>> aligned on a 256-byte boundary. An accumulator consists of a four-byte >>> status area on the left, followed by a 164-byte numeric area." >>> >>> The operands are specified by virtual address of their in-memory accumulator. >> >> Makes sense, given the time this was implemented. This was also a >> mid-range machine, not a number cruncher. I do not find the >> number of cycles that the instructions took. > > At the time, memory was just a few clock cycles away from the CPU, so > not really that problematic. Today, such a super-accumulator would stay > in $L1 most of the time, or at least the central, in-use cache line of > it, would do so. > >> >> But this was also for hex floating point. A similar scheme for IEEE >> double would need a bit more than 2048 bits, so five AVX-512 registers. > > With 1312 bits of storage, their fp inputs (hex fp?) must have had a > smaller exponent range than ieee double. IBM format had one sign bit, seven exponent bits and six or fourteen hexadecimal digits for single and double precision, respectively. (Insert fear and loathing for hex float here).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-29 20:21 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <2498f2668ce4a728dbae17d5bf5e8d80@www.novabbs.org> |
| In reply to | #109906 |
On Tue, 29 Oct 2024 19:57:25 +0000, Thomas Koenig wrote: > Terje Mathisen <terje.mathisen@tmsw.no> schrieb: >> Thomas Koenig wrote: >>> EricP <ThatWouldBeTelling@thevillage.com> schrieb: >>>> Thomas Koenig wrote: >>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb: >>>>> >>>>>> In posits, a quire is an accumulator with as many binary digits >>>>>> as to cover max-exponent to min-exponent; so one can accumulate >>>>>> an essentially unbounded number of sums without loss of precision >>>>>> --to obtain a sum with a single rounding. >>>>> >>>>> Not restricted to posits, I believe (but the term may differ). >>>>> >>>>> At university, I had my programming >>>>> courses on a Pascal compiler which implemented >>>>> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >>>>> a hardware implementation was on the 4361 as an option >>>>> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility >>>> >>>> These would be very large registers. You'd need some way to store and >>>> load >>>> the these for register spills, fills and task switch, as well as move >>>> and manage them. >>>> >>>> Karlsruhe above has a link to >>>> http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf >>>> >>>> which describes their large accumulators as residing in memory, which >>>> avoids the spill/fill/switch issue but with an obvious performance hit: >>>> >>>> "A floating-point accumulator occupies a 168-byte storage area that is >>>> aligned on a 256-byte boundary. An accumulator consists of a four-byte >>>> status area on the left, followed by a 164-byte numeric area." >>>> >>>> The operands are specified by virtual address of their in-memory >>>> accumulator. >>> >>> Makes sense, given the time this was implemented. This was also a >>> mid-range machine, not a number cruncher. I do not find the >>> number of cycles that the instructions took. >> >> At the time, memory was just a few clock cycles away from the CPU, so >> not really that problematic. Today, such a super-accumulator would stay >> in $L1 most of the time, or at least the central, in-use cache line of >> it, would do so. >> >>> >>> But this was also for hex floating point. A similar scheme for IEEE >>> double would need a bit more than 2048 bits, so five AVX-512 registers. >> >> With 1312 bits of storage, their fp inputs (hex fp?) must have had a >> smaller exponent range than ieee double. Terje--IEEE is all capitals. > IBM format had one sign bit, seven exponent bits and six or fourteen > hexadecimal digits for single and double precision, respectively. The span of an IEEE double "quire" would be the exponent-2 + fraction. a) The most significant non-infinity has an exponent of +1023 b) The least significant non-underflow has an exponent of -1023 Leaving a span of 2046 bits plus 52 denormalized bits or 2098-bits or 262 bytes. One note: When left in memory, one indexes the accumulator with the (exponent>>6) and fetches 2 doublewords. A carry out requires accessing the 3rd doubleword (possibly transitively). > (Insert fear and loathing for hex float here). Heck, watching Kahan's notes on FP problems leaves one in fear of binary floating point representations.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-29 21:27 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfrk01$1ngit$1@dont-email.me> |
| In reply to | #109907 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: >> (Insert fear and loathing for hex float here). > > Heck, watching Kahan's notes on FP problems leaves one in fear of > binary floating point representations. True, but... hex float is so much worse. "Hacker's delight" has some choice words there, and the author worked for IBM :-)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-29 20:30 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <oBbUO.55879$5Cq3.53599@fx06.iad> |
| In reply to | #109906 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Terje Mathisen <terje.mathisen@tmsw.no> schrieb: >> Thomas Koenig wrote: >>> EricP <ThatWouldBeTelling@thevillage.com> schrieb: >>>> Thomas Koenig wrote: >>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb: >>>>> >>>>>> In posits, a quire is an accumulator with as many binary digits >>>>>> as to cover max-exponent to min-exponent; so one can accumulate >>>>>> an essentially unbounded number of sums without loss of precision >>>>>> --to obtain a sum with a single rounding. >>>>> >>>>> Not restricted to posits, I believe (but the term may differ). >>>>> >>>>> At university, I had my programming >>>>> courses on a Pascal compiler which implemented >>>>> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >>>>> a hardware implementation was on the 4361 as an option >>>>> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility >>>> >>>> These would be very large registers. You'd need some way to store and load >>>> the these for register spills, fills and task switch, as well as move >>>> and manage them. >>>> >>>> Karlsruhe above has a link to >>>> http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf >>>> >>>> which describes their large accumulators as residing in memory, which >>>> avoids the spill/fill/switch issue but with an obvious performance hit: >>>> >>>> "A floating-point accumulator occupies a 168-byte storage area that is >>>> aligned on a 256-byte boundary. An accumulator consists of a four-byte >>>> status area on the left, followed by a 164-byte numeric area." >>>> >>>> The operands are specified by virtual address of their in-memory accumulator. >>> >>> Makes sense, given the time this was implemented. This was also a >>> mid-range machine, not a number cruncher. I do not find the >>> number of cycles that the instructions took. >> >> At the time, memory was just a few clock cycles away from the CPU, so >> not really that problematic. Today, such a super-accumulator would stay >> in $L1 most of the time, or at least the central, in-use cache line of >> it, would do so. >> >>> >>> But this was also for hex floating point. A similar scheme for IEEE >>> double would need a bit more than 2048 bits, so five AVX-512 registers. >> >> With 1312 bits of storage, their fp inputs (hex fp?) must have had a >> smaller exponent range than ieee double. > >IBM format had one sign bit, seven exponent bits and six or fourteen >hexadecimal digits for single and double precision, respectively. >(Insert fear and loathing for hex float here). Burroughs Medium systems had four exponent sign bits, eight exponent bits, four mantissa sign bits, and up to 400 mantissa bits. BCD, so that's an exponent range of -99 to +99 and a 1 to 100 digit mantissa.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2024-10-29 14:29 -0400 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <zQ9UO.740256$_o_3.500221@fx17.iad> |
| In reply to | #109902 |
Thomas Koenig wrote: > EricP <ThatWouldBeTelling@thevillage.com> schrieb: >> Thomas Koenig wrote: >>> MitchAlsup1 <mitchalsup@aol.com> schrieb: >>> >>>> In posits, a quire is an accumulator with as many binary digits >>>> as to cover max-exponent to min-exponent; so one can accumulate >>>> an essentially unbounded number of sums without loss of precision >>>> --to obtain a sum with a single rounding. >>> Not restricted to posits, I believe (but the term may differ). >>> >>> At university, I had my programming >>> courses on a Pascal compiler which implemented >>> https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic , >>> a hardware implementation was on the 4361 as an option >>> https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility >> These would be very large registers. You'd need some way to store and load >> the these for register spills, fills and task switch, as well as move >> and manage them. >> >> Karlsruhe above has a link to >> http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf >> >> which describes their large accumulators as residing in memory, which >> avoids the spill/fill/switch issue but with an obvious performance hit: >> >> "A floating-point accumulator occupies a 168-byte storage area that is >> aligned on a 256-byte boundary. An accumulator consists of a four-byte >> status area on the left, followed by a 164-byte numeric area." >> >> The operands are specified by virtual address of their in-memory accumulator. > > Makes sense, given the time this was implemented. This was also a > mid-range machine, not a number cruncher. I do not find the > number of cycles that the instructions took. > > But this was also for hex floating point. A similar scheme for IEEE > double would need a bit more than 2048 bits, so five AVX-512 registers. Right, something like 2048+52+3 = 2103 bits for data, plus some status bits. For x64 they could overlay it onto AVX-512 register file in groups of 5 and use existing SIMD instructions for management. That would allow them to pack 3 accumulators into registers z0..z14. For RISC-V they have the large vector registers, 32 * 256-bits each I think, so again 3 accumulators. So its a plausible proposition.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-10-29 14:19 -0400 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <jwvfroe23kb.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #109872 |
> In posits, a quire is an accumulator with as many binary digits
> as to cover max-exponent to min-exponent; so one can accumulate
> an essentially unbounded number of sums without loss of precision
> --to obtain a sum with a single rounding.
IIUC you can already implement such a thing with standard IEEE
operations, based on the "standard" Knuth approach of computing the
exact result of `a + b` as the sum of x + y where x is the "normal" sum
of a + b (and hence y holds the remaining bits lost to rounding).
I wonder how often this is used in practice.
Intuitively it should be possible to make it reasonably efficient, where
you first compute the "naive" sum but also keep the N remaining numbers
representing the bits lost to each of the N roundings. I.e. you take in
a vector "as" of N numbers and return a pair of the "naive" sum plus
a vector of N rounding errors.
Σ as => (round(Σ As), rs)
such that round(Σ As) = the naive IEEE sum of as
and Σ as = round(Σ As) + Σ rs
You can then recursively compute "Σ rs" in the same way. At each step of
the recursion you can compute round(Σ |rs|) to estimate an upper bound
on the remaining error and thus stop when that error is smaller than
1 ULP or somesuch.
AFAICT, if your sum is well-conditioned you should need at most 2 steps
of the recursion, and I suspect you can predict when the next estimated
error will be too small before you start the last recursion, so the last
recursion might skip the generation of the last "rs" vector.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-23 21:09 +0200 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfbhls$26trl$1@dont-email.me> |
| In reply to | #109858 |
Tim Rentsch wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: > >> Tim Rentsch wrote: >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> >>> [C vs assembly] >>> >>>> For near-light-speed code I used to write it first in C, optimize >>>> that, then I would translate it into (inline) asm and re-optimize >>>> based on having the full cpu architecture available, before in the >>>> final stage I would use the asm experience to tweak the C just >>>> enough to let the compiler generate machine code quite close >>>> (90+%) to my best asm, while still being portable to any cpu with >>>> more or less the same capabilities. >>>> >>>> One example: When I won an international competition to write the >>>> fastest Pentomino solver (capable of finding all 2339/1010/368/2 >>>> solutions of the 6x10/5x12/4x15/3x20 layouts), I also included the >>>> portable C version. >>>> >>>> My asm submission was twice as fast as anyone else, while the C >>>> version was still fast enough that a couple of years later I got a >>>> prize in the mail: Someone in France had submitted my C code, >>>> with my name & address, to a similar competition there and it was >>>> still faster than anyone else. :-) >>> >>> I hope you will consider writing a book, "Writing Fast Code" (or >>> something along those lines). The core of the book could be, oh, >>> let's say between 8 and 12 case studies, starting with a problem >>> statement and tracing through the process that you followed, or >>> would follow, with stops along the way showing the code at each >>> of the different stages. >>> >>> If you do write such a book I guarantee I will want to buy one. >> >> Thank you Tim! > > I know from past experience you are good at this. I would love > to hear what you have to say. > >> Probably not a book but I would consider writing a series of blog >> posts similar to that, now that I am about to retire: > > You could try writing one blog post a month on the subject. By > this time next year you will have plenty of material and be well > on your way to putting a book together. (First drafts are always > the hardest part...) I'm sure you're right! > >> My wife and I will both go on "permanent vacation" starting a week >> before Christmas. :-) > > I'm guessing that permanent vacation will be some mixture of actual > vacation and self-chosen "work". In any case I hope you both enjoy > the time. > > P.S. Is the email address in your message a good way to reach you? > Yes, that is my personal domain, so it won't be affected by my retirement. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-24 06:55 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <2024Oct24.085520@mips.complang.tuwien.ac.at> |
| In reply to | #109858 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Terje Mathisen <terje.mathisen@tmsw.no> writes: >> Probably not a book but I would consider writing a series of blog >> posts similar to that, now that I am about to retire: > >You could try writing one blog post a month on the subject. By >this time next year you will have plenty of material and be well >on your way to putting a book together. (First drafts are always >the hardest part...) One thing I have thought of is a wiki of optimization techniques that contains descriptions of the techniques and case studies, but I have not yet implemented this idea. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-24 10:00 +0200 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfcuqg$2i7bt$1@dont-email.me> |
| In reply to | #109869 |
On 24/10/2024 08:55, Anton Ertl wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> Probably not a book but I would consider writing a series of blog >>> posts similar to that, now that I am about to retire: >> >> You could try writing one blog post a month on the subject. By >> this time next year you will have plenty of material and be well >> on your way to putting a book together. (First drafts are always >> the hardest part...) > > One thing I have thought of is a wiki of optimization techniques that > contains descriptions of the techniques and case studies, but I have > not yet implemented this idea. > Would it make sense to start something under Wikibooks on Wikipedia? I have no experience with it myself, but it looks to me like a way to have a collaborative collection of related knowledge. It could provide the structure and framework, saving you (plural) from having to set up a wiki, blog, or whatever.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-24 16:34 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <2024Oct24.183445@mips.complang.tuwien.ac.at> |
| In reply to | #109870 |
David Brown <david.brown@hesbynett.no> writes: >On 24/10/2024 08:55, Anton Ertl wrote: >> One thing I have thought of is a wiki of optimization techniques that >> contains descriptions of the techniques and case studies, but I have >> not yet implemented this idea. >> > >Would it make sense to start something under Wikibooks on Wikipedia? Yes, I was thinking about that. In the bookshelf on computer programming <https://en.wikibooks.org/wiki/Shelf:Computer_programming> there are two "Books nearing completion" that have "Opti" in the title: https://en.wikibooks.org/wiki/Optimizing_Code_for_Speed https://en.wikibooks.org/wiki/Optimizing_C%2B%2B Looking at the contents of the former, it's rather short and high-level, and I don't think it's intended for the kind of project we have in mind. The latter is more in the direction I have in mind, but the limitation to C++ is, well, limiting. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 8 of 23 — ← Prev page 1 … 6 7 [8] 9 10 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web