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 12 of 23 — ← Prev page 1 … 10 11 [12] 13 14 … 23 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-18 05:39 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <86ldylwpp5.fsf@linuxsc.com> |
| In reply to | #109698 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: [ISA support for copying possibly overlapping regions of memory] [Separately, what is possible to do in portable standard C] > [...] I really don't think any of us really disagree, it is just > that we have been discussing two (mostly) orthogonal issues. I would summarize the string of conversations as follows. It started with talking about what is or is not possible in "standard C", by which is meant C that does not rely on any implementation-specific behavior. (Topic A.) The discussion shifted after a comment about how to provide architectual support for copying one region of memory to another, where the areas of memory might overlap. (Topic B.) After the introduction of Topic B, most of the subsequent conversation either ignored Topic A or conflated the two topics. The key point is that Topic B has nothing to do with Topic A, and vice versa. It's like asking why it's colder in the mountains than it is in the summer: both parts have something to do with temperature, but in spite of that there is no meaningful relationship between them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-12 05:11 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <86ttdhy0zj.fsf@linuxsc.com> |
| In reply to | #109607 |
mitchalsup@aol.com (MitchAlsup1) writes: > On Wed, 9 Oct 2024 20:22:16 +0000, David Brown wrote: > >> On 09/10/2024 20:10, Thomas Koenig wrote: >> >>> David Brown <david.brown@hesbynett.no> schrieb: >>> >>>> When would you ever /need/ to compare pointers to different >>>> objects? For almost all C programmers, the answer is "never". >>> >>> Sometimes, it is handy to encode certain conditions in pointers, >>> rather than having only a valid pointer or NULL. A compiler, >>> for example, might want to store the fact that an error occurred >>> while parsing a subexpression as a special pointer constant. >>> >>> Compilers often have the unfair advantage, though, that they can >>> rely on what application programmers cannot, their implementation >>> details. (Some do not, such as f2c). >> >> Standard library authors have the same superpowers, so that they >> can implement an efficient memmove() even though a pure standard C >> programmer cannot (other than by simply calling the standard >> library memmove() function!). > > This is more a symptom of bad ISA design/evolution than of libc > writers needing superpowers. Throughout this long thread you keep missing the point. Having different instructions available doesn't change the definition of the C language. It is possible to write code in standard C (which means, C that does NOT depend on any internal details of any implementation) to copy bytes from one place to another with semantics matching those of memmove(), BUT that code is clunky. To get a decent implementation of memmove() semantics requires knowledge of some internal implementation details that are not part of standard C. Whether those details are part of the compiler or part of the runtime environment (the library) is irrelevant - they still aren't part of standard C. Adding new instructions to the ISA, no matter what those new instructions are, cannot change that.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-13 15:45 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <2024Oct13.174537@mips.complang.tuwien.ac.at> |
| In reply to | #109583 |
David Brown <david.brown@hesbynett.no> writes: >When would you ever /need/ to compare pointers to different objects? >For almost all C programmers, the answer is "never". Pretty much the >only example people ever give of needing such comparisons is to >implement memmove() efficiently - but you don't need to implement >memmove(), because it is already in the standard library. When you implements something like, say vsum(double *a, double *b, double *c, size_t n); where a, b, and c may point to arrays in different objects, or may point to overlapping parts of the same object, and the result vector c in the overlap case should be the same as in the no-overlap case (similar to memmove()), being able to compare pointers to possibly different objects also comes in handy. Another example is when the programmer uses the address as a key in, e.g., a binary search tree. And, as you write, casting to intptr_t is not guarenteed to work by the C standard, either. An example that probably compares pointers to the same object as far as the C standard is concerned, but feel like different objects to the programmer, is logic variables (in, e.g., a Prolog implementation). When you have two free variables, and you unify them, in the implementation one variable points to the other one. Now which should point to which? The younger variable should point to the older one, because it will die sooner. How do you know which variable is younger? You compare the addresses; the variables reside on a stack, so the younger one is closer to the top. If that stack is one object as far as the C standard is concerned, there is no problem with that solution. If the stack is implemented as several objects (to make it easier growable; I don't know if there is a Prolog implementation that does that), you first have to check in which piece it is (maybe with a binary search), and then possibly compare within the stack piece at hand. >> An interesting case is the Forth standard. It specifies "contiguous >> regions", which correspond to objects in C, but in Forth each address >> is a cell and can be added, subtracted, compared, etc. irrespective of >> where it came from. So Forth really has a flat-memory model. It has >> had that since its origins in the 1970s. Some of the 8086 >> implementations had some extensions for dealing with more than 64KB, >> but they were never standardized and are now mostly forgotten. >> > >Forth does not require a flat memory model in the hardware, as far as I >am aware, any more than C does. (I appreciate that your knowledge of >Forth is /vastly/ greater than mine.) A Forth implementation could >interpret part of the address value as the segment or other memory block >identifier and part of it as an index into that block, just as a C >implementation can. I.e., what you are saying is that one can simulate a flat-memory model on a segmented memory model. Certainly. In the case of the 8086 (and even more so on the 286) the costs of that are so high that no widely-used Forth system went there. One can also simulate segmented memory (a natural fit for many programming languages) on flat memory. In this case the cost is much smaller, plus it gives the maximum flexibility about segment/object sizes and numbers. That is why flat memory has won. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-14 17:04 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vejbts$1772o$2@dont-email.me> |
| In reply to | #109688 |
On 13/10/2024 17:45, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> When would you ever /need/ to compare pointers to different objects? >> For almost all C programmers, the answer is "never". Pretty much the >> only example people ever give of needing such comparisons is to >> implement memmove() efficiently - but you don't need to implement >> memmove(), because it is already in the standard library. > > When you implements something like, say > > vsum(double *a, double *b, double *c, size_t n); > > where a, b, and c may point to arrays in different objects, or may > point to overlapping parts of the same object, and the result vector c > in the overlap case should be the same as in the no-overlap case > (similar to memmove()), being able to compare pointers to possibly > different objects also comes in handy. > OK, I can agree with that - /if/ you need such a function. I'd suggest that when you are writing code that might call such a function, you've a very good idea whether you want to do "vec_c = vec_a + vec_b;", or "vec_c += vec_a;" (that is, "b" and "c" are the same). In other words, the programmer calling vsum already knows if there are overlaps, and you'd get the best results if you had different functions for the separate cases. It is conceivable that you don't know if there is an overlap, especially if you are only dealing with parts of arrays rather than full arrays, but I think such cases will be rare. I do think it would be convenient if there were a fully standard way to compare independent pointers (other than just for equality). Rarely needing something does not mean /never/ needing it. Since a fully defined portable method might not be possible (or at least, not efficiently possible) for some weird targets, and it's a good thing that C supports weird targets, I think perhaps the ideal would be to have some feature that exists if and only if you can do sensible comparisons. This could be an additional <stdint.h> pointer type, or some pointer compare macros, or a pre-defined macro to say if you can simply use uintptr_t for the purpose (as you can on most modern C implementations). > Another example is when the programmer uses the address as a key in, > e.g., a binary search tree. And, as you write, casting to intptr_t is > not guarenteed to work by the C standard, either. Casting to uintptr_t (why would one want a /signed/ address?) is all you need for most systems - and for any target where casting to uintptr_t will not be sufficient here, the type uintptr_t will not exist and you get a nice, safe hard compile-time error rather than silently UB code. For uses like this, you don't need to compare pointers - comparing the integers converted from the pointers is fine. (Imagine a system where converted addresses consist of a 16-bit segment number and a 16-bit offset, where the absolute address is the segment number times a scale factor, plus the offset. You can't easily compare two pointers for real address ordering by converting them to an integer type, but the result of casting to uintptr_t is still fine for your binary tree.) > > An example that probably compares pointers to the same object as far > as the C standard is concerned, but feel like different objects to the > programmer, is logic variables (in, e.g., a Prolog implementation). > When you have two free variables, and you unify them, in the > implementation one variable points to the other one. Now which should > point to which? The younger variable should point to the older one, > because it will die sooner. How do you know which variable is > younger? You compare the addresses; the variables reside on a stack, > so the younger one is closer to the top. > > If that stack is one object as far as the C standard is concerned, > there is no problem with that solution. If the stack is implemented > as several objects (to make it easier growable; I don't know if there > is a Prolog implementation that does that), you first have to check in > which piece it is (maybe with a binary search), and then possibly > compare within the stack piece at hand. > My only experience of Prolog was working through a short tutorial article when I was a teenager - I have no idea about implementations! But again I come back to the same conclusion - there are situations where being able to compare addresses can be useful, but it is very rare for most programmers to ever actually need to do so. And I think it is good that there is a widely portable way to achieve this, by casting to uintptr_t and comparing those integers. There are things that people want to do with C programming that can be done with implementation-specific code, but which cannot be done with fully portable standard code. While it is always nice if you /can/ use fully portable solutions (while still being clear and efficient), it's okay to have non-portable code when you need it. >>> An interesting case is the Forth standard. It specifies "contiguous >>> regions", which correspond to objects in C, but in Forth each address >>> is a cell and can be added, subtracted, compared, etc. irrespective of >>> where it came from. So Forth really has a flat-memory model. It has >>> had that since its origins in the 1970s. Some of the 8086 >>> implementations had some extensions for dealing with more than 64KB, >>> but they were never standardized and are now mostly forgotten. >>> >> >> Forth does not require a flat memory model in the hardware, as far as I >> am aware, any more than C does. (I appreciate that your knowledge of >> Forth is /vastly/ greater than mine.) A Forth implementation could >> interpret part of the address value as the segment or other memory block >> identifier and part of it as an index into that block, just as a C >> implementation can. > > I.e., what you are saying is that one can simulate a flat-memory model > on a segmented memory model. Yes. > Certainly. In the case of the 8086 (and > even more so on the 286) the costs of that are so high that no > widely-used Forth system went there. > OK. That's much the same as C on segmented targets. > One can also simulate segmented memory (a natural fit for many > programming languages) on flat memory. In this case the cost is much > smaller, plus it gives the maximum flexibility about segment/object > sizes and numbers. That is why flat memory has won. > Sure, flat memory is nicer in many ways.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-14 19:02 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <3e885f3c9d768541e2b07180d5821a1f@www.novabbs.org> |
| In reply to | #109699 |
On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > On 13/10/2024 17:45, Anton Ertl wrote: > I do think it would be convenient if there were a fully standard way to > compare independent pointers (other than just for equality). Rarely > needing something does not mean /never/ needing it. OK, take a segmented memory model with 16-bit pointers and a 24-bit virtual address space. How do you actually compare to segmented pointers ??
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-14 22:20 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241014222042.00004247@yahoo.com> |
| In reply to | #109702 |
On Mon, 14 Oct 2024 19:02:51 +0000 mitchalsup@aol.com (MitchAlsup1) wrote: > On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > > > On 13/10/2024 17:45, Anton Ertl wrote: > > > I do think it would be convenient if there were a fully standard > > way to compare independent pointers (other than just for equality). > > Rarely needing something does not mean /never/ needing it. > > OK, take a segmented memory model with 16-bit pointers and a 24-bit > virtual address space. How do you actually compare to segmented > pointers ?? That's their problem. The rest of the C world shouldn't suffer because of odd birds.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-15 00:14 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <3f1fedcdd2dd5821307450056e3b1afe@www.novabbs.org> |
| In reply to | #109703 |
On Mon, 14 Oct 2024 19:20:42 +0000, Michael S wrote: > On Mon, 14 Oct 2024 19:02:51 +0000 > mitchalsup@aol.com (MitchAlsup1) wrote: > >> On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: >> >>> On 13/10/2024 17:45, Anton Ertl wrote: >> >>> I do think it would be convenient if there were a fully standard >>> way to compare independent pointers (other than just for equality). >>> Rarely needing something does not mean /never/ needing it. >> >> OK, take a segmented memory model with 16-bit pointers and a 24-bit >> virtual address space. How do you actually compare to segmented >> pointers ?? > > That's their problem. The rest of the C world shouldn't suffer because > of odd birds. So, you are saying that 286 in its hey-day was/is odd ?!?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-15 10:41 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241015104141.00005417@yahoo.com> |
| In reply to | #109710 |
On Tue, 15 Oct 2024 00:14:25 +0000 mitchalsup@aol.com (MitchAlsup1) wrote: > On Mon, 14 Oct 2024 19:20:42 +0000, Michael S wrote: > > > On Mon, 14 Oct 2024 19:02:51 +0000 > > mitchalsup@aol.com (MitchAlsup1) wrote: > > > >> On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > >> > >>> On 13/10/2024 17:45, Anton Ertl wrote: > >> > >>> I do think it would be convenient if there were a fully standard > >>> way to compare independent pointers (other than just for > >>> equality). Rarely needing something does not mean /never/ needing > >>> it. > >> > >> OK, take a segmented memory model with 16-bit pointers and a 24-bit > >> virtual address space. How do you actually compare to segmented > >> pointers ?? > > > > That's their problem. The rest of the C world shouldn't suffer > > because of odd birds. > > So, you are saying that 286 in its hey-day was/is odd ?!? In its heyday 80286 was used as MUCH faster 8088. 286-as-286 was/is odd creature. I'd dare to say that it had no heyday.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-14 19:39 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <1sePO.260703$v8v2.138100@fx18.iad> |
| In reply to | #109702 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > >> On 13/10/2024 17:45, Anton Ertl wrote: > >> I do think it would be convenient if there were a fully standard way to >> compare independent pointers (other than just for equality). Rarely >> needing something does not mean /never/ needing it. > >OK, take a segmented memory model with 16-bit pointers and a 24-bit >virtual address space. How do you actually compare to segmented >pointers ?? Depends. On the Burroughs mainframe there could be eight active segments and the segment number was part of the pointer. Pointers were 32-bits (actually 8 BCD digits) S s OOOOOO Where 'S' was a sign digit (C or D), 's' was the segment number (0-7) and OOOOOO was the six digit offset within the segment (500kB/1000kD each). A particular task (process) could have up to one million "environments", each environment could have up to 100 "memory areas (up to 1000kD) of which the first eight were loaded into the processor base/limit registers. Index registers were 8 digits and were loaded with a pointer as described above. Operands could optionally select one of the index registers and the operand address was treated as an offset to the index register; there were 7 index registers. Access to memory areas 8-99 use string instructions where the pointer was 16 BCD digits: EEEEEEMM SsOOOOOO Where EEEEEE was the evironment number (0-999999); environments starting with D00000 were reserved for the MCP (Operating System). MM was the memory area number and the remaining eight digits described the data within the memory area. A subroutine call could call within a memory area or switch to a new environment. Memory area 1 was the code region for the segment, Memory area 0 held the stack and some global variables and was typically shared by all environments. Memory areas 2-7 were application dependent and could be configured to be shared between environments at link time.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-15 00:15 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <52c9e21ea94028b0a3f8b5fc756cdb90@www.novabbs.org> |
| In reply to | #109704 |
On Mon, 14 Oct 2024 19:39:41 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: >> >>> On 13/10/2024 17:45, Anton Ertl wrote: >> >>> I do think it would be convenient if there were a fully standard way to >>> compare independent pointers (other than just for equality). Rarely >>> needing something does not mean /never/ needing it. >> >>OK, take a segmented memory model with 16-bit pointers and a 24-bit >>virtual address space. How do you actually compare to segmented >>pointers ?? > > Depends. On the Burroughs mainframe there could be eight > active segments and the segment number was part of the pointer. > > Pointers were 32-bits (actually 8 BCD digits) Stick to the question asked. Registers were 16-binary digits, and segment registers enabled access to 24-bit address space.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-18 12:47 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241018124753.00002084@yahoo.com> |
| In reply to | #109704 |
On Mon, 14 Oct 2024 19:39:41 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > mitchalsup@aol.com (MitchAlsup1) writes: > >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > > > >> On 13/10/2024 17:45, Anton Ertl wrote: > > > >> I do think it would be convenient if there were a fully standard > >> way to compare independent pointers (other than just for > >> equality). Rarely needing something does not mean /never/ needing > >> it. > > > >OK, take a segmented memory model with 16-bit pointers and a 24-bit > >virtual address space. How do you actually compare to segmented > >pointers ?? > > Depends. On the Burroughs mainframe there could be eight > active segments and the segment number was part of the pointer. > > Pointers were 32-bits (actually 8 BCD digits) > > S s OOOOOO > > Where 'S' was a sign digit (C or D), 's' was the > segment number (0-7) and OOOOOO was the six digit > offset within the segment (500kB/1000kD each). > > A particular task (process) could have up to > one million "environments", each environment > could have up to 100 "memory areas (up to 1000kD) > of which the first eight were loaded into the > processor base/limit registers. Index registers > were 8 digits and were loaded with a pointer as > described above. Operands could optionally select > one of the index registers and the operand address > was treated as an offset to the index register; > there were 7 index registers. > > Access to memory areas 8-99 use string instructions > where the pointer was 16 BCD digits: > > EEEEEEMM SsOOOOOO > > Where EEEEEE was the evironment number (0-999999); > environments starting with D00000 were reserved for > the MCP (Operating System). MM was the memory area > number and the remaining eight digits described the > data within the memory area. A subroutine call could > call within a memory area or switch to a new environment. > > Memory area 1 was the code region for the segment, > Memory area 0 held the stack and some global variables > and was typically shared by all environments. > Memory areas 2-7 were application dependent and could > be configured to be shared between environments at > link time. What was the size of phiscal address space ? I would suppose, more than 1,000,000 words?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-18 14:06 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <tXtQO.77260$UZH4.60981@fx44.iad> |
| In reply to | #109798 |
Michael S <already5chosen@yahoo.com> writes: >On Mon, 14 Oct 2024 19:39:41 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >> >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: >> > >> >> On 13/10/2024 17:45, Anton Ertl wrote: >> > >> >> I do think it would be convenient if there were a fully standard >> >> way to compare independent pointers (other than just for >> >> equality). Rarely needing something does not mean /never/ needing >> >> it. >> > >> >OK, take a segmented memory model with 16-bit pointers and a 24-bit >> >virtual address space. How do you actually compare to segmented >> >pointers ?? >> >> Depends. On the Burroughs mainframe there could be eight >> active segments and the segment number was part of the pointer. >> >> Pointers were 32-bits (actually 8 BCD digits) >> >> S s OOOOOO >> >> Where 'S' was a sign digit (C or D), 's' was the >> segment number (0-7) and OOOOOO was the six digit >> offset within the segment (500kB/1000kD each). >> >> A particular task (process) could have up to >> one million "environments", each environment >> could have up to 100 "memory areas (up to 1000kD) >> of which the first eight were loaded into the >> processor base/limit registers. Index registers >> were 8 digits and were loaded with a pointer as >> described above. Operands could optionally select >> one of the index registers and the operand address >> was treated as an offset to the index register; >> there were 7 index registers. >> >> Access to memory areas 8-99 use string instructions >> where the pointer was 16 BCD digits: >> >> EEEEEEMM SsOOOOOO >> >> Where EEEEEE was the evironment number (0-999999); >> environments starting with D00000 were reserved for >> the MCP (Operating System). MM was the memory area >> number and the remaining eight digits described the >> data within the memory area. A subroutine call could >> call within a memory area or switch to a new environment. >> >> Memory area 1 was the code region for the segment, >> Memory area 0 held the stack and some global variables >> and was typically shared by all environments. >> Memory areas 2-7 were application dependent and could >> be configured to be shared between environments at >> link time. > >What was the size of phiscal address space ? >I would suppose, more than 1,000,000 words? It varied based on the generation. In the 1960s, a half megabyte (10^6 digits) was the limit. In the 1970s, the architecture supported 10^8 digits, the largest B4800 systems were shipped with 2 million digits (1MB). In 1979, the B4900 was introduced supporting up to 10MB (20 MD), later increased to 20MB/40MD. In the 1980s, the largest systems (V500) supported up to 10^9 digits. It was that generation of machine where the environment scheme was introduced. Binaries compiled in 1966 ran on all generations without recompilation. There was room in the segmentation structures for up to 10^18 digit physical addresses (where the segments were aligned on 10^3 digit boundaries). Unisys discontinued that line of systems in 1992.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-18 17:34 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241018173416.00004a0f@yahoo.com> |
| In reply to | #109801 |
On Fri, 18 Oct 2024 14:06:17 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Mon, 14 Oct 2024 19:39:41 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> mitchalsup@aol.com (MitchAlsup1) writes: > >> >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > >> > > >> >> On 13/10/2024 17:45, Anton Ertl wrote: > >> > > >> >> I do think it would be convenient if there were a fully standard > >> >> way to compare independent pointers (other than just for > >> >> equality). Rarely needing something does not mean /never/ > >> >> needing it. > >> > > >> >OK, take a segmented memory model with 16-bit pointers and a > >> >24-bit virtual address space. How do you actually compare to > >> >segmented pointers ?? > >> > >> Depends. On the Burroughs mainframe there could be eight > >> active segments and the segment number was part of the pointer. > >> > >> Pointers were 32-bits (actually 8 BCD digits) > >> > >> S s OOOOOO > >> > >> Where 'S' was a sign digit (C or D), 's' was the > >> segment number (0-7) and OOOOOO was the six digit > >> offset within the segment (500kB/1000kD each). > >> > >> A particular task (process) could have up to > >> one million "environments", each environment > >> could have up to 100 "memory areas (up to 1000kD) > >> of which the first eight were loaded into the > >> processor base/limit registers. Index registers > >> were 8 digits and were loaded with a pointer as > >> described above. Operands could optionally select > >> one of the index registers and the operand address > >> was treated as an offset to the index register; > >> there were 7 index registers. > >> > >> Access to memory areas 8-99 use string instructions > >> where the pointer was 16 BCD digits: > >> > >> EEEEEEMM SsOOOOOO > >> > >> Where EEEEEE was the evironment number (0-999999); > >> environments starting with D00000 were reserved for > >> the MCP (Operating System). MM was the memory area > >> number and the remaining eight digits described the > >> data within the memory area. A subroutine call could > >> call within a memory area or switch to a new environment. > >> > >> Memory area 1 was the code region for the segment, > >> Memory area 0 held the stack and some global variables > >> and was typically shared by all environments. > >> Memory areas 2-7 were application dependent and could > >> be configured to be shared between environments at > >> link time. > > > >What was the size of phiscal address space ? > >I would suppose, more than 1,000,000 words? > > It varied based on the generation. In the > 1960s, a half megabyte (10^6 digits) > was the limit. > > In the 1970s, the architecture supported > 10^8 digits, the largest B4800 systems > were shipped with 2 million digits (1MB). > In 1979, the B4900 was introduced supporting > up to 10MB (20 MD), later increased to > 20MB/40MD. > > In the 1980s, the largest systems (V500) > supported up to 10^9 digits. It > was that generation of machine where the > environment scheme was introduced. > > Binaries compiled in 1966 ran on all > generations without recompilation. > > There was room in the segmentation structures > for up to 10^18 digit physical addresses > (where the segments were aligned on 10^3 > digit boundaries). So, can it be said that ar least some of B6500-compatible models suffered from the same problem as 80286 - the segment of maximal size didn't cover all linear (or physical) address space? Or their index register width was increased to accomodate 1e9 digits in the single segment? > > Unisys discontinued that line of systems in 1992. I thought it lasted longer. My impresion was that there were still hardware implemntation (alongside with emulation on Xeons) sold up until 15 years ago.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-18 16:19 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <0UvQO.100333$xO0f.88362@fx48.iad> |
| In reply to | #109803 |
Michael S <already5chosen@yahoo.com> writes: >On Fri, 18 Oct 2024 14:06:17 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >On Mon, 14 Oct 2024 19:39:41 GMT >> >scott@slp53.sl.home (Scott Lurndal) wrote: >> > >> >> mitchalsup@aol.com (MitchAlsup1) writes: >> >> >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: >> >> > >> >> >> On 13/10/2024 17:45, Anton Ertl wrote: >> >> > >> >> >> I do think it would be convenient if there were a fully standard >> >> >> way to compare independent pointers (other than just for >> >> >> equality). Rarely needing something does not mean /never/ >> >> >> needing it. >> >> > >> >> >OK, take a segmented memory model with 16-bit pointers and a >> >> >24-bit virtual address space. How do you actually compare to >> >> >segmented pointers ?? >> >> >> >> Depends. On the Burroughs mainframe there could be eight >> >> active segments and the segment number was part of the pointer. >> >> >> >> Pointers were 32-bits (actually 8 BCD digits) >> >> >> >> S s OOOOOO >> >> >> >> Where 'S' was a sign digit (C or D), 's' was the >> >> segment number (0-7) and OOOOOO was the six digit >> >> offset within the segment (500kB/1000kD each). >> >> >> >> A particular task (process) could have up to >> >> one million "environments", each environment >> >> could have up to 100 "memory areas (up to 1000kD) >> >> of which the first eight were loaded into the >> >> processor base/limit registers. Index registers >> >> were 8 digits and were loaded with a pointer as >> >> described above. Operands could optionally select >> >> one of the index registers and the operand address >> >> was treated as an offset to the index register; >> >> there were 7 index registers. >> >> >> >> Access to memory areas 8-99 use string instructions >> >> where the pointer was 16 BCD digits: >> >> >> >> EEEEEEMM SsOOOOOO >> >> >> >> Where EEEEEE was the evironment number (0-999999); >> >> environments starting with D00000 were reserved for >> >> the MCP (Operating System). MM was the memory area >> >> number and the remaining eight digits described the >> >> data within the memory area. A subroutine call could >> >> call within a memory area or switch to a new environment. >> >> >> >> Memory area 1 was the code region for the segment, >> >> Memory area 0 held the stack and some global variables >> >> and was typically shared by all environments. >> >> Memory areas 2-7 were application dependent and could >> >> be configured to be shared between environments at >> >> link time. >> > >> >What was the size of phiscal address space ? >> >I would suppose, more than 1,000,000 words? >> >> It varied based on the generation. In the >> 1960s, a half megabyte (10^6 digits) >> was the limit. >> >> In the 1970s, the architecture supported >> 10^8 digits, the largest B4800 systems >> were shipped with 2 million digits (1MB). >> In 1979, the B4900 was introduced supporting >> up to 10MB (20 MD), later increased to >> 20MB/40MD. >> >> In the 1980s, the largest systems (V500) >> supported up to 10^9 digits. It >> was that generation of machine where the >> environment scheme was introduced. >> >> Binaries compiled in 1966 ran on all >> generations without recompilation. >> >> There was room in the segmentation structures >> for up to 10^18 digit physical addresses >> (where the segments were aligned on 10^3 >> digit boundaries). > >So, can it be said that ar least some of B6500-compatible models No. The systems I described above are from the medium systems family (B2000/B3000/B4000). The B5000/B6000/B7000 (large) family systems were a completely different stack based architecture with a 48-bit word size. The Small systems (B1000) supported task-specific dynamic microcode loading (different microcode for a cobol app vs. a fortran app). Medium systems evolved from the Electrodata Datatron and 220 (1954) through the Burroughs B300 to the Burroughs B3500 by 1965. The B5000 was also developed at the old Electrodata plant in Pasadena (where I worked in the 80s) - eventually large systems moved out - the more capable large systems (B7XXX) were designed in Tredyffrin Pa, the less capable large systems (B5XXX) were designed in Mission Viejo, Ca. >suffered from the same problem as 80286 - the segment of maximal size >didn't cover all linear (or physical) address space? >Or their index register width was increased to accomodate 1e9 digits in >the single segment? > >> >> Unisys discontinued that line of systems in 1992. > >I thought it lasted longer. My impresion was that there were still >hardware implemntation (alongside with emulation on Xeons) sold up >until 15 years ago. Large systems still exist today in emulation[*], as do the former Univac (Sperry 2200) systems. The last medium system (V380) was retired by the City of Santa Ana in 2010 (almost two decades after Unisys cancelled the product line) and was moved to the Living Computer Museum. City of Santa Ana replaced the single 1980 vintage V380 with 29 windows servers. After the merger of Burroughs and Sperry in '86 there were six different mainframe architectures - by 1990, all but two (2200 and large systems) had been terminated. [*] Clearpath Libra https://www.unisys.com/client-education/clearpath-forward-libra-servers/
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-19 19:46 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241019194641.0000213b@yahoo.com> |
| In reply to | #109804 |
On Fri, 18 Oct 2024 16:19:08 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Fri, 18 Oct 2024 14:06:17 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> >On Mon, 14 Oct 2024 19:39:41 GMT > >> >scott@slp53.sl.home (Scott Lurndal) wrote: > >> > > >> >> mitchalsup@aol.com (MitchAlsup1) writes: > >> >> >On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: > >> >> > > >> >> >> On 13/10/2024 17:45, Anton Ertl wrote: > >> >> > > >> >> >> I do think it would be convenient if there were a fully > >> >> >> standard way to compare independent pointers (other than > >> >> >> just for equality). Rarely needing something does not mean > >> >> >> /never/ needing it. > >> >> > > >> >> >OK, take a segmented memory model with 16-bit pointers and a > >> >> >24-bit virtual address space. How do you actually compare to > >> >> >segmented pointers ?? > >> >> > >> >> Depends. On the Burroughs mainframe there could be eight > >> >> active segments and the segment number was part of the pointer. > >> >> > >> >> Pointers were 32-bits (actually 8 BCD digits) > >> >> > >> >> S s OOOOOO > >> >> > >> >> Where 'S' was a sign digit (C or D), 's' was the > >> >> segment number (0-7) and OOOOOO was the six digit > >> >> offset within the segment (500kB/1000kD each). > >> >> > >> >> A particular task (process) could have up to > >> >> one million "environments", each environment > >> >> could have up to 100 "memory areas (up to 1000kD) > >> >> of which the first eight were loaded into the > >> >> processor base/limit registers. Index registers > >> >> were 8 digits and were loaded with a pointer as > >> >> described above. Operands could optionally select > >> >> one of the index registers and the operand address > >> >> was treated as an offset to the index register; > >> >> there were 7 index registers. > >> >> > >> >> Access to memory areas 8-99 use string instructions > >> >> where the pointer was 16 BCD digits: > >> >> > >> >> EEEEEEMM SsOOOOOO > >> >> > >> >> Where EEEEEE was the evironment number (0-999999); > >> >> environments starting with D00000 were reserved for > >> >> the MCP (Operating System). MM was the memory area > >> >> number and the remaining eight digits described the > >> >> data within the memory area. A subroutine call could > >> >> call within a memory area or switch to a new environment. > >> >> > >> >> Memory area 1 was the code region for the segment, > >> >> Memory area 0 held the stack and some global variables > >> >> and was typically shared by all environments. > >> >> Memory areas 2-7 were application dependent and could > >> >> be configured to be shared between environments at > >> >> link time. > >> > > >> >What was the size of phiscal address space ? > >> >I would suppose, more than 1,000,000 words? > >> > >> It varied based on the generation. In the > >> 1960s, a half megabyte (10^6 digits) > >> was the limit. > >> > >> In the 1970s, the architecture supported > >> 10^8 digits, the largest B4800 systems > >> were shipped with 2 million digits (1MB). > >> In 1979, the B4900 was introduced supporting > >> up to 10MB (20 MD), later increased to > >> 20MB/40MD. > >> > >> In the 1980s, the largest systems (V500) > >> supported up to 10^9 digits. It > >> was that generation of machine where the > >> environment scheme was introduced. > >> > >> Binaries compiled in 1966 ran on all > >> generations without recompilation. > >> > >> There was room in the segmentation structures > >> for up to 10^18 digit physical addresses > >> (where the segments were aligned on 10^3 > >> digit boundaries). > > > >So, can it be said that ar least some of B6500-compatible models > > No. The systems I described above are from the medium > systems family (B2000/B3000/B4000). I didn't realize that you were not talking about Large Systems. I didn't even know that Medium Systems used segmented memory. Sorry. > The B5000/B6000/B7000 > (large) family systems were a completely different stack based > architecture with a 48-bit word size. The Small systems (B1000) > supported task-specific dynamic microcode loading (different > microcode for a cobol app vs. a fortran app). > > Medium systems evolved from the Electrodata Datatron and 220 (1954) > through the Burroughs B300 to the Burroughs B3500 by 1965. The B5000 > was also developed at the old Electrodata plant in Pasadena > (where I worked in the 80s) - eventually large systems moved > out - the more capable large systems (B7XXX) were designed in > Tredyffrin Pa, the less capable large systems (B5XXX) were designed > in Mission Viejo, Ca. > > >suffered from the same problem as 80286 - the segment of maximal size > >didn't cover all linear (or physical) address space? > >Or their index register width was increased to accomodate 1e9 digits > >in the single segment? > > > >> > >> Unisys discontinued that line of systems in 1992. > > > >I thought it lasted longer. My impresion was that there were still > >hardware implemntation (alongside with emulation on Xeons) sold up > >until 15 years ago. > > Large systems still exist today in emulation[*], as do the > former Univac (Sperry 2200) systems. The last medium system > (V380) was retired by the City of Santa Ana in 2010 (almost two > decades after Unisys cancelled the product line) and was moved > to the Living Computer Museum. > > City of Santa Ana replaced the single 1980 vintage V380 with > 29 windows servers. > > After the merger of Burroughs and Sperry in '86 there were six > different mainframe architectures - by 1990, all but > two (2200 and large systems) had been terminated. > > [*] Clearpath Libra > https://www.unisys.com/client-education/clearpath-forward-libra-servers/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-15 12:38 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <velgng$1lhfe$1@dont-email.me> |
| In reply to | #109702 |
On 14/10/2024 21:02, MitchAlsup1 wrote:
> On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote:
>
>> On 13/10/2024 17:45, Anton Ertl wrote:
>
>> I do think it would be convenient if there were a fully standard way to
>> compare independent pointers (other than just for equality). Rarely
>> needing something does not mean /never/ needing it.
>
> OK, take a segmented memory model with 16-bit pointers and a 24-bit
> virtual address space. How do you actually compare to segmented
> pointers ??
void * p = ...
void * q = ...
uintptr_t pu = (uintptr_t) p;
uintptr_t qu = (uintptr_t) q;
if (pu > qu) {
...
} else if (pu < qu) {
...
} else {
...
}
If your comparison needs to actually match up with the real virtual
addresses, then this will not work. But does that actually matter?
Think about using this comparison for memmove().
Consider where these pointers come from. Maybe they are pointers to
statically allocated data. Then you would expect the segment to be the
same in each case, and the uintptr_t comparison will be fine for
memmove(). Maybe they come from malloc() and are in different segments.
Then the comparison here might not give the same result as a full
virtual address comparison - but that does not matter. If the pointers
came from different mallocs, they could not overlap and memmove() can
run either direction.
The same applies to other uses, such as indexing in a binary search tree
or a hash map - the comparison above will be correct when it matters.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-15 14:22 +0300 |
| Subject | Re: 80286 protected mode |
| Message-ID | <20241015142246.00001f24@yahoo.com> |
| In reply to | #109720 |
On Tue, 15 Oct 2024 12:38:40 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 14/10/2024 21:02, MitchAlsup1 wrote:
> > On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote:
> >
> >> On 13/10/2024 17:45, Anton Ertl wrote:
> >
> >> I do think it would be convenient if there were a fully standard
> >> way to compare independent pointers (other than just for
> >> equality). Rarely needing something does not mean /never/ needing
> >> it.
> >
> > OK, take a segmented memory model with 16-bit pointers and a 24-bit
> > virtual address space. How do you actually compare to segmented
> > pointers ??
>
>
> void * p = ...
> void * q = ...
>
> uintptr_t pu = (uintptr_t) p;
> uintptr_t qu = (uintptr_t) q;
>
> if (pu > qu) {
> ...
> } else if (pu < qu) {
> ...
> } else {
> ...
> }
>
>
> If your comparison needs to actually match up with the real virtual
> addresses, then this will not work. But does that actually matter?
>
> Think about using this comparison for memmove().
>
> Consider where these pointers come from. Maybe they are pointers to
> statically allocated data. Then you would expect the segment to be
> the same in each case, and the uintptr_t comparison will be fine for
> memmove(). Maybe they come from malloc() and are in different
> segments. Then the comparison here might not give the same result as
> a full virtual address comparison - but that does not matter. If the
> pointers came from different mallocs, they could not overlap and
> memmove() can run either direction.
>
> The same applies to other uses, such as indexing in a binary search
> tree or a hash map - the comparison above will be correct when it
> matters.
>
>
>
It's all fine for as long as there are no objects bigger than 64KB.
But with 16MB of virtual memory and with several* MB of physical memory
one does want objects that are bigger than 64KB!
---
* https://theretroweb.com/motherboards/s/compaq-deskpro-286e-p-n-001226
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-15 14:09 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <velm2m$1lhfe$4@dont-email.me> |
| In reply to | #109723 |
On 15/10/2024 13:22, Michael S wrote:
> On Tue, 15 Oct 2024 12:38:40 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 14/10/2024 21:02, MitchAlsup1 wrote:
>>> On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote:
>>>
>>>> On 13/10/2024 17:45, Anton Ertl wrote:
>>>
>>>> I do think it would be convenient if there were a fully standard
>>>> way to compare independent pointers (other than just for
>>>> equality). Rarely needing something does not mean /never/ needing
>>>> it.
>>>
>>> OK, take a segmented memory model with 16-bit pointers and a 24-bit
>>> virtual address space. How do you actually compare to segmented
>>> pointers ??
>>
>>
>> void * p = ...
>> void * q = ...
>>
>> uintptr_t pu = (uintptr_t) p;
>> uintptr_t qu = (uintptr_t) q;
>>
>> if (pu > qu) {
>> ...
>> } else if (pu < qu) {
>> ...
>> } else {
>> ...
>> }
>>
>>
>> If your comparison needs to actually match up with the real virtual
>> addresses, then this will not work. But does that actually matter?
>>
>> Think about using this comparison for memmove().
>>
>> Consider where these pointers come from. Maybe they are pointers to
>> statically allocated data. Then you would expect the segment to be
>> the same in each case, and the uintptr_t comparison will be fine for
>> memmove(). Maybe they come from malloc() and are in different
>> segments. Then the comparison here might not give the same result as
>> a full virtual address comparison - but that does not matter. If the
>> pointers came from different mallocs, they could not overlap and
>> memmove() can run either direction.
>>
>> The same applies to other uses, such as indexing in a binary search
>> tree or a hash map - the comparison above will be correct when it
>> matters.
>>
>>
>>
>
> It's all fine for as long as there are no objects bigger than 64KB.
> But with 16MB of virtual memory and with several* MB of physical memory
> one does want objects that are bigger than 64KB!
>
I don't know how such objects would be allocated and addressed in such a
system. (I didn't do much DOS/Win16 programming, and on the few
occasions when I needed structures bigger than 64KB in total, they were
structured in multiple levels.)
But I would expect that in almost any practical system where you can use
"p++" to step through big arrays, you can also convert the pointer to a
uintptr_t and compare as shown above.
The exceptions would be systems where pointers hold more than just
addresses, such as access control information or bounds that mean they
are larger than the largest integer type on the target.
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2024-10-15 19:46 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vemgqf$1r0im$1@dont-email.me> |
| In reply to | #109726 |
David Brown <david.brown@hesbynett.no> wrote:
> On 15/10/2024 13:22, Michael S wrote:
>> On Tue, 15 Oct 2024 12:38:40 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> On 14/10/2024 21:02, MitchAlsup1 wrote:
>>>> On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote:
>>>>
>>>>> On 13/10/2024 17:45, Anton Ertl wrote:
>>>>
>>>>> I do think it would be convenient if there were a fully standard
>>>>> way to compare independent pointers (other than just for
>>>>> equality). Rarely needing something does not mean /never/ needing
>>>>> it.
>>>>
>>>> OK, take a segmented memory model with 16-bit pointers and a 24-bit
>>>> virtual address space. How do you actually compare to segmented
>>>> pointers ??
>>>
>>>
>>> void * p = ...
>>> void * q = ...
>>>
>>> uintptr_t pu = (uintptr_t) p;
>>> uintptr_t qu = (uintptr_t) q;
>>>
>>> if (pu > qu) {
>>> ...
>>> } else if (pu < qu) {
>>> ...
>>> } else {
>>> ...
>>> }
>>>
>>>
>>> If your comparison needs to actually match up with the real virtual
>>> addresses, then this will not work. But does that actually matter?
>>>
>>> Think about using this comparison for memmove().
>>>
>>> Consider where these pointers come from. Maybe they are pointers to
>>> statically allocated data. Then you would expect the segment to be
>>> the same in each case, and the uintptr_t comparison will be fine for
>>> memmove(). Maybe they come from malloc() and are in different
>>> segments. Then the comparison here might not give the same result as
>>> a full virtual address comparison - but that does not matter. If the
>>> pointers came from different mallocs, they could not overlap and
>>> memmove() can run either direction.
>>>
>>> The same applies to other uses, such as indexing in a binary search
>>> tree or a hash map - the comparison above will be correct when it
>>> matters.
>>>
>>>
>>>
>>
>> It's all fine for as long as there are no objects bigger than 64KB.
>> But with 16MB of virtual memory and with several* MB of physical memory
>> one does want objects that are bigger than 64KB!
>>
>
> I don't know how such objects would be allocated and addressed in such a
> system. (I didn't do much DOS/Win16 programming, and on the few
> occasions when I needed structures bigger than 64KB in total, they were
> structured in multiple levels.)
>
> But I would expect that in almost any practical system where you can use
> "p++" to step through big arrays, you can also convert the pointer to a
> uintptr_t and compare as shown above.
>
> The exceptions would be systems where pointers hold more than just
> addresses, such as access control information or bounds that mean they
> are larger than the largest integer type on the target.
EGA graphics had more than 64k, smart software would group one or more scan
lines into segments for bit mapping the array. A bit mapper works a scan
line at a time so segment changes were not that expensive. This was
profoundly faster than using pixel pokes and the other default methods of
changing bits.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2024-10-08 16:00 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ve3kuh$22nr$1@gal.iecc.com> |
| In reply to | #109515 |
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. Even if you wanted to write code that put objects in segments, you really couldn't. You had to minimize the number of segment switches to get decent performance. >Would it have been differently if the 8086/8088 had already had >protected mode? I think that having one segment per object would have >been too inefficient, and also that 8192 segments is not enough for >that kind of usage, ... That's all true, but I'd think the slowness of segment switches would be even more of a problem. -- 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]
Page 12 of 23 — ← Prev page 1 … 10 11 [12] 13 14 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web