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 6 of 23 — ← Prev page 1 … 4 5 [6] 7 8 … 23 Next page →
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2024-10-16 15:07 -0400 |
| Subject | Re: C and turtles, 80286 protected mode |
| Message-ID | <vep2t7$2c62t$1@dont-email.me> |
| In reply to | #109740 |
On 10/15/24 9:08 PM, John Levine wrote: > According to MitchAlsup1 <mitchalsup@aol.com>: >> The paragraaph with 3 >'s indicates malloc() cannot be written >> in std. C. It used to be written in std. K&R C. I am not asking >> if it is still in the std libraries, I am asking what happened >> to make it impossible to write malloc() in std. C ?!? > > It's easy enough to write malloc() in standard C if your flavor of the > standard includes a way to ask the operating system for heap space. > Back in the old days it was sbrk(). Now it's mmap(MAP_ANON). Another possibility might be for the OS/hardware to support allocate on use. This would be similar to an implicit mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this would not be portable, but sbrk() and mmap() are not portable. (unmap() might be supported by memsetting a page as zero. With hardware support, this information could be communicated to the OS. Using deduplication to "free" such memory would also be possible, but that seems relatively expensive.) Permissions would seem to require some kind of system call. (Separating the address space into execute, read-only, and read-write segments might extend the use cases for such a "simple" allocation interface. JIT compilation seems problematic.) I am not certain how/if this could handle an allocation failure (from the OS) other than by catching signals (SIGSEGV?) from the OS. If malloc() only found a suitably-sized free chunk in the address space and did not access any of that page (if it is new), the signal would point to the first load/store instruction to access the chunk, which sounds more difficult to handle. This is not terribly dissimilar to the Mill's backless storage where hardware allocates a free page when a write is performed to an appropriately marked region (unitialized backless store reads as zero). (An OS handles underflow and overflow of the hardware free list with watermarks to avoid actual, stalling underflow and overflow.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-16 19:41 +0000 |
| Subject | Re: C and turtles, 80286 protected mode |
| Message-ID | <jFUPO.92784$S9Vb.50052@fx45.iad> |
| In reply to | #109757 |
"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>On 10/15/24 9:08 PM, John Levine wrote:
>> According to MitchAlsup1 <mitchalsup@aol.com>:
>>> The paragraaph with 3 >'s indicates malloc() cannot be written
>>> in std. C. It used to be written in std. K&R C. I am not asking
>>> if it is still in the std libraries, I am asking what happened
>>> to make it impossible to write malloc() in std. C ?!?
>>
>> It's easy enough to write malloc() in standard C if your flavor of the
>> standard includes a way to ask the operating system for heap space.
>> Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).
>
>Another possibility might be for the OS/hardware to support
>allocate on use. This would be similar to an implicit
>mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
>would not be portable, but sbrk() and mmap() are not portable.
The easiest way to implement malloc in standard C is to
start with a statically defined allocation region.
e.g. malloc.c:
...
static unsigned char region[MAX_HEAP_IN_BYTES];
void *
malloc(size_t size)
{
/* manage heap and return allocation of size bytes */
}
Downside is that the application always uses MAX_HEAP_IN_BYTES
plus the app size in memory; appropriate for standalone apps.
(traditional definition of standalone - no OS or other
runtime support).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-17 16:13 +0200 |
| Subject | Re: C and turtles, 80286 protected mode |
| Message-ID | <ver62e$2pcju$1@dont-email.me> |
| In reply to | #109761 |
On 16/10/2024 21:41, Scott Lurndal wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>> On 10/15/24 9:08 PM, John Levine wrote:
>>> According to MitchAlsup1 <mitchalsup@aol.com>:
>>>> The paragraaph with 3 >'s indicates malloc() cannot be written
>>>> in std. C. It used to be written in std. K&R C. I am not asking
>>>> if it is still in the std libraries, I am asking what happened
>>>> to make it impossible to write malloc() in std. C ?!?
>>>
>>> It's easy enough to write malloc() in standard C if your flavor of the
>>> standard includes a way to ask the operating system for heap space.
>>> Back in the old days it was sbrk(). Now it's mmap(MAP_ANON).
>>
>> Another possibility might be for the OS/hardware to support
>> allocate on use. This would be similar to an implicit
>> mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault. Obviously, this
>> would not be portable, but sbrk() and mmap() are not portable.
>
> The easiest way to implement malloc in standard C is to
> start with a statically defined allocation region.
>
> e.g. malloc.c:
>
> ...
> static unsigned char region[MAX_HEAP_IN_BYTES];
>
> void *
> malloc(size_t size)
> {
> /* manage heap and return allocation of size bytes */
> }
>
> Downside is that the application always uses MAX_HEAP_IN_BYTES
> plus the app size in memory; appropriate for standalone apps.
> (traditional definition of standalone - no OS or other
> runtime support).
>
There are other downsides to this.
One is that the "region" must be zeroed by the pre-main startup code.
On some systems, there may be efficient ways to handle this, but on
small embedded devices it usually means effectively memset'ing the heap
before main() can start. That can be a significant inconvenience for
some systems. C has (at the moment) no standard way to say that a
variable does not need to be initialised, but there are usually
implementation-specific ways to handle this.
The other issue is that returned memory blocks have a type - they are
arrays of unsigned char - and when you use them for something else, your
malloc'ed object aliases part of another normal C object (the array
"region"). This can cause complications with advanced compiler analysis.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-20 07:07 +0000 |
| Subject | Re: C and turtles, 80286 protected mode |
| Message-ID | <vf2a6p$agbh$2@dont-email.me> |
| In reply to | #109757 |
On Wed, 16 Oct 2024 15:07:14 -0400, Paul A. Clayton wrote: > Obviously, this would not be portable, but sbrk() and mmap() are not > portable. They are portable at the OS level, since they are part of POSIX.
[toc] | [prev] | [next] | [standalone]
| From | "Paul A. Clayton" <paaronclayton@gmail.com> |
|---|---|
| Date | 2024-10-20 12:14 -0400 |
| Subject | Re: C and turtles, 80286 protected mode |
| Message-ID | <vf3a8f$g1vh$1@dont-email.me> |
| In reply to | #109808 |
On 10/20/24 3:07 AM, Lawrence D'Oliveiro wrote: > On Wed, 16 Oct 2024 15:07:14 -0400, Paul A. Clayton wrote: > >> Obviously, this would not be portable, but sbrk() and mmap() are not >> portable. > > They are portable at the OS level, since they are part of POSIX. I think my (theoretical) proposal of "an implicit mmap(MAP_ANONYMOUS | MAP_FIXED) on a page fault" would be portable at the OS level, though "portable to some obscure research OS" — if such was every developed — could be reasonable argued as less portable than "portable to POSIX".☺ (I do think such is an _interesting_ interface.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-16 15:38 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <b6RPO.380391$FzW1.307451@fx14.iad> |
| In reply to | #109739 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >>>On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote: >>> >>>>> There is an advantage to the C approach of separating out some >>>>> facilities and supplying them only in the standard library. >>>> >>>> It goes a bit further: for a general purpose language, any existing >>>> functionality that cannot be written using the language is a sign of >>>> a weakness because it shows that despite being "general purpose" it >>>> fails to cover this specific "purpose". >>> >>>One of the key ways C got into the minds of programmers was that >>>one could write stuff like printf() in C and NOT needd to have it >>>entirely built-into the language. >>> >>>> In an ideal world, it would be better if we could define `malloc` and >>>> `memmove` efficiently in standard C, but at least they can be >>>> implemented in non-standard C. >>> >>>malloc() used to be std. K&R C--what dropped if from the std ?? >> >> It still is part of the ISO C standard. > >The paragraaph with 3 >'s indicates malloc() cannot be written >in std. C. It used to be written in std. K&R C. K&R may have been 'de facto' standard C, but not 'de jure'. Unix V6 malloc used the 'brk' system call to allocate space for the heap. Later versions used 'sbrk'. Those are both kernel system calls.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2024-10-16 23:06 -0400 |
| Subject | Re: 80286 protected mode |
| Message-ID | <rhq0hj5h9nfd9qbb64mc8jvaf8bonf61q9@4ax.com> |
| In reply to | #109751 |
On Wed, 16 Oct 2024 15:38:47 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >mitchalsup@aol.com (MitchAlsup1) writes: >>On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote: >> >>> mitchalsup@aol.com (MitchAlsup1) writes: >>>>On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote: >>>> >>>>>> There is an advantage to the C approach of separating out some >>>>>> facilities and supplying them only in the standard library. >>>>> >>>>> It goes a bit further: for a general purpose language, any existing >>>>> functionality that cannot be written using the language is a sign of >>>>> a weakness because it shows that despite being "general purpose" it >>>>> fails to cover this specific "purpose". >>>> >>>>One of the key ways C got into the minds of programmers was that >>>>one could write stuff like printf() in C and NOT needd to have it >>>>entirely built-into the language. >>>> >>>>> In an ideal world, it would be better if we could define `malloc` and >>>>> `memmove` efficiently in standard C, but at least they can be >>>>> implemented in non-standard C. >>>> >>>>malloc() used to be std. K&R C--what dropped if from the std ?? >>> >>> It still is part of the ISO C standard. >> >>The paragraaph with 3 >'s indicates malloc() cannot be written >>in std. C. It used to be written in std. K&R C. > >K&R may have been 'de facto' standard C, but not 'de jure'. > >Unix V6 malloc used the 'brk' system call to allocate space >for the heap. Later versions used 'sbrk'. > >Those are both kernel system calls. Yes, but malloc() subdivides an already provided space. Because that space can be treated as a single array of char, and comparing pointers to elements of the same array is legal, the only thing I can see that prevents writing malloc() in standard C would be the need to somhow define the array from the /language's/ POV (not the compiler's) prior to using it. Which circles back to why something like char (*heap)[ULONG_MAX] = ... ; would/does not satisfy the language's requirement. All the compilers I have ever seen would have been happy with it, but none of them ever needed something like it anyway. Conversion to <an integer type> also would always work, but also was never needed. I am not a language lawyer - I don't even pretend to understand the arguments against allowing general pointer comparison. Aside: I have worked on architectures (DSPs) having disjoint memory spaces, spaces with differing bit widths, and even spaces where [sans MMU] the same physical address had multiple logical addresses whose use depended on the type of access. I have written allocators and even a GC for such architectures. Never had a problem convincing C compilers to compare pointers - the only issue I ever faced was whether the result actually was meaningful to the program.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-17 03:16 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <86ttdbvxua.fsf@linuxsc.com> |
| In reply to | #109771 |
George Neuner <gneuner2@comcast.net> writes: > On Wed, 16 Oct 2024 15:38:47 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >> >>> On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote: >>> >>>> mitchalsup@aol.com (MitchAlsup1) writes: [...] >>>>> malloc() used to be standard K&R C--what dropped it from the >>>>> standard ?? >>>> >>>> It still is part of the ISO C standard. >>> >>> The paragraaph with 3 >'s indicates malloc() cannot be written in >>> standard C. It used to be written in standard K&R C. >> >> K&R may have been 'de facto' standard C, but not 'de jure'. >> >> Unix V6 malloc used the 'brk' system call to allocate space >> for the heap. Later versions used 'sbrk'. >> >> Those are both kernel system calls. > > Yes, but malloc() subdivides an already provided space. Not necessarily. > Because that space can be treated as a single array of char, Not always.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-17 16:16 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ver68a$2pcju$2@dont-email.me> |
| In reply to | #109771 |
On 17/10/2024 05:06, George Neuner wrote: > On Wed, 16 Oct 2024 15:38:47 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >>> On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote: >>> >>>> mitchalsup@aol.com (MitchAlsup1) writes: >>>>> On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote: >>>>> >>>>>>> There is an advantage to the C approach of separating out some >>>>>>> facilities and supplying them only in the standard library. >>>>>> >>>>>> It goes a bit further: for a general purpose language, any existing >>>>>> functionality that cannot be written using the language is a sign of >>>>>> a weakness because it shows that despite being "general purpose" it >>>>>> fails to cover this specific "purpose". >>>>> >>>>> One of the key ways C got into the minds of programmers was that >>>>> one could write stuff like printf() in C and NOT needd to have it >>>>> entirely built-into the language. >>>>> >>>>>> In an ideal world, it would be better if we could define `malloc` and >>>>>> `memmove` efficiently in standard C, but at least they can be >>>>>> implemented in non-standard C. >>>>> >>>>> malloc() used to be std. K&R C--what dropped if from the std ?? >>>> >>>> It still is part of the ISO C standard. >>> >>> The paragraaph with 3 >'s indicates malloc() cannot be written >>> in std. C. It used to be written in std. K&R C. >> >> K&R may have been 'de facto' standard C, but not 'de jure'. >> >> Unix V6 malloc used the 'brk' system call to allocate space >> for the heap. Later versions used 'sbrk'. >> >> Those are both kernel system calls. > > Yes, but malloc() subdivides an already provided space. Because that > space can be treated as a single array of char, and comparing pointers > to elements of the same array is legal, the only thing I can see that > prevents writing malloc() in standard C would be the need to somhow > define the array from the /language's/ POV (not the compiler's) prior > to using it. > It is common for malloc() implementations to ask the OS for large chunks of memory, then subdivide it and pass it out to the application. When the chunk(s) it has run out, it will ask for more from the OS. You could reasonably argue that each chunk it gets may be considered a single unsigned char array, but that is certainly not true for additional chunks.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-16 20:00 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vep60r$2ck8s$1@dont-email.me> |
| In reply to | #109739 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > The paragraaph with 3 >'s indicates malloc() cannot be written > in std. C. It used to be written in std. K&R C. I am not asking > if it is still in the std libraries, I am asking what happened > to make it impossible to write malloc() in std. C ?!? You need to reserve memory by some way from the operating system, which is, by necessity, outside of the scope of C (via brk(), GETMAIN, mmap() or whatever). But more problematic is the implementation of free() without knowing how to compare pointers.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-16 22:18 +0000 |
| Subject | Re: 80286 protected mode |
| Message-ID | <08f6b8a4fe6331c87971d285ff906d32@www.novabbs.org> |
| In reply to | #109762 |
On Wed, 16 Oct 2024 20:00:27 +0000, Thomas Koenig wrote: > MitchAlsup1 <mitchalsup@aol.com> schrieb: > >> The paragraaph with 3 >'s indicates malloc() cannot be written >> in std. C. It used to be written in std. K&R C. I am not asking >> if it is still in the std libraries, I am asking what happened >> to make it impossible to write malloc() in std. C ?!? > > You need to reserve memory by some way from the operating system, > which is, by necessity, outside of the scope of C (via brk(), > GETMAIN, mmap() or whatever). Agreed, but once you HAVE a way of getting memory (by whatever name) you can write malloc in std. C. > But more problematic is the implementation of free() without > knowing how to compare pointers. Never wrote a program that actually needs free--I have re-written programs that used free to avoid using free, though.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-17 01:18 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <864j5bxhvn.fsf@linuxsc.com> |
| In reply to | #109766 |
mitchalsup@aol.com (MitchAlsup1) writes: > On Wed, 16 Oct 2024 20:00:27 +0000, Thomas Koenig wrote: > >> MitchAlsup1 <mitchalsup@aol.com> schrieb: >> >>> The paragraaph with 3 >'s indicates malloc() cannot be written in >>> standard C. It used to be written in standard K&R C. I am not >>> asking if it is still in the std libraries, I am asking what >>> happened to make it impossible to write malloc() in standard C ?!? >> >> You need to reserve memory by some way from the operating system, >> which is, by necessity, outside of the scope of C (via brk(), >> GETMAIN, mmap() or whatever). > > Agreed, but once you HAVE a way of getting memory (by whatever name) > you can write malloc in standard C. The point is that getting more memory is inherently platform specific, which is why malloc() must be defined by each particular implementation, and so was put in the standard library.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-17 00:40 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <868qunxjm5.fsf@linuxsc.com> |
| In reply to | #109762 |
Thomas Koenig <tkoenig@netcologne.de> writes: > MitchAlsup1 <mitchalsup@aol.com> schrieb: > >> The paragraaph with 3 >'s indicates malloc() cannot be written >> in std. C. It used to be written in std. K&R C. I am not asking >> if it is still in the std libraries, I am asking what happened >> to make it impossible to write malloc() in std. C ?!? > > You need to reserve memory by some way from the operating system, > which is, by necessity, outside of the scope of C (via brk(), > GETMAIN, mmap() or whatever). Right. And that is why malloc(), or some essential internal component of malloc(), has to be platform specific, and thus malloc() must be supplied by the implementation (which means both the compiler and the standard library). > But more problematic is the implementation of free() without knowing > how to compare pointers. Once there is a way to get additional memory from whatever underlying environment is there, malloc() and free() can be implemented (and I believe most often are implemented) without needing to compare pointers. Note: pointers can be tested for equality without having to compare them relationally, and testing pointers for equality is well-defined between any two pointers (which may need to be converted to 'void *' to avoid a type mismatch).
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2024-10-17 18:31 +0000 |
| Subject | Re: fine points of dynamic memory allocation, not 80286 protected mode |
| Message-ID | <verl5q$1lsr$1@gal.iecc.com> |
| In reply to | #109773 |
According to Tim Rentsch <tr.17687@z991.linuxsc.com>: >Once there is a way to get additional memory from whatever underlying >environment is there, malloc() and free() can be implemented (and I >believe most often are implemented) without needing to compare >pointers. Note: pointers can be tested for equality without having >to compare them relationally, and testing pointers for equality is >well-defined between any two pointers (which may need to be converted >to 'void *' to avoid a type mismatch). I suppose it's possible, but the versions I know keep free lists and consolidate adjacent free chunks which requires comparing the pointers. -- 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 | 2024-10-17 19:01 +0000 |
| Subject | Re: fine points of dynamic memory allocation, not 80286 protected mode |
| Message-ID | <EadQO.87664$afc4.21380@fx42.iad> |
| In reply to | #109785 |
John Levine <johnl@taugh.com> writes: >According to Tim Rentsch <tr.17687@z991.linuxsc.com>: >>Once there is a way to get additional memory from whatever underlying >>environment is there, malloc() and free() can be implemented (and I >>believe most often are implemented) without needing to compare >>pointers. Note: pointers can be tested for equality without having >>to compare them relationally, and testing pointers for equality is >>well-defined between any two pointers (which may need to be converted >>to 'void *' to avoid a type mismatch). > >I suppose it's possible, but the versions I know keep free lists >and consolidate adjacent free chunks which requires comparing the >pointers. Assuming the malloc implementation associates metadata with the allocation (e.g. in bytes either before the returned pointer or after the allocation), the comparision for consolidation should always be standard supported equality comparisons.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2024-10-17 19:32 +0000 |
| Subject | Re: fine points of dynamic memory allocation, not 80286 protected mode |
| Message-ID | <verop8$2vkm$1@gal.iecc.com> |
| In reply to | #109786 |
According to Scott Lurndal <slp53@pacbell.net>: >>I suppose it's possible, but the versions I know keep free lists >>and consolidate adjacent free chunks which requires comparing the >>pointers. > >Assuming the malloc implementation associates metadata with the >allocation (e.g. in bytes either before the returned pointer or >after the allocation), the comparision for consolidation should >always be standard supported equality comparisons. I've seen allocators that sort the free list. And then there's other approches like buddy allocators that futz directly with the address bits. You probably could write a malloc/free that worked without doing anything other than equality comparisons but I doubt it would be a very good ones. The real ones I've seen also have tons of defensive compares to try to check for pointer smashing. -- 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 | 2024-10-17 21:01 +0000 |
| Subject | Re: fine points of dynamic memory allocation, not 80286 protected mode |
| Message-ID | <RWeQO.268848$kxD8.48864@fx11.iad> |
| In reply to | #109787 |
John Levine <johnl@taugh.com> writes: >According to Scott Lurndal <slp53@pacbell.net>: >>>I suppose it's possible, but the versions I know keep free lists >>>and consolidate adjacent free chunks which requires comparing the >>>pointers. >> >>Assuming the malloc implementation associates metadata with the >>allocation (e.g. in bytes either before the returned pointer or >>after the allocation), the comparision for consolidation should >>always be standard supported equality comparisons. > >I've seen allocators that sort the free list. And then there's >other approches like buddy allocators that futz directly with >the address bits. > >You probably could write a malloc/free that worked without doing >anything other than equality comparisons but I doubt it would be a >very good ones. The real ones I've seen also have tons of defensive >compares to try to check for pointer smashing. It's really an academic question. Very few useful C programs have ever been written in pure standard C. 'cat' perhaps? checks Unixware's cat.c; not portable - it uses 'fstat', 'read' and 'write'.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-18 07:12 -0700 |
| Subject | Re: fine points of dynamic memory allocation, not 80286 protected mode |
| Message-ID | <86cyjxwlcs.fsf@linuxsc.com> |
| In reply to | #109785 |
John Levine <johnl@taugh.com> writes: > According to Tim Rentsch <tr.17687@z991.linuxsc.com>: > >> Once there is a way to get additional memory from whatever underlying >> environment is there, malloc() and free() can be implemented (and I >> believe most often are implemented) without needing to compare >> pointers. Note: pointers can be tested for equality without having >> to compare them relationally, and testing pointers for equality is >> well-defined between any two pointers (which may need to be converted >> to 'void *' to avoid a type mismatch). > > I suppose it's possible, but the versions I know keep free lists > and consolidate adjacent free chunks which requires comparing the > pointers. It might seem that way, but it isn't so. There is a fairly straightforward scheme -- using a single address-sized cell before each memory block -- that consolidates adjacent free chunks and maintains free lists, without needing to compare pointers (and in fact doesn't use pointers at all except for the free lists). Doing a malloc() needs to search an appropriate free list for an adequately large free block, and is constant time thereafter; doing a free() uses constant time, including consolidation of adjacent free chunks. For an implementation with 8-byte addresses, this can be done with a grain size of 16 bytes and a minimum of 32-byte blocks (of which 24 bytes can be used by the client). Coincidentally (or not) that matches the sizes I see in tests done on an Ubuntu Linux system (any size less than 25 uses 32 bytes, any size less than 41 uses 48 bytes, etc). The key insight is to use the preceding memory word to hold the size of this block plus two bits: bit A is one if this block is not free, and bit B is one if the previous block is not free. If bit B is zero (so the previous block is free) then the last word of the previous block holds the size of that block. Free lists are maintained using the first two words in each free block (of course plus the list headers, which is a small fixed overhead). This information is enough to combine adjacent free blocks when a free() is done.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-17 02:48 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <86y12nvz3y.fsf@linuxsc.com> |
| In reply to | #109739 |
mitchalsup@aol.com (MitchAlsup1) writes: > On Tue, 15 Oct 2024 22:05:56 +0000, Scott Lurndal wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: >> >>> On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote: >>> >>>>> There is an advantage to the C approach of separating out some >>>>> facilities and supplying them only in the standard library. >>>> >>>> It goes a bit further: for a general purpose language, any >>>> existing functionality that cannot be written using the language >>>> is a sign of a weakness because it shows that despite being >>>> "general purpose" it fails to cover this specific "purpose". >>> >>> One of the key ways C got into the minds of programmers was that >>> one could write stuff like printf() in C and NOT need to have it >>> entirely built-into the language. >>> >>>> In an ideal world, it would be better if we could define `malloc` >>>> and `memmove` efficiently in standard C, but at least they can be >>>> implemented in non-standard C. >>> >>> malloc() used to be standard K&R C--what dropped if from the >>> standard?? >> >> It still is part of the ISO C standard. > > The paragraph with 3 >'s indicates malloc() cannot be written in > standard C. It used to be written in standard K&R C. No, it didn't. In the original book (my copy is from the third printing of the first edition, copyright 1978), on page 175 there is a function 'alloc()' that shows how to write a memory allocator. The code in alloc() calls 'morecore()', described as follows: The function morecore obtains storage from the operating system. The details of how this is done of course vary from system to system. In UNIX, the system entry sbrk() returns a pointer to n more bytes of storage. [...] An implementation of morecore() is shown on the next page, and it indeed uses sbrk() to get more memory. That makes it UNIX specific, not portable standard C. Both alloc() and morecore() are part of chapter 8, "The UNIX System Interface". Note also that chapter 7, titled "Input and Output" and describing the standard library, mentions in section 7.9, "Some Miscellaneous Functions", the function calloc() as part of the standard library. (There is no mention of malloc().) The point of having a standard library is that the functions it contains depend on details of the underlying OS and thus cannot be written in platform-agnostic code. Being platform portable is the defining property of "standard C". (Amusing aside: the entire standard library seems to be covered by just #include <stdio.h>.) > I am not > asking if it is still in the standard libraries, I am asking what > happened to make it impossible to write malloc() in standard C ?!? Functions such as sbrk() are not part of the C language. Whether it's called calloc() or malloc(), memory allocation has always needed access to some facilities not provided by the C language itself. The function malloc() is not any more writable in standard K&R C than it is in standard ISO C (except of course malloc() can be implemented by using calloc() internally, but that depends on calloc() being part of the standard library).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-16 09:38 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <venqhc$241bk$3@dont-email.me> |
| In reply to | #109736 |
On 15/10/2024 23:55, MitchAlsup1 wrote: > On Tue, 15 Oct 2024 21:26:29 +0000, Stefan Monnier wrote: > >>> There is an advantage to the C approach of separating out some >>> facilities and supplying them only in the standard library. >> >> It goes a bit further: for a general purpose language, any existing >> functionality that cannot be written using the language is a sign of >> a weakness because it shows that despite being "general purpose" it >> fails to cover this specific "purpose". > > One of the key ways C got into the minds of programmers was that > one could write stuff like printf() in C and NOT needd to have it > entirely built-into the language. It's a very good philosophy in programming language design that the core language should only contain what it has to contain - if a desired feature can be put in a library and be equally efficient and convenient to use, then it should be in the standard library, not the core language. It is much easier to develop, implement, enhance, adapt, and otherwise change things in libraries than the core language. And it is also fine, IMHO, that some things in the standard library need non-standard C - the standard library is part of the implementation. > >> In an ideal world, it would be better if we could define `malloc` and >> `memmove` efficiently in standard C, but at least they can be >> implemented in non-standard C. > > malloc() used to be std. K&R C--what dropped if from the std ?? The function has always been available in C since the language was standardised, and AFAIK it was in K&R C. But no one (in authority) ever claimed it could be implemented purely in standard C. What do you think has changed?
[toc] | [prev] | [next] | [standalone]
Page 6 of 23 — ← Prev page 1 … 4 5 [6] 7 8 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web