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 4 of 23 — ← Prev page 1 2 3 [4] 5 6 … 23 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-07 07:33 +0000 |
| Subject | 80286 protected mode |
| Message-ID | <2024Oct7.093314@mips.complang.tuwien.ac.at> |
| In reply to | #109494 |
jgd@cix.co.uk (John Dallman) writes: >In article <2024Oct6.150415@mips.complang.tuwien.ac.at>, >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> I find it hard to believe that many customers would ask Intel >> for something the 80286 protected mode with segments limited >> to 64KB, and even if, that Intel would listen to them. This >> looks much more like an idee fixe to me that one or more of >> the 286 project leaders had, and all customer input was made >> to fit into this idea, or was ignored. > >Either half-remembered from older architectures, or re-invented and >considered viable a decade after the original inventors had learned >better. Here's another speculation: The 286 protected mode was what they already had in mind when they built the 8086, but there were not enough transistors to do it in the 8086, so they did real mode, and in the 80286 they finally got around to it. And the idea was (like AFAIK in the iAPX432) to have one segment per object and per procedure, i.e., the large memory model. The smaller memory models were possible, but not really intended. The Huge memory model was completely alien to protected mode, as was direct hardware access, as was common on the IBM PC. And computing with segment register contents was also not intended. If programmers had used the 8086 in the intended way, porting to protected mode would have been easy, but the programmers used it in other ways, and the protected mode flopped. Would it have been differently if the 8086/8088 had already had protected mode? I think that having one segment per object would have been too inefficient, and also that 8192 segments is not enough for that kind of usage, given 640KB of RAM (not to mention the 16MB that the 286 supported); and with 640KB having the segments limited to 64KB is too restrictive for a number of applications. - 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 | Lars Poulsen <lars@cleo.beagle-ears.com> |
|---|---|
| Date | 2024-10-07 12:42 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <slrnvg7lpc.25gut.lars@cleo.beagle-ears.com> |
| In reply to | #109515 |
On 2024-10-07, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Here's another speculation: The 286 protected mode was what they > already had in mind when they built the 8086, but there were not > enough transistors to do it in the 8086, so they did real mode, and in > the 80286 they finally got around to it. And the idea was (like AFAIK > in the iAPX432) to have one segment per object and per procedure, > i.e., the large memory model. The smaller memory models were > possible, but not really intended. The Huge memory model was > completely alien to protected mode, as was direct hardware access, as > was common on the IBM PC. And computing with segment register > contents was also not intended. > > If programmers had used the 8086 in the intended way, porting to > protected mode would have been easy, but the programmers used it in > other ways, and the protected mode flopped. > > Would it have been differently if the 8086/8088 had already had > protected mode? I think that having one segment per object would have > been too inefficient, and also that 8192 segments is not enough for > that kind of usage, given 640KB of RAM (not to mention the 16MB that > the 286 supported); and with 640KB having the segments limited to 64KB > is too restrictive for a number of applications. I completely agree. Back when the 8086 was designed, 640K seemed like a lot. They never expected it to grow beyond the minframes of their time.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-07 15:17 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve0n1h$1nqlh$1@dont-email.me> |
| In reply to | #109523 |
Lars Poulsen wrote: > On 2024-10-07, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Here's another speculation: The 286 protected mode was what they >> already had in mind when they built the 8086, but there were not >> enough transistors to do it in the 8086, so they did real mode, and in >> the 80286 they finally got around to it. And the idea was (like AFAIK >> in the iAPX432) to have one segment per object and per procedure, >> i.e., the large memory model. The smaller memory models were >> possible, but not really intended. The Huge memory model was >> completely alien to protected mode, as was direct hardware access, as >> was common on the IBM PC. And computing with segment register >> contents was also not intended. >> >> If programmers had used the 8086 in the intended way, porting to >> protected mode would have been easy, but the programmers used it in >> other ways, and the protected mode flopped. >> >> Would it have been differently if the 8086/8088 had already had >> protected mode? I think that having one segment per object would have >> been too inefficient, and also that 8192 segments is not enough for >> that kind of usage, given 640KB of RAM (not to mention the 16MB that >> the 286 supported); and with 640KB having the segments limited to 64KB >> is too restrictive for a number of applications. > > I completely agree. Back when the 8086 was designed, 640K seemed like a > lot. They never expected it to grow beyond the minframes of their time. 640K was an artifact of the frame buffer placement selected by the original IBM PC, it could just as well have been 900+ K. Afair the PC also mishandled interrupt handling? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-07 17:45 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241007174519.00001d47@yahoo.com> |
| In reply to | #109524 |
On Mon, 7 Oct 2024 15:17:36 +0200 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > Lars Poulsen wrote: > > On 2024-10-07, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > > >> Here's another speculation: The 286 protected mode was what they > >> already had in mind when they built the 8086, but there were not > >> enough transistors to do it in the 8086, so they did real mode, > >> and in the 80286 they finally got around to it. And the idea was > >> (like AFAIK in the iAPX432) to have one segment per object and per > >> procedure, i.e., the large memory model. The smaller memory > >> models were possible, but not really intended. The Huge memory > >> model was completely alien to protected mode, as was direct > >> hardware access, as was common on the IBM PC. And computing with > >> segment register contents was also not intended. > >> > >> If programmers had used the 8086 in the intended way, porting to > >> protected mode would have been easy, but the programmers used it in > >> other ways, and the protected mode flopped. > >> > >> Would it have been differently if the 8086/8088 had already had > >> protected mode? I think that having one segment per object would > >> have been too inefficient, and also that 8192 segments is not > >> enough for that kind of usage, given 640KB of RAM (not to mention > >> the 16MB that the 286 supported); and with 640KB having the > >> segments limited to 64KB is too restrictive for a number of > >> applications. > > > > I completely agree. Back when the 8086 was designed, 640K seemed > > like a lot. They never expected it to grow beyond the minframes of > > their time. > > 640K was an artifact of the frame buffer placement selected by the > original IBM PC, it could just as well have been 900+ K. > > Afair the PC also mishandled interrupt handling? > > Terje > Yes it did. IIRC, Intel recommended interrupt slots 0 to 31 to be reserved for hardware interrupts, but IBM ignored their recommendation and put various BIOS at slots 16 to 31.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-07 21:55 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve1lbp$1s0ug$5@dont-email.me> |
| In reply to | #109524 |
On Mon, 7 Oct 2024 15:17:36 +0200, Terje Mathisen wrote: > 640K was an artifact of the frame buffer placement selected by the > original IBM PC, it could just as well have been 900+ K. Another MS-DOS machine, the DEC Rainbow, could be upgraded to 896KiB of RAM. I know because our Comp Sci department had one. That was the one with the dual Z80 and 8086 (8088?) chips, so it could run 3 different OSes: CP/M-80, CP/M-86, and MS-DOS. Not more than one at once, though (that would have been some trick). But it was not fully hardware-compatible with the IBM PC.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-08 10:44 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve2re6$24hio$3@dont-email.me> |
| In reply to | #109557 |
Lawrence D'Oliveiro wrote: > On Mon, 7 Oct 2024 15:17:36 +0200, Terje Mathisen wrote: > >> 640K was an artifact of the frame buffer placement selected by the >> original IBM PC, it could just as well have been 900+ K. > > Another MS-DOS machine, the DEC Rainbow, could be upgraded to 896KiB of > RAM. I know because our Comp Sci department had one. > > That was the one with the dual Z80 and 8086 (8088?) chips, so it could run > 3 different OSes: CP/M-80, CP/M-86, and MS-DOS. Not more than one at once, > though (that would have been some trick). > > But it was not fully hardware-compatible with the IBM PC. When I was hired by Hydro in 1984, my boss decided that he liked the Rainbow best, so he took responsibility for that model, while I got all IBM compatibles: Hardware/Software/add-on cards/etc for a company with 77K employees in 130 countries. By the time Hydro was broken up into 3-4 separate companies (around 2008?) I had to share that responsibility with 2-300 other people. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2024-10-07 16:32 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve12f1$1pgdd$1@dont-email.me> |
| In reply to | #109515 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > jgd@cix.co.uk (John Dallman) writes: >> In article <2024Oct6.150415@mips.complang.tuwien.ac.at>, >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >> >>> I find it hard to believe that many customers would ask Intel >>> for something the 80286 protected mode with segments limited >>> to 64KB, and even if, that Intel would listen to them. This >>> looks much more like an idee fixe to me that one or more of >>> the 286 project leaders had, and all customer input was made >>> to fit into this idea, or was ignored. >> >> Either half-remembered from older architectures, or re-invented and >> considered viable a decade after the original inventors had learned >> better. > > Here's another speculation: The 286 protected mode was what they > already had in mind when they built the 8086, but there were not > enough transistors to do it in the 8086, so they did real mode, and in > the 80286 they finally got around to it. And the idea was (like AFAIK > in the iAPX432) to have one segment per object and per procedure, > i.e., the large memory model. The smaller memory models were > possible, but not really intended. The Huge memory model was > completely alien to protected mode, as was direct hardware access, as > was common on the IBM PC. And computing with segment register > contents was also not intended. > > If programmers had used the 8086 in the intended way, porting to > protected mode would have been easy, but the programmers used it in > other ways, and the protected mode flopped. > > Would it have been differently if the 8086/8088 had already had > protected mode? I think that having one segment per object would have > been too inefficient, and also that 8192 segments is not enough for > that kind of usage, given 640KB of RAM (not to mention the 16MB that > the 286 supported); and with 640KB having the segments limited to 64KB > is too restrictive for a number of applications. I have for decades pointed out that the four bit offset of 8086 segments was planned obsolescence. An 8 bit offset with 16 megabytes of address space would have kept the low end alive for too long in Intels eyes. To control the market you need to drive complexity onto the users, which weeds out licensed competition. Everything Intel did drove needless patentable complexity into the follow on CPUs. > - anton
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-07 20:03 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241007200335.000047b6@yahoo.com> |
| In reply to | #109527 |
On Mon, 7 Oct 2024 16:32:34 -0000 (UTC) Brett <ggtgp@yahoo.com> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > jgd@cix.co.uk (John Dallman) writes: > >> In article <2024Oct6.150415@mips.complang.tuwien.ac.at>, > >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> > >>> I find it hard to believe that many customers would ask Intel > >>> for something the 80286 protected mode with segments limited > >>> to 64KB, and even if, that Intel would listen to them. This > >>> looks much more like an idee fixe to me that one or more of > >>> the 286 project leaders had, and all customer input was made > >>> to fit into this idea, or was ignored. > >> > >> Either half-remembered from older architectures, or re-invented and > >> considered viable a decade after the original inventors had learned > >> better. > > > > Here's another speculation: The 286 protected mode was what they > > already had in mind when they built the 8086, but there were not > > enough transistors to do it in the 8086, so they did real mode, and > > in the 80286 they finally got around to it. And the idea was (like > > AFAIK in the iAPX432) to have one segment per object and per > > procedure, i.e., the large memory model. The smaller memory models > > were possible, but not really intended. The Huge memory model was > > completely alien to protected mode, as was direct hardware access, > > as was common on the IBM PC. And computing with segment register > > contents was also not intended. > > > > If programmers had used the 8086 in the intended way, porting to > > protected mode would have been easy, but the programmers used it in > > other ways, and the protected mode flopped. > > > > Would it have been differently if the 8086/8088 had already had > > protected mode? I think that having one segment per object would > > have been too inefficient, and also that 8192 segments is not > > enough for that kind of usage, given 640KB of RAM (not to mention > > the 16MB that the 286 supported); and with 640KB having the > > segments limited to 64KB is too restrictive for a number of > > applications. > > I have for decades pointed out that the four bit offset of 8086 > segments was planned obsolescence. An 8 bit offset with 16 megabytes > of address space would have kept the low end alive for too long in > Intels eyes. To control the market you need to drive complexity onto > the users, which weeds out licensed competition. > > Everything Intel did drove needless patentable complexity into the > follow on CPUs. > > > - anton > > > You forget that Intel didn't and couldn't expect that 8088 would be such stunning success. Not just that. According to Oral history they didn't realize what they have in hands until 1983.
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2024-10-07 17:40 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve16dk$1q3ek$1@dont-email.me> |
| In reply to | #109530 |
Michael S <already5chosen@yahoo.com> wrote: > On Mon, 7 Oct 2024 16:32:34 -0000 (UTC) > Brett <ggtgp@yahoo.com> wrote: > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> jgd@cix.co.uk (John Dallman) writes: >>>> In article <2024Oct6.150415@mips.complang.tuwien.ac.at>, >>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>>> >>>>> I find it hard to believe that many customers would ask Intel >>>>> for something the 80286 protected mode with segments limited >>>>> to 64KB, and even if, that Intel would listen to them. This >>>>> looks much more like an idee fixe to me that one or more of >>>>> the 286 project leaders had, and all customer input was made >>>>> to fit into this idea, or was ignored. >>>> >>>> Either half-remembered from older architectures, or re-invented and >>>> considered viable a decade after the original inventors had learned >>>> better. >>> >>> Here's another speculation: The 286 protected mode was what they >>> already had in mind when they built the 8086, but there were not >>> enough transistors to do it in the 8086, so they did real mode, and >>> in the 80286 they finally got around to it. And the idea was (like >>> AFAIK in the iAPX432) to have one segment per object and per >>> procedure, i.e., the large memory model. The smaller memory models >>> were possible, but not really intended. The Huge memory model was >>> completely alien to protected mode, as was direct hardware access, >>> as was common on the IBM PC. And computing with segment register >>> contents was also not intended. >>> >>> If programmers had used the 8086 in the intended way, porting to >>> protected mode would have been easy, but the programmers used it in >>> other ways, and the protected mode flopped. >>> >>> Would it have been differently if the 8086/8088 had already had >>> protected mode? I think that having one segment per object would >>> have been too inefficient, and also that 8192 segments is not >>> enough for that kind of usage, given 640KB of RAM (not to mention >>> the 16MB that the 286 supported); and with 640KB having the >>> segments limited to 64KB is too restrictive for a number of >>> applications. >> >> I have for decades pointed out that the four bit offset of 8086 >> segments was planned obsolescence. An 8 bit offset with 16 megabytes >> of address space would have kept the low end alive for too long in >> Intels eyes. To control the market you need to drive complexity onto >> the users, which weeds out licensed competition. >> >> Everything Intel did drove needless patentable complexity into the >> follow on CPUs. >> > You forget that Intel didn't and couldn't expect that 8088 would be > such stunning success. Not just that. According to Oral history they > didn't realize what they have in hands until 1983. Today the 8088 is a joke microcontroller, that was not the case when it was introduced. The 8088 was a major project with major profits, not some afterthought. Yes the success eventually dwarfed expectations, but that was a lightning strike, the plan was in place and so the lightning strike could be taken advantage of to build a monopoly, instead of the small walled fortress with moat that was planned. You saw what happened to the MC680x0 series that did not have a moat or a good plan.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-07 21:52 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve1l6v$1s0ug$4@dont-email.me> |
| In reply to | #109515 |
On Mon, 07 Oct 2024 07:33:14 GMT, Anton Ertl wrote: > Here's another speculation: The 286 protected mode was what they already > had in mind when they built the 8086, but there were not enough > transistors to do it in the 8086, so they did real mode, and in the > 80286 they finally got around to it. Nah. Intel were never capable of thinking that far ahead. Each bodge to the x80/x86 line was made just to take the product one step further, without regard to any future growth. The 8086/8088 was designed to make it easy to port across 8080/8085 code, with the segment registers tacked on to give you a bit more address space if you needed it, if you could figure out how to use it -- that was their idea of “technological progress”. And then the next step was to add this new-fangled “hardware memory protection” that the folks using the Big Computers were always going on about, so they bodged the 8086 segmentation scheme into kind of a memory- management scheme in the 80286. Finally, in the 80386, they gave everybody the large, linear address space they had been crying out for. That is, everybody who wasn’t already using more sensibly-designed chips from companies like Motorola, NatSemi and the RISC vendors.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-07 23:13 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> |
| In reply to | #109515 |
On Mon, 7 Oct 2024 7:33:14 +0000, Anton Ertl wrote: > jgd@cix.co.uk (John Dallman) writes: >>In article <2024Oct6.150415@mips.complang.tuwien.ac.at>, >>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >> >>> I find it hard to believe that many customers would ask Intel >>> for something the 80286 protected mode with segments limited >>> to 64KB, and even if, that Intel would listen to them. This >>> looks much more like an idee fixe to me that one or more of >>> the 286 project leaders had, and all customer input was made >>> to fit into this idea, or was ignored. >> >>Either half-remembered from older architectures, or re-invented and >>considered viable a decade after the original inventors had learned >>better. > > Here's another speculation: The 286 protected mode was what they > already had in mind when they built the 8086, but there were not > enough transistors to do it in the 8086, so they did real mode, and in > the 80286 they finally got around to it. And the idea was (like AFAIK > in the iAPX432) to have one segment per object and per procedure, > i.e., the large memory model. The smaller memory models were > possible, but not really intended. The Huge memory model was > completely alien to protected mode, as was direct hardware access, as > was common on the IBM PC. And computing with segment register > contents was also not intended. Is protected mode not "how Pascal" thinks of memory and objects in memory ?? > If programmers had used the 8086 in the intended way, porting to > protected mode would have been easy, but the programmers used it in > other ways, and the protected mode flopped. Whereas by the time 286 got out, everybody was wanting flat memory ala C. > Would it have been differently if the 8086/8088 had already had > protected mode? I think that having one segment per object would have > been too inefficient, and also that 8192 segments is not enough for > that kind of usage, given 640KB of RAM (not to mention the 16MB that > the 286 supported); and with 640KB having the segments limited to 64KB > is too restrictive for a number of applications. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-08 06:16 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve2inb$23gqs$1@dont-email.me> |
| In reply to | #109558 |
On Mon, 7 Oct 2024 23:13:25 +0000, MitchAlsup1 wrote: > Is protected mode not "how Pascal" thinks of memory and objects in > memory ?? How is that different from C? > Whereas by the time 286 got out, everybody was wanting flat memory ala > C. When did they not want that?
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-08 20:53 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <8a762db010cecdc24bf7631b8f39b839@www.novabbs.org> |
| In reply to | #109562 |
On Tue, 8 Oct 2024 6:16:12 +0000, Lawrence D'Oliveiro wrote: > On Mon, 7 Oct 2024 23:13:25 +0000, MitchAlsup1 wrote: > >> Is protected mode not "how Pascal" thinks of memory and objects in >> memory ?? > > How is that different from C? In pascal you cannot subtract pointers to different objects, in C you can. >> Whereas by the time 286 got out, everybody was wanting flat memory ala >> C. > > When did they not want that? The Algol family of block structure gave the illusion that flat was less necessary and it could all be done with lexical address- ing and block scoping rules. Then malloc() and mmap() came along.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-09 08:48 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve58vq$2igvr$1@dont-email.me> |
| In reply to | #109578 |
On 08/10/2024 22:53, MitchAlsup1 wrote: > On Tue, 8 Oct 2024 6:16:12 +0000, Lawrence D'Oliveiro wrote: > >> On Mon, 7 Oct 2024 23:13:25 +0000, MitchAlsup1 wrote: >> >>> Is protected mode not "how Pascal" thinks of memory and objects in >>> memory ?? >> >> How is that different from C? > > In pascal you cannot subtract pointers to different objects, > in C you can. No, you can't - unless the pointers are of compatible types, and each points to a sub-object within the same encompassing object. So if you have two pointers that point within the same array, you can subtract them. If they point to different objects, trying to subtract them is undefined behaviour. > >>> Whereas by the time 286 got out, everybody was wanting flat memory ala >>> C. >> >> When did they not want that? > > The Algol family of block structure gave the illusion that flat > was less necessary and it could all be done with lexical address- > ing and block scoping rules. > > Then malloc() and mmap() came along. malloc() does not need a flat memory space. C does not need a flat memory space. Indeed, people use C all the time on systems where memory is disjoint.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-14 23:46 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vekag2$1co97$4@dont-email.me> |
| In reply to | #109578 |
On Tue, 8 Oct 2024 20:53:00 +0000, MitchAlsup1 wrote: > The Algol family of block structure gave the illusion that flat was less > necessary and it could all be done with lexical address- > ing and block scoping rules. > > Then malloc() and mmap() came along. Algol-68 already had heap allocation and flex arrays. (The folks over in MULTICS land were working on mmap.)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-08 07:28 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <2024Oct8.092821@mips.complang.tuwien.ac.at> |
| In reply to | #109558 |
mitchalsup@aol.com (MitchAlsup1) writes: >Is protected mode not "how Pascal" thinks of memory and objects >in memory ?? You can map the object of standard C (essentially what one malloc() call gives you, or what a variable contains) and the equivalent of Pascal into a segment on the 286, but then that object is limited to 64KB in size, and the program is limited to 8192 objects. And the program runs very slowly. So I doubt that Pascal compiler implementors though that the 80286 is their dream machine. Especially given that you can implement Pascal just as well with less performance disadvantages on hardware with flat memory (and still perform bounds checking where necessary). In particular, I doubt that Turbo Pascal used the 286 in this way. >Whereas by the time 286 got out, everybody was wanting flat >memory ala C. It's interesting that, when C was standardized, the segmentation found its way into it by disallowing subtracting and comparing between addresses in different objects. This disallows performing certain forms of induction variable elimination by hand. So while flat memory is C culture so much that you write "flat memory ala C", the standardized subset of C (what standard C fanatics claim is the only meaning of "C") actually specifies a segmented memory model. An interesting case is the Forth standard. It specifies "contiguous regions", which correspond to objects in C, but in Forth each address is a cell and can be added, subtracted, compared, etc. irrespective of where it came from. So Forth really has a flat-memory model. It has had that since its origins in the 1970s. Some of the 8086 implementations had some extensions for dealing with more than 64KB, but they were never standardized and are now mostly forgotten. - 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 | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2024-10-08 07:28 -0400 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve350m$25ngb$1@dont-email.me> |
| In reply to | #109568 |
Nostalgia. I think the second machine I bought was a ‘286. Which was a 20 MHz machine with a ‘287 math coprocessor. 4MB RAM. IIRC it was faster than the ‘386sx which I think was only 16 MHz at the time. Eventually I got a ‘386, but I kept the ‘286 motherboard and for a while hung it on the wall as a piece of artwork. Invested some time learning about segmentation and protected mode. I still have the chips from the motherboard in a drawer somewhere.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-09 10:24 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve5ek3$2jamt$1@dont-email.me> |
| In reply to | #109568 |
On 08/10/2024 09:28, Anton Ertl wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >> Whereas by the time 286 got out, everybody was wanting flat >> memory ala C. > > It's interesting that, when C was standardized, the segmentation found > its way into it by disallowing subtracting and comparing between > addresses in different objects. It is difficult to talk about the timing of features (either things that are allowed, or things explicitly disallowed) before the standardisation of C, as there was no single language "C". Different variants supported by different compilers had different rules. > This disallows performing certain > forms of induction variable elimination by hand. So while flat memory > is C culture so much that you write "flat memory ala C", the > standardized subset of C (what standard C fanatics claim is the only > meaning of "C") actually specifies a segmented memory model. > No, the C standard does not in any sense specify a segmented memory model. Nor does it specify a non-segmented or flat or contiguous memory. The nearest it gets is the description of converting between pointers and integers, where it says that the conversion of a pointer to an integer might not fit in any integer type, in which case the conversions are undefined behaviour - but if they /are/ convertible, the intention is that the value (of type "uintptr_t") should be consistent with "the addressing structure of the execution environment". The way C is specified is intended to be strong enough to allow programmers to do all they generally need to do using portable code (i.e., code that doesn't rely on anything other than standard behaviour), without unnecessarily restricting the kinds of systems that can implement C, and without unnecessarily restricting what people can write in non-portable code. When would you ever /need/ to compare pointers to different objects? For almost all C programmers, the answer is "never". Pretty much the only example people ever give of needing such comparisons is to implement memmove() efficiently - but you don't need to implement memmove(), because it is already in the standard library. (Standard library implementations don't need to be portable, and can rely on extensions or other compiler-specific features.) In practice, on all but the most niche or specialised platforms, if you do feel you need to compare random pointers, you can cast them to uintptr_t and compare these. That will generally work on segmented, non-contiguous or flat memories. > An interesting case is the Forth standard. It specifies "contiguous > regions", which correspond to objects in C, but in Forth each address > is a cell and can be added, subtracted, compared, etc. irrespective of > where it came from. So Forth really has a flat-memory model. It has > had that since its origins in the 1970s. Some of the 8086 > implementations had some extensions for dealing with more than 64KB, > but they were never standardized and are now mostly forgotten. > Forth does not require a flat memory model in the hardware, as far as I am aware, any more than C does. (I appreciate that your knowledge of Forth is /vastly/ greater than mine.) A Forth implementation could interpret part of the address value as the segment or other memory block identifier and part of it as an index into that block, just as a C implementation can. A flat address model is almost certainly more /efficient/, for C, Forth and many other languages. But that does not mean a particular model is /required/ or specified by the language.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-09 16:28 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <be506ccef76d682d13205c69c761a086@www.novabbs.org> |
| In reply to | #109583 |
On Wed, 9 Oct 2024 8:24:34 +0000, David Brown wrote: > On 08/10/2024 09:28, Anton Ertl wrote:. > > When would you ever /need/ to compare pointers to different objects? > For almost all C programmers, the answer is "never". Pretty much the > only example people ever give of needing such comparisons is to > implement memmove() efficiently - but you don't need to implement > memmove(), because it is already in the standard library. (Standard > library implementations don't need to be portable, and can rely on > extensions or other compiler-specific features.) Somebody has to write memmove() and they want to use C to do it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-09 16:42 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <2oyNO.155431$15a6.73965@fx12.iad> |
| In reply to | #109589 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Wed, 9 Oct 2024 8:24:34 +0000, David Brown wrote: > >> On 08/10/2024 09:28, Anton Ertl wrote:. >> >> When would you ever /need/ to compare pointers to different objects? >> For almost all C programmers, the answer is "never". Pretty much the >> only example people ever give of needing such comparisons is to >> implement memmove() efficiently - but you don't need to implement >> memmove(), because it is already in the standard library. (Standard >> library implementations don't need to be portable, and can rely on >> extensions or other compiler-specific features.) > >Somebody has to write memmove() and they want to use C to do it. In most every mainstream implementation, memmove() is written in assembler in order to inject the appropriate prefeches and follow the recommended instruction usage per the target architecture software optimization guide.
[toc] | [prev] | [next] | [standalone]
Page 4 of 23 — ← Prev page 1 2 3 [4] 5 6 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web