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 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2024-10-16 23:32 -0400 |
| Subject | Re: 80286 protected mode |
| Message-ID | <prv0hj9belf10h7pjqpv00s35sqvc46puu@4ax.com> |
| In reply to | #109747 |
On Wed, 16 Oct 2024 09:38:20 +0200, David Brown <david.brown@hesbynett.no> wrote: >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. But it is a problem if the library has to be written using a different compiler. [For this purpose I would consider specifying different compiler flags to be using a different compiler.] Why? Because once these things are discovered, many programmers will see their advantages and lack the discipline to avoid using them for more general application work. >>> 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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-17 16:25 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <ver6nt$2pcju$3@dont-email.me> |
| In reply to | #109772 |
On 17/10/2024 05:32, George Neuner wrote: > On Wed, 16 Oct 2024 09:38:20 +0200, David Brown > <david.brown@hesbynett.no> wrote: > > >> 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. > > But it is a problem if the library has to be written using a different > compiler. [For this purpose I would consider specifying different > compiler flags to be using a different compiler.] Specifying different flags would technically give you a different /implementation/, but it would not normally be considered a different /compiler/. I see no problem at all if libraries (standard library or otherwise) are compiled with different flags. I can absolutely guarantee that the flags I use for compiling my application code are not the same as those used for compiling the static libraries that came with my toolchains. Using different /compilers/ could be a significant inconvenience, and might mean you lose additional features (such as link-time optimisation), but as long as the ABI is consistent then they should work fine. > > Why? Because once these things are discovered, many programmers will > see their advantages and lack the discipline to avoid using them for > more general application work. > Really? Have you ever looked at the source code for a library such as glibc or newlib? Most developers would look at that and quickly shy away from all the macros, additional compiler-specific attributes, conditional compilation, and the rest of it. Very, very few would look into the details to see if there are any "tricks" or "secret" compiler extensions they can copy. And with very few exceptions, all the compiler-specific features will already be documented and available to programmers enthusiastic enough to RTFM. > >>>> 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]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-17 03:17 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <86plnzvxs2.fsf@linuxsc.com> |
| In reply to | #109736 |
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". That is a foolish statement.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-16 09:21 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <venpin$241bk$2@dont-email.me> |
| In reply to | #109735 |
On 15/10/2024 23:26, 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". > > 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. > I don't see an advantage in being able to implement them in standard C. I /do/ see an advantage in being able to do so well in non-standard, implementation-specific C. The reason why you might want your own special memmove, or your own special malloc, is that you are doing niche and specialised software. For example, you might be making real-time software and require specific time constraints on these functions. In such cases, you are not interested in writing fully portable software - it will already contain many implementation-specific features or use compiler extensions.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-10-16 11:18 -0400 |
| Subject | Re: 80286 protected mode |
| Message-ID | <jwvldyo3x1h.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #109746 |
>>> 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".
>> 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.
> I don't see an advantage in being able to implement them in standard C.
It means you can likely also implement a related yet different API
without having your code "demoted" to non-standard.
E.g. say if your application wants to use a region/pool/zone-based
memory management.
The fact that malloc can't be implemented in standard C is evidence
that standard C may not be general-purpose enough to accommodate an
application that wants to use a custom-designed allocator.
I don't disagree with you, from a practical perspective:
- in practice, C serves us well for Emacs's GC, even though that can't
be written in standard C.
- it's not like there are lots of other languages out there that offer
you portability together with the ability to define your own `malloc`.
But it's still a weakness, just a fairly minor one.
> The reason why you might want your own special memmove, or your own special
> malloc, is that you are doing niche and specialised software.
Region/pool/zone-based memory management is common enough that I would
not call it "niche", FWIW, and it's also used in applications that do want
portability (GCC and Apache come to mind).
Can't think of a practical reason to implement my own `memove`, OTOH.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-16 19:57 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <veoupf$2b2ul$1@dont-email.me> |
| In reply to | #109749 |
(Please do not snip or omit attributions. There are Usenet standards for a reason.) On 16/10/2024 17:18, 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". >>> 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. >> I don't see an advantage in being able to implement them in standard C. > > It means you can likely also implement a related yet different API > without having your code "demoted" to non-standard. That makes no sense to me. We are talking about implementing standard library functions. If you want to implement other functions, go ahead. Or do you mean that it is only possible to implement related functions (such as memory pools) if you also can implement malloc in fully portable standard C? That would make a little more sense if it were true, but it is not. First, you can implement such functions in implementation-specific code, so you are not hindered from writing the code you want. Secondly, standard C provides functions such as malloc() and aligned_alloc() that give you the parts you need - the fact that you need something outside of standard C to implement malloc() does not imply that you need those same features to implement your additional functions. > E.g. say if your application wants to use a region/pool/zone-based > memory management. > > The fact that malloc can't be implemented in standard C is evidence > that standard C may not be general-purpose enough to accommodate an > application that wants to use a custom-designed allocator. > No, it is not - see above. And remember how C was designed and how it was intended to be used. The aim was to be able to write portable code that could be reused on many systems, and /also/ implementation, OS and target specific code for maximum efficiency, systems programming, and other non-portable work. A typical C program combines these - some parts can be fully portable, other parts are partially portable (such as to any POSIX system, or targets with 32-bit int and 8-bit char), and some parts may be very compiler-specific or target specific. That's not an indication of failure of C for general-purpose programming. (But I would certainly not suggest that C is the best choice of language for many "general" programming tasks.) > I don't disagree with you, from a practical perspective: > > - in practice, C serves us well for Emacs's GC, even though that can't > be written in standard C. > - it's not like there are lots of other languages out there that offer > you portability together with the ability to define your own `malloc`. > > But it's still a weakness, just a fairly minor one. > >> The reason why you might want your own special memmove, or your own special >> malloc, is that you are doing niche and specialised software. > > Region/pool/zone-based memory management is common enough that I would > not call it "niche", FWIW, and it's also used in applications that do want > portability (GCC and Apache come to mind). > Can't think of a practical reason to implement my own `memove`, OTOH. > > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-10-21 14:04 -0400 |
| Subject | Re: 80286 protected mode |
| Message-ID | <jwved492v9f.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #109754 |
>>> I don't see an advantage in being able to implement them in standard C.
>> It means you can likely also implement a related yet different API
>> without having your code "demoted" to non-standard.
> That makes no sense to me. We are talking about implementing standard
> library functions. If you want to implement other functions, go ahead.
No, I'm talking about a very general principle that applies to
languages, libraries, etc...
For example, in Emacs I always try [and don't always succeed] to make
sure that the default behavior for a given functionality can be
implemented using the official API entry points of the underlying
library, because it makes it more likely that whoever wants to replace
that behavior with something else will be able to do it without having
to break abstraction barriers.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2024-10-18 17:38 +0100 |
| Subject | Re: 80286 protected mode |
| Message-ID | <veu2uv$3cluq$1@dont-email.me> |
| In reply to | #109746 |
On 16/10/2024 08:21, David Brown wrote: > > I don't see an advantage in being able to implement them in standard C. > I /do/ see an advantage in being able to do so well in non-standard, > implementation-specific C. > > The reason why you might want your own special memmove, or your own > special malloc, is that you are doing niche and specialised software. > For example, you might be making real-time software and require specific > time constraints on these functions. In such cases, you are not > interested in writing fully portable software - it will already contain > many implementation-specific features or use compiler extensions. > I have a vague feeling that once upon a time I wrote a malloc for an embedded system. Having only one process it had access to the entire memory range, and didn't need to talk to the OS. Entirely C is quite feasible there. But memmove? On an 80286 it will be using rep movsw, rather than a software loop, to copy the memory contents to the new location. _That_ does require assembler, or compiler extensions, not standard C. Andy
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-18 21:45 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <veudt1$3ep62$1@dont-email.me> |
| In reply to | #109805 |
On 18/10/2024 18:38, Vir Campestris wrote: > On 16/10/2024 08:21, David Brown wrote: >> >> I don't see an advantage in being able to implement them in standard >> C. I /do/ see an advantage in being able to do so well in >> non-standard, implementation-specific C. >> >> The reason why you might want your own special memmove, or your own >> special malloc, is that you are doing niche and specialised software. >> For example, you might be making real-time software and require >> specific time constraints on these functions. In such cases, you are >> not interested in writing fully portable software - it will already >> contain many implementation-specific features or use compiler extensions. >> > I have a vague feeling that once upon a time I wrote a malloc for an > embedded system. Having only one process it had access to the entire > memory range, and didn't need to talk to the OS. Entirely C is quite > feasible there. > Sure - but you are not writing portable standard C. You are relying on implementation details, or writing code that is only suitable for a particular implementation (or set of implementations). It is normal to write this kind of thing in C, but it is non-portable C. (Or at least, not fully portable C.) > But memmove? On an 80286 it will be using rep movsw, rather than a > software loop, to copy the memory contents to the new location. > > _That_ does require assembler, or compiler extensions, not standard C. > It would normally be written in C, and the compiler will generate the "rep" assembly. The bit you can't write in fully portable standard C is the comparison of the pointers so you know which direction to do the copying.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2024-10-20 21:51 +0100 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vf3qgi$ijah$1@dont-email.me> |
| In reply to | #109806 |
On 18/10/2024 20:45, David Brown wrote: > On 18/10/2024 18:38, Vir Campestris wrote: >> On 16/10/2024 08:21, David Brown wrote: >>> >>> I don't see an advantage in being able to implement them in standard >>> C. I /do/ see an advantage in being able to do so well in non- >>> standard, implementation-specific C. >>> >>> The reason why you might want your own special memmove, or your own >>> special malloc, is that you are doing niche and specialised software. >>> For example, you might be making real-time software and require >>> specific time constraints on these functions. In such cases, you are >>> not interested in writing fully portable software - it will already >>> contain many implementation-specific features or use compiler >>> extensions. >>> >> I have a vague feeling that once upon a time I wrote a malloc for an >> embedded system. Having only one process it had access to the entire >> memory range, and didn't need to talk to the OS. Entirely C is quite >> feasible there. >> > > Sure - but you are not writing portable standard C. You are relying on > implementation details, or writing code that is only suitable for a > particular implementation (or set of implementations). It is normal to > write this kind of thing in C, but it is non-portable C. (Or at least, > not fully portable C.) > Ah, I see your point. Because some implementations will require communication with the OS there cannot be a truly portable malloc. >> But memmove? On an 80286 it will be using rep movsw, rather than a >> software loop, to copy the memory contents to the new location. >> >> _That_ does require assembler, or compiler extensions, not standard C. >> > > It would normally be written in C, and the compiler will generate the > "rep" assembly. The bit you can't write in fully portable standard C is > the comparison of the pointers so you know which direction to do the > copying. > It's a long time since I had to mistrust a compiler so much that I was pulling the assembler apart. It sounds as though they have got smarter in the meantime. I just checked BTW, and you are correct. Andy
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-21 08:58 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vf4u1t$qo5f$2@dont-email.me> |
| In reply to | #109813 |
On 20/10/2024 22:51, Vir Campestris wrote: > On 18/10/2024 20:45, David Brown wrote: >> On 18/10/2024 18:38, Vir Campestris wrote: >>> On 16/10/2024 08:21, David Brown wrote: >>>> >>>> I don't see an advantage in being able to implement them in standard >>>> C. I /do/ see an advantage in being able to do so well in non- >>>> standard, implementation-specific C. >>>> >>>> The reason why you might want your own special memmove, or your own >>>> special malloc, is that you are doing niche and specialised >>>> software. For example, you might be making real-time software and >>>> require specific time constraints on these functions. In such >>>> cases, you are not interested in writing fully portable software - >>>> it will already contain many implementation-specific features or use >>>> compiler extensions. >>>> >>> I have a vague feeling that once upon a time I wrote a malloc for an >>> embedded system. Having only one process it had access to the entire >>> memory range, and didn't need to talk to the OS. Entirely C is quite >>> feasible there. >>> >> >> Sure - but you are not writing portable standard C. You are relying >> on implementation details, or writing code that is only suitable for a >> particular implementation (or set of implementations). It is normal >> to write this kind of thing in C, but it is non-portable C. (Or at >> least, not fully portable C.) >> > Ah, I see your point. Because some implementations will require > communication with the OS there cannot be a truly portable malloc. Yes. I think /every/ implementation will require communication with the OS, if there is an OS - otherwise it will need support from other parts of the toolchain (such as symbols created in a linker script to define the heap area - that's the typical implementation in small embedded systems). The nearest you could get to a portable implementation would be using a local unsigned char array as the heap, but I don't believe that would be fully correct according to the effective type rules (or the "strict aliasing" or type-based aliasing rules, if you prefer those terms). It would also not be good enough for the needs of many programs. Of course, a fair amount of the code for malloc/free can written in fully portable C - and almost all of it can be written in a somewhat vaguely defined "widely portable C" where you can mask pointer bits to handle alignment, and other such conveniences. > >>> But memmove? On an 80286 it will be using rep movsw, rather than a >>> software loop, to copy the memory contents to the new location. >>> >>> _That_ does require assembler, or compiler extensions, not standard C. >>> >> >> It would normally be written in C, and the compiler will generate the >> "rep" assembly. The bit you can't write in fully portable standard C >> is the comparison of the pointers so you know which direction to do >> the copying. >> > It's a long time since I had to mistrust a compiler so much that I was > pulling the assembler apart. It sounds as though they have got smarter > in the meantime. > > I just checked BTW, and you are correct. > Looking at the generated assembly is usually not a matter of mistrusting the compiler. One of the reasons I do so is to check that the compiler can generate efficient object code from my source code, in cases where I need maximal efficiency. I'd rather not write assembly unless I really have to!
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-21 09:21 +0200 |
| Subject | Re: 80286 protected mode |
| Message-ID | <vf4ve7$rtqt$1@dont-email.me> |
| In reply to | #109817 |
David Brown wrote: > On 20/10/2024 22:51, Vir Campestris wrote: >> On 18/10/2024 20:45, David Brown wrote: >>> On 18/10/2024 18:38, Vir Campestris wrote: >>>> On 16/10/2024 08:21, David Brown wrote: >>>>> >>>>> I don't see an advantage in being able to implement them in >>>>> standard C. I /do/ see an advantage in being able to do so well in >>>>> non- standard, implementation-specific C. >>>>> >>>>> The reason why you might want your own special memmove, or your own >>>>> special malloc, is that you are doing niche and specialised >>>>> software. For example, you might be making real-time software and >>>>> require specific time constraints on these functions. In such >>>>> cases, you are not interested in writing fully portable software - >>>>> it will already contain many implementation-specific features or >>>>> use compiler extensions. >>>>> >>>> I have a vague feeling that once upon a time I wrote a malloc for an >>>> embedded system. Having only one process it had access to the entire >>>> memory range, and didn't need to talk to the OS. Entirely C is quite >>>> feasible there. >>>> >>> >>> Sure - but you are not writing portable standard C. You are relying >>> on implementation details, or writing code that is only suitable for >>> a particular implementation (or set of implementations). It is >>> normal to write this kind of thing in C, but it is non-portable C. >>> (Or at least, not fully portable C.) >>> >> Ah, I see your point. Because some implementations will require >> communication with the OS there cannot be a truly portable malloc. > > Yes. > > I think /every/ implementation will require communication with the OS, > if there is an OS - otherwise it will need support from other parts of > the toolchain (such as symbols created in a linker script to define the > heap area - that's the typical implementation in small embedded systems). > > The nearest you could get to a portable implementation would be using a > local unsigned char array as the heap, but I don't believe that would be > fully correct according to the effective type rules (or the "strict > aliasing" or type-based aliasing rules, if you prefer those terms). It > would also not be good enough for the needs of many programs. > > Of course, a fair amount of the code for malloc/free can written in > fully portable C - and almost all of it can be written in a somewhat > vaguely defined "widely portable C" where you can mask pointer bits to > handle alignment, and other such conveniences. > >> >>>> But memmove? On an 80286 it will be using rep movsw, rather than a >>>> software loop, to copy the memory contents to the new location. >>>> >>>> _That_ does require assembler, or compiler extensions, not standard C. >>>> >>> >>> It would normally be written in C, and the compiler will generate the >>> "rep" assembly. The bit you can't write in fully portable standard >>> C is the comparison of the pointers so you know which direction to do >>> the copying. >>> >> It's a long time since I had to mistrust a compiler so much that I was >> pulling the assembler apart. It sounds as though they have got smarter >> in the meantime. >> >> I just checked BTW, and you are correct. >> > > Looking at the generated assembly is usually not a matter of mistrusting > the compiler. One of the reasons I do so is to check that the compiler > can generate efficient object code from my source code, in cases where I > need maximal efficiency. I'd rather not write assembly unless I really > have to! For near-light-speed code I used to write it first in C, optimize that, then I would translate it into (inline) asm and re-optimize based on having the full cpu architecture available, before in the final stage I would use the asm experience to tweak the C just enough to let the compiler generate machine code quite close (90+%) to my best asm, while still being portable to any cpu with more or less the same capabilities. One example: When I won an international competition to write the fastest Pentomino solver (capable of finding all 2339/1010/368/2 solutions of the 6x10/5x12/4x15/3x20 layouts), I also included the portable C version. My asm submission was twice as fast as anyone else, while the C version was still fast enough that a couple of years later I got a prize in the mail: Someone in France had submitted my C code, with my name & address, to a similar competition there and it was still faster than anyone else. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-21 18:32 -0700 |
| Subject | Re: 80286 protected mode |
| Message-ID | <86zfmwvs5w.fsf@linuxsc.com> |
| In reply to | #109818 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: [C vs assembly] > For near-light-speed code I used to write it first in C, optimize > that, then I would translate it into (inline) asm and re-optimize > based on having the full cpu architecture available, before in the > final stage I would use the asm experience to tweak the C just > enough to let the compiler generate machine code quite close > (90+%) to my best asm, while still being portable to any cpu with > more or less the same capabilities. > > One example: When I won an international competition to write the > fastest Pentomino solver (capable of finding all 2339/1010/368/2 > solutions of the 6x10/5x12/4x15/3x20 layouts), I also included the > portable C version. > > My asm submission was twice as fast as anyone else, while the C > version was still fast enough that a couple of years later I got a > prize in the mail: Someone in France had submitted my C code, > with my name & address, to a similar competition there and it was > still faster than anyone else. :-) I hope you will consider writing a book, "Writing Fast Code" (or something along those lines). The core of the book could be, oh, let's say between 8 and 12 case studies, starting with a problem statement and tracing through the process that you followed, or would follow, with stops along the way showing the code at each of the different stages. If you do write such I book I guarantee I will want to buy one.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-22 08:27 +0200 |
| Subject | Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vf7gk0$1ce7n$1@dont-email.me> |
| In reply to | #109832 |
Tim Rentsch wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: > > [C vs assembly] > >> For near-light-speed code I used to write it first in C, optimize >> that, then I would translate it into (inline) asm and re-optimize >> based on having the full cpu architecture available, before in the >> final stage I would use the asm experience to tweak the C just >> enough to let the compiler generate machine code quite close >> (90+%) to my best asm, while still being portable to any cpu with >> more or less the same capabilities. >> >> One example: When I won an international competition to write the >> fastest Pentomino solver (capable of finding all 2339/1010/368/2 >> solutions of the 6x10/5x12/4x15/3x20 layouts), I also included the >> portable C version. >> >> My asm submission was twice as fast as anyone else, while the C >> version was still fast enough that a couple of years later I got a >> prize in the mail: Someone in France had submitted my C code, >> with my name & address, to a similar competition there and it was >> still faster than anyone else. :-) > > I hope you will consider writing a book, "Writing Fast Code" (or > something along those lines). The core of the book could be, oh, > let's say between 8 and 12 case studies, starting with a problem > statement and tracing through the process that you followed, or > would follow, with stops along the way showing the code at each > of the different stages. > > If you do write such I book I guarantee I will want to buy one. > Thank you Tim! Probably not a book but I would consider writing a series of blog posts similar to that, now that I am about to retire: My wife and I will both go on "permanent vacation" starting a week before Christmas. :-) I already know that this will give me more time to work on digital mapping projects (ref my https://mapant.no/ Norwegian topo map generated from ~50 TB of LiDAR), but if there's an interest in optimization I might do that as well. BTW, I am also open to doing some consulting work, if the problems are interesting enough. :-) Regards, Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-23 07:25 -0700 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <86sesmvqu1.fsf@linuxsc.com> |
| In reply to | #109836 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: > Tim Rentsch wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >> [C vs assembly] >> >>> For near-light-speed code I used to write it first in C, optimize >>> that, then I would translate it into (inline) asm and re-optimize >>> based on having the full cpu architecture available, before in the >>> final stage I would use the asm experience to tweak the C just >>> enough to let the compiler generate machine code quite close >>> (90+%) to my best asm, while still being portable to any cpu with >>> more or less the same capabilities. >>> >>> One example: When I won an international competition to write the >>> fastest Pentomino solver (capable of finding all 2339/1010/368/2 >>> solutions of the 6x10/5x12/4x15/3x20 layouts), I also included the >>> portable C version. >>> >>> My asm submission was twice as fast as anyone else, while the C >>> version was still fast enough that a couple of years later I got a >>> prize in the mail: Someone in France had submitted my C code, >>> with my name & address, to a similar competition there and it was >>> still faster than anyone else. :-) >> >> I hope you will consider writing a book, "Writing Fast Code" (or >> something along those lines). The core of the book could be, oh, >> let's say between 8 and 12 case studies, starting with a problem >> statement and tracing through the process that you followed, or >> would follow, with stops along the way showing the code at each >> of the different stages. >> >> If you do write such a book I guarantee I will want to buy one. > > Thank you Tim! I know from past experience you are good at this. I would love to hear what you have to say. > Probably not a book but I would consider writing a series of blog > posts similar to that, now that I am about to retire: You could try writing one blog post a month on the subject. By this time next year you will have plenty of material and be well on your way to putting a book together. (First drafts are always the hardest part...) > My wife and I will both go on "permanent vacation" starting a week > before Christmas. :-) I'm guessing that permanent vacation will be some mixture of actual vacation and self-chosen "work". In any case I hope you both enjoy the time. P.S. Is the email address in your message a good way to reach you?
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-23 18:11 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <f76d30e07a848362c2ce912ee8d62479@www.novabbs.org> |
| In reply to | #109858 |
On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: >> My wife and I will both go on "permanent vacation" starting a week >> before Christmas. :-) > > I'm guessing that permanent vacation will be some mixture of actual > vacation and self-chosen "work". In any case I hope you both enjoy > the time. Just remember, retirement does not mean you "stop working" it means you "stop working for HIM".
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-10-23 18:27 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <_dbSO.204542$2nv5.75703@fx39.iad> |
| In reply to | #109859 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: > >>> My wife and I will both go on "permanent vacation" starting a week >>> before Christmas. :-) >> >> I'm guessing that permanent vacation will be some mixture of actual >> vacation and self-chosen "work". In any case I hope you both enjoy >> the time. > >Just remember, retirement does not mean you "stop working" >it means you "stop working for HIM". And start working for "HER". (Honeydew list).
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-23 21:12 +0200 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfbhrp$26trl$3@dont-email.me> |
| In reply to | #109860 |
Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >> On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>>> My wife and I will both go on "permanent vacation" starting a week >>>> before Christmas. :-) >>> >>> I'm guessing that permanent vacation will be some mixture of actual >>> vacation and self-chosen "work". In any case I hope you both enjoy >>> the time. >> >> Just remember, retirement does not mean you "stop working" >> it means you "stop working for HIM". > > And start working for "HER". (Honeydew list). > My wife do have a small list of things that we (i.e. I) could do when we retire... Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2024-10-27 20:45 +0000 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfm8ol$j2qq$4@dont-email.me> |
| In reply to | #109863 |
On 23/10/2024 20:12, Terje Mathisen wrote: >> > My wife do have a small list of things that we (i.e. I) could do when we > retire... Since I retired the garden is looking much better, I've started to win the odd trophy sailing, most of the house has been redecorated... But best of all - I've lost 5kG and been able to stop worrying about my weight! Andy
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2024-10-23 21:11 +0200 |
| Subject | Re: Retirement hobby (was Re: 80286 protected mode) |
| Message-ID | <vfbhpv$26trl$2@dont-email.me> |
| In reply to | #109859 |
MitchAlsup1 wrote: > On Wed, 23 Oct 2024 14:25:42 +0000, Tim Rentsch wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: > >>> My wife and I will both go on "permanent vacation" starting a week >>> before Christmas. :-) >> >> I'm guessing that permanent vacation will be some mixture of actual >> vacation and self-chosen "work". In any case I hope you both enjoy >> the time. > > Just remember, retirement does not mean you "stop working" > it means you "stop working for HIM". Exactly! I have unlimited amounts of potential/available mapping work, and I do want to get back to NTP Hackers. We recently started (officially) on the 754-2029 revision. I'm still connected to Mill Computing as well. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
Page 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web