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 15 of 23 — ← Prev page 1 … 13 14 [15] 16 17 … 23 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-15 20:59 +0000 |
| Subject | Re: Segments |
| Message-ID | <vm97j3$342b3$1@dont-email.me> |
| In reply to | #110529 |
Michael S <already5chosen@yahoo.com> schrieb: > On Wed, 15 Jan 2025 18:00:34 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > >> Michael S <already5chosen@yahoo.com> schrieb: >> > On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) >> > Thomas Koenig <tkoenig@netcologne.de> wrote: >> > >> >> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >> >> > Thomas Koenig <tkoenig@netcologne.de> writes: >> >> > [...] >> >> >> CHERY targets C, which on the one hand, I understand (there's a >> >> >> ton of C code out there), but trying to retrofit a safe memory >> >> >> model onto C seems a bit awkward - it might have been better to >> >> >> target a language which has arrays in the first place, unlike >> >> >> C. >> >> > [...] >> >> > >> >> > C does have arrays. >> >> >> >> Sort of - they decay into pointers at first sight. >> >> >> >> But what I should have written was "multi-dimensional arrays", >> >> with a reasonable way of handling them. >> > >> > C language always had multi-dimensional arrays, with limitation that >> > dimensions have to be known in compile time. >> > C99 lifted that limitation, making C support for multi-dimensional >> > arrays comparable to that in old Fortran. >> > C11 said that lifting is optional. >> > Now C23 makes part of the lifting (variably-modified types) again >> > mandatory. >> >> I'd missed that one. >> >> > Relatively to F90, support for multi-dimensional arrays in C23 is >> > primitive. >> >> From what you describe, support for multi-dimensional arrays >> in C23 now reached the level of Fortran II, released in >> 1958. Only a bit more than six decades, can't complain >> about that. > > Well, apart from playing with what is mandatory and what is not, arrays > stuff in C had not changed (AFAIK) since C99. It's not mandatory, so compilers are free to ignore it (and a major compiler, from a certain company in Redmond, does not support it). That's as good as sayhing that it does not exist in the language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-16 12:36 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmar0d$3g078$1@dont-email.me> |
| In reply to | #110530 |
On 15/01/2025 21:59, Thomas Koenig wrote: > Michael S <already5chosen@yahoo.com> schrieb: >> On Wed, 15 Jan 2025 18:00:34 -0000 (UTC) >> Thomas Koenig <tkoenig@netcologne.de> wrote: >> >>> Michael S <already5chosen@yahoo.com> schrieb: >>>> On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: >>>> >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >>>>>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>>> [...] >>>>>>> CHERY targets C, which on the one hand, I understand (there's a >>>>>>> ton of C code out there), but trying to retrofit a safe memory >>>>>>> model onto C seems a bit awkward - it might have been better to >>>>>>> target a language which has arrays in the first place, unlike >>>>>>> C. >>>>>> [...] >>>>>> >>>>>> C does have arrays. >>>>> >>>>> Sort of - they decay into pointers at first sight. >>>>> >>>>> But what I should have written was "multi-dimensional arrays", >>>>> with a reasonable way of handling them. >>>> >>>> C language always had multi-dimensional arrays, with limitation that >>>> dimensions have to be known in compile time. >>>> C99 lifted that limitation, making C support for multi-dimensional >>>> arrays comparable to that in old Fortran. >>>> C11 said that lifting is optional. >>>> Now C23 makes part of the lifting (variably-modified types) again >>>> mandatory. >>> >>> I'd missed that one. >>> >>>> Relatively to F90, support for multi-dimensional arrays in C23 is >>>> primitive. >>> >>> From what you describe, support for multi-dimensional arrays >>> in C23 now reached the level of Fortran II, released in >>> 1958. Only a bit more than six decades, can't complain >>> about that. >> >> Well, apart from playing with what is mandatory and what is not, arrays >> stuff in C had not changed (AFAIK) since C99. > > It's not mandatory, so compilers are free to ignore it (and a > major compiler, from a certain company in Redmond, does > not support it). That's as good as sayhing that it does not > exist in the language. Not really, no. The world of C programmers can be divided into those that work with C compilers and can freely use pretty much anything in C, and those that have to content with limited, non-standard or otherwise problematic compilers and write code that works for them. Such compilers include embedded toolchains for very small microcontrollers or DSPs, and MS's C compiler. Some C code needs to be written in a way that works on MS's C compiler as well as other tools, but most is free from such limitations. Even for those targeting Windows, it's common to use clang or gcc for serious C coding. MS used to have a long-term policy of specifically not supporting C well because that might make it easier for people to write cross-platform C code for Windows and Linux. Instead, they preferred to push developers towards C# and Windows-only programming - or if that failed, C++ which was not as commonly used on *nix. Now, I think, they just don't care much about C - they don't see many people using their tools for C and haven't bothered supporting any feature that needs much effort. They know that they can't catch up with other C compilers, so have made it easier to integrate clang with their IDE's and development tools.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-16 14:35 +0200 |
| Subject | Re: Segments |
| Message-ID | <20250116143532.00002117@yahoo.com> |
| In reply to | #110537 |
On Thu, 16 Jan 2025 12:36:45 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 15/01/2025 21:59, Thomas Koenig wrote: > > Michael S <already5chosen@yahoo.com> schrieb: > >> On Wed, 15 Jan 2025 18:00:34 -0000 (UTC) > >> Thomas Koenig <tkoenig@netcologne.de> wrote: > >> > >>> Michael S <already5chosen@yahoo.com> schrieb: > >>>> On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) > >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: > >>>> > >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: > >>>>>> Thomas Koenig <tkoenig@netcologne.de> writes: > >>>>>> [...] > >>>>>>> CHERY targets C, which on the one hand, I understand (there's > >>>>>>> a ton of C code out there), but trying to retrofit a safe > >>>>>>> memory model onto C seems a bit awkward - it might have been > >>>>>>> better to target a language which has arrays in the first > >>>>>>> place, unlike C. > >>>>>> [...] > >>>>>> > >>>>>> C does have arrays. > >>>>> > >>>>> Sort of - they decay into pointers at first sight. > >>>>> > >>>>> But what I should have written was "multi-dimensional arrays", > >>>>> with a reasonable way of handling them. > >>>> > >>>> C language always had multi-dimensional arrays, with limitation > >>>> that dimensions have to be known in compile time. > >>>> C99 lifted that limitation, making C support for > >>>> multi-dimensional arrays comparable to that in old Fortran. > >>>> C11 said that lifting is optional. > >>>> Now C23 makes part of the lifting (variably-modified types) again > >>>> mandatory. > >>> > >>> I'd missed that one. > >>> > >>>> Relatively to F90, support for multi-dimensional arrays in C23 is > >>>> primitive. > >>> > >>> From what you describe, support for multi-dimensional arrays > >>> in C23 now reached the level of Fortran II, released in > >>> 1958. Only a bit more than six decades, can't complain > >>> about that. > >> > >> Well, apart from playing with what is mandatory and what is not, > >> arrays stuff in C had not changed (AFAIK) since C99. > > > > It's not mandatory, so compilers are free to ignore it (and a > > major compiler, from a certain company in Redmond, does > > not support it). That's as good as sayhing that it does not > > exist in the language. > > Not really, no. The world of C programmers can be divided into those > that work with C compilers and can freely use pretty much anything in > C, and those that have to content with limited, non-standard or > otherwise problematic compilers and write code that works for them. > Such compilers include embedded toolchains for very small > microcontrollers or DSPs, and MS's C compiler. > > Some C code needs to be written in a way that works on MS's C > compiler as well as other tools, but most is free from such > limitations. Even for those targeting Windows, it's common to use > clang or gcc for serious C coding. > > MS used to have a long-term policy of specifically not supporting C > well because that might make it easier for people to write > cross-platform C code for Windows and Linux. Instead, they preferred > to push developers towards C# and Windows-only programming - or if > that failed, C++ which was not as commonly used on *nix. Now, I > think, they just don't care much about C - they don't see many people > using their tools for C and haven't bothered supporting any feature > that needs much effort. They know that they can't catch up with > other C compilers, so have made it easier to integrate clang with > their IDE's and development tools. > Microsoft does care about C, but only in one specific area - kernel programming. The only other language officially allowed for Windows kernel programming is C++, but coding kernel drivers in C++ is discouraged. I suppose that driver written in C++ would have major difficulties passing Windows HLK tests and getting WHQL signing. As you can guess, in kernel drivers VLA are unwelcome. VMTs are, may be, tolerable (I wonder what is current policy of Linux and BSD kernels), but hardly desirable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-16 13:59 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmavsb$3gpni$1@dont-email.me> |
| In reply to | #110539 |
On 16/01/2025 13:35, Michael S wrote: > On Thu, 16 Jan 2025 12:36:45 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 15/01/2025 21:59, Thomas Koenig wrote: >>> Michael S <already5chosen@yahoo.com> schrieb: >>>> On Wed, 15 Jan 2025 18:00:34 -0000 (UTC) >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: >>>> >>>>> Michael S <already5chosen@yahoo.com> schrieb: >>>>>> On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) >>>>>> Thomas Koenig <tkoenig@netcologne.de> wrote: >>>>>> >>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >>>>>>>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>>>>> [...] >>>>>>>>> CHERY targets C, which on the one hand, I understand (there's >>>>>>>>> a ton of C code out there), but trying to retrofit a safe >>>>>>>>> memory model onto C seems a bit awkward - it might have been >>>>>>>>> better to target a language which has arrays in the first >>>>>>>>> place, unlike C. >>>>>>>> [...] >>>>>>>> >>>>>>>> C does have arrays. >>>>>>> >>>>>>> Sort of - they decay into pointers at first sight. >>>>>>> >>>>>>> But what I should have written was "multi-dimensional arrays", >>>>>>> with a reasonable way of handling them. >>>>>> >>>>>> C language always had multi-dimensional arrays, with limitation >>>>>> that dimensions have to be known in compile time. >>>>>> C99 lifted that limitation, making C support for >>>>>> multi-dimensional arrays comparable to that in old Fortran. >>>>>> C11 said that lifting is optional. >>>>>> Now C23 makes part of the lifting (variably-modified types) again >>>>>> mandatory. >>>>> >>>>> I'd missed that one. >>>>> >>>>>> Relatively to F90, support for multi-dimensional arrays in C23 is >>>>>> primitive. >>>>> >>>>> From what you describe, support for multi-dimensional arrays >>>>> in C23 now reached the level of Fortran II, released in >>>>> 1958. Only a bit more than six decades, can't complain >>>>> about that. >>>> >>>> Well, apart from playing with what is mandatory and what is not, >>>> arrays stuff in C had not changed (AFAIK) since C99. >>> >>> It's not mandatory, so compilers are free to ignore it (and a >>> major compiler, from a certain company in Redmond, does >>> not support it). That's as good as sayhing that it does not >>> exist in the language. >> >> Not really, no. The world of C programmers can be divided into those >> that work with C compilers and can freely use pretty much anything in >> C, and those that have to content with limited, non-standard or >> otherwise problematic compilers and write code that works for them. >> Such compilers include embedded toolchains for very small >> microcontrollers or DSPs, and MS's C compiler. >> >> Some C code needs to be written in a way that works on MS's C >> compiler as well as other tools, but most is free from such >> limitations. Even for those targeting Windows, it's common to use >> clang or gcc for serious C coding. >> >> MS used to have a long-term policy of specifically not supporting C >> well because that might make it easier for people to write >> cross-platform C code for Windows and Linux. Instead, they preferred >> to push developers towards C# and Windows-only programming - or if >> that failed, C++ which was not as commonly used on *nix. Now, I >> think, they just don't care much about C - they don't see many people >> using their tools for C and haven't bothered supporting any feature >> that needs much effort. They know that they can't catch up with >> other C compilers, so have made it easier to integrate clang with >> their IDE's and development tools. >> > > Microsoft does care about C, but only in one specific area - kernel > programming. OK. That's not an area I have been involved in at all, so I will take your word for it. Does that also extend to device drivers? > The only other language officially allowed for Windows > kernel programming is C++, but coding kernel drivers in C++ is > discouraged. C++ is absolutely fine for low-level programming, but you need to know how to write low-level C++ code. Someone used to writing application code in C++ can write really bad low-level C++ code very, very quickly - it takes more effort to get things totally wrong in C! > I suppose that driver written in C++ would have major > difficulties passing Windows HLK tests and getting WHQL signing. > I once took a brief look at that process many years ago, and decided it was not for me! > As you can guess, in kernel drivers VLA are unwelcome. I can imagine that they are - but I really don't understand why. I've never understood why people think there is something "dangerous" about VLAs, or why they think using heap allocations is somehow "safer". > VMTs are, may > be, tolerable (I wonder what is current policy of Linux and BSD > kernels), but hardly desirable. >
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-16 16:46 +0000 |
| Subject | Re: Segments |
| Message-ID | <vmbd4n$3v6su$3@paganini.bofh.team> |
| In reply to | #110540 |
David Brown <david.brown@hesbynett.no> wrote:
> On 16/01/2025 13:35, Michael S wrote:
>> On Thu, 16 Jan 2025 12:36:45 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> On 15/01/2025 21:59, Thomas Koenig wrote:
>>>> Michael S <already5chosen@yahoo.com> schrieb:
>>>>> On Wed, 15 Jan 2025 18:00:34 -0000 (UTC)
>>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>
>> As you can guess, in kernel drivers VLA are unwelcome.
>
> I can imagine that they are - but I really don't understand why. I've
> never understood why people think there is something "dangerous" about
> VLAs, or why they think using heap allocations is somehow "safer".
VLA normally allocate on the stack. Which at first glance look
great. But once one realize how small are stacks in modern
systems (compared to whole memory), this no longer looks good.
Basically, to use VLA one needs rather small bound on maximal
size of array. Given such bound always allocating maximal
size is simpler. Without _small_ bound on size heap is
safer, as it is desined to handle also big allocations.
In the past I was a fan of VLA and stack allocation in general.
But I saw enough bug reports due to programs exceeding their
stack limits that I changed my view.
I do not know about Windows, but IIUC in some period Linux limit
for kernel stack was something like 2 kB (single page shared
with some other per-process data structures). I think it
was increased later, but even moderate size arrays are
unwelcame on kernel stack due to size limits.
>> VMTs are, may
>> be, tolerable (I wonder what is current policy of Linux and BSD
>> kernels), but hardly desirable.
IMO VMT-s are vastly superior to raw pointers, but to fully
get their advantages one would need better tools. Also,
kernel needs to deal with variable size arrays embedded in
various data structures. This is possible using pointers,
but current VMT-s are too weak for many such uses.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-16 18:12 +0000 |
| Subject | Re: Segments |
| Message-ID | <vmbi6u$3js5u$1@dont-email.me> |
| In reply to | #110543 |
Waldek Hebisch <antispam@fricas.org> schrieb:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 16/01/2025 13:35, Michael S wrote:
>>> On Thu, 16 Jan 2025 12:36:45 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>> On 15/01/2025 21:59, Thomas Koenig wrote:
>>>>> Michael S <already5chosen@yahoo.com> schrieb:
>>>>>> On Wed, 15 Jan 2025 18:00:34 -0000 (UTC)
>>>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>>
>
>>> As you can guess, in kernel drivers VLA are unwelcome.
>>
>> I can imagine that they are - but I really don't understand why. I've
>> never understood why people think there is something "dangerous" about
>> VLAs, or why they think using heap allocations is somehow "safer".
>
> VLA normally allocate on the stack.
You can pass them as VLAs (which Fortran has had since 1958)
or you can declare them. It is the latter which would need
to allocate on the stack.
But allocating them on the stack is an implementation detail.
Since Fortran 90, you can also do
subroutine foo(n,m)
integer, intent(in) :: n,m
real, dimension(n,m) :: a
which will delcare the array a with the bounds of n and m.
(Fortran can also do dynamic memory allocation, so
subroutine foo(n,m)
integer, intent(in) :: n,m
real, dimension(:,:), allocatable :: c
allocate (c(n,m))
would also work, and also automatically release the memory).
Because Fortran users are used to large arrays, any good Fortran
compiler will also allocate a on the heap if it is too large.
> Which at first glance look
> great. But once one realize how small are stacks in modern
> systems (compared to whole memory), this no longer looks good.
Stacks are small because OS people make them small, not because of
a valid technical reason that has ever been explained to me.
"To avoid infinite recursion" is not a valid reason, IMHO.
> Basically, to use VLA one needs rather small bound on maximal
> size of array. Given such bound always allocating maximal
> size is simpler. Without _small_ bound on size heap is
> safer, as it is desined to handle also big allocations.
Allocating data on the stack promotes cache locality, which can
increase performance by quite a lot.
If you have a memory allocation pattern like
p1 = malloc(chunk_1); /* Fill it */
p2 = malloc(chunk_2);
/* Use it */
free (p2);
p3 = malloc(chunk_3);
/* Use it */
free (p3)
/* Use p1 */
There is a chance that p2 still pollutes the cache and parts of
p1 may have been removed unnecessarily. This would not have been
the case p2 and p3 had been allocated on the stack.
> In the past I was a fan of VLA and stack allocation in general.
> But I saw enough bug reports due to programs exceeding their
> stack limits that I changed my view.
Stack limits are artificial, but
>
> I do not know about Windows, but IIUC in some period Linux limit
> for kernel stack was something like 2 kB (single page shared
> with some other per-process data structures). I think it
> was increased later, but even moderate size arrays are
> unwelcame on kernel stack due to size limits.
... for kernels maybe less so.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-16 18:30 +0000 |
| Subject | Re: Segments |
| Message-ID | <04876fc002ab019a74c78113a36622f3@www.novabbs.org> |
| In reply to | #110547 |
On Thu, 16 Jan 2025 18:12:46 +0000, Thomas Koenig wrote:
> Waldek Hebisch <antispam@fricas.org> schrieb:
>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>
>> Which at first glance look
>> great. But once one realize how small are stacks in modern
>> systems (compared to whole memory), this no longer looks good.
>
> Stacks are small because OS people make them small, not because of
> a valid technical reason that has ever been explained to me.
> "To avoid infinite recursion" is not a valid reason, IMHO.
Algol 60 only had stack allocation for dynamically sized arrays,
so stacks had to be as big as the data are.
>> Basically, to use VLA one needs rather small bound on maximal
>> size of array. Given such bound always allocating maximal
>> size is simpler. Without _small_ bound on size heap is
>> safer, as it is desined to handle also big allocations.
>
> Allocating data on the stack promotes cache locality, which can
> increase performance by quite a lot.
If/when HW can track deallocating stack storage; the core
does not have to write back modified lines to memory at cache
line replacement. {{Look, once the SP moves out of that part of
the stack, nobody is allowed to dereference it anymore, so,
nobody cares about the value in those containers.}}
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-01-18 03:08 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vmf5vv$2cse$1@gal.iecc.com> |
| In reply to | #110549 |
According to MitchAlsup1 <mitchalsup@aol.com>: >> Stacks are small because OS people make them small, not because of >> a valid technical reason that has ever been explained to me. >> "To avoid infinite recursion" is not a valid reason, IMHO. > >Algol 60 only had stack allocation for dynamically sized arrays, >so stacks had to be as big as the data are. Huh? Algol 60 routines could be mutually recursive so unless it was a leaf procedure or the outer block, everything not declared "own" went on the stack. On my FreeBSD server the default stack limit is half a gigabyte. I don't ever recall running into it. -- 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 | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-01-18 10:59 +0200 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <lv18qpFjhe9U1@mid.individual.net> |
| In reply to | #110578 |
On 2025-01-18 5:08, John Levine wrote: > According to MitchAlsup1 <mitchalsup@aol.com>: >>> Stacks are small because OS people make them small, not because of >>> a valid technical reason that has ever been explained to me. >>> "To avoid infinite recursion" is not a valid reason, IMHO. >> >> Algol 60 only had stack allocation for dynamically sized arrays, >> so stacks had to be as big as the data are. > > Huh? Algol 60 routines could be mutually recursive so unless it was > a leaf procedure or the outer block, everything not declared "own" > went on the stack. Mitch's point AIUI was that Algol 60 had no heap allocation (and no explicit pointer types), so indeed all data were either on the stack or statically allocated. I'm not an English native speaker, but it seems to me that Mitch should have written "Algol 60 had only stack allocation" instead of "Algol 60 only had stack allocation". The most-used Ada compiler, GNAT, uses a "secondary stack" to reduce the need for heap. Dynamically sized local data are placed on the secondary stack, and dynamically sized return values of functions are returned on the secondary stack. So a function can return "by value" an array sized 1..N, with N a function parameter, without needing the heap. Of course the programmer then has the problem of setting sufficient sizes for /two/ stacks, the primary and the secondary. For embedded-systems programs one usually avoids constructs that would need a secondary stack.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-01-18 19:41 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vmh064$sv1$1@gal.iecc.com> |
| In reply to | #110580 |
According to Niklas Holsti <niklas.holsti@tidorum.invalid>: >>> Algol 60 only had stack allocation for dynamically sized arrays, >>> so stacks had to be as big as the data are. >> >> Huh? Algol 60 routines could be mutually recursive so unless it was >> a leaf procedure or the outer block, everything not declared "own" >> went on the stack. > >Mitch's point AIUI was that Algol 60 had no heap allocation (and no >explicit pointer types), so indeed all data were either on the stack or >statically allocated. It sounded to me like he said that dynamically sized arrays were on the stack, nothing else was. I think we agree that everything but "own" is on the stack. Algol 60 did need a heap because own arrays could have variable size. That wasn't an accident since sec 5.2.2 shows an example of a variable size own array. I suspect they didn't realize the implications both of resizing non-stack data, and what happens in an upper level call if a lower level call resizes the array underneath it. It wasn't the only mistake like that. Alan Perlis told me that they intended call by name to be an elegantly phrased definition of call by reference, and it wasn't until Jensen's device that they realized what they had actually done. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-19 17:33 +0100 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vmj9hh$2bkbs$1@dont-email.me> |
| In reply to | #110580 |
On 18/01/2025 09:59, Niklas Holsti wrote: > On 2025-01-18 5:08, John Levine wrote: >> According to MitchAlsup1 <mitchalsup@aol.com>: >>>> Stacks are small because OS people make them small, not because of >>>> a valid technical reason that has ever been explained to me. >>>> "To avoid infinite recursion" is not a valid reason, IMHO. >>> >>> Algol 60 only had stack allocation for dynamically sized arrays, >>> so stacks had to be as big as the data are. >> >> Huh? Algol 60 routines could be mutually recursive so unless it was >> a leaf procedure or the outer block, everything not declared "own" >> went on the stack. > > > Mitch's point AIUI was that Algol 60 had no heap allocation (and no > explicit pointer types), so indeed all data were either on the stack or > statically allocated. > > I'm not an English native speaker, but it seems to me that Mitch should > have written "Algol 60 had only stack allocation" instead of "Algol 60 > only had stack allocation". > > The most-used Ada compiler, GNAT, uses a "secondary stack" to reduce the > need for heap. Dynamically sized local data are placed on the secondary > stack, and dynamically sized return values of functions are returned on > the secondary stack. So a function can return "by value" an array sized > 1..N, with N a function parameter, without needing the heap. > > Of course the programmer then has the problem of setting sufficient > sizes for /two/ stacks, the primary and the secondary. For > embedded-systems programs one usually avoids constructs that would need > a secondary stack. > A two-stack setup can be used in C too. (The C standards don't require a stack at all.) On the AVR microcontroller, it is not uncommon for C implementations to work with a dual stack, since it does not have any kind of "[SP + n]" or "[SP + r]" addressing modes, but it /does/ have an "[Y + n]" addressing mode using an index register. Two stacks are also pretty much required for FORTH. The use of a dual stack could also significantly improve the security of systems by separating call/return addresses from data.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-19 18:28 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <c0e894f1e2a4f551cb6d117cc00525ba@www.novabbs.org> |
| In reply to | #110584 |
On Sun, 19 Jan 2025 16:33:53 +0000, David Brown wrote: > > A two-stack setup can be used in C too. (The C standards don't require > a stack at all.) On the AVR microcontroller, it is not uncommon for C > implementations to work with a dual stack, since it does not have any > kind of "[SP + n]" or "[SP + r]" addressing modes, but it /does/ have an > "[Y + n]" addressing mode using an index register. > > Two stacks are also pretty much required for FORTH. > > The use of a dual stack could also significantly improve the security of > systems by separating call/return addresses from data. In My 66000 the code cannot read/write that other stack with LD and ST instructions. It can only be accessed by ENTER (stores) and EXIT (LDs). The mapping PTE is marked RWE = 000. So, while you can still overrun buffers, you cannot damage the call/ return stack or the preserved registers !!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-20 12:55 +0200 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <20250120125537.000075e0@yahoo.com> |
| In reply to | #110585 |
On Sun, 19 Jan 2025 18:28:40 +0000 mitchalsup@aol.com (MitchAlsup1) wrote: > > In My 66000 the code cannot read/write that other stack with LD and ST > instructions. It can only be accessed by ENTER (stores) and EXIT > (LDs). The mapping PTE is marked RWE = 000. > > So, while you can still overrun buffers, you cannot damage the call/ > return stack or the preserved registers !! Not that I am a specialist in GC, but according to my understanding the most common and the best performing variants of GC can not work without read access to preserved registers. Compacting collector seems to need write access as well. As to return addresses, I would think that read access to stack of return addresses is necessary for exception handling.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-20 11:12 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vmlb3k$1314j$1@paganini.bofh.team> |
| In reply to | #110589 |
Michael S <already5chosen@yahoo.com> wrote:
> On Sun, 19 Jan 2025 18:28:40 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:
>
>>
>> In My 66000 the code cannot read/write that other stack with LD and ST
>> instructions. It can only be accessed by ENTER (stores) and EXIT
>> (LDs). The mapping PTE is marked RWE = 000.
>>
>> So, while you can still overrun buffers, you cannot damage the call/
>> return stack or the preserved registers !!
>
> Not that I am a specialist in GC, but according to my understanding
> the most common and the best performing variants of GC can not work
> without read access to preserved registers. Compacting collector seems
> to need write access as well.
> As to return addresses, I would think that read access to stack of
> return addresses is necessary for exception handling.
_Correctness_ of GC depends on ability to see preserved registers
and return address: return address may be the only live reference
to some function and similarly for preserved registers. On could
try to work around lack of access using separate software-managed
stack duplicating data from "hardware" stack, but that is ugly
and is likely to kill any performance advantage from hardware
features.
BTW, the same holds for debuggers and exception handling. Those
clearly need some way to go around hardware limitations.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-20 22:05 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <43e21bd0bddea1733cd672c07a6319d4@www.novabbs.org> |
| In reply to | #110590 |
On Mon, 20 Jan 2025 11:12:54 +0000, Waldek Hebisch wrote:
> Michael S <already5chosen@yahoo.com> wrote:
>> On Sun, 19 Jan 2025 18:28:40 +0000
>> mitchalsup@aol.com (MitchAlsup1) wrote:
>>
>>>
>>> In My 66000 the code cannot read/write that other stack with LD and ST
>>> instructions. It can only be accessed by ENTER (stores) and EXIT
>>> (LDs). The mapping PTE is marked RWE = 000.
>>>
>>> So, while you can still overrun buffers, you cannot damage the call/
>>> return stack or the preserved registers !!
>>
>> Not that I am a specialist in GC, but according to my understanding
>> the most common and the best performing variants of GC can not work
>> without read access to preserved registers. Compacting collector seems
>> to need write access as well.
>> As to return addresses, I would think that read access to stack of
>> return addresses is necessary for exception handling.
>
> _Correctness_ of GC depends on ability to see preserved registers
> and return address: return address may be the only live reference
> to some function and similarly for preserved registers. On could
> try to work around lack of access using separate software-managed
> stack duplicating data from "hardware" stack, but that is ugly
> and is likely to kill any performance advantage from hardware
> features.
>
> BTW, the same holds for debuggers and exception handling. Those
> clearly need some way to go around hardware limitations.
Yes, there is a way to do all those things, but I am not in a position
to discuss due to USPTO rules.
It is like there is a privilege level between application and GuestOS.
{{I spent all afternoon trying to think of a name for this privilege
above application "non-privileged" and below "privileged". Maybe
meso-privileged ?!?
I/O works similarly--in that to the application a page may be marked
RWE=001 (execute only) but the swap disk is allowed to read or write
those pages.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-21 01:25 +0200 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <20250121012519.00006d31@yahoo.com> |
| In reply to | #110592 |
On Mon, 20 Jan 2025 22:05:10 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:
> On Mon, 20 Jan 2025 11:12:54 +0000, Waldek Hebisch wrote:
>
> > Michael S <already5chosen@yahoo.com> wrote:
> >> On Sun, 19 Jan 2025 18:28:40 +0000
> >> mitchalsup@aol.com (MitchAlsup1) wrote:
> >>
> >>>
> >>> In My 66000 the code cannot read/write that other stack with LD
> >>> and ST instructions. It can only be accessed by ENTER (stores)
> >>> and EXIT (LDs). The mapping PTE is marked RWE = 000.
> >>>
> >>> So, while you can still overrun buffers, you cannot damage the
> >>> call/ return stack or the preserved registers !!
> >>
> >> Not that I am a specialist in GC, but according to my understanding
> >> the most common and the best performing variants of GC can not work
> >> without read access to preserved registers. Compacting collector
> >> seems to need write access as well.
> >> As to return addresses, I would think that read access to stack of
> >> return addresses is necessary for exception handling.
> >
> > _Correctness_ of GC depends on ability to see preserved registers
> > and return address: return address may be the only live reference
> > to some function and similarly for preserved registers. On could
> > try to work around lack of access using separate software-managed
> > stack duplicating data from "hardware" stack, but that is ugly
> > and is likely to kill any performance advantage from hardware
> > features.
> >
> > BTW, the same holds for debuggers and exception handling. Those
> > clearly need some way to go around hardware limitations.
>
> Yes, there is a way to do all those things, but I am not in a position
> to discuss due to USPTO rules.
>
> It is like there is a privilege level between application and GuestOS.
> {{I spent all afternoon trying to think of a name for this privilege
> above application "non-privileged" and below "privileged". Maybe
> meso-privileged ?!?
>
Call it 'user'. Then rename the level that you now call 'application'
to 'sandbox'.
> I/O works similarly--in that to the application a page may be marked
> RWE=001 (execute only) but the swap disk is allowed to read or write
> those pages.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-21 00:17 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <d9086bcc761ea79f8eebe5e4b0cb6018@www.novabbs.org> |
| In reply to | #110593 |
On Mon, 20 Jan 2025 23:25:19 +0000, Michael S wrote:
> On Mon, 20 Jan 2025 22:05:10 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:
>
>> On Mon, 20 Jan 2025 11:12:54 +0000, Waldek Hebisch wrote:
>>
>>> Michael S <already5chosen@yahoo.com> wrote:
>>>> On Sun, 19 Jan 2025 18:28:40 +0000
>>>> mitchalsup@aol.com (MitchAlsup1) wrote:
>>>>
>>>>>
>>>>> In My 66000 the code cannot read/write that other stack with LD
>>>>> and ST instructions. It can only be accessed by ENTER (stores)
>>>>> and EXIT (LDs). The mapping PTE is marked RWE = 000.
>>>>>
>>>>> So, while you can still overrun buffers, you cannot damage the
>>>>> call/ return stack or the preserved registers !!
>>>>
>>>> Not that I am a specialist in GC, but according to my understanding
>>>> the most common and the best performing variants of GC can not work
>>>> without read access to preserved registers. Compacting collector
>>>> seems to need write access as well.
>>>> As to return addresses, I would think that read access to stack of
>>>> return addresses is necessary for exception handling.
>>>
>>> _Correctness_ of GC depends on ability to see preserved registers
>>> and return address: return address may be the only live reference
>>> to some function and similarly for preserved registers. On could
>>> try to work around lack of access using separate software-managed
>>> stack duplicating data from "hardware" stack, but that is ugly
>>> and is likely to kill any performance advantage from hardware
>>> features.
>>>
>>> BTW, the same holds for debuggers and exception handling. Those
>>> clearly need some way to go around hardware limitations.
>>
>> Yes, there is a way to do all those things, but I am not in a position
>> to discuss due to USPTO rules.
>>
>> It is like there is a privilege level between application and GuestOS.
>> {{I spent all afternoon trying to think of a name for this privilege
>> above application "non-privileged" and below "privileged". Maybe
>> meso-privileged ?!?
>>
>
> Call it 'user'. Then rename the level that you now call 'application'
> to 'sandbox'.
Realistically--there are 3 levels in each privilege layer::
least) sandbox--for Jitted code
medium) {user, JIT, Dynamic library, ...}
higher) {debug, GC, Exception, interrupt, Dynamic loader, device DMA,
..}
{{none of which need access to other-than-user VAS, or other-than-user
privileges}}
All sharing a single address space, and a software stack of supervision,
interrupt table, file-ids, socket-ids,...
The higher level of privilege allows this level to disobey the
permissions
in the PTE (possibly under a flag from ROOT).
So, while sandbox is a fine name for the least privileged running
environment, we are still needing a for the medium level. It is almost
like the higher level is a good portion of GuestOS kernel--those parts
requiring no privilege in any normal sense.
>> I/O works similarly--in that to the application a page may be marked
>> RWE=001 (execute only) but the swap disk is allowed to read or write
>> those pages.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-21 06:21 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vmnedg$3rp5f$1@dont-email.me> |
| In reply to | #110592 |
MitchAlsup1 <mitchalsup@aol.com> schrieb:
> It is like there is a privilege level between application and GuestOS.
> {{I spent all afternoon trying to think of a name for this privilege
> above application "non-privileged" and below "privileged". Maybe
> meso-privileged ?!?
Authorized? Or a numbering system for different privilege levels,
like it was used for rings?
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2025-01-21 10:36 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <0001HW.2D3FB01400BE82A630EEF538F@news.individual.net> |
| In reply to | #110592 |
On 20 Jan 2025, MitchAlsup1 wrote
(in article<43e21bd0bddea1733cd672c07a6319d4@www.novabbs.org>):
> It is like there is a privilege level between application and GuestOS.
> {{I spent all afternoon trying to think of a name for this privilege
> above application "non-privileged" and below "privileged". Maybe
> meso-privileged ?!?
Entitled? 8-)
--
Bill Findlay
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-21 17:49 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <ed907a4ed6a3554913d158c54a4d7eec@www.novabbs.org> |
| In reply to | #110596 |
On Tue, 21 Jan 2025 10:36:04 +0000, Bill Findlay wrote:
> On 20 Jan 2025, MitchAlsup1 wrote
> (in article<43e21bd0bddea1733cd672c07a6319d4@www.novabbs.org>):
>
>> It is like there is a privilege level between application and GuestOS.
>> {{I spent all afternoon trying to think of a name for this privilege
>> above application "non-privileged" and below "privileged". Maybe
>> meso-privileged ?!?
>
> Entitled? 8-)
Not bad, not bad at all ...
[toc] | [prev] | [next] | [standalone]
Page 15 of 23 — ← Prev page 1 … 13 14 [15] 16 17 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web