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 13 of 23 — ← Prev page 1 … 11 12 [13] 14 15 … 23 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-08 16:23 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <2024Oct8.182332@mips.complang.tuwien.ac.at> |
| In reply to | #109574 |
John Levine <johnl@taugh.com> writes: >According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>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. > >If you look at the 8086 manuals, that's clearly what they had in mind. > >What I don't get is that the 286's segment stuff was so slow. It had to load the whole segment descriptor from RAM and possibly perform some additional setup. - 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 | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2024-10-08 21:03 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve46nc$2leh$1@gal.iecc.com> |
| In reply to | #109575 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>If you look at the 8086 manuals, that's clearly what they had in mind. >> >>What I don't get is that the 286's segment stuff was so slow. > >It had to load the whole segment descriptor from RAM and possibly >perform some additional setup. Right, and they appeared not to care or realize it was a performance problem. They didn't even do obvious things like see if you're reloading the same value into the segment register and skip the rest of the setup. Sure, you could put checks in your code and skip the segment load but that would make your code a lot bigger and uglier. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-15 05:20 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <veku29$1jctr$1@dont-email.me> |
| In reply to | #109579 |
On Tue, 8 Oct 2024 21:03:40 -0000 (UTC), John Levine wrote: > According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >> >>>If you look at the 8086 manuals, that's clearly what they had in mind. >>> >>>What I don't get is that the 286's segment stuff was so slow. >> >>It had to load the whole segment descriptor from RAM and possibly >>perform some additional setup. > > Right, and they appeared not to care or realize it was a performance > problem. They didn’t expect anybody to make serious use of it.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-15 11:59 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241015115927.00001015@yahoo.com> |
| In reply to | #109579 |
On Tue, 8 Oct 2024 21:03:40 -0000 (UTC) John Levine <johnl@taugh.com> wrote: > According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: > >>If you look at the 8086 manuals, that's clearly what they had in > >>mind. > >> > >>What I don't get is that the 286's segment stuff was so slow. > > > >It had to load the whole segment descriptor from RAM and possibly > >perform some additional setup. > > Right, and they appeared not to care or realize it was a performance > problem. > > They didn't even do obvious things like see if you're reloading the > same value into the segment register and skip the rest of the setup. > Sure, you could put checks in your code and skip the segment load but > that would make your code a lot bigger and uglier. > The question is how slowness of 80286 segments compares to contemporaries that used segment-based protected memory. Wikipedia lists following machines as examples of segmentation: - Burroughs B5000 and following Burroughs Large Systems - GE 645 -> Honeywell 6080 - Prime 400 and successors - IBM System/38 They also mention S/370, but to me segmentation in S/370 looks very different and probably not intended for fine-grained protection. Of those Burroughs B5900 looks to me as the most comparable to 80286.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-18 07:01 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vet13k$36dnf$4@dont-email.me> |
| In reply to | #109718 |
On Tue, 15 Oct 2024 11:59:27 +0300, Michael S wrote: > The question is how slowness of 80286 segments compares to > contemporaries that used segment-based protected memory. > Wikipedia lists following machines as examples of segmentation: > - Burroughs B5000 and following Burroughs Large Systems > - GE 645 -> Honeywell 6080 > - Prime 400 and successors > - IBM System/38 Certainly the first two had “segmentation” that was nothing like the Intel (mis)interpretation of the concept.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-03 03:37 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vl7m2b$6iat$1@paganini.bofh.team> |
| In reply to | #109490 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>On 04/10/2024 19:30, Anton Ertl wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 04/10/2024 00:17, Lawrence D'Oliveiro wrote:
>>>>> Compare this with the pain the x86 world went through, over a much longer
>>>>> time, to move to 32-bit.
>>>>
>>>> The x86 started from 8-bit roots, and increased width over time, which
>>>> is a very different path.
>>>
>>> Still, the question is why they did the 286 (released 1982) with its
>>> protected mode instead of adding IA-32 to the architecture, maybe at
>>> the start with a 386SX-like package and with real-mode only, or with
>>> the MMU in a separate chip (like the 68020/68551).
>>>
>>
>>I can only guess the obvious - it is what some big customer(s) were
>>asking for. Maybe Intel didn't see the need for 32-bit computing in the
>>markets they were targeting, or at least didn't see it as worth the cost.
>
> Anyone could see the problems that the PDP-11 had with its 16-bit
> limitation. Intel saw it in the iAPX 432 starting in 1975. It is
> obvious that, as soon as memory grows beyond 64KB (and already the
> 8086 catered for that), the protected mode of the 80286 would be more
> of a hindrance than even the real mode of the 8086. 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.
From my point of view main drawbacks of 286 is poor support for
large arrays and problem for Lisp-like system which have a lot
of small data structures and traverse then via pointers.
However, playing devil's advocate I can see sense in 286. IMO
Intel targeted quite a diffferent market. IIUC main intended marker
for 8086 were industial control and various embedded aplication.
286 was probably intenended for similar markets, but with stronger
emphasis on security. In control application it is typical to
have several cooperating processes. 286 allows separate local
descriptor tables for each task, so mutitasking program easily
may have say 30000 descriptors. Trying to get similar number
of separately protected objects using paging would require
similar number of pages, which with 16 MB total address space
leads to 512 byte pages. For smaller paged systems situation
is even worse: with 512 kB of memory 512 byte pages lead to
1024 pages in total which means that access control can not
be very granular and one would get significant memory
fragmentation for parts smaller than page. I can guess that
Intel rejected very small pages as problematic in implementation.
So if the goal is fine grained access control, then segementation
for machine of size of 286 looks better than paging.
Concerning code "model", I think that Intel assumend that
most procedures would fit in a single segment and that
average procedure will be of order of single kilobytes.
Using 16-bit offsets for jumps inside procedure and
segment-offset pair for calls is likely to lead to better
or similar performance as purely 32-bit machine. For
control applications it is likely that each procedure
will access moderate number of segments and total amount
of accessed data will be moderate. In other words, Intel
probably considerd "mostly medium" model where procedure
mainly accesses it data segment using just 16-bit offsets
and occasionally accesses other segments.
Compared to PDP-11 this leads to resonably natural
code that use some hundreds of kilobytes of memory,
much better than 128 kB limit of PDP-11 with separate
code and data areas. And segment maniputlation allows
also bigger programs.
What went wrong? IIUC there were several control systems
using 286 features, so there was some success. But PC-s
became main user of x86 chips and significant fraction
of PC-s was used for gaming. Game authors wanted direct
access to hardware which in case of 286 forced real mode.
Also, for long time 8088 played mayor role and PC software
"had" to run on 8088. Software vendors theoretically could
release separate versions for each processor or do some
runtime switching of critical procedures, but easiest way
was to depend on compatibility with 8088. "Better" OS-es
went Unix way, depending on paging and not using segmentation.
But IIUC first paging Unix appeared _after_ release of 286.
In 286 time Multics was highly regarded and it heavily depended
on segmentaion. MVS was using paging hardware, but was
talking about segments, except for that MVS segmentation
was flawed because some addresses far outside a segment were
considered as part of different segment. I think that also
in VMS there was some taliking about segments. So creators
of 286 could believe that they are providing "right thing"
and not a fake possible with paging hardware.
> Concerning the cost, ther 80286 has 134,000 transistors, compared to
> supposedly 68,000 for the 68000, and the 190,000 of the 68020. I am
> sure that Intel could have managed a 32-bit 8086 (maybe even with the
> nice addressing modes that the 386 has in 32-bit mode) with those
> 134,000 transistors if Motorola could build the 68000 with half of
> that.
I think that Intel could manage to build "mostly" 32-bit processor
in transistor budget of 8086, that is have say 7 registers 32-bit
each, where each register could be treated as a pair of 16-bit
registers and 32-bit operations would take twice as much time
as 16-bit operation. But I think that such processor would be
slower (say 10% slower) than 8086 mostly because of more need to
use longer addresses. Similarly, hypotetical 32-bit 286 would
be slower than real 286. And I do not think thay could make
32-bit processor with segmentation in available transistor
buget, and even it they managed it would be slowed down by too
long addresses (segment + 32-bit offset).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-01-03 08:38 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <2025Jan3.093849@mips.complang.tuwien.ac.at> |
| In reply to | #110360 |
antispam@fricas.org (Waldek Hebisch) writes: >From my point of view main drawbacks of 286 is poor support for >large arrays and problem for Lisp-like system which have a lot >of small data structures and traverse then via pointers. Yes. In the first case the segments are too small, in the latter case there are too few segments (if you have one segment per object). >Concerning code "model", I think that Intel assumend that >most procedures would fit in a single segment and that >average procedure will be of order of single kilobytes. >Using 16-bit offsets for jumps inside procedure and >segment-offset pair for calls is likely to lead to better >or similar performance as purely 32-bit machine. With the 80286's segments and their slowness, that is very doubtful. The 8086 has branches with 8-bit offsets and branches and calls with 16-bit offsets. The 386 in 32-bit mode has branches with 8-bit offsets and branches and calls with 32-bit offsets; if 16-bit offsets for branches would be useful enough for performance, they could instead have designed the longer branch length to be 16 bits, and maybe a prefix for 32-bit branch offsets. That would be faster than what you outline, as soon as one call happens. But apparently 16-bit branches are not that beneficial, or they would have gone that way on the 386. Another usage of segments for code would be to put the code segment of a shared object (known as DLL among Windowsheads) in a segment, and use far calls to call functions in other shared objects, while using near calls within a shared object. This allows to share the code segments between different programs, and to locate them anywhere in physical memory. However, AFAIK shared objects were not a thing in the 80286 timeframe; Unix only got them in the late 1980s. I used Xenix on a 286 in 1986 or 1987; my impression is that programs were limited to 64KB code and 64KB data size, exactly the PDP-11 model you denounce. >What went wrong? IIUC there were several control systems >using 286 features, so there was some success. But PC-s >became main user of x86 chips and significant fraction >of PC-s was used for gaming. Game authors wanted direct >access to hardware which in case of 286 forced real mode. Every successful software used direct access to hardware because of performance; the rest waned. Using BIOS calls was just too slow. Lotus 1-2-3 won out over VisiCalc and Multiplan by being faster from writing directly to video. >But IIUC first paging Unix appeared _after_ release of 286. From <https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution#3BSD>: |The kernel of 32V was largely rewritten by Berkeley graduate student |Özalp Babaoğlu to include a virtual memory implementation, and a |complete operating system including the new kernel, ports of the 2BSD |utilities to the VAX, and the utilities from 32V was released as 3BSD |at the end of 1979. The 80286 was introduced on February 1, 1982. >In 286 time Multics was highly regarded and it heavily depended >on segmentaion. MVS was using paging hardware, but was >talking about segments, except for that MVS segmentation >was flawed because some addresses far outside a segment were >considered as part of different segment. I think that also >in VMS there was some taliking about segments. So creators >of 286 could believe that they are providing "right thing" >and not a fake possible with paging hardware. There was various segmented hardware around, first and foremost (for the designers of the 80286), the iAPX432. And as you write, all the good reasons that resulted in segments on the iAPX432 also persisted in the 80286. However, given the slowness of segmentation, only the tiny (all in one segment), small (one segment for code and one for data), and maybe medium memory models (one data segment) are competetive in protected mode compared to real mode. So if they really had wanted protected mode to succeed, they should have designed in 32-bit data segments (and maybe also 32-bit code segments). Alternatively, if protected mode and the 32-bit addresses do not fit in the 286 transistor budget, a CPU that implements the 32-bit feature and leaves away protected mode would have been more popular than the 80286; and (depending on how the 32-bit extension was implemented) it might have been a better stepping stone towards the kind of CPU with protected mode that they imagined; but the alt-386 designers probably would not have designed in this kind of protected mode that they did. Concerning paging, all these scenarios are without paging. Paging was primarily a virtual-memory feature, not a memory-protection feature. It acquired memory protection only as far as it was easy with pages (i.e., at page granularity). So paging was not designed as a competition to segments as far as protection was concerned. If computer architects had managed to design segmentation with competetive performance, we would be seeing hardware with both paging and segmentation nowadays. Or maybe even without paging, now that memories tend to be big enough to make virtual memory mostly unnecessary. >And I do not think thay could make >32-bit processor with segmentation in available transistor >buget, Maybe not. >and even it they managed it would be slowed down by too >long addresses (segment + 32-bit offset). On the contrary, every program that does not fit in the medium memory model on the 80286 would run at least as fast on such a CPU in real mode and significantly faster in protected mode. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-03 18:11 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <JLVdP.468817$oR74.158108@fx16.iad> |
| In reply to | #110362 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >antispam@fricas.org (Waldek Hebisch) writes: >>From my point of view main drawbacks of 286 is poor support for >>large arrays and problem for Lisp-like system which have a lot >>of small data structures and traverse then via pointers. >>But IIUC first paging Unix appeared _after_ release of 286. > >From ><https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution#3BSD>: > >|The kernel of 32V was largely rewritten by Berkeley graduate student >|Özalp Babaoğlu to include a virtual memory implementation, and a >|complete operating system including the new kernel, ports of the 2BSD >|utilities to the VAX, and the utilities from 32V was released as 3BSD >|at the end of 1979. There was also a version of Western Electric unix that ran on the VAX in that time frame.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-04 22:40 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vlcddh$j2gr$1@paganini.bofh.team> |
| In reply to | #110362 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>>From my point of view main drawbacks of 286 is poor support for
>>large arrays and problem for Lisp-like system which have a lot
>>of small data structures and traverse then via pointers.
>
> Yes. In the first case the segments are too small, in the latter case
> there are too few segments (if you have one segment per object).
In the second case one can pack several objects into single
segment, so except for loct security properties this is not
a big problem. But there is a lot of loading segment registers
and slow loading is a problem.
>>Concerning code "model", I think that Intel assumend that
>>most procedures would fit in a single segment and that
>>average procedure will be of order of single kilobytes.
>>Using 16-bit offsets for jumps inside procedure and
>>segment-offset pair for calls is likely to lead to better
>>or similar performance as purely 32-bit machine.
>
> With the 80286's segments and their slowness, that is very doubtful.
> The 8086 has branches with 8-bit offsets and branches and calls with
> 16-bit offsets. The 386 in 32-bit mode has branches with 8-bit
> offsets and branches and calls with 32-bit offsets; if 16-bit offsets
> for branches would be useful enough for performance, they could
> instead have designed the longer branch length to be 16 bits, and
> maybe a prefix for 32-bit branch offsets.
At that time Intel apparently wanted to avoid having too many
instructions.
> That would be faster than
> what you outline, as soon as one call happens. But apparently 16-bit
> branches are not that beneficial, or they would have gone that way on
> the 386.
For machine with 32-bit bus benefit is much smaller.
> Another usage of segments for code would be to put the code segment of
> a shared object (known as DLL among Windowsheads) in a segment, and
> use far calls to call functions in other shared objects, while using
> near calls within a shared object. This allows to share the code
> segments between different programs, and to locate them anywhere in
> physical memory. However, AFAIK shared objects were not a thing in
> the 80286 timeframe; Unix only got them in the late 1980s.
IIUC shared segments were widely used on Multics.
> I used Xenix on a 286 in 1986 or 1987; my impression is that programs
> were limited to 64KB code and 64KB data size, exactly the PDP-11 model
> you denounce.
Maybe. I have seen many cases where sofware essentiallt "wastes"
good things offered by hardware.
>>What went wrong? IIUC there were several control systems
>>using 286 features, so there was some success. But PC-s
>>became main user of x86 chips and significant fraction
>>of PC-s was used for gaming. Game authors wanted direct
>>access to hardware which in case of 286 forced real mode.
>
> Every successful software used direct access to hardware because of
> performance; the rest waned. Using BIOS calls was just too slow.
> Lotus 1-2-3 won out over VisiCalc and Multiplan by being faster from
> writing directly to video.
For most early graphic cards direct screen access could be allowed
just by allocating appropriate segment. And most non-games
could gain good performance with better system interface.
I think that variaty of tricks used in games and their
popularity made protected mode system much less appealing
to vendors. And that discouraged work on better interfaces
for non-games.
More generally, vendors could release separate versions of
programs for 8086 and 286 but few did so. And users having
only binaries wanted to use 8086 on their new systems which
led to heroic efforts like OS/2 DOS box and later Linux
dosemu. But integration of 8086 programs with protected
mode was solved too late for 286 model to gain traction
(and on 286 "DOS box" had to run in real mode, breaking
normal system protection).
>>But IIUC first paging Unix appeared _after_ release of 286.
>
> From
> <https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution#3BSD>:
>
> |The kernel of 32V was largely rewritten by Berkeley graduate student
> |Ã?zalp BabaoÄ?lu to include a virtual memory implementation, and a
> |complete operating system including the new kernel, ports of the 2BSD
> |utilities to the VAX, and the utilities from 32V was released as 3BSD
> |at the end of 1979.
>
> The 80286 was introduced on February 1, 1982.
OK
>>In 286 time Multics was highly regarded and it heavily depended
>>on segmentaion. MVS was using paging hardware, but was
>>talking about segments, except for that MVS segmentation
>>was flawed because some addresses far outside a segment were
>>considered as part of different segment. I think that also
>>in VMS there was some taliking about segments. So creators
>>of 286 could believe that they are providing "right thing"
>>and not a fake possible with paging hardware.
>
> There was various segmented hardware around, first and foremost (for
> the designers of the 80286), the iAPX432. And as you write, all the
> good reasons that resulted in segments on the iAPX432 also persisted
> in the 80286. However, given the slowness of segmentation, only the
> tiny (all in one segment), small (one segment for code and one for
> data), and maybe medium memory models (one data segment) are
> competetive in protected mode compared to real mode.
AFAICS that covered wast majority of programs during eighties.
Turbo Pascal offered only medium memory model and was quite
popular. Its code generator produced mediocre output, but
real Turbo Pascal programs used a lot of inline assembly
and performance was not bad.
Intel apparently assumed that programmers are willing to spend
extra work to get good performance and IMO this was right
as a general statement. Intel probably did not realize that
programmers will be very reluctant to spent work on security
features and in particular to spent work on making programs
fast in 286 protected mode.
> So if they really had wanted protected mode to succeed, they should
> have designed in 32-bit data segments (and maybe also 32-bit code
> segments). Alternatively, if protected mode and the 32-bit addresses
> do not fit in the 286 transistor budget, a CPU that implements the
> 32-bit feature and leaves away protected mode would have been more
> popular than the 80286; and (depending on how the 32-bit extension was
> implemented) it might have been a better stepping stone towards the
> kind of CPU with protected mode that they imagined; but the alt-386
> designers probably would not have designed in this kind of protected
> mode that they did.
Intel probably assumend that 286 would cover most needs, especially
given that most system had much less memory than 16 MB theoreticlly
allowed by 286. And for bigger systems they released 386.
> Concerning paging, all these scenarios are without paging. Paging was
> primarily a virtual-memory feature, not a memory-protection feature.
Yes, exactly.
> It acquired memory protection only as far as it was easy with pages
> (i.e., at page granularity). So paging was not designed as a
> competition to segments as far as protection was concerned. If
> computer architects had managed to design segmentation with
> competetive performance, we would be seeing hardware with both paging
> and segmentation nowadays. Or maybe even without paging, now that
> memories tend to be big enough to make virtual memory mostly
> unnecessary.
>
>>And I do not think thay could make
>>32-bit processor with segmentation in available transistor
>>buget,
>
> Maybe not.
>
>>and even it they managed it would be slowed down by too
>>long addresses (segment + 32-bit offset).
>
> On the contrary, every program that does not fit in the medium memory
> model on the 80286 would run at least as fast on such a CPU in real
> mode and significantly faster in protected mode.
I think that Intel considerd "programs that do it in the medium
memory model" as tiny minority. IMO this is partially true: there
is a class of programs which with some work fit into medium
model, but using flat address space is easier. I think that
on 286 (that is with 16 bit bus) those programs (assuming enough
tuning) run faster than flat 32-bit version. But naive compilation
in large (or huge) model leads to worse speed than flat mode.
In a bit different spirit, for programs that do not fit in
64kB, but are not too large there is natural temptation to
have some "compression" scheme for pointers and use mostly
16-bit pointers. That can be done without special hardware
support. OTOH Intel segmentation is a specific proposal
in such direction with hardware support. Clearly it is
less flexible than software schemes based on native 32-bit
addressing. But I think that Intel segmentation had some
attractive features during eighties.
Another thing is 386. I think that designers of 286 thought
that 386 will remove some limitations. And 386 allowed
bigger segmensts removing one major limitation. OTOH
for 32-bit processor with segementation it would be natural
to have 32-bit segment registers. It is not clear to
me if 16-bit segment registers in 386 were deemed necessary
for backward compatibility or maybe in 386 period flat
fraction in Intel won and they kept segmentation mostly
for compatibility.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-05 08:54 +0100 |
| Subject | Re: Byte ordering |
| Message-ID | <vlddrm$ubkq$1@dont-email.me> |
| In reply to | #110377 |
Waldek Hebisch wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> There was various segmented hardware around, first and foremost (for >> the designers of the 80286), the iAPX432. And as you write, all the >> good reasons that resulted in segments on the iAPX432 also persisted >> in the 80286. However, given the slowness of segmentation, only the >> tiny (all in one segment), small (one segment for code and one for >> data), and maybe medium memory models (one data segment) are >> competetive in protected mode compared to real mode. > > AFAICS that covered wast majority of programs during eighties. > Turbo Pascal offered only medium memory model and was quite > popular. Its code generator produced mediocre output, but > real Turbo Pascal programs used a lot of inline assembly > and performance was not bad. As someone who wrote megabytes of that asm, I feel qualified to comment: Turbo Pascal itself 1.0 ran in Small model (64kB code & data) afair, but since the compiler/editor/linker/loader/debugger only used 35 kB (37 kB if you also loaded the text error messages), it had enough room left over for the source code it compiled. From the very beginning it supported Medium as you state, with separate code in the CS reg and data+stack (DS+SS) sharing a single segment. This way you had to use ES for all cross-segment operations, particularly REP MOVSB block moves. Later versions supported the Large model where all addresses were segment+offset pairs, as well as Huge where the segment was pointing at the object, rounded down to the nearest 16-byte boundary, and the offset (typically BX) was always [0-15]. > > Intel apparently assumed that programmers are willing to spend > extra work to get good performance and IMO this was right > as a general statement. Intel probably did not realize that > programmers will be very reluctant to spent work on security > features and in particular to spent work on making programs > fast in 286 protected mode. Protected could only be fast if segment reloads were rare, in my own code I would allocate arrays of largish objects as the max number that would fit in 64K, then grab the next. Terje PS. Happy New Year! -- - <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 | 2025-01-05 11:10 +0000 |
| Subject | 80286 protected mode (was: Byte ordering) |
| Message-ID | <2025Jan5.121028@mips.complang.tuwien.ac.at> |
| In reply to | #110377 |
antispam@fricas.org (Waldek Hebisch) writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >>>From my point of view main drawbacks of 286 is poor support for >>>large arrays and problem for Lisp-like system which have a lot >>>of small data structures and traverse then via pointers. >> >> Yes. In the first case the segments are too small, in the latter case >> there are too few segments (if you have one segment per object). > >In the second case one can pack several objects into single >segment, so except for loct security properties this is not >a big problem. If you go that way, you lose all the benefits of segments, and run into the "segments too small" problem. Which you then want to circumvent by using segment and offset in your addressing of the small data structures, which leads to: >But there is a lot of loading segment registers >and slow loading is a problem. ... >>>Using 16-bit offsets for jumps inside procedure and >>>segment-offset pair for calls is likely to lead to better >>>or similar performance as purely 32-bit machine. >> >> With the 80286's segments and their slowness, that is very doubtful. >> The 8086 has branches with 8-bit offsets and branches and calls with >> 16-bit offsets. The 386 in 32-bit mode has branches with 8-bit >> offsets and branches and calls with 32-bit offsets; if 16-bit offsets >> for branches would be useful enough for performance, they could >> instead have designed the longer branch length to be 16 bits, and >> maybe a prefix for 32-bit branch offsets. > >At that time Intel apparently wanted to avoid having too many >instructions. Looking in my Pentium manual, the section on CALL has a 20 lines for "call intersegment", "call gate" (with priviledge variants) and "call to task" instructions, 10 of which probably already existed on the 286 (compared to 2 lines for "call near" instructions that existed on the 286), and the "Operation" section (the specification in pseudocode) consumes about 4 pages, followed by a 1.5 page "Description" section. 9 of these 10 far call variants deal with protected-mode things, so Intel obviously had no qualms about adding instruction variants. If they instead had no protected mode, but some 32-bit support, including the near call with 32-bit offset that I suggest, that would have reduced the number of instruction variants. >> I used Xenix on a 286 in 1986 or 1987; my impression is that programs >> were limited to 64KB code and 64KB data size, exactly the PDP-11 model >> you denounce. > >Maybe. I have seen many cases where sofware essentiallt "wastes" >good things offered by hardware. Which "good things offered by hardware" do you see "wasted" by this usage in Xenix? To me this seems to be the only workable way to use the 286 protected mode. Ok, the medium model (near data, far code) may also have been somewhat workable, but looking at the cycle counts for the protected-mode far calls on the Pentium (and on the 286 they were probably even more costly), which start at 22 cycles for a "call gate, same priviledge" (compared to 1 cycle on the Pentium for a direct call near), one would strongly prefer the small model. >> Every successful software used direct access to hardware because of >> performance; the rest waned. Using BIOS calls was just too slow. >> Lotus 1-2-3 won out over VisiCalc and Multiplan by being faster from >> writing directly to video. > >For most early graphic cards direct screen access could be allowed >just by allocating appropriate segment. And most non-games >could gain good performance with better system interface. >I think that variaty of tricks used in games and their >popularity made protected mode system much less appealing >to vendors. And that discouraged work on better interfaces >for non-games. MicroSoft and IBM invested lots of work in a 286 protected-mode interface: OS/2 1.x. It was limited to the 286 at the insistence of IBM, even though work started in August 1985, when they already knew that the 386 was coming soon. OS/2 1.0 was released in April 1987, 1.5 years after the 386. OS/2 1.x flopped, and by the time OS/2 was adjusted to the 386, it was too late, so the 286 killed OS/2; here we have a case of a software project being death-marched by tying itself to "good things offered by hardware" (except that Microsoft defected from the death march after a few years). Meanwhile, Microsoft introduced Windows/386 in September 1987 (in addition to the base (8086) variant of Windows 2.0, which was released in December 1987), which used 386 protected mode and virtual 8086 mode (which was missing in the "brain-damaged" (Bill Gates) 286). So Windows completely ignored 286 protected mode. Windows eventually became a big success. Also, Microsoft started NT OS/2 in November 1988 to target the 386 while IBM was still working on 286 OS/2. Eventually Microsoft and IBM parted ways, NT OS/2 became Windows NT, which is the starting point of all remaining Windowses from Windows XP onwards. Xenix, apart from OS/2 the only other notable protected-mode OS for the 286, was ported to the 386 in 1987, after SCO secured "knowledge from Microsoft insiders that Microsoft was no longer developing Xenix", so SCO (or Microsoft) might have done it even earlier if the commercial situation had been less muddled; in any case, Xenix jumped the 286 ship ASAP. The verdict is: The only good use of the 286 is as a faster 8086; small memory model multi-tasking use is possible, but the 64KB segments are so limiting that everybody who understood software either decided to skip this twist (MicroSoft, except on their OS/2 death march), or jumped ship ASAP (SCO). >More generally, vendors could release separate versions of >programs for 8086 and 286 but few did so. Were there any who released software both as 8086 and a protected-mode 80286 variants? Microsoft/SCO with Xenix, anyone else? >And users having >only binaries wanted to use 8086 on their new systems which >led to heroic efforts like OS/2 DOS box and later Linux >dosemu. But integration of 8086 programs with protected >mode was solved too late for 286 model to gain traction >(and on 286 "DOS box" had to run in real mode, breaking >normal system protection). Linux never ran on a 80286, and DOSemu uses the virtual 8086 mode, which does not require heroic efforts AFAIK. >> There was various segmented hardware around, first and foremost (for >> the designers of the 80286), the iAPX432. And as you write, all the >> good reasons that resulted in segments on the iAPX432 also persisted >> in the 80286. However, given the slowness of segmentation, only the >> tiny (all in one segment), small (one segment for code and one for >> data), and maybe medium memory models (one data segment) are >> competetive in protected mode compared to real mode. > >AFAICS that covered wast majority of programs during eighties. The "vast majority" is not enough; if a key application like Lotus 1-2-3 or Wordperfect did not work on the DOS alternative, the DOS alternative was not used. And Lotus 1-2-3 and Wordperfect certainly did not limit themselves to 64KB of data. >Turbo Pascal offered only medium memory model Acoording to Terje Mathiesen, it also offered the large memory model. On its Wikipedia page, I find: "Besides allowing applications larger than 64 KB, Byte in 1988 reported ... for version 4.0". So apparently Turbo Pascal 4.0 introduced support for the large memory model in 1988. >Intel apparently assumed that programmers are willing to spend >extra work to get good performance and IMO this was right >as a general statement. Intel probably did not realize that >programmers will be very reluctant to spent work on security >features and in particular to spent work on making programs >fast in 286 protected mode. 80286 protected mode is never faster than real mode on the same CPU, so the way to make programs fast on the 286 is to stick with real mode; using the small memory model is an alternative, but as mentioned, the memory limits are too restrictive. >Intel probably assumend that 286 would cover most needs, As far as protected mode was concerned, they hardly could have been more wrong. >especially >given that most system had much less memory than 16 MB theoreticlly >allowed by 286. They provided 24 address pins, so they obviously assumed that there would be 80286 systems with >8MB. 64KB segments are already too limiting on systems with 1MB (which was supported by the 8086), probably even for anything beyond 128KB. >IMO this is partially true: there >is a class of programs which with some work fit into medium >model, but using flat address space is easier. I think that >on 286 (that is with 16 bit bus) those programs (assuming enough >tuning) run faster than flat 32-bit version. Maybe in real mode. Certainly not in protected mode. Just run your tuned large-model protected-mode program against a 32-bit small-model program for the same task on a 386SX (which is reported as having a very similar speed to the 80286 on 16-bit programs). And even if you find one case where the protected-mode program wins, nobody found it worth their time to do this nonsense. And so OS/2 flopped despite being backed by IBM and, until 1990, Microsoft. >But I think that Intel segmentation had some >attractive features during eighties. You are one of a tiny minority. Even Intel finally saw the light, as did everybody else, and nowadays segments are just a bad memory. >Another thing is 386. I think that designers of 286 thought >that 386 will remove some limitations. And 386 allowed >bigger segmensts removing one major limitation. OTOH >for 32-bit processor with segementation it would be natural >to have 32-bit segment registers. It is not clear to >me if 16-bit segment registers in 386 were deemed necessary >for backward compatibility or maybe in 386 period flat >fraction in Intel won and they kept segmentation mostly >for compatibility. The latter (read the 386 oral history). The 386 designers knew that segments have no future, and they were right, so they kept them at a minimum. If they had gone for 32-bit segment registers (and 64-bit segment registers for AMD64), would segments have fared any better? I doubt it. Using segments would have stayed slow, and would have been ignored by nearly all programmers. These days we see segment-like things in security extensions of instruction sets, but slowness still plagues these extensions, and security researchers often find ways to subvert the promised security (and sometimes even more). - 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 Swindells <rjs@fdy2.co.uk> |
|---|---|
| Date | 2025-01-05 18:30 +0000 |
| Subject | Re: 80286 protected mode (was: Byte ordering) |
| Message-ID | <vlej4h$14nnc$1@dont-email.me> |
| In reply to | #110383 |
On Sun, 05 Jan 2025 11:10:28 GMT, Anton Ertl wrote: > Xenix, apart from OS/2 the only other notable protected-mode OS for the > 286, was ported to the 386 in 1987, after SCO secured "knowledge from > Microsoft insiders that Microsoft was no longer developing Xenix", so > SCO (or Microsoft) might have done it even earlier if the commercial > situation had been less muddled; in any case, Xenix jumped the 286 ship > ASAP. Microport Systems had UNIX System V for the 286.
[toc] | [prev] | [next] | [standalone]
| From | "Brian G. Lucas" <bagel99@gmail.com> |
|---|---|
| Date | 2025-01-05 16:38 -0500 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vleu1n$178v9$1@dont-email.me> |
| In reply to | #110388 |
On 1/5/25 1:30 PM, Robert Swindells wrote: > On Sun, 05 Jan 2025 11:10:28 GMT, Anton Ertl wrote: > >> Xenix, apart from OS/2 the only other notable protected-mode OS for the >> 286, was ported to the 386 in 1987, after SCO secured "knowledge from >> Microsoft insiders that Microsoft was no longer developing Xenix", so >> SCO (or Microsoft) might have done it even earlier if the commercial >> situation had been less muddled; in any case, Xenix jumped the 286 ship >> ASAP. > > Microport Systems had UNIX System V for the 286. \ And Interactive Systems had a follow-up to PC/IX than was tuned to the 286. They even had a version that worked around a chip errata because a customer had bought a lot of flawed 286s. brian
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-05 21:49 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vleuou$rv85$1@paganini.bofh.team> |
| In reply to | #110383 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>>>From my point of view main drawbacks of 286 is poor support for
>>>>large arrays and problem for Lisp-like system which have a lot
>>>>of small data structures and traverse then via pointers.
>>>
>>> Yes. In the first case the segments are too small, in the latter case
>>> there are too few segments (if you have one segment per object).
>>
>>In the second case one can pack several objects into single
>>segment, so except for loct security properties this is not
>>a big problem.
>
> If you go that way, you lose all the benefits of segments, and run
> into the "segments too small" problem. Which you then want to
> circumvent by using segment and offset in your addressing of the small
> data structures, which leads to:
>
>>But there is a lot of loading segment registers
>>and slow loading is a problem.
>
> ...
>>>>Using 16-bit offsets for jumps inside procedure and
>>>>segment-offset pair for calls is likely to lead to better
>>>>or similar performance as purely 32-bit machine.
>>>
>>> With the 80286's segments and their slowness, that is very doubtful.
>>> The 8086 has branches with 8-bit offsets and branches and calls with
>>> 16-bit offsets. The 386 in 32-bit mode has branches with 8-bit
>>> offsets and branches and calls with 32-bit offsets; if 16-bit offsets
>>> for branches would be useful enough for performance, they could
>>> instead have designed the longer branch length to be 16 bits, and
>>> maybe a prefix for 32-bit branch offsets.
>>
>>At that time Intel apparently wanted to avoid having too many
>>instructions.
>
> Looking in my Pentium manual, the section on CALL has a 20 lines for
> "call intersegment", "call gate" (with priviledge variants) and "call
> to task" instructions, 10 of which probably already existed on the 286
> (compared to 2 lines for "call near" instructions that existed on the
> 286), and the "Operation" section (the specification in pseudocode)
> consumes about 4 pages, followed by a 1.5 page "Description" section.
>
> 9 of these 10 far call variants deal with protected-mode things, so
> Intel obviously had no qualms about adding instruction variants. If
> they instead had no protected mode, but some 32-bit support, including
> the near call with 32-bit offset that I suggest, that would have
> reduced the number of instruction variants.
I wrote "instructions". Intel clearly used modes and variants,
but different call would lead to new opcode.
>>> I used Xenix on a 286 in 1986 or 1987; my impression is that programs
>>> were limited to 64KB code and 64KB data size, exactly the PDP-11 model
>>> you denounce.
>>
>>Maybe. I have seen many cases where sofware essentiallt "wastes"
>>good things offered by hardware.
>
> Which "good things offered by hardware" do you see "wasted" by this
> usage in Xenix?
Medimu mode and shared segments. Plus escape for programs needing
bigger memory (traditional Unix programs by neccesity fit in 64kB
limits).
> To me this seems to be the only workable way to use
> the 286 protected mode. Ok, the medium model (near data, far code)
> may also have been somewhat workable, but looking at the cycle counts
> for the protected-mode far calls on the Pentium (and on the 286 they
> were probably even more costly), which start at 22 cycles for a "call
> gate, same priviledge" (compared to 1 cycle on the Pentium for a
> direct call near), one would strongly prefer the small model.
I have found instruction list on the web which claims 26 + m cycles
where m in "length of next instruction" (whatever that means) for
protected mode call using segement. Real mode call using segement
is 13 + m cycles. Near call call is 7 + m cycles.
Intel clearly expected that segment-changing calls are infrequent.
AFAICS this was better than system conventions on IBM mainframes
where "standard" call normally called memory allocation function
to allocate stack frame. I do not have data for VAX handy, but
VAX calls were quite complex, so probably also not fast.
And modern data at least partially confirms Intel beliefs. When
AMD introduced 64-bit mode thay also introduced complex calling
convention intended to optimize speed of calls. Later there
was a paper by Intel folks essentially claiming that this
calling convention does not matter: C compilers inline small
routines, so cost of calls relatively to other things is quite
small. I think that what was inlined in 2010 would be called
using near calls in 1982.
>>> Every successful software used direct access to hardware because of
>>> performance; the rest waned. Using BIOS calls was just too slow.
>>> Lotus 1-2-3 won out over VisiCalc and Multiplan by being faster from
>>> writing directly to video.
>>
>>For most early graphic cards direct screen access could be allowed
>>just by allocating appropriate segment. And most non-games
>>could gain good performance with better system interface.
>>I think that variaty of tricks used in games and their
>>popularity made protected mode system much less appealing
>>to vendors. And that discouraged work on better interfaces
>>for non-games.
>
> MicroSoft and IBM invested lots of work in a 286 protected-mode
> interface: OS/2 1.x. It was limited to the 286 at the insistence of
> IBM, even though work started in August 1985, when they already knew
> that the 386 was coming soon. OS/2 1.0 was released in April 1987,
> 1.5 years after the 386.
>
> OS/2 1.x flopped, and by the time OS/2 was adjusted to the 386, it was
> too late, so the 286 killed OS/2; here we have a case of a software
> project being death-marched by tying itself to "good things offered by
> hardware" (except that Microsoft defected from the death march after a
> few years).
>
> Meanwhile, Microsoft introduced Windows/386 in September 1987 (in
> addition to the base (8086) variant of Windows 2.0, which was released
> in December 1987), which used 386 protected mode and virtual 8086 mode
> (which was missing in the "brain-damaged" (Bill Gates) 286). So
> Windows completely ignored 286 protected mode. Windows eventually
> became a big success.
What I recall is a bit different. IIRC first successful version of
Windows, that is Windows 3.0 had 3 modes of operation: 8086 compatible,
286 protected mode and 386 protected mode. Only later Microsoft
dropped requirement for 8086 compatiblity. I think still later
it dropped 286 support. Windows 95 was supposed to be 32-bit,
but contained quite a lot of 16-bit code. IIRC system interface
to Windows 3.0 and 3.1 was 16-bit and only later Microsoft
released extention allowing 32-bit system calls.
I have no information about Windows internals except for some
public statements by Microsoft and other people, but I think
it reasonable to assume that Windows was actually a succesful
example of 8086/286/386 compatibility. That is their 16 bit
code could use real mode segmentation or protected mode
segmentation the later both for 286 and 386. For 32-bit
version they added translation layer to transform arguments
between 16-bit world and 32-bit world. It is possible
that this translation layer involved a lot of effort. IIUC
DEC when porting VMS to Alpha essentially gave up using
32-bit pointers as main interface.
Anyway, it seems that Windows was at least as tied to 286
as OS/2 when it became sucessful and dropped 286 support
later. And for long time after dropping 286 support
Windows massively used 16-bit segments.
> Also, Microsoft started NT OS/2 in November 1988 to target the 386
> while IBM was still working on 286 OS/2. Eventually Microsoft and IBM
> parted ways, NT OS/2 became Windows NT, which is the starting point of
> all remaining Windowses from Windows XP onwards.
>
> Xenix, apart from OS/2 the only other notable protected-mode OS for
> the 286, was ported to the 386 in 1987, after SCO secured "knowledge
> from Microsoft insiders that Microsoft was no longer developing
> Xenix", so SCO (or Microsoft) might have done it even earlier if the
> commercial situation had been less muddled; in any case, Xenix jumped
> the 286 ship ASAP.
>
> The verdict is: The only good use of the 286 is as a faster 8086;
> small memory model multi-tasking use is possible, but the 64KB
> segments are so limiting that everybody who understood software either
> decided to skip this twist (MicroSoft, except on their OS/2 death
> march), or jumped ship ASAP (SCO).
As I mentioned above I do not believe your claim about Microsoft.
There were DOS-extenders which allowed use of 286 protected mode
under DOS. They were used by several software vendors. Clearly,
programming for flat 32-bit mode is easier and on software market
that matters more than other factors.
I think that 286 protected mode is good for its intended use, that
is protected multitasking systems having more than 64 kB but less
than say 4 MB. Of course, if you have a lot of hardware resources,
than 32-bit system using paging may be easier to create. Also,
speed is tricky: on 486 (and possibly 386) hardware task switch
was easy to use, but slower than tuned purely software
implementation. In other parts reloading of segment registers
could slow down things quite a lot, so 16-bit protected mode
required a lot of tuning to minimize number of times when
segement registers were reloaded.
I do not know if people used 286 in this way, but natural use
of 286 is as a debugger for 8086 programs. That is use segment
protection to catch stray accesses. Once program works OK
deliver it as a real mode program on 8086 gaining speed and
bigger market.
AFAIK Linux started using 32-bit mode but heavily depending on
386 segmentation. Rater quickly dependence on segments was
limited and what remained was well isolated. But I think that
Linux shows that _creating_ simple multitasking system is
easier using hardware properties coming together with 286
segmentation.
Intel misjudged what is typical in programs. But they were not
alone in this. I have translation of Tanenbaum book on computer
architecture from 1976 (original, translation is from 1983).
Tanenbaum is very posivite about segmentation, descriptors and
"high level machines". He gave simple examples where descriptors
and microprogrammed "high level machine" are supposed to give
better performance than more conventianal machine.
And as I already wrote, Intel misjudged market for 286. They
could guess that 286 system will be too expensive for home
market for long time. They probably did not expect that
286 will find its way into PC-s.
>>More generally, vendors could release separate versions of
>>programs for 8086 and 286 but few did so.
>
> Were there any who released software both as 8086 and a protected-mode
> 80286 variants? Microsoft/SCO with Xenix, anyone else?
IIUC Microsoft Windows up to 3.0 and probably everbody who wanted
to say "supported on Windows". That is Windows 3.0 on 286 almost
surely used 286 protected mode and probably run "Windows" programs
in protected mode. But Windows also supported 8086 and Microsoft
guidelines insisted that proper "Windows program" should run on
8086.
On DOS I do not remember names of specific programs. I remember
Phar Lap who provided 286 DOS extender and quite a few programs
used it. Browsing trough binaries on machines that I used I saw
the name several times. Sometimes program using DOS extender
would clearly say that it requires 286, but I vaguely remember
cases with separate 286 binaries and 8086 binaries where startup
code loaded right binary. Probably there were also cases whare
needed switching was hidden inside a single binary.
>>And users having
>>only binaries wanted to use 8086 on their new systems which
>>led to heroic efforts like OS/2 DOS box and later Linux
>>dosemu. But integration of 8086 programs with protected
>>mode was solved too late for 286 model to gain traction
>>(and on 286 "DOS box" had to run in real mode, breaking
>>normal system protection).
>
> Linux never ran on a 80286, and DOSemu uses the virtual 8086 mode,
> which does not require heroic efforts AFAIK.
Well, baside virtual 8086 mode there is tricky code to get
right effect. A lot of late "DOS" programs dependend on DOS
extenders and significant fraction of such programs run fine
under dosemu. I do not know if Windows ever got its DOS box
to level of dosemu, but when I used dosemu I heard that
various things did not work in Windows DOS box.
>>> There was various segmented hardware around, first and foremost (for
>>> the designers of the 80286), the iAPX432. And as you write, all the
>>> good reasons that resulted in segments on the iAPX432 also persisted
>>> in the 80286. However, given the slowness of segmentation, only the
>>> tiny (all in one segment), small (one segment for code and one for
>>> data), and maybe medium memory models (one data segment) are
>>> competetive in protected mode compared to real mode.
>>
>>AFAICS that covered wast majority of programs during eighties.
>
> The "vast majority" is not enough; if a key application like Lotus
> 1-2-3 or Wordperfect did not work on the DOS alternative, the DOS
> alternative was not used. And Lotus 1-2-3 and Wordperfect certainly
> did not limit themselves to 64KB of data.
I do not know if they offered protected mode versions. But it
is likely that they did once machines with more than 640 kB
formed resonable fraction of the PC market.
>>Turbo Pascal offered only medium memory model
>
> Acoording to Terje Mathiesen, it also offered the large memory model.
> On its Wikipedia page, I find: "Besides allowing applications larger
> than 64 KB, Byte in 1988 reported ... for version 4.0". So apparently
> Turbo Pascal 4.0 introduced support for the large memory model in
> 1988.
I am not entirely sure, but probaly I used 4.0. I certainly used
5.0 and later versions. AFAIR all versions that I used limited
"static" data to 64 kB, that together with no such limit for code
I take as definition of "medium" model. I do not remeber explicit
model switches which were common on PC C compilers. PC compilers
allowed far/near qualifiers on pointers and I do not rememeber
significant restrictions on this (but other folks reported that
some combinations did not work): for data model set defaults,
but programmer could override it. So in Turbo Pascal one could
use large pointers if desired (or maybe even by default), but
static data was in a single 64 kB segment.
>>Intel apparently assumed that programmers are willing to spend
>>extra work to get good performance and IMO this was right
>>as a general statement. Intel probably did not realize that
>>programmers will be very reluctant to spent work on security
>>features and in particular to spent work on making programs
>>fast in 286 protected mode.
>
> 80286 protected mode is never faster than real mode on the same CPU,
> so the way to make programs fast on the 286 is to stick with real
> mode; using the small memory model is an alternative, but as
> mentioned, the memory limits are too restrictive.
Well, if program needs more than 1 MB total workarounds on 286
may be more expensive than cost of protected mode. More to
the point, if one needs security features, then doing them
in real mode via sofware is likely to take more time than 286
version. Intel clearly did not anticipate that large fraction
of 286-s will be used in PC-s and that in PC vendors/developers
will prefer speed gain (modest when protected mode version
has enough tuning) to protection.
>>Intel probably assumend that 286 would cover most needs,
>
> As far as protected mode was concerned, they hardly could have been
> more wrong.
>
>>especially
>>given that most system had much less memory than 16 MB theoreticlly
>>allowed by 286.
>
> They provided 24 address pins, so they obviously assumed that there
> would be 80286 systems with >8MB. 64KB segments are already too
> limiting on systems with 1MB (which was supported by the 8086),
> probably even for anything beyond 128KB.
>
>>IMO this is partially true: there
>>is a class of programs which with some work fit into medium
>>model, but using flat address space is easier. I think that
>>on 286 (that is with 16 bit bus) those programs (assuming enough
>>tuning) run faster than flat 32-bit version.
>
> Maybe in real mode. Certainly not in protected mode. Just run your
> tuned large-model protected-mode program against a 32-bit small-model
> program for the same task on a 386SX (which is reported as having a
> very similar speed to the 80286 on 16-bit programs).
My instruction table show _longer_ times for several intructions
on 386 compared to 286. For example real mode far call on 286
has 13 clocks + penalty, on 386 17 clocks + the same penalty,
protected mode call on 286 has 26 clocks + penalty, on 386 has
34 clocks + penalty. Near call on both is 7 clocks + penalty.
Anyway, if program consists of several procedures (or clusters
of closely related procedures) each having few kilobytes then
it can easily happen that there are thousends of instructions
between far calls, so cost of far calls is going to be
negligible (19 clocks per thousends of instructions). If
program manages to do its work in single 64 kB data (not
unreasonable for 1 MB code), than it will be faster than
program using 32-bit addresses. More relevant, in multitaking
situation with each task having its own data segment there
will be reloading of segment registers on task switch,
which is likely to be negligible. Again, each task will
gain due to smaller pointers. With OS present there will
be segment reloading due to system calls and this may
be more significant. However, this mostly due to protection
and not segmentation.
> And even if you
> find one case where the protected-mode program wins, nobody found it
> worth their time to do this nonsense.
That is largely true. I wonder what will happen with x32 mode
on x86_64. AFAIK x32 mode showed measurable performance gains,
20-30% smaller programs and similar speed gains. In principle
it should be cheap to support it as it is "just another 32-bit
target". But some (for me important) programs do not work
in this mode and there are voices to completly drop it.
> And so OS/2 flopped despite
> being backed by IBM and, until 1990, Microsoft.
>
>>But I think that Intel segmentation had some
>>attractive features during eighties.
>
> You are one of a tiny minority. Even Intel finally saw the light, as
> did everybody else, and nowadays segments are just a bad memory.
Well, 16-bit segments clearly are too limited when one has several
megabytes of memory. And consistently 32-bit segmented system
increases memory use which is nontrivial cost. OTOH there is
question how much customers are going to pay for security
features. I think recent times show that secuity has significant
costs. But lack of security may lead to big losses. So
there is no easy choice.
Now people talk more about capabilities. AFAICS capabilities
offer more than segments, but are going to have higher cost.
So abstractly, for some systems segments still may look
attractive. OTOH we now understand that software ecosystem
is much more varied than prevalent view in seventies, so
system that fit well to segments are a tiny part.
And considering bad memory, do you remember PAE? That had
similar spirit to 8086 segmentation. I guess that due
to bad feeling for segments among programmers (and possibly
more relevant compatiblity troubles) Intel did not extend
this to segments, but spirit was still there.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-01-05 23:01 -0500 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ndamnjpnt8pkllatkdgq9qn2turaao1f0a@4ax.com> |
| In reply to | #110396 |
On Sun, 5 Jan 2025 21:49:20 -0000 (UTC), antispam@fricas.org (Waldek Hebisch) wrote: >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> >> Meanwhile, Microsoft introduced Windows/386 in September 1987 (in >> addition to the base (8086) variant of Windows 2.0, which was released >> in December 1987), which used 386 protected mode and virtual 8086 mode >> (which was missing in the "brain-damaged" (Bill Gates) 286). So >> Windows completely ignored 286 protected mode. Windows eventually >> became a big success. > >What I recall is a bit different. IIRC first successful version of >Windows, that is Windows 3.0 had 3 modes of operation: 8086 compatible, >286 protected mode and 386 protected mode. Only later Microsoft >dropped requirement for 8086 compatiblity. They didn't drop 8086 so much as required 386. Windows and "DOS box" required the CPU to have "virtual 8086" mode. > I think still later it dropped 286 support. I know 286 protected mode support continued at least through NT. Not sure about 2K. >Windows 95 was supposed to be 32-bit, but contained quite a lot >of 16-bit code. The GUI was 32-bit, the kernel and drivers were 16-bit. Weird, but it made some hardware interfacing easier. >IIRC system interface to Windows 3.0 and 3.1 was 16-bit and only >later Microsoft released extention allowing 32-bit system calls. Never programmed 3.0. 3.1 and 3.11 (WfW) had a combination 16/32-bit kernel in which most device drivers were 16-bit, but the disk driver could be either 16 or 32 bit. In WfW the network stack also was 32-bit and the NIC driver could be either. However the GUI in all 3.x versions was 16-bit 286 protected mode. You could run 32-bit "Win32s" programs (Win32s being a subset of Win32), but Win32s programs could not use graphics. >I have no information about Windows internals except for some >public statements by Microsoft and other people, but I think >it reasonable to assume that Windows was actually a succesful >example of 8086/286/386 compatibility. That is their 16 bit >code could use real mode segmentation or protected mode >segmentation the later both for 286 and 386. For 32-bit >version they added translation layer to transform arguments >between 16-bit world and 32-bit world. It is possible >that this translation layer involved a lot of effort. For a number of years I worked on Windows based image processing systems that used OTS ISA-bus acceleration hardware. The drivers were 16-bit DLLs, and /non-reentrant/. There was one "general" purpose board and several special purpose boards that could be combined with the general board in "stacks" that communicated via a private high speed bus. There could be multiple stacks of boards in the same system. [Our most complicated system had 7 boards in 2 stacks, one with 5 boards and the other with 2. Our biggest system had 18 boards: 6 stacks of 3 boards each. Ever see a 20 slot ISA backplane?] The non-reentrant driver made it difficult to simultaneously control separate stacks to do different tasks. We created a (reentrant) 32->16 bit dispatching "thunk" DLL to translate calls for every function of every board that we might possibly want to use ... hundreds in all ... and then dynamically loaded multiple instances of the driver as required. PITA !!! Worked fine but very hard to debug, particularly when doing several different operations simultaneously. On 3.x we simulated threading in the shared 16-bit application space using multiple processes, messaging with hidden windows, and "far call" IPC using the main program as a kind of "shared library". Having real threads on 95 and later allowed actually consolidating everything into the same program and (at least initially) made everything easier. But then NT forced dealing with protected mode interrupts, while at the same time still using 16-bit drivers for everything else - and that became yet another PITA. We continued to use the image hardware until SIMD became fast enough to compete (circa GHz Pentium4 being available on SBC). Excepting NT3.x we had systems based on every Windows from 3.1 to NT4. >Anyway, it seems that Windows was at least as tied to 286 >as OS/2 when it became sucessful and dropped 286 support >later. And for long time after dropping 286 support >Windows massively used 16-bit segments. I don't know exactly when 286 protected mode was dropped. I do know that, at least through NT4, 16-bit DOS mode and GUI applications would run so long as they relied on system calls and didn't directly try to touch hardware. I occasionally needed to run 16-bit VC++ on my NT4 machine. >IIUC Microsoft Windows up to 3.0 and probably everbody who wanted >to say "supported on Windows". That is Windows 3.0 on 286 almost >surely used 286 protected mode and probably run "Windows" programs >in protected mode. But Windows also supported 8086 and Microsoft >guidelines insisted that proper "Windows program" should run on >8086. Yes. I used - but never programmed - 3.0 on a V20 (8086 clone). It was painfully slow even with 1MB of RAM. >> ... Even Intel finally saw the light, as >> did everybody else, and nowadays segments are just a bad memory. > >Well, 16-bit segments clearly are too limited when one has several >megabytes of memory. And consistently 32-bit segmented system >increases memory use which is nontrivial cost. OTOH there is >question how much customers are going to pay for security >features. I think recent times show that secuity has significant >costs. But lack of security may lead to big losses. So >there is no easy choice. > >Now people talk more about capabilities. AFAICS capabilities >offer more than segments, but are going to have higher cost. >So abstractly, for some systems segments still may look >attractive. OTOH we now understand that software ecosystem >is much more varied than prevalent view in seventies, so >system that fit well to segments are a tiny part. > >And considering bad memory, do you remember PAE? That had >similar spirit to 8086 segmentation. I guess that due >to bad feeling for segments among programmers (and possibly >more relevant compatiblity troubles) Intel did not extend >this to segments, but spirit was still there. The bad taste of segments is from exposure to Intel's half-assed implementation which exposed the segment selector as part of the address. Segments /should/ have been implemented similar to the way paging is done: the program using flat 32-bit addresses and the MMU (SMU?) consulting some kind of segment "database" [using the term loosely]. Intel had a chance to do it right with the 386, but instead they doubled down and expanded the existing poor implementation to support larger segments. I realize that transistor counts at the time might have made an on-chip SMU impossible, but ISTM the SMU would have been a very small component that (if necessary) could have been implemented on-die as a coprocessor. <grin>Maybe my de-deuces are wild ...</grin> but there they are nonetheless. YMMV.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-01-06 08:24 +0000 |
| Subject | Segments (was: 80286 protected mode) |
| Message-ID | <2025Jan6.092443@mips.complang.tuwien.ac.at> |
| In reply to | #110399 |
George Neuner <gneuner2@comcast.net> writes: >The bad taste of segments is from exposure to Intel's half-assed >implementation which exposed the segment selector as part of the >address. > >Segments /should/ have been implemented similar to the way paging is >done: the program using flat 32-bit addresses and the MMU (SMU?) >consulting some kind of segment "database" [using the term loosely]. What benefits do you expect from segments? One benefit usually mentioned is security, in particular, protection against out-of-bounds accesses (e.g., buffer overflow exploits). If the program uses 32-bit (or nowadays 64-bit) addresses, and the segment number is just part of that, you don't get that protection: An out-of-bounds access could not be distinguished from a valid access to a different segment. There might be some addresses that are in no segment, and that would lead to a segment violation, but the same is true for paging-based "security" now; the important part is that there would be (and is) no guarantee that an out-of-bounds access is caught. The 286 segments catch out-of-segment accesses. The size granularity of the 386's 32-bit segments is coarse, but at least out-of-bounds accesses do not intrude into other segments. On the 286 and 386 segment numbers are stored in memory just like any other data, so an attacker may be able to change the segment number in addition to (or instead of) the offset, and thus gain access to sensitive data, so the security provided by 286/386 segments is limited. I have not looked closely into CHERI, but I dimly remember some claims that they protect against manipulation of the extra data (what would be the segment number in the 286) in the 128-bit address. >Intel had a chance to do it right with the 386, but instead they >doubled down and expanded the existing poor implementation to support >larger segments. It looks to me that they took the right choices: Support 286 protected mode, add virtual 8086 mode, support a flat memory model like everybody else has done in modern computers (S/360, PDP-11); to combine these requirements, they added support for segments up to 4GB in size, so people wanting to use flat 32-bit addressing could just use the tiny memory model (CS=DS=SS) and forget about segments. >I realize that transistor counts at the time might have made an >on-chip SMU impossible, but ISTM the SMU would have been a very small >component that (if necessary) could have been implemented on-die as a >coprocessor. How would the addresses be divided into segment and offset in your model? What kind of addresses would you have used on the 286? What would the SMU have to do? Would a PC have used such an SMU if it was a separate chip? If they had made the 286 a kind of real-mode-only 386SX-like CPU, I think that PCs would have been designed without SMU. And one problem would have been that you probably would want 32 address bits to flow from the CPU to the SMU, but the 286 and 386SX only have 24 address pins, and additional pins are expensive. - 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-06 14:41 +0200 |
| Subject | Re: Segments (was: 80286 protected mode) |
| Message-ID | <20250106144122.00005532@yahoo.com> |
| In reply to | #110400 |
On Mon, 06 Jan 2025 08:24:43 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > How would the addresses be divided into segment and offset in your > model? What would the SMU have to do? > > > - anton Those are sort of questions that in the past I several times asked Nick Maclaren when he was still active on c.a. Never got an answer that I was able to understand.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-06 16:05 +0100 |
| Subject | Re: Segments |
| Message-ID | <vlgreu$1lsr9$1@dont-email.me> |
| In reply to | #110400 |
Anton Ertl wrote: > George Neuner <gneuner2@comcast.net> writes: >> The bad taste of segments is from exposure to Intel's half-assed >> implementation which exposed the segment selector as part of the >> address. >> >> Segments /should/ have been implemented similar to the way paging is >> done: the program using flat 32-bit addresses and the MMU (SMU?) >> consulting some kind of segment "database" [using the term loosely]. > > What benefits do you expect from segments? One benefit usually > mentioned is security, in particular, protection against out-of-bounds > accesses (e.g., buffer overflow exploits). The best idea I have seen to help detect out of bounds accesses, is to round all requested memory blocks up to the next 4K boundary and mark the next page as unavailable, then return a skewed pointer back, so that the end of the requested region coincides with the end of the (last) allocated page. This does require at least 8kB for every allocation, but I guess they can all share a single trapping segment? (This idea does not help locate negative buffer overruns (underruns?) but they seem to be much less common?) 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 | 2025-01-06 16:36 +0000 |
| Subject | Re: Segments |
| Message-ID | <2025Jan6.173641@mips.complang.tuwien.ac.at> |
| In reply to | #110404 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: >The best idea I have seen to help detect out of bounds accesses, is to >round all requested memory blocks up to the next 4K boundary and mark >the next page as unavailable, then return a skewed pointer back, so that >the end of the requested region coincides with the end of the (last) >allocated page. This does require at least 8kB for every allocation, but >I guess they can all share a single trapping segment? > >(This idea does not help locate negative buffer overruns (underruns?) >but they seem to be much less common?) It also does not help for out-of-bounds accesses that are not just adjacent to an earlier in-bounds access. That may also be a less common vulnerability than adjacent positive-stride buffer overflows. But if we throw hardware on the problem, do we want to spend hardware on something that does not catch all out-of-bounds accesses? - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-06 19:49 +0000 |
| Subject | Re: Segments |
| Message-ID | <35495df6319c48e684e27ce7b46884ff@www.novabbs.org> |
| In reply to | #110407 |
On Mon, 6 Jan 2025 16:36:41 +0000, Anton Ertl wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>The best idea I have seen to help detect out of bounds accesses, is to
>>round all requested memory blocks up to the next 4K boundary and mark
>>the next page as unavailable, then return a skewed pointer back, so that
>>the end of the requested region coincides with the end of the (last)
>>allocated page. This does require at least 8kB for every allocation, but
>>I guess they can all share a single trapping segment?
>>
>>(This idea does not help locate negative buffer overruns (underruns?)
>>but they seem to be much less common?)
>
> It also does not help for out-of-bounds accesses that are not just
> adjacent to an earlier in-bounds access. That may also be a less
> common vulnerability than adjacent positive-stride buffer overflows.
> But if we throw hardware on the problem, do we want to spend hardware
> on something that does not catch all out-of-bounds accesses?
An IBM guy once told me::
"If you are going to put it in HW, put it in in such a way that you
never have to change the definition of what you put in.
So, to answer the above question:: you want to check absolutely
all boundaries on all multi-container data objects, including
array bounds within a structure::
struct { integer a,b,c,d;
double l[max],m[max],n[max][max]; } k;
Any access to m[] is checked to be within the substructure
of m[*], so you cannot touch l[] or n[][], or a,b,c, or d.
Try doing that with segmentation bounds checking...or
capabilities...
> - anton
[toc] | [prev] | [next] | [standalone]
Page 13 of 23 — ← Prev page 1 … 11 12 [13] 14 15 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web