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 22 of 23 — ← Prev page 1 … 20 21 [22] 23 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-17 21:05 -0800 |
| Subject | Re: Segments |
| Message-ID | <877c6s7lu2.fsf@nosuchdomain.example.com> |
| In reply to | #110561 |
mitchalsup@aol.com (MitchAlsup1) writes:
> On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> [...]
>>> I do know that several people have created fast string libraries,
>>> where any string that is short enough ends up entirely inside the dope
>>> vector, so no heap allocation.
>>
>> Some implementations of C++ std::string do this. For example, the GNU
>> implementation appears to store up to 16 characters (including the
>> trailing null character) in the std::string object.
>
> Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !!
Can you rephrase or expand on that comment? I'm having trouble
figuring out what underlying point you're making. Or, if you prefer,
we can drop it.
Storing short strings directly in the std::string object seems like
a pretty good idea to me.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-01-20 12:29 -0800 |
| Subject | Re: Segments |
| Message-ID | <vmmbmp$iaan$1@dont-email.me> |
| In reply to | #110551 |
On 1/16/2025 11:12 AM, Terje Mathisen wrote: > Stephen Fuld wrote: >> On 1/16/2025 1:11 AM, Terje Mathisen wrote: >>> Thomas Koenig wrote: >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >>>>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>> [...] >>>>>> CHERY targets C, which on the one hand, I understand (there's a >>>>>> ton of C code out there), but trying to retrofit a safe memory >>>>>> model onto C seems a bit awkward - it might have been better to >>>>>> target a language which has arrays in the first place, unlike C. >>>>> [...] >>>>> >>>>> C does have arrays. >>>> >>>> Sort of - they decay into pointers at first sight. >>>> >>>> But what I should have written was "multi-dimensional arrays", >>>> with a reasonable way of handling them. >>>> >>> Rust provides an interesting data point here: >>> >>> It has Vec<> which is always implemented as a dope vector, i.e. a >>> header which contains the starting point and current length, along >>> with allocated size. For multidimendional work, the natural mapping >>> is Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >>> boundary checking. >>> >>> However, in my own testing I have found that it is often faster to >>> flatten those multi-dim vectors, and instead use explicit >>> multiplication to get the actual position: >>> >>> Â array[y][x] -> array[y*width + x] >>> >>> Terje >> >> I am obviously missing something, but why doesn't the compiler >> generate code for that itself? >> > > Because Rust really doesn't have multi-dim vectors, instead using > vectors of pointers to vectors? > > OTOH, it is perfectly OK to create your own multi-dim data structure, > and using macros you can probably get the compiler to generate near- > optimal code as well, but afaik, nothing like that is part of the core > language. That surprised me. So I did a search for "Rust Multi dimensional arrays", and got several hits. It seems there are various ways to do this depending upon whether you want an array of arrays or a "traditional" multi-dimensional array. There is a crate for the latter. I don't know enough Rust to get all the details in the various search results, but it seems there are options. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-22 14:15 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmqr2c$1166d$1@dont-email.me> |
| In reply to | #110591 |
Stephen Fuld wrote: > On 1/16/2025 11:12 AM, Terje Mathisen wrote: >> Stephen Fuld wrote: >>> On 1/16/2025 1:11 AM, Terje Mathisen wrote: >>>> Thomas Koenig wrote: >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >>>>>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>>> [...] >>>>>>> CHERY targets C, which on the one hand, I understand (there's a >>>>>>> ton of C code out there), but trying to retrofit a safe memory >>>>>>> model onto C seems a bit awkward - it might have been better to >>>>>>> target a language which has arrays in the first place, unlike C. >>>>>> [...] >>>>>> >>>>>> C does have arrays. >>>>> >>>>> Sort of - they decay into pointers at first sight. >>>>> >>>>> But what I should have written was "multi-dimensional arrays", >>>>> with a reasonable way of handling them. >>>>> >>>> Rust provides an interesting data point here: >>>> >>>> It has Vec<> which is always implemented as a dope vector, i.e. a >>>> header which contains the starting point and current length, along >>>> with allocated size. For multidimendional work, the natural mapping >>>> is Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >>>> boundary checking. >>>> >>>> However, in my own testing I have found that it is often faster to >>>> flatten those multi-dim vectors, and instead use explicit >>>> multiplication to get the actual position: >>>> >>>>  Â array[y][x] -> array[y*width + x] >>>> >>>> Terje >>> >>> I am obviously missing something, but why doesn't the compiler >>> generate code for that itself? >>> >> >> Because Rust really doesn't have multi-dim vectors, instead using >> vectors of pointers to vectors? >> >> OTOH, it is perfectly OK to create your own multi-dim data structure, >> and using macros you can probably get the compiler to generate near- >> optimal code as well, but afaik, nothing like that is part of the core >> language. > > That surprised me. So I did a search for "Rust Multi dimensional > arrays", and got several hits. It seems there are various ways to do > this depending upon whether you want an array of arrays or a > "traditional" multi-dimensional array. There is a crate for the latter. > > I don't know enough Rust to get all the details in the various search > results, but it seems there are options. Notice what I wrote above, Rust allows for compile-time code generation in the form of macros which are in some ways even more powerful than C++ templates, so I'n not surprised to learn that there already exists public crate(s) to handle this. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-22 18:44 +0000 |
| Subject | Re: Segments |
| Message-ID | <vmre9u$156r0$1@dont-email.me> |
| In reply to | #110601 |
Terje Mathisen <terje.mathisen@tmsw.no> schrieb: > Notice what I wrote above, Rust allows for compile-time code generation > in the form of macros which are in some ways even more powerful than C++ > templates, so I'n not surprised to learn that there already exists > public crate(s) to handle this. :-) That sounds scary; C++ templates are already Turing-complete...
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-06 23:41 +0000 |
| Subject | Re: Segments |
| Message-ID | <8ea06df32cff07e30dd477b425dbdd0a@www.novabbs.org> |
| In reply to | #110415 |
On Mon, 6 Jan 2025 22:02:30 +0000, Thomas Koenig wrote:
> Hmm... a beginning of an idea (for which I am ready to be shot
> down, this is comp.arch :-)
>
> This would work best for languages which explicitly pass
> array bounds or sizes (like Fortran's assumed size arrays,
> or, if I read this correctly, Rust's slices).
>
> Assume a class of load and store instructions containing
>
> - One source or destination register
> - One base register
> - One index register
> - One ubound register
>
> Memory access is to base + index, with one additional point:
> If index > ubound, then the instruction raises an exception.
Now, you are only checking the ubound and not the lbound; so,
you only stumble over ½ the bound errors.
Where you should START is with a data structure that defines
the memory region::
First Byte accessible Possibly lbound
Last Byte accessible Possibly ubound
other stuff as needed
Then figure out how to efficiently perform the checks in ISA
of choice (or add to ISA).
> This works less well with C's pointers, for which you would have
> to pass some sort of fat pointer. Compilers would have to make
> sure that the address of the base object is passed.
I blame the programmers for not using FAT pointers (and then
teaching the compilers how to get rid of most of the checks.)
Nothing is preventing C programmers from using FAT pointers,
and thereby avoid all those buffer overruns.
> Comments?
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-07 10:53 +0000 |
| Subject | Re: Segments |
| Message-ID | <vlj12t$25onk$1@dont-email.me> |
| In reply to | #110417 |
MitchAlsup1 <mitchalsup@aol.com> schrieb:
> On Mon, 6 Jan 2025 22:02:30 +0000, Thomas Koenig wrote:
>
>> Hmm... a beginning of an idea (for which I am ready to be shot
>> down, this is comp.arch :-)
>>
>> This would work best for languages which explicitly pass
>> array bounds or sizes (like Fortran's assumed size arrays,
>> or, if I read this correctly, Rust's slices).
>>
>> Assume a class of load and store instructions containing
>>
>> - One source or destination register
>> - One base register
>> - One index register
>> - One ubound register
>>
>> Memory access is to base + index, with one additional point:
>> If index > ubound, then the instruction raises an exception.
>
> Now, you are only checking the ubound and not the lbound; so,
> you only stumble over ½ the bound errors.
If the base register does point to the start of the entity,
that would also be covered, at least for one-dimensional
arrays.
>
> Where you should START is with a data structure that defines
> the memory region::
>
> First Byte accessible Possibly lbound
> Last Byte accessible Possibly ubound
> other stuff as needed
>
> Then figure out how to efficiently perform the checks in ISA
> of choice (or add to ISA).
One such example is defined in the Fortran standard, in the C
descriptors, from ISO_Fortran_binding.h . There are two data
structures: The CFI_dim_t structure, which describes (in integer
variables) the lower bound, the extend (a.k.a number of elements)
and the stride. The CFI_cdesc_t structure then describes the
base address (a void *), the length of an individual element,
the version, the rank, the type, several attributes (is it
allocatable or a pointer) and the number of dimension.
You can see an example at
https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgfortran/ISO_Fortran_binding.h;hb=refs/heads/master
(Unfortunately, for historical reasons, gfortran uses another
format internally for array descriptors).
Hmm... let's look at a simplified example.
void bounds_error (const char *fmt, ...) __attribute__ ((format (printf, 1,2)))
__attribute__ ((noreturn));
void set_element (double *a, unsigned long lower, unsigned long upper,
unsigned long n)
{
if (n < lower || n > upper)
bounds_error ("Error: %ld not between %ld and %ld", n, lower, upper);
a[n - lower] = 1.0;
}
it is hard avoiding two comparisons and branches without having
some sort of range comparison, something like
cmpr Rdst,Rsrc,Rlow,Rhigh
which would then set conditional bits according to the different
ranges that Rsrc can be in.
>> This works less well with C's pointers, for which you would have
>> to pass some sort of fat pointer. Compilers would have to make
>> sure that the address of the base object is passed.
>
> I blame the programmers for not using FAT pointers (and then
> teaching the compilers how to get rid of most of the checks.)
> Nothing is preventing C programmers from using FAT pointers,
> and thereby avoid all those buffer overruns.
They still have to do it by hand, it is much easier to do if
the language they use would offer it.
[toc] | [prev] | [next] | [standalone]
| From | Andy Valencia <vandys@vsta.org> |
|---|---|
| Date | 2025-01-11 13:59 -0800 |
| Subject | Re: Segments |
| Message-ID | <173663276157.23190.12092117245116719600@media.vsta.org> |
| In reply to | #110400 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: > The best idea I have seen to help detect out of bounds accesses, is to > round all requested memory blocks up to the next 4K boundary and mark > the next page as unavailable, then return a skewed pointer back, so that > the end of the requested region coincides with the end of the (last) > allocated page. I think I've mentioned this once before, but I did precisely this during my time at Sequent, and the C library blew up. Turned out the C string support routines were pulling in cache line lengths at a time, and it was such a win they didn't want to observe "strict" C string access rules. I assume they padded things such that no "real life" string could end up against a page boundary abutted to an invalid page address, but since they weren't interested in fixing it, I stopped worrying about it. A kinder, gentler time. I wonder if such things still lurk out there. Andy Valencia Home page: https://www.vsta.org/andy/ To contact me: https://www.vsta.org/contact/andy.html Fediverse: @vandys@goto.vsta.org
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-01-06 18:58 +0000 |
| Subject | Re: what's a segment, 80286 protected mode |
| Message-ID | <vlh948$1875$1@gal.iecc.com> |
| In reply to | #110399 |
According to George Neuner <gneuner2@comcast.net>: >The bad taste of segments is from exposure to Intel's half-assed >implementation which exposed the segment selector as part of the >address. > >Segments /should/ have been implemented similar to the way paging is >done: the program using flat 32-bit addresses and the MMU (SMU?) >consulting some kind of segment "database" [using the term loosely]. The whole point of a segmented architecture is that the segments are visible and meaningful. You put a thing (for some definition of thing) in a segment to control access to the thing. So if it's an array, all of the address calculations are relative to the segment and out of bounds references fail because they point to a non-existent part of the segment. Similiarly if it's code, a jump outside the segment's boundaries fails. Muitics and the Burroughs machines had (still have, I suppose for emulated Burroughs) visible segments and programmers liked them just fine. The problems were that the segment sizes were too small as memories got bigger, and that they weren't byte addressed which these days is practically mandatory. The 286 added additional flaws that there weren't enough segment registers and segment loads were very slow. What you're describing is multi-level page tables. Every virtual memory system has them. Sometimes the operating systems make the higher level tables visible to applications, sometimes they don't. For example, in IBM mainframes the second level page table entries, which they call segments, can be shared between applications. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-06 19:45 +0000 |
| Subject | Re: what's a segment, 80286 protected mode |
| Message-ID | <HpWeP.29026$nlJ1.24267@fx41.iad> |
| In reply to | #110408 |
John Levine <johnl@taugh.com> writes: >According to George Neuner <gneuner2@comcast.net>: >>The bad taste of segments is from exposure to Intel's half-assed >>implementation which exposed the segment selector as part of the >>address. >> >>Segments /should/ have been implemented similar to the way paging is >>done: the program using flat 32-bit addresses and the MMU (SMU?) >>consulting some kind of segment "database" [using the term loosely]. > >The whole point of a segmented architecture is that the segments are visible and >meaningful. You put a thing (for some definition of thing) in a segment to >control access to the thing. So if it's an array, all of the address >calculations are relative to the segment and out of bounds references fail >because they point to a non-existent part of the segment. Similiarly if it's >code, a jump outside the segment's boundaries fails. > >Muitics and the Burroughs machines had (still have, I suppose for emulated The original HP-3000 also had segments.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-06 19:48 +0000 |
| Subject | Re: what's a segment, 80286 protected mode |
| Message-ID | <ysWeP.29027$nlJ1.21947@fx41.iad> |
| In reply to | #110408 |
John Levine <johnl@taugh.com> writes: >According to George Neuner <gneuner2@comcast.net>: >>The bad taste of segments is from exposure to Intel's half-assed >>implementation which exposed the segment selector as part of the >>address. >> >>Segments /should/ have been implemented similar to the way paging is >>done: the program using flat 32-bit addresses and the MMU (SMU?) >>consulting some kind of segment "database" [using the term loosely]. > >The whole point of a segmented architecture is that the segments are visible and >meaningful. You put a thing (for some definition of thing) in a segment to >control access to the thing. So if it's an array, all of the address >calculations are relative to the segment and out of bounds references fail >because they point to a non-existent part of the segment. Similiarly if it's >code, a jump outside the segment's boundaries fails. > >Muitics and the Burroughs machines had (still have, I suppose for emulated >Burroughs) visible segments and programmers liked them just fine. The problems >were that the segment sizes were too small as memories got bigger, and that they >weren't byte addressed which these days is practically mandatory. The 286 added >additional flaws that there weren't enough segment registers and segment loads >were very slow. > >What you're describing is multi-level page tables. Every virtual memory system >has them. Sometimes the operating systems make the higher level tables visible >to applications, sometimes they don't. For example, in IBM mainframes the second >level page table entries, which they call segments, can be shared between >applications. There have been a number of attempts to use capabilities to describe individual data items (the aforementioned Burrougsh systems are the canonical examples). There are investigations into adapting such schemes to modern microprocessors, one of which is CHERI which uses 128-bit pointers to encode various attributes, including the size of the object. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-01-06 17:28 -1000 |
| Subject | Re: what's a segment, 80286 protected mode |
| Message-ID | <87frlvjoac.fsf@localhost> |
| In reply to | #110408 |
John Levine <johnl@taugh.com> writes: > What you're describing is multi-level page tables. Every virtual > memory system has them. Sometimes the operating systems make the > higher level tables visible to applications, sometimes they don't. For > example, in IBM mainframes the second level page table entries, which > they call segments, can be shared between applications. initial adding virtual memory to all IBM 370s was similar to 24bit 360/67 but had options for 16 1mbyte segments or 256 64kbyte segments and either 4kbyte or 2kbyte pages. Initial mapping of 360 MVT to VS2/SVS was single 16mbyte address space ... very similar to running MVT in a CP/67 16mbyte virtual machine. The upgrade to VS2/MVS gave each region its own 16mbyte virtual address space. However, OS/360 MVT API heritage was pointer passing API ... so they mapped a common 8mbyte image of the "MVS" kernel into every 16mbyte virtual address space (leaving 8mbytes for application code), kernel API call code could still directly access user code API parameters (basically same code from MVT days). However, MVT subsystems were also moved into their separate 16mbyte virtual address space ... making it harder to access application API calling parameters. So they defined a common segment area (CSA), 1mbyte segment mapped into every 16mbyte virtual address space, application code would get space in the CSA for API parameter information calling subsystesm. Problem was the requirement for subsystem API parameter (CSA) space was proportional to number of concurrent applications plus number of subsystems and quickly exceed 1mbyte ... and it morphs into multi-megabyte common system area. By the end of the 70s, CSAs were running 5-6mbytes (leaving 2-3mbytes for programs) and threatening to become 8mbytes (leaving zero mbytes for programs)... part of the mad rush to XA/370 and 31-bit virtual addressing (as well as access registers, and multiple concurrent virtual address spaces ... "Program Call" instruction had a table of MVS/XA address space pointers for subsystems, the PC instruction whould move the caller's address space pointer to secondary and load the subsystem address space pointer into primary ... program return instruction reversed the processes and moved the secondary pointer back to primary). -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-05 15:20 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <3rxeP.23593$YXj.6771@fx34.iad> |
| In reply to | #110377 |
antispam@fricas.org (Waldek Hebisch) writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Another usage of segments for code would be to put the code segment of >> a shared object (known as DLL among Windowsheads) in a segment, and >> use far calls to call functions in other shared objects, while using >> near calls within a shared object. This allows to share the code >> segments between different programs, and to locate them anywhere in >> physical memory. However, AFAIK shared objects were not a thing in >> the 80286 timeframe; Unix only got them in the late 1980s. > >IIUC shared segments were widely used on Multics. They were widely used on both the Burroughs large systems and the HP-3000 as well, both exemplars of segmentation done right, in so far as it can be.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-01-05 02:56 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <vlcsc8$2drk$1@gal.iecc.com> |
| In reply to | #110362 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >antispam@fricas.org (Waldek Hebisch) writes: >>From my point of view main drawbacks of 286 is poor support for >>large arrays and problem for Lisp-like system which have a lot >>of small data structures and traverse then via pointers. > >Yes. In the first case the segments are too small, in the latter case >there are too few segments (if you have one segment per object). Intel clearly had some strong opinions about how people would program the 286, which turned out to bear almost no relation to the way we actually wanted to program it. Some of the stuff they did was just perverse, like putting flag bits in the low part of the segment number rather than the high bit. If you had objects bigger than 64K, you had to shift the segment number three bits to the left when computing addresses. They also apparently didn't expect people to switch segments much. If you loaded a segment register with the value it already contained, it still fetched all of the stuff from memory. How many gates would it have taken to check for the same value and bypass the loads? If they had done that, we could have used large model calls everywhere since long and short calls would be about the same speed, and not had to screw around deciding what was a long call and what was short and writing glue codes to allow both kinds. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-05 03:55 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <6d5fa21e63e14491948ffb6a9d08485a@www.novabbs.org> |
| In reply to | #110378 |
On Sun, 5 Jan 2025 2:56:08 +0000, John Levine wrote: > According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >>antispam@fricas.org (Waldek Hebisch) writes: >>>From my point of view main drawbacks of 286 is poor support for >>>large arrays and problem for Lisp-like system which have a lot >>>of small data structures and traverse then via pointers. >> >>Yes. In the first case the segments are too small, in the latter case >>there are too few segments (if you have one segment per object). > > Intel clearly had some strong opinions about how people would program > the 286, which turned out to bear almost no relation to the way we > actually wanted to program it. Clearly, Intel thought that .text, .data, .stack, and .heap were about all anyone would ever need. > Some of the stuff they did was just perverse, like putting flag > bits in the low part of the segment number rather than the high > bit. If you had objects bigger than 64K, you had to shift > the segment number three bits to the left when computing > addresses. Let us just agree that whatever they were thinking, they blew it. > They also apparently didn't expect people to switch segments much. Clearly. They expected segments to be essentially stagnant--unlike the people trying to do things with x86s... > If you loaded a segment register with the value it already contained, > it still fetched all of the stuff from memory. If segment LD was 1 cycle, the number of segment changes would be fine. But since LDing a segment was so expensive, they probably could not afford the transistors and wires to do what you suggest. > How many gates would > it have taken to check for the same value and bypass the loads? 286:: 180 gates per segment register 386:: 360 gates per segment register > If > they had done that, we could have used large model calls everywhere > since long and short calls would be about the same speed, and not > had to screw around deciding what was a long call and what was short > and writing glue codes to allow both kinds. If you had 32 segment registers, it probably would not have mattered that segment LD was slow. And if you had 32 pointing registers, you would not have need a LD-OP ISA. Sigh ...
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2025-01-05 15:15 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <memo.20250105151541.20984j@jgd.cix.co.uk> |
| In reply to | #110379 |
In article <6d5fa21e63e14491948ffb6a9d08485a@www.novabbs.org>, mitchalsup@aol.com (MitchAlsup1) wrote: > On Sun, 5 Jan 2025 2:56:08 +0000, John Levine wrote: > > They also apparently didn't expect people to switch segments much. > > Clearly. They expected segments to be essentially stagnant--unlike > the people trying to do things with x86s... An idea: The target markets for the 8080 and 8085 were clearly embedded systems. The Z80 and 6502 rapidly became popular in the micro-computer market, but the 808[05] did not. Intel may still have been thinking in terms of embedded systems when designing the 80286. The IBM PC was launched in August 1981 and around a year passed before it became clear that this machine was having a huge and lasting effect on the market. The 80286 was released on February 1st 1982, although it wasn't used much in PCs until the IBM PC/AT in August 1984. The 80386 sampled in 1985 and was mass-produced in 1986. That would seem to have been the first version of x86 where it was obvious at the start of design that use in general-purpose computers would be important. It was far more suitable for the job than the 80286, and things developed from there. John
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-05 15:23 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <_txeP.23594$YXj.2600@fx34.iad> |
| In reply to | #110385 |
jgd@cix.co.uk (John Dallman) writes: >In article <6d5fa21e63e14491948ffb6a9d08485a@www.novabbs.org>, >mitchalsup@aol.com (MitchAlsup1) wrote: >> On Sun, 5 Jan 2025 2:56:08 +0000, John Levine wrote: >> > They also apparently didn't expect people to switch segments much. >> >> Clearly. They expected segments to be essentially stagnant--unlike >> the people trying to do things with x86s... > >An idea: The target markets for the 8080 and 8085 were clearly embedded >systems. The Z80 and 6502 rapidly became popular in the micro-computer >market, but the 808[05] did not. Intel may still have been thinking in >terms of embedded systems when designing the 80286. I suspect that we don't, today, recall all the constraints that were facing Intel with respect to processor ASIC development in the late 70's and early 80's.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-01-05 17:51 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <2025Jan5.185134@mips.complang.tuwien.ac.at> |
| In reply to | #110385 |
jgd@cix.co.uk (John Dallman) writes: >An idea: The target markets for the 8080 and 8085 were clearly embedded >systems. The Z80 and 6502 rapidly became popular in the micro-computer >market, but the 808[05] did not. The 8080 was used in the first microcomputers, e.g., the 1974 Altair 8800 and the IMSAI 8080. It was important for all the CP/M machines, because the CP/M software (both the OS and the programs running on it) were written to use the 8080 instruction set, not the Z80 instruction set. And CP/M was the professional microcomputer OS before the IBM PC compatible market took off, despite the fact that the most popular microcomputers of the time (such as the Apple II, TRS-80 ad PET) did not use it; there was an add-on card for the Apple II with a Z80 for running CP/M, though, which shows the importance of CP/M. Anyway, while Zilog may have taken their sales, I very much believe that Intel was aware of the general-purpose computing market, and the iAPX432 clearly showed that they wanted to be dominant there. It's an irony of history that the 8086/8088 actually went where the action was. Intel released the MCS-51 (aka 8051) in 1980 for embedded systems, and it's very successful there, and before that came the MCS-48 (8048) in 1976. >Intel may still have been thinking in >terms of embedded systems when designing the 80286. I very much doubt that the segments and the 24 address bits were designed for embedded systems. The segments look more like an echo of the iAPX432 than of anything designed for embedded systems. The idea of some static allocation of memory for which segments might work may come from old mainframe systems, where programs were (in my impression) more static than PC programs and modern computing. Even in Unix programs, which were more dynamic than mainframe programs had quite a bit of static allocation in the early days; this is reflected in the paragraph in the GNU coding standards: |Avoid arbitrary limits on the length or number of any data structure, |including file names, lines, files, and symbols, by allocating all |data structures dynamically. In most Unix utilities, "long lines are |silently truncated". This is not acceptable in a GNU utility. >The IBM PC was launched in August 1981 and around a year passed before it >became clear that this machine was having a huge and lasting effect on >the market. The 80286 was released on February 1st 1982, although it >wasn't used much in PCs until the IBM PC/AT in August 1984. The 80286 project was started in 1978, before any use of the 8086. <https://timeline.intel.com/1978/kicking-off-the-80286> claims that they "spent six months on field research into customers' needs alone"; Judging by the results, maybe the customers were clueless, or maybe Intel asked the wrong questions. >The 80386 sampled in 1985 and was mass-produced in 1986. That would seem >to have been the first version of x86 where it was obvious at the start >of design that use in general-purpose computers would be important. Actually, reading the oral history of the 386, at the start the 386 project was just an unimportant followon of the 286, while the main action was expected to be on the BiiN project (from which the i960 came). Only sometime during that project the IBM PC market exploded and the 386 became the most important project of the company. But yes, they were very much aware of the needs of programmers in the 386 project, and would probably have done something with just paging and no segments if they did not have the 8086 and 80286 legacy. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-05 19:40 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <cf990deeb2a460ed9dbcd1cd1f7823f7@www.novabbs.org> |
| In reply to | #110389 |
On Sun, 5 Jan 2025 17:51:34 +0000, Anton Ertl wrote: > jgd@cix.co.uk (John Dallman) writes: >>An idea: The target markets for the 8080 and 8085 were clearly embedded >>systems. The Z80 and 6502 rapidly became popular in the micro-computer >>market, but the 808[05] did not. > > The 8080 was used in the first microcomputers, e.g., the 1974 Altair > 8800 and the IMSAI 8080. It was important for all the CP/M machines, > because the CP/M software (both the OS and the programs running on it) > were written to use the 8080 instruction set, not the Z80 instruction > set. And CP/M was the professional microcomputer OS before the IBM PC > compatible market took off, despite the fact that the most popular > microcomputers of the time (such as the Apple II, TRS-80 ad PET) did > not use it; there was an add-on card for the Apple II with a Z80 for > running CP/M, though, which shows the importance of CP/M. > > Anyway, while Zilog may have taken their sales, I very much believe > that Intel was aware of the general-purpose computing market, and the > iAPX432 clearly showed that they wanted to be dominant there. It's an > irony of history that the 8086/8088 actually went where the action > was. > > Intel released the MCS-51 (aka 8051) in 1980 for embedded systems, and > it's very successful there, and before that came the MCS-48 (8048) in > 1976. > >>Intel may still have been thinking in >>terms of embedded systems when designing the 80286. > > I very much doubt that the segments and the 24 address bits were > designed for embedded systems. The segments look more like an echo of > the iAPX432 than of anything designed for embedded systems. > > The idea of some static allocation of memory for which segments might > work may come from old mainframe systems, where programs were (in my > impression) more static than PC programs and modern computing. Even > in Unix programs, which were more dynamic than mainframe programs had > quite a bit of static allocation in the early days; this is reflected > in the paragraph in the GNU coding standards: > > |Avoid arbitrary limits on the length or number of any data structure, > |including file names, lines, files, and symbols, by allocating all > |data structures dynamically. In most Unix utilities, "long lines are > |silently truncated". This is not acceptable in a GNU utility. > >>The IBM PC was launched in August 1981 and around a year passed before it >>became clear that this machine was having a huge and lasting effect on >>the market. The 80286 was released on February 1st 1982, although it >>wasn't used much in PCs until the IBM PC/AT in August 1984. > > The 80286 project was started in 1978, before any use of the 8086. > <https://timeline.intel.com/1978/kicking-off-the-80286> claims that > they "spent six months on field research into customers' needs alone"; > Judging by the results, maybe the customers were clueless, or maybe > Intel asked the wrong questions. Or perhaps what Intel thought they heard was not closely related to what the customers were actually saying. >>The 80386 sampled in 1985 and was mass-produced in 1986. That would seem >>to have been the first version of x86 where it was obvious at the start >>of design that use in general-purpose computers would be important. > > Actually, reading the oral history of the 386, at the start the 386 > project was just an unimportant followon of the 286, while the main > action was expected to be on the BiiN project (from which the i960 > came). Only sometime during that project the IBM PC market exploded > and the 386 became the most important project of the company. > > But yes, they were very much aware of the needs of programmers in the > 386 project, and would probably have done something with just paging > and no segments if they did not have the 8086 and 80286 legacy. Oh well ... > > - anton
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-01-05 20:01 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <vleoel$p$1@gal.iecc.com> |
| In reply to | #110389 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >Anyway, while Zilog may have taken their sales, I very much believe >that Intel was aware of the general-purpose computing market, and the >iAPX432 clearly showed that they wanted to be dominant there. It's an >irony of history that the 8086/8088 actually went where the action >was. I have heard that the IBM PC was originally designed with a Z80, and fairly late in the process someone decided (not unreasonably) that it wouldn't be different enough from all the other Z80 boxes to be an interesting product. They wanted a 16 bit processor but for time and money reasons they stayed with the 8 bit bus they already had. The options were 68008 and 8088. Moto was only shipping samples of the 68008 while Intel could provide 8088 in quantity, so they went with the 8088. If Moto had been a little farther along, the history of the PC industry could have been quite different. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2025-01-05 20:46 +0000 |
| Subject | Re: the 286, Byte ordering |
| Message-ID | <vler3i$16vjt$1@dont-email.me> |
| In reply to | #110391 |
John Levine <johnl@taugh.com> wrote: > According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >> Anyway, while Zilog may have taken their sales, I very much believe >> that Intel was aware of the general-purpose computing market, and the >> iAPX432 clearly showed that they wanted to be dominant there. It's an >> irony of history that the 8086/8088 actually went where the action >> was. > > I have heard that the IBM PC was originally designed with a Z80, and fairly late > in the process someone decided (not unreasonably) that it wouldn't be different > enough from all the other Z80 boxes to be an interesting product. They wanted a > 16 bit processor but for time and money reasons they stayed with the 8 bit bus > they already had. The options were 68008 and 8088. Moto was only shipping > samples of the 68008 while Intel could provide 8088 in quantity, so they went > with the 8088. > > If Moto had been a little farther along, the history of the PC industry > could have been quite different. The 8088 was not a threat to any of IBM’s existing products, the 68x00 was.
[toc] | [prev] | [next] | [standalone]
Page 22 of 23 — ← Prev page 1 … 20 21 [22] 23 Next page →
Back to top | Article view | comp.arch
csiph-web