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 18 of 23 — ← Prev page 1 … 16 17 [18] 19 20 … 23 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-06 20:49 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <4605d2464e8cd7dbe2aa76ef19129ec6@www.novabbs.org> |
| In reply to | #110758 |
On Thu, 6 Feb 2025 18:51:12 +0000, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: ----------------------------------- >> >> Currently, PTE uses a 3-bit access control field, and PTE has >> 2-bits spare. So making access control larger is easy. >> >>> The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table >>> is in the MMU. >> >> How does 16×12 get to the MMU (or I/O MMU) ?? in such a way that super >> cannot see things Hyper can see and the same with secure. So, somewhere >> in the various control blocks I need to find space without changing >> the overall use pattern of the control blocks and tables. Which is >> why I alluded to 4×16×3 each interpretation of the 4-bit access control >> is stored it its own natural place. It also means each layer can apply >> its own interpretation (mapping). > > Its just an SRAM loaded by the boot ROM before the Hypervisor boots. > The super-secure version of boot ROM loads a table with values > (Sandbox, User, Kernel, Hypervisor): > > Snd Usr Krn Hyp > na na na R > na na na RE > na na na RW > na na na REW > na na R na > na na RE na > na na RW na > na na REW na > na R R na > na RE RE na > .... > REW REW REW na > > which grants mode 0 (Hyp) no direct RW access to any memory outside > itself. > Boot ROM sets an optional table lock so even hypervisor cannot later > grant itself access permission to less priv memory by changing the > table. > >>> The core's 2-bit mode selects-muxes one of the 3-bit allowed access >>> fields from the indexed 12-bits to extract the 3 R-E-W bits. >> >> That much is straightforward. >> >>> The 2-bit mode comes from the LD/ST uOp, which was set to the mode >>> active when the instruction was decoded (so it can pipeline mode >>> changes). >> >> Yes, core-state index follows the memref down the pipe. >> Core-state index is written into MMI/O/device control block for the >> DMA portion of a command, other CD indexes are associated with I/O >> page faults and device errors. > > Not sure how this would work with device IO and DMA. > Say a secure kernel that owns a disk drive with secrets that even the HV > is not authorized to see (so HV operators don't need Top Secret > clearance). In this case, HV needs to know its limitations and not access the device nor the secure memory. Probably by taking the memory out of the pool it "does normal stuff with" and take the device out of its list of accessible devices (at least for a while). > The Hypervisor has to pass to a hardware device DMA access to a memory > frame that it has no access to itself. How does one block the HV from > setting the IOMMU to DMA the device's secrets into its own memory? I am thinking more like SR-IOV where HV loans a virtual device to a Guest OS, and Guest OS performs the I/O request, HV and SM are only there to deal with HV page faults and device errors. If a HV page fault occurs (which it will) a pretty secure corner of HV will construct a PTE mapping that/those page[s] only to page the missing page into memory so I/O can proceed. HV will then have to dismantle said mapping after the page arrives to restart device DMA. > Hmmm... something like: once a secure HV passes a physical frame address > to a secure kernel then it cannot take it back, it can only ask that > kernel for it back. Which means that the HV looses control of any > core or IOMMU PTE's that map that frame until it is handed back. > That would seem to imply that once an HV gives memory to a secure > guest kernel that it can only page that guest with its permission. > Hmmm... Yes, exactly. No normal access to the page, only swap access is allowed--although this can be alleviated by not paging secure memory::then HV just knows nothing about that/those pages until the process terminates where it can put the pages back in the normal pool after cleaning them out.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-02-05 21:31 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <tMQoP.1439755$2xE6.1001191@fx18.iad> |
| In reply to | #110704 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Mon, 3 Feb 2025 22:47:24 +0000, Scott Lurndal wrote: > > >User is the privilege level where sandbox does not apply but >also there is no ability to over-access things protected by >PTE.RWE. > >Application is a privilege level where PTE.RWE can sometimes >be usurped--such as DMA from a device needing to write into >a execute only page. > For most modern server CPUs (Intel/AMD/ARM) that is the responsibility of the IOMMU, not the processor/core/thread. >Where does memmove() come from is not the library ?? Some applications roll their own. In higher level languages, such as C++, explicit calls to memmove are rare to non-existent (the standard C++ library and compiler handle data movement). > >Libraries have a SW-kind of trust even if they are >devoid of HW kinds of trust (PTE.RWE overrides). Libraries are easy to usurp in many systems (e.g. with LD_PRELOAD); precautions are in place to prevent such interpositions for applications with security constraints (e.g. installed with enhance capabilities or with UID==0). > >But these levels are just talking point at this point. > >> The hypervisor is optional, as would be a library. > >It cannot be a library of process !! Why not? See either Burroughs or HP-3000 for example of libraries as first-class objects with independent security contexts. >It is not a library of GuestOS ! >it is certainly not a library of Secure Monitor !! Why should such code not be able to leverage all the advantages of libraries, given suitable security controls? > >> >> The Burroughs Large systems and HP-3000 segmented libraries >> were distinct entities with attributes. > >And could change (update/upgrade) the library while the process >was running !! Under certain well-defined conditions, yes. > >> Code in a library could be more privileged than the application >> when acting on behalf of the application, for example; but the >> application could not take advantage of the permissions assigned >> to the library it was linked with without using interfaces >> provided by the library. > >No disagreement.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2025-01-19 23:37 +0200 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <lv59kdF77fbU1@mid.individual.net> |
| In reply to | #110584 |
On 2025-01-19 18:33, David Brown wrote:
> On 18/01/2025 09:59, Niklas Holsti wrote:
[...]
>> 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.
Yes. Other C compilers use a single stack but use Y as a frame pointer
so they can use "[Y + n]" to access stack-frame locations.
The issue is more acute for 8051/MCS-51 systems where the call/return
stack is in the very small "internal" RAM, so C compilers often allocate
a larger "SW stack" for stack data in the larger "external" RAM. But
they do so only for potentially recursive or reentrant functions, and
instead use statically allocated space for the call-frames of other
functions (with smart whole-program analysis to share such space for
functions that can never be active at the same time).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-20 09:00 +0100 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vmkvrb$2v047$1@dont-email.me> |
| In reply to | #110587 |
On 19/01/2025 22:37, Niklas Holsti wrote: > On 2025-01-19 18:33, David Brown wrote: >> On 18/01/2025 09:59, Niklas Holsti wrote: > > [...] > > >>> 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. > > > Yes. Other C compilers use a single stack but use Y as a frame pointer > so they can use "[Y + n]" to access stack-frame locations. > gcc for the AVR does that. I assume that it would be a massive effort to introduce a secondary data stack to gcc, whereas the original AVR port of gcc was much simpler at the cost of inefficiencies (basically the 32 8-bit registers were paired up and viewed as 16 16-bit registers, making the AVR appear like 16-bit RISC processors already well supported, with peephole optimisations to reduce redundant operations after code generation). Other AVR compilers that were made from scratch, or from compilers that already had complicated stack setups (such as ones for the 8051 you mention below), were more likely to use a separate data stack. The efficiency advantages and disadvantages of these two arrangements are not clear-cut for the AVR - it depends a lot on the way the code is written. > The issue is more acute for 8051/MCS-51 systems where the call/return > stack is in the very small "internal" RAM, so C compilers often allocate > a larger "SW stack" for stack data in the larger "external" RAM. But > they do so only for potentially recursive or reentrant functions, and > instead use statically allocated space for the call-frames of other > functions (with smart whole-program analysis to share such space for > functions that can never be active at the same time). > Yes. This also applies to several other "brain-dead" 8-bit CISC architectures.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-01-27 17:26 -0800 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <86cyg73ezo.fsf@linuxsc.com> |
| In reply to | #110580 |
Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > 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". Yes. I have seen this situation described as a rule for "only" to be put as late in the sentence as still make sense. Putting on my editor hat, I would recommend revising the sentence more thoroughly, as for example, "Algol 60 had no way of allocating memory except by means local variables on the stack" (assuming that is the case; my memories of the rules of Algol may have undetected ECC errors).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-18 16:30 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <wGQiP.198500$ay1.119525@fx12.iad> |
| In reply to | #110578 |
John Levine <johnl@taugh.com> writes: >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. For some flavors of Algol _everything_ was on the stack. (e.g. B5500 and successors).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-18 17:40 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <796f33ccd1214dfe0460c634ff68ebac@www.novabbs.org> |
| In reply to | #110581 |
On Sat, 18 Jan 2025 16:30:20 +0000, Scott Lurndal wrote: > John Levine <johnl@taugh.com> writes: >>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. > > For some flavors of Algol _everything_ was on the stack. > (e.g. B5500 and successors). 1108 Algol had everything on the stack.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-16 20:46 +0200 |
| Subject | Re: Segments |
| Message-ID | <20250116204604.00000916@yahoo.com> |
| In reply to | #110547 |
On Thu, 16 Jan 2025 18:12:46 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > 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. > The part about passing, including dynamic allocation, is what in C called VM types. > 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. In user space it is just unfortunate tradition. Not in all languages, BTW. In Go, for example, default stack is 1 GB, which is still small, but not ridiculously small as 1 to 8 MB that are typical in C, C++, Rust and I suppose Fortran. However original point of discussion was kernel programming. In kernel there are pretty good reasons in place why default stack is very small. 8-32 KB, I think. May be on Apple few times bigger, I didn't check. The reason is that in many kernel contexts page fault not allowed, so you have to allocate physical memory rather than just reserve address space. > "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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-16 20:34 +0000 |
| Subject | Re: Segments |
| Message-ID | <vmbqh9$3vv9n$1@paganini.bofh.team> |
| In reply to | #110547 |
Thomas Koenig <tkoenig@netcologne.de> wrote:
> 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.
As explained in other post in C VLA means allocation, passing
is VMT.
>> 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.
On multiuser machine there is some point in it: you do not
want buggy student program to cause thrashing. In other
words you need stack limit that is some smallish fraction
of real memory. With virtual memory heap allocations bigger
than RAM work fine.
There is good reason for small kernel stacks: it is used to
handle interupts, including page faults, so must be real
memory. Since each thread needs its own kernel stack, bigger
stack would mean quite a lot of memory use.
In 32-bit era there was also valid reason for small user stacks.
Namely, one needs to pre-allocate address space for stack(s) and
with lots of threads there is not enough address space to give
sizeable stack to each thread.
IIUC popular current processors are still quite far from having
64-bit virtual address space, so there is still reason to limit
stack size, simply limit can be much bigger than on 32-bit
systems.
There is also another issue: stack allocations become invalid
when routine doing allocation returns. Which depending on
application may be unacceptable. So, reuse of code doing
stack allocation is tricky, while for heap allocation simple
reference count may be ehough to ensure that allocation is
freed when nobody uses given area. Consequently, there is
tendency to use heap allocation to allow more flexible use
patterns. With more use of heap allocation there is less
use of stack allocation and big stacks are considered
unnecessary.
>> 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.
Sure.
>> 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.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-16 21:02 +0000 |
| Subject | Re: Segments |
| Message-ID | <EteiP.189539$FOb4.34069@fx15.iad> |
| In reply to | #110554 |
antispam@fricas.org (Waldek Hebisch) writes: >Thomas Koenig <tkoenig@netcologne.de> wrote: >> Waldek Hebisch <antispam@fricas.org> schrieb: >IIUC popular current processors are still quite far from having >64-bit virtual address space, so there is still reason to limit >stack size, simply limit can be much bigger than on 32-bit >systems. The ARMv8/ARMv9 architecture supports up to 52 bits of VA space (and up to 52-bits of PA space). Most implementations typically provide 48/48; I know of one that does 52/52 and another that supports 48/52. Going larger would require more levels of translation table.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-16 22:16 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmbsvr$3lpar$1@dont-email.me> |
| In reply to | #110543 |
On 16/01/2025 17:46, Waldek Hebisch wrote: > 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. Sure. > 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. You don't allocate anything in a VLA without knowing the bounds and being sure it is appropriate to put on the stack. You don't allocate anything on the heap without knowing the bounds and being sure it is appropriate. There's no fundamental difference - it's just the cut-off point that is different. The stack on Linux is 10 MB by default, and 1 MB by default on Windows. That's a /lot/ if you are working with fairly small but non-constant sizes. So if you are working with a selection of short-lived medium-sized bits of data - say, parts of strings for some formatting work - putting them on the stack is safe and can be significantly faster than using the heap. Using VLAs (or the older but related technique, alloca) means you don't waste space. Maybe you are working with file paths, and want to support up to 4096 characters per path - but in reality most paths are less than 100 characters. With fixed size arrays, allocating 16 of these and initialising them will use up your entire level 1 cache - with VLAs, it will use only a tiny fraction. These things can make a big difference to code that aims to be fast. Fixed size arrays are certainly easier to analyse and are often a good choice, but VLA's definitely have their advantages in some situations, and they are perfectly safe and reliable if you use them appropriately and correctly. > > 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. > Other people might have bad uses of VLAs - it doesn't mean /you/ have to use them badly too! > 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. If a kernel stack is that small (or you are working on an embedded system with very small stacks), then clearly you have to take that into account. I've used them a couple of times in embedded systems with small stacks - obviously the size of the VLA was also small. (On such systems, heap allocations are very much unwelcome - though not quite as unwelcome as overflowing the stack :-) ) Far and away my most common use of VLAs is, however, not variable length at all. It's more like : const int no_of_whatsits = 20; const int size_of_whatsit = 4; uint8_t whatsits_data[no_of_whatsits * size_of_whatsit]; Technically in C, that is a VLA because the size expression is not a constant expression according to the rules of the language. But of course it is a size that is known at compile-time, and the compiler generates exactly the same code as if it was a constant expression. It is equally amenable to analysis and testing. (In C++, it is considered a normal array - C++ does not support VLAs, but is happy with code like that.) With C23, these const variables can now be constexpr, and the array will then be a normal array and not a VLA - without that making the slightest difference to the actual generated code. > >>> 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. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-16 21:40 +0000 |
| Subject | Re: Segments |
| Message-ID | <r1fiP.189541$FOb4.58758@fx15.iad> |
| In reply to | #110557 |
David Brown <david.brown@hesbynett.no> writes: >On 16/01/2025 17:46, Waldek Hebisch wrote: >You don't allocate anything in a VLA without knowing the bounds and >being sure it is appropriate to put on the stack. You don't allocate >anything on the heap without knowing the bounds and being sure it is >appropriate. There's no fundamental difference - it's just the cut-off >point that is different. > >The stack on Linux is 10 MB by default, and 1 MB by default on Windows. On all the linux systems I use, the stack limit defaults to 8192KB. That includes RHEL, Fedora, CentOS, Scientific Linux and Ubuntu. Now, that's for the primary thread stack, for which the OS manages the growth. For other threads in the process, the size varies based on the threads library in use and whether the application is compiled for 32-bit or 64-bit systems.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-17 10:20 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmd7db$3vqp0$1@dont-email.me> |
| In reply to | #110559 |
On 16/01/2025 22:40, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 16/01/2025 17:46, Waldek Hebisch wrote: > >> You don't allocate anything in a VLA without knowing the bounds and >> being sure it is appropriate to put on the stack. You don't allocate >> anything on the heap without knowing the bounds and being sure it is >> appropriate. There's no fundamental difference - it's just the cut-off >> point that is different. >> >> The stack on Linux is 10 MB by default, and 1 MB by default on Windows. > > On all the linux systems I use, the stack limit defaults to 8192KB. OK. The details don't matter much here. (Of course, if you are intending to put large objects on the stack, then the details /do/ matter, and you probably want to specify a minimum stack size explicitly.) > > That includes RHEL, Fedora, CentOS, Scientific Linux and Ubuntu. > > Now, that's for the primary thread stack, for which the OS > manages the growth. For other threads in the process, > the size varies based on the threads library in use > and whether the application is compiled for 32-bit or > 64-bit systems. >
[toc] | [prev] | [next] | [standalone]
| From | "Brian G. Lucas" <bagel99@gmail.com> |
|---|---|
| Date | 2025-01-17 10:08 -0500 |
| Subject | Re: Segments |
| Message-ID | <vmdrlv$38r9$1@dont-email.me> |
| In reply to | #110566 |
On 1/17/25 4:20 AM, David Brown wrote: > On 16/01/2025 22:40, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 16/01/2025 17:46, Waldek Hebisch wrote: >> >>> You don't allocate anything in a VLA without knowing the bounds and >>> being sure it is appropriate to put on the stack. You don't allocate >>> anything on the heap without knowing the bounds and being sure it is >>> appropriate. There's no fundamental difference - it's just the cut-off >>> point that is different. >>> >>> The stack on Linux is 10 MB by default, and 1 MB by default on Windows. >> >> On all the linux systems I use, the stack limit defaults to 8192KB. > On linux, one can call the routine setrlimit(RLIMIT_STACK, ...) to change the stack size. > OK. The details don't matter much here. (Of course, if you are intending to > put large objects on the stack, then the details /do/ matter, and you probably > want to specify a minimum stack size explicitly.) > >> >> That includes RHEL, Fedora, CentOS, Scientific Linux and Ubuntu. >> >> Now, that's for the primary thread stack, for which the OS >> manages the growth. For other threads in the process, >> the size varies based on the threads library in use >> and whether the application is compiled for 32-bit or >> 64-bit systems. >> >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-17 15:17 +0000 |
| Subject | Re: Segments |
| Message-ID | <dwuiP.160486$a6K9.142270@fx06.iad> |
| In reply to | #110569 |
"Brian G. Lucas" <bagel99@gmail.com> writes: >On 1/17/25 4:20 AM, David Brown wrote: >> On 16/01/2025 22:40, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 16/01/2025 17:46, Waldek Hebisch wrote: >>> >>>> You don't allocate anything in a VLA without knowing the bounds and >>>> being sure it is appropriate to put on the stack. You don't allocate >>>> anything on the heap without knowing the bounds and being sure it is >>>> appropriate. There's no fundamental difference - it's just the cut-off >>>> point that is different. >>>> >>>> The stack on Linux is 10 MB by default, and 1 MB by default on Windows. >>> >>> On all the linux systems I use, the stack limit defaults to 8192KB. >> >On linux, one can call the routine setrlimit(RLIMIT_STACK, ...) to change >the stack size. Yes, as a unix/linux kernel engineer, I've implemented that system call and the supporting kernel infrastructure in a version of unix a few decades ago. I'll point out that the implementation provides both HARD and SOFT limits for the stack (and all other resources), and the user can only affect the SOFT limit, and the user may not raise the SOFT limit above the HARD limit, unless running with the appropriate capabilities (e.g. UID == 0).
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2025-01-19 18:49 +0000 |
| Subject | Re: Segments |
| Message-ID | <memo.20250119184943.17588G@jgd.cix.co.uk> |
| In reply to | #110559 |
In article <r1fiP.189541$FOb4.58758@fx15.iad>, scott@slp53.sl.home (Scott Lurndal) wrote: > On all the linux systems I use, the stack limit defaults to 8192KB. > > That includes RHEL, Fedora, CentOS, Scientific Linux and Ubuntu. > > Now, that's for the primary thread stack, for which the OS > manages the growth. For other threads in the process, > the size varies based on the threads library in use > and whether the application is compiled for 32-bit or > 64-bit systems. The library I work on documents the required stack sizes for threads that enter it, and for the threads it creates. Just another of the details one has to take care of. We didn't think of it when the project was started, but that was forty years ago this year. John
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-01-17 02:22 +0000 |
| Subject | Re: Segments |
| Message-ID | <vmcets$5vp2$1@paganini.bofh.team> |
| In reply to | #110557 |
David Brown <david.brown@hesbynett.no> wrote:
> On 16/01/2025 17:46, Waldek Hebisch wrote:
>> 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.
>
> Sure.
>
>> 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.
>
> You don't allocate anything in a VLA without knowing the bounds and
> being sure it is appropriate to put on the stack. You don't allocate
> anything on the heap without knowing the bounds and being sure it is
> appropriate. There's no fundamental difference - it's just the cut-off
> point that is different.
Well, AFAICS VLA-s may get allocated on function entry. In such
case caller have to check for allocation size, which spreads
allocation related code between caller and called function.
In case of 'malloc' one can simply check return value. In fact,
in many programs simple wrapper that exits in case of allocation
failure is enough (if application can not do its work without
memory and there is no memory, then there is no point in continuing
execution).
> The stack on Linux is 10 MB by default, and 1 MB by default on Windows.
> That's a /lot/ if you are working with fairly small but non-constant
> sizes. So if you are working with a selection of short-lived
> medium-sized bits of data - say, parts of strings for some formatting
> work - putting them on the stack is safe and can be significantly faster
> than using the heap.
IME this is relatively rare case. For formatting frequently a single
result buffer (possibly expanded when needed) with other pieces of
data added there gave me good performance. Intermediate strings
appeared as return values of called functions. Without reoganizing
code this does not respect stack discipline. Once reorganized
I get best results without materializing intermediate strings.
> Using VLAs (or the older but related technique, alloca) means you don't
> waste space. Maybe you are working with file paths, and want to support
> up to 4096 characters per path - but in reality most paths are less than
> 100 characters. With fixed size arrays, allocating 16 of these and
> initialising them will use up your entire level 1 cache - with VLAs, it
> will use only a tiny fraction.
One case initialize only used part. Or simply used uninitialized
arrays (that is what I do normally). It rather hard to give
meaningful initialization in case where size of payload varies.
> These things can make a big difference
> to code that aims to be fast.
>
> Fixed size arrays are certainly easier to analyse and are often a good
> choice, but VLA's definitely have their advantages in some situations,
> and they are perfectly safe and reliable if you use them appropriately
> and correctly.
>
>>
>> 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.
>>
>
> Other people might have bad uses of VLAs - it doesn't mean /you/ have to
> use them badly too!
Well, for me typical cases is for work arrays where needed size
may vary widely. Using 'malloc' is simpler is such use given
small stack limit. With small stack limit VLA would be a
micro-optimization, not worth extra effort.
<snip>
> Far and away my most common use of VLAs is, however, not variable length
> at all. It's more like :
>
> const int no_of_whatsits = 20;
> const int size_of_whatsit = 4;
>
> uint8_t whatsits_data[no_of_whatsits * size_of_whatsit];
>
> Technically in C, that is a VLA because the size expression is not a
> constant expression according to the rules of the language. But of
> course it is a size that is known at compile-time, and the compiler
> generates exactly the same code as if it was a constant expression.
OK, that is useful case (but in spirt this is not VLA).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-16 19:52 -0800 |
| Subject | Re: Segments |
| Message-ID | <87r0526qqt.fsf@nosuchdomain.example.com> |
| In reply to | #110564 |
antispam@fricas.org (Waldek Hebisch) writes:
[...]
> Well, AFAICS VLA-s may get allocated on function entry.
[...]
That would rarely be possible for objects with automatic storage
duration (local variables). For example:
void func(void) {
do_this();
do_that();
int vla[rand() % 10 + 1];
}
Memory for `vla` can't be allocated until its size is known,
and it can't be known until the definition is reached. For most
automatically allocated objects, the lifetime begins when execution
reaches the `{` of the enclosing block; the lifetime of `vla`
begins at its definition.
Or did you have something else in mind?
(Should this part of the discussion migrate to comp.lang.c, or is it
still sufficiently relevant to computer architecture?)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-17 15:52 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmdqs0$32ji$1@dont-email.me> |
| In reply to | #110565 |
On 17/01/2025 04:52, Keith Thompson wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
> [...]
>> Well, AFAICS VLA-s may get allocated on function entry.
> [...]
>
> That would rarely be possible for objects with automatic storage
> duration (local variables). For example:
>
> void func(void) {
> do_this();
> do_that();
> int vla[rand() % 10 + 1];
> }
>
> Memory for `vla` can't be allocated until its size is known,
> and it can't be known until the definition is reached. For most
> automatically allocated objects, the lifetime begins when execution
> reaches the `{` of the enclosing block; the lifetime of `vla`
> begins at its definition.
>
> Or did you have something else in mind?
I'm guessing he was thinking of something like :
void func(int n) {
if (n < 1000) {
int vla[n];
do_stuff(vla);
} else {
int * p = malloc(n * sizeof(int));
do_stuff(p);
free(p);
}
}
Although the lifetime of vla[n] is limited to the block that is in that
one branch, the compiler could certainly handle the allocation with a
single stack-pointer change at the entry to the function. It is common
for optimised code to try to have just one stack frame allocation at
code entry, and a deallocation at exit, rather than re-arranging the
stack within blocks of code. But it is not common to do so when the
sizes are not known at compile time and the VLA (or alloca) is not on
all paths - precisely because the programmer might be doing such checks.
>
> (Should this part of the discussion migrate to comp.lang.c, or is it
> still sufficiently relevant to computer architecture?)
>
Some of the "arch" folks here have compared to other languages, which is
nice. But if regulars here think the thread branch has become too
bogged down in details of C, we can stop.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-17 15:30 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmdpi1$32g7$1@dont-email.me> |
| In reply to | #110564 |
On 17/01/2025 03:22, Waldek Hebisch wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 16/01/2025 17:46, Waldek Hebisch wrote: >>> 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. >> >> Sure. >> >>> 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. >> >> You don't allocate anything in a VLA without knowing the bounds and >> being sure it is appropriate to put on the stack. You don't allocate >> anything on the heap without knowing the bounds and being sure it is >> appropriate. There's no fundamental difference - it's just the cut-off >> point that is different. > > Well, AFAICS VLA-s may get allocated on function entry. It could be allocated as soon as the size is known, yes. > In such > case caller have to check for allocation size, which spreads > allocation related code between caller and called function. It is not about allocation sizes - it's about knowing the data you are dealing with, and sanitising unknown data. In the very rough example I gave of string formatting or manipulation, you might be getting the strings in from outside - command line parameters, database entries, wildcard directory searches, etc. You sanity check the data when it comes in - regardless of whether or not you plan to allocate memory (stack or heap) for copying them. Now you know that the sizes are reasonable, you can allocate VLAs (or use alloca, or use malloc) without extra worries. I am not suggesting you should have some kind of rule to check sizes just before every VLA declaration - I am suggesting that when you know the size is reasonable and safe, then using a VLA is reasonable and safe. > In case of 'malloc' one can simply check return value. Drivel. That's a myth that originated in the days of K&R C. It is certainly true that if malloc returns 0, your allocation has failed. There are a few - but only a very few - circumstances where that is something that can realistically happen in code that is doing its job properly. Typically that would be in resource-constrainted systems where you might have some unusual circumstances causing overload. But generally (and this means there will be exceptions), checking for null returns from malloc is : a) Never properly tested, and often results in leaked resources or other problems; b) Totally unrealistic in any real-world use of the code; c) Treated as though it is a divine duty that must always be done ritually and religiously; d) Treated as though it magically makes the code safe, correct and reliable. Hopefully you can see that these points are self-contradictory. If you try to call malloc with a size that is unreasonable for the circumstances, all kinds of bad things can happen /despite/ a non-null return value. What goes wrong can depend on many factors, including the OS, the malloc library, the size, the system setup, and what you do with the returned pointer. Simply /trying/ to run malloc with a bad size may, on some systems, lead to the OS trying to free up as much memory as it can in order to accommodate your request - whether malloc ends up returning null or not. Or maybe the request is done in with lazy allocations - you asked for 100 TB of memory and you got a pointer back, and things will only go wrong when you start using the virtual space. Remember, from the point of view of people using the computer, having the OS push lots of stuff out of memory is tantamount to a broken system. A program that has runaway memory usage causes great frustration, and often leads to users doing a hard reset. And all the time, the malloc() calls have returned a non-null value. So what does all that mean? It means you do /not/ blindly call malloc(), check for a null result, and think that's all good. It means you be sure you know what sizes you are asking for /before/ you call malloc - probably long before you get to the bit of code that actually calls malloc(). It means you look /before/ you leap - you don't "just go for it" and hope that you can figure out what went wrong from the debris left at the crash site. And if you are in doubt - maybe you are pushing the target system to the limits, or have a program that demands more memory than many systems might have - you check in advance to see if the memory will be easily available. Such checks will be OS specific, of course. (I'm sure some people will now be thinking "you should have used ulimit", or "don't enable swap", or "that's the fault of over-commit". That would all be missing the point. You can of course use such tools as a way of making sure your sizes are reasonable - it's up to the developer to decide how to handle such checks and controls. But checking the return of malloc is so far from being sufficient that it is basically useless in most circumstances.) It is /exactly/ the same for VLAs (or alloca). The limits for what sizes are "reasonable" will, of course, be smaller for stack allocations than for heap allocations. But that's all target dependent anyway - for the systems I typically work with, the limit for "reasonable" heap allocations is orders of magnitude smaller than "reasonable" stack allocations on desktops. > In fact, > in many programs simple wrapper that exits in case of allocation > failure is enough (if application can not do its work without > memory and there is no memory, then there is no point in continuing > execution). Have you ever seen that happening in real life? Have you ever even known such code to be properly tested? Don't get me wrong - a wrapper like this can be a good idea. But it's like an electrical fuse - it's a last resort, and only triggers if something has gone badly wrong. When you see a great music system with a 10 kW amplifier, you check if your house electrical system can handle that /before/ you buy it. You don't buy it, plug it in and rely on the fusebox to keep your house from burning down - even though you want the fuse there as a failsafe. For the most part, if malloc ever returns 0, the problem lies before malloc is called. (Sorry for the rant - "my code is safe because I check the result of malloc" is one of these misconceptions that really annoy me.)
[toc] | [prev] | [next] | [standalone]
Page 18 of 23 — ← Prev page 1 … 16 17 [18] 19 20 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web