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 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-01-27 17:18 -0800 |
| Subject | Re: Segments |
| Message-ID | <86h65j3fdz.fsf@linuxsc.com> |
| In reply to | #110619 |
Michael S <already5chosen@yahoo.com> writes: > On Thu, 23 Jan 2025 08:14:52 GMT > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> Not every system capable of running C supports signals. I would >>> think that those that support signals are not even majority. >> >> "man raise" tells me that raise() is C99. "man signal" tells me >> that signal() is C99. > > I would guess that it belongs to the part of the standard that > defines requirements for hosted implementation. [...] Right. Almost all of the standard library is not required for freestanding implementations, and <signal.h> is not among the required set.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-23 14:02 -0800 |
| Subject | Re: Segments |
| Message-ID | <87zfjhmbnm.fsf@nosuchdomain.example.com> |
| In reply to | #110617 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Michael S <already5chosen@yahoo.com> writes:
>>Not every system capable of running C supports signals. I would
>>think that those that support signals are not even majority.
>
> "man raise" tells me that raise() is C99. "man signal" tells me that
> signal() is C99.
[...]
To be clear, raise() and signal() are specified in all editions of
the C standard going back to 1989. The man page probably refers
to C99 because that was the current edition when it was written.
Like all library functions, raise() and signal() are required only for
hosted implementations, not freestanding implementations. (Almost all;
C23 adds a requirement for freestanding implementation to support
most string functions, excluding functions that allocate memory.)
--
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 | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-01-23 11:50 -0500 |
| Subject | Re: Segments |
| Message-ID | <3ms4pjp5ckpk79kr3s4dl9bc9lbtuf9v7l@4ax.com> |
| In reply to | #110609 |
On Wed, 22 Jan 2025 22:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >mitchalsup@aol.com (MitchAlsup1) writes: >>On Wed, 22 Jan 2025 20:00:30 +0000, Scott Lurndal wrote: >> >>> mitchalsup@aol.com (MitchAlsup1) writes: >>>>On Wed, 22 Jan 2025 14:58:04 +0000, Scott Lurndal wrote: >>>>>(MitchAlsup1) >>> >>>>>>On a Linux machine, you can find the last envp[*] entry and subtract >>>>>>SP from it. >>>>> >>>>> I would discourage programmers from relying on that for any reason >>>>> whatsoever. The aux vectors are pushed before the envp entries. >>>> >>>>This brings into question what is "on" the stack ?? to be included >>>>in the measurement of stack size. >>>> >>>>Only user data ?? >>>>Data that is present when control arrives ?? >>>>Could <equivalent> CRT0 store SP at arrival ?? >>>> >>>>I think we have an illdefined measurement !! >>> >>> Everything between the base address of the stack >>> and the limit address of the stack. The kernel exec(2) >>> family system calls will allocate the initial >>> stack region (with guard pages to handle extension) >>> and populate it with the AUX, ENVP and ARG vectors >>> before invoking the CRT in usermode. >> >>So, how does one find the base (highest address on the stack) ?? >>in a way that works on every system capable of running C-code ?? > >It's not something that a programmer generally would need, or want to >do. https://plover.com/~mjd/misc/hbaker-archive/CheneyMTA.html or any problem requiring potentially unbounded recursion. >However, if the OS they're using has a guard page to prevent >stack underflow, one could write a subroutine which accesses >page-aligned addresses towards the beginning of the stack >region (anti the direction of growth) until a >SIGSEGV is delivered.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-23 17:18 +0000 |
| Subject | Re: Segments |
| Message-ID | <IRukP.83391$G93a.4966@fx05.iad> |
| In reply to | #110625 |
George Neuner <gneuner2@comcast.net> writes: >On Wed, 22 Jan 2025 22:44:45 GMT, scott@slp53.sl.home (Scott Lurndal) >wrote: > >>>So, how does one find the base (highest address on the stack) ?? >>>in a way that works on every system capable of running C-code ?? >> >>It's not something that a programmer generally would need, or want to >>do. Note the word "generally". > >https://plover.com/~mjd/misc/hbaker-archive/CheneyMTA.html > >or any problem requiring potentially unbounded recursion. For which the standard unix resource limits are usually sufficient. Henry's 'scheme' is not typical of the vast majority of programs. Even Henry notes that the macro for his scheme (pun intended) is machine dependent.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-01-22 02:54 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <vmpml9$1inh$1@gal.iecc.com> |
| In reply to | #110598 |
According to George Neuner <gneuner2@comcast.net>: >Not standard compliant for sure, but you certainly can approximate >stack use in C: just store (as byte*) the address of a local in your >top level function, and check the (absolute value of) the difference >to the address of a local in the current function. Ugh, but yes that would work with the usual stack structure, >The bigger problem is knowing how much stack is available to use - >there may be no way (or no easy way) to find the actual size ... or >the limit if the stack expands ... and circumstances beyond the >program may have limited it to be smaller than the program requested. There's often no way to tell since it may depend on things like running out of swap space which depends on how much memory other programs are using. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-22 15:25 +0200 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <20250122152543.00000682@yahoo.com> |
| In reply to | #110600 |
On Wed, 22 Jan 2025 02:54:33 -0000 (UTC) John Levine <johnl@taugh.com> wrote: > According to George Neuner <gneuner2@comcast.net>: > >Not standard compliant for sure, but you certainly can approximate > >stack use in C: just store (as byte*) the address of a local in your > >top level function, and check the (absolute value of) the difference > >to the address of a local in the current function. > > Ugh, but yes that would work with the usual stack structure, > > >The bigger problem is knowing how much stack is available to use - > >there may be no way (or no easy way) to find the actual size ... or > >the limit if the stack expands ... and circumstances beyond the > >program may have limited it to be smaller than the program > >requested. > > There's often no way to tell since it may depend on things like > running out of swap space which depends on how much memory other > programs are using. > At least you can know the size of reserved VA space which is both an upper bound of the limit and in 99% of the cases an actual limit. On Windows: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadstacklimits I suppose that similar functions are available on other OSes as well.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-22 15:01 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <iL7kP.72726$oCrf.34929@fx33.iad> |
| In reply to | #110602 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 22 Jan 2025 02:54:33 -0000 (UTC) >John Levine <johnl@taugh.com> wrote: > >> According to George Neuner <gneuner2@comcast.net>: >> >Not standard compliant for sure, but you certainly can approximate >> >stack use in C: just store (as byte*) the address of a local in your >> >top level function, and check the (absolute value of) the difference >> >to the address of a local in the current function. >> >> Ugh, but yes that would work with the usual stack structure, >> >> >The bigger problem is knowing how much stack is available to use - >> >there may be no way (or no easy way) to find the actual size ... or >> >the limit if the stack expands ... and circumstances beyond the >> >program may have limited it to be smaller than the program >> >requested. >> >> There's often no way to tell since it may depend on things like >> running out of swap space which depends on how much memory other >> programs are using. >> > >At least you can know the size of reserved VA space which is both an >upper bound of the limit and in 99% of the cases an actual limit. > >On Windows: >https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadstacklimits > >I suppose that similar functions are available on other OSes as well. > https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_attr_getstack.html There is no equivlent function for the main process stack, other than the 'getrlimit(RLIMIT_STACK...' functionality.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-23 01:45 +0200 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <20250123014516.00006d99@yahoo.com> |
| In reply to | #110604 |
On Wed, 22 Jan 2025 15:01:34 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Wed, 22 Jan 2025 02:54:33 -0000 (UTC) > >John Levine <johnl@taugh.com> wrote: > > > >> According to George Neuner <gneuner2@comcast.net>: > >> >Not standard compliant for sure, but you certainly can approximate > >> >stack use in C: just store (as byte*) the address of a local in > >> >your top level function, and check the (absolute value of) the > >> >difference to the address of a local in the current function. > >> > >> Ugh, but yes that would work with the usual stack structure, > >> > >> >The bigger problem is knowing how much stack is available to use - > >> >there may be no way (or no easy way) to find the actual size ... > >> >or the limit if the stack expands ... and circumstances beyond the > >> >program may have limited it to be smaller than the program > >> >requested. > >> > >> There's often no way to tell since it may depend on things like > >> running out of swap space which depends on how much memory other > >> programs are using. > >> > > > >At least you can know the size of reserved VA space which is both an > >upper bound of the limit and in 99% of the cases an actual limit. > > > >On Windows: > >https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadstacklimits > > > >I suppose that similar functions are available on other OSes as well. > > > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_attr_getstack.html > > There is no equivlent function for the main process stack, Do you mean "there is no equivlent *POSIX* function", right? But I sincerily hope that most Unix-like systems provide such functionality in system-specific manner. Because it looks usable. > other than > the 'getrlimit(RLIMIT_STACK...' functionality.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-23 01:07 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <WCgkP.917153$DPl.591279@fx13.iad> |
| In reply to | #110611 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 22 Jan 2025 15:01:34 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >On Wed, 22 Jan 2025 02:54:33 -0000 (UTC) >> >John Levine <johnl@taugh.com> wrote: >> > >> >> According to George Neuner <gneuner2@comcast.net>: >> >> >Not standard compliant for sure, but you certainly can approximate >> >> >stack use in C: just store (as byte*) the address of a local in >> >> >your top level function, and check the (absolute value of) the >> >> >difference to the address of a local in the current function. >> >> >> >> Ugh, but yes that would work with the usual stack structure, >> >> >> >> >The bigger problem is knowing how much stack is available to use - >> >> >there may be no way (or no easy way) to find the actual size ... >> >> >or the limit if the stack expands ... and circumstances beyond the >> >> >program may have limited it to be smaller than the program >> >> >requested. >> >> >> >> There's often no way to tell since it may depend on things like >> >> running out of swap space which depends on how much memory other >> >> programs are using. >> >> >> > >> >At least you can know the size of reserved VA space which is both an >> >upper bound of the limit and in 99% of the cases an actual limit. >> > >> >On Windows: >> >https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadstacklimits >> > >> >I suppose that similar functions are available on other OSes as well. >> > >> >> https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_attr_getstack.html >> >> There is no equivlent function for the main process stack, > > >Do you mean "there is no equivlent *POSIX* function", right? >But I sincerily hope that most Unix-like systems provide such >functionality in system-specific manner. Because it looks usable. What would an application (portable or otherwise) use the process stack base address for? The data is available through the /proc/ filesystem. $ cat /proc/$$/maps | grep "[stack]" 7fff77b52000-7fff77b73000 rw-p 00000000 00:00 0 [stack]
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-23 02:47 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <214ed8b743ce4dc75cfec22daa9b8880@www.novabbs.org> |
| In reply to | #110613 |
On Thu, 23 Jan 2025 1:07:02 +0000, Scott Lurndal wrote: > Michael S <already5chosen@yahoo.com> writes: >>On Wed, 22 Jan 2025 15:01:34 GMT >>scott@slp53.sl.home (Scott Lurndal) wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >On Wed, 22 Jan 2025 02:54:33 -0000 (UTC) >>> >John Levine <johnl@taugh.com> wrote: >>> > >>> >> According to George Neuner <gneuner2@comcast.net>: >>> >> >Not standard compliant for sure, but you certainly can approximate >>> >> >stack use in C: just store (as byte*) the address of a local in >>> >> >your top level function, and check the (absolute value of) the >>> >> >difference to the address of a local in the current function. >>> >> >>> >> Ugh, but yes that would work with the usual stack structure, >>> >> >>> >> >The bigger problem is knowing how much stack is available to use - >>> >> >there may be no way (or no easy way) to find the actual size ... >>> >> >or the limit if the stack expands ... and circumstances beyond the >>> >> >program may have limited it to be smaller than the program >>> >> >requested. >>> >> >>> >> There's often no way to tell since it may depend on things like >>> >> running out of swap space which depends on how much memory other >>> >> programs are using. >>> >> >>> > >>> >At least you can know the size of reserved VA space which is both an >>> >upper bound of the limit and in 99% of the cases an actual limit. >>> > >>> >On Windows: >>> >https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadstacklimits >>> > >>> >I suppose that similar functions are available on other OSes as well. >>> > >>> >>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_attr_getstack.html >>> >>> There is no equivlent function for the main process stack, >> >> >>Do you mean "there is no equivlent *POSIX* function", right? >>But I sincerily hope that most Unix-like systems provide such >>functionality in system-specific manner. Because it looks usable. > > What would an application (portable or otherwise) use the process > stack base address for? As a place to put TLS (or &TLS) on register-starved architectures.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-23 14:00 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <dYrkP.1188702$Uup4.676171@fx10.iad> |
| In reply to | #110615 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Thu, 23 Jan 2025 1:07:02 +0000, Scott Lurndal wrote: > >>>Do you mean "there is no equivlent *POSIX* function", right? >>>But I sincerily hope that most Unix-like systems provide such >>>functionality in system-specific manner. Because it looks usable. >> >> What would an application (portable or otherwise) use the process >> stack base address for? > >As a place to put TLS (or &TLS) on register-starved architectures. That's a function of the implementation, not the programmer.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-23 17:49 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <e619e4546c173446ac5d1d0e60ff42d3@www.novabbs.org> |
| In reply to | #110621 |
On Thu, 23 Jan 2025 14:00:41 +0000, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Thu, 23 Jan 2025 1:07:02 +0000, Scott Lurndal wrote:
>>
>
>>>>Do you mean "there is no equivlent *POSIX* function", right?
>>>>But I sincerily hope that most Unix-like systems provide such
>>>>functionality in system-specific manner. Because it looks usable.
>>>
>>> What would an application (portable or otherwise) use the process
>>> stack base address for?
>>
>>As a place to put TLS (or &TLS) on register-starved architectures.
>
> That's a function of the implementation, not the programmer.
The compiler needs to know a way of getting TLS in a register starved
ISA. {This is why segmentation bled over into x86-64}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-23 19:45 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <b%wkP.1382334$DYF8.209106@fx14.iad> |
| In reply to | #110627 |
mitchalsup@aol.com (MitchAlsup1) writes:
>On Thu, 23 Jan 2025 14:00:41 +0000, Scott Lurndal wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>On Thu, 23 Jan 2025 1:07:02 +0000, Scott Lurndal wrote:
>>>
>>
>>>>>Do you mean "there is no equivlent *POSIX* function", right?
>>>>>But I sincerily hope that most Unix-like systems provide such
>>>>>functionality in system-specific manner. Because it looks usable.
>>>>
>>>> What would an application (portable or otherwise) use the process
>>>> stack base address for?
>>>
>>>As a place to put TLS (or &TLS) on register-starved architectures.
>>
>> That's a function of the implementation, not the programmer.
>
>The compiler needs to know a way of getting TLS in a register starved
>ISA.
The compiler is part of the "implementation". Very few programmers
work on compilers for register starved architectures (of which few
are still in common use). And very few of them care about the
stack base address.
> {This is why segmentation bled over into x86-64}
Well, it gave them a couple scratch registers for use as
kernel and user-mode thread specific region pointers (fs, gs).
However, I doubt that played a huge factor in AMD keeping what's
left of 80286 segments, they could have just re-used the
encodings for FS and GS for new GPRs and reserved them for
TLS in ABI's for implementations that support threads.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-23 20:04 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <d330db88336882fec5fa33fa9fdd43a2@www.novabbs.org> |
| In reply to | #110629 |
On Thu, 23 Jan 2025 19:45:11 +0000, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Thu, 23 Jan 2025 14:00:41 +0000, Scott Lurndal wrote:
>>
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>On Thu, 23 Jan 2025 1:07:02 +0000, Scott Lurndal wrote:
>>>>
>>>
>>>>>>Do you mean "there is no equivlent *POSIX* function", right?
>>>>>>But I sincerily hope that most Unix-like systems provide such
>>>>>>functionality in system-specific manner. Because it looks usable.
>>>>>
>>>>> What would an application (portable or otherwise) use the process
>>>>> stack base address for?
>>>>
>>>>As a place to put TLS (or &TLS) on register-starved architectures.
>>>
>>> That's a function of the implementation, not the programmer.
>>
>>The compiler needs to know a way of getting TLS in a register starved
>>ISA.
>
> The compiler is part of the "implementation". Very few programmers
> work on compilers for register starved architectures (of which few
> are still in common use). And very few of them care about the
> stack base address.
>
>
>> {This is why segmentation bled over into x86-64}
>
> Well, it gave them a couple scratch registers for use as
> kernel and user-mode thread specific region pointers (fs, gs).
>
> However, I doubt that played a huge factor in AMD keeping what's
> left of 80286 segments, they could have just re-used the
> encodings for FS and GS for new GPRs and reserved them for
> TLS in ABI's for implementations that support threads.
We had long conversations about what to leave in and what to take
(back) out.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-01-24 08:11 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <2025Jan24.091134@mips.complang.tuwien.ac.at> |
| In reply to | #110629 |
scott@slp53.sl.home (Scott Lurndal) writes: >Well, it gave them a couple scratch registers for use as >kernel and user-mode thread specific region pointers (fs, gs). > >However, I doubt that played a huge factor in AMD keeping what's >left of 80286 segments, they could have just re-used the >encodings for FS and GS for new GPRs and reserved them for >TLS in ABI's for implementations that support threads. Unfortunately, Mitch Alsup has not stated the reasoning behind their decisions, but my speculation why they decided on the current solution and not on what you outline is: * The hardware needs a 32+32+32+32-bit (i.e., four-input) adder in the address path for IA-32 anyway, and at least a three-input 64+64+32-bit adder for AMD64, so the additional cost of requiring a 64+64+64+32-bit adder for AMD64 is relatively small. * Also, decoding the FS:/GS: prefix as a segment prefix in IA-32 and as a GPR (for which register use in the instruction?) in AMD64 complicates the decoder. * On the software side, having FS: as separate argument means that software can use the full power of the addressing modes to access TLS; however, thinking about usage scenarios (arrays in TLS), it seems to me that the TLS-base would often be a constant (fitting in the regular addressing modes), or is fetched from TLS (which can be done with three-address operations) and then used (which also does not need segment prefix if the fetched address is absolute rather than TLS-relative; and why should it be TLS-relative when the address is thread-specific rather than useful across threads). - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-24 14:50 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <501b375d6702880e3d86796d4035d1bb@www.novabbs.org> |
| In reply to | #110632 |
On Fri, 24 Jan 2025 8:11:34 +0000, Anton Ertl wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >>Well, it gave them a couple scratch registers for use as >>kernel and user-mode thread specific region pointers (fs, gs). >> >>However, I doubt that played a huge factor in AMD keeping what's >>left of 80286 segments, they could have just re-used the >>encodings for FS and GS for new GPRs and reserved them for >>TLS in ABI's for implementations that support threads. > > Unfortunately, Mitch Alsup has not stated the reasoning behind their > decisions, On purpose. > but my speculation why they decided on the current solution > and not on what you outline is: > > * The hardware needs a 32+32+32+32-bit (i.e., four-input) adder in the > address path for IA-32 anyway, and at least a three-input > 64+64+32-bit adder for AMD64, so the additional cost of requiring a > 64+64+64+32-bit adder for AMD64 is relatively small. One can add the displacement and the segment base in DECODE, delaying the rest of address generation to AGEN, saving an input to the AGEN adder. Displacement is a constant, and segment base is a relative constant. Thus one never needs more than 3-input adders--even with segmentation. > * Also, decoding the FS:/GS: prefix as a segment prefix in IA-32 and > as a GPR (for which register use in the instruction?) in AMD64 > complicates the decoder. > > * On the software side, having FS: as separate argument means that > software can use the full power of the addressing modes to access > TLS; however, thinking about usage scenarios (arrays in TLS), it > seems to me that the TLS-base would often be a constant (fitting in > the regular addressing modes), or is fetched from TLS (which can be > done with three-address operations) and then used (which also does > not need segment prefix if the fetched address is absolute rather > than TLS-relative; and why should it be TLS-relative when the > address is thread-specific rather than useful across threads). > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-01-23 07:24 +0000 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <2025Jan23.082412@mips.complang.tuwien.ac.at> |
| In reply to | #110613 |
scott@slp53.sl.home (Scott Lurndal) writes: >What would an application (portable or otherwise) use the process >stack base address for? Finding roots for garbage collection. >The data is available through the /proc/ filesystem. > >$ cat /proc/$$/maps | grep "[stack]" > >7fff77b52000-7fff77b73000 rw-p 00000000 00:00 0 [stack] That's Linux (I just tried it on AIX 7.3.3; there is no /proc/$$/maps). For the kind of application under discussion Linux also has /proc/self/maps, so you don't need to getpid() and convert it to decimal, but in the example that would produce the maps of the "cat" process, not that of the surrounding shell. I would use "grep -F", because grep by default searches for regexp and '[' and ']' are regexp meta-characters. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-01-22 20:28 -0500 |
| Subject | Re: stack sizes, Segments |
| Message-ID | <ef63pjhiojglr5p0mk3s8i547uh8atktqj@4ax.com> |
| In reply to | #110604 |
On Wed, 22 Jan 2025 15:01:34 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Michael S <already5chosen@yahoo.com> writes: >>On Wed, 22 Jan 2025 02:54:33 -0000 (UTC) >>John Levine <johnl@taugh.com> wrote: >> >>> According to George Neuner <gneuner2@comcast.net>: >>> >Not standard compliant for sure, but you certainly can approximate >>> >stack use in C: just store (as byte*) the address of a local in your >>> >top level function, and check the (absolute value of) the difference >>> >to the address of a local in the current function. >>> >>> Ugh, but yes that would work with the usual stack structure, >>> >>> >The bigger problem is knowing how much stack is available to use - >>> >there may be no way (or no easy way) to find the actual size ... or >>> >the limit if the stack expands ... and circumstances beyond the >>> >program may have limited it to be smaller than the program >>> >requested. >>> >>> There's often no way to tell since it may depend on things like >>> running out of swap space which depends on how much memory other >>> programs are using. >>> >> >>At least you can know the size of reserved VA space which is both an >>upper bound of the limit and in 99% of the cases an actual limit. >> >>On Windows: >>https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getcurrentthreadstacklimits >> >>I suppose that similar functions are available on other OSes as well. >> > >https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_attr_getstack.html > >There is no equivlent function for the main process stack, other than >the 'getrlimit(RLIMIT_STACK...' functionality. pthread_attr_getstack works for POSIX threads ... but no clue if it would work for the main thread or for OS threads not started by pthread_create. Unfortunately away from my Linux machine so can't try it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-16 11:43 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmant5$3fes2$1@dont-email.me> |
| In reply to | #110529 |
On 15/01/2025 21:28, Michael S wrote: > On Wed, 15 Jan 2025 18:00:34 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > >> Michael S <already5chosen@yahoo.com> schrieb: >>> On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) >>> Thomas Koenig <tkoenig@netcologne.de> wrote: >>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >>>>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>> [...] >>>>>> CHERY targets C, which on the one hand, I understand (there's a >>>>>> ton of C code out there), but trying to retrofit a safe memory >>>>>> model onto C seems a bit awkward - it might have been better to >>>>>> target a language which has arrays in the first place, unlike >>>>>> C. >>>>> [...] >>>>> >>>>> C does have arrays. >>>> >>>> Sort of - they decay into pointers at first sight. >>>> >>>> But what I should have written was "multi-dimensional arrays", >>>> with a reasonable way of handling them. >>> >>> C language always had multi-dimensional arrays, with limitation that >>> dimensions have to be known in compile time. >>> C99 lifted that limitation, making C support for multi-dimensional >>> arrays comparable to that in old Fortran. >>> C11 said that lifting is optional. >>> Now C23 makes part of the lifting (variably-modified types) again >>> mandatory. >> >> I'd missed that one. It's not a big thing. VLA's were added in C99, but one big and influential compiler supplier didn't want to bother supporting them (there's lots in C99 that they didn't bother supporting) so the argued for it to be optional in C11. By the time C23 was in planning, they had finally got around to supporting most of C99, so it is no longer optional for standards compliance. But basically the situation is the same as it always has been - if you use a solid C compiler like gcc, clang, icc, etc., you can freely use VLA's. If you use MS's half-done effort, you can't. (MS's compiler has much better support for newer C++ standards - they just seem determined to be useless at C support.) >> >>> Relatively to F90, support for multi-dimensional arrays in C23 is >>> primitive. >> >> From what you describe, support for multi-dimensional arrays >> in C23 now reached the level of Fortran II, released in >> 1958. Only a bit more than six decades, can't complain >> about that. > > Well, apart from playing with what is mandatory and what is not, arrays > stuff in C had not changed (AFAIK) since C99. So, more like four > decades. Or 33 years since Fortran got its first standard. > Yes. >> >>> There are no array descriptors generated automatically by >>> compiler. But saying that there is no support is incorrect. >> >> What happens for mismatched array bounds between caller >> and callee? Nothing, I guess? Bad things /might/ happen. But they might not - it's undefined behaviour. > > I don't know. I didn't read this part of the standard. Or any part of > any C standard past C89. > > Never used them, too. For me, multi-dimensional arrays look mostly like > source of confusion rather than useful feature. At least as long as > there are no automatically generated descriptors. With exception for > VERY conservative cases like array fields in structure, with all > dimensions fixed at compile time. > > I don't know, but I can guess. And in case I am wrong Keith Thompson > will correct me. > Most likely the standard says that mismatched array bounds between > caller and callee is UB. Yes. If you have: int x[4][6]; then the expression "x[i]" is evaluated by converting "x" to a pointer to an array of 6 ints. Thus x[0][6] would be an out-of-bounds access to the first array of 6 ints in x - it is /not/ defined to work like x[1][0], even though you'd get the same bit of memory if you worked out the array address by hand. In practice, it might work fine. When you declare an array type, the compiler will believe you - C is a trusting language. But if you have given the compiler conflicting information, things can go badly wrong. So if you declare an array somewhere with one format that the compiler can see, and then access it through an lvalue (such as a pointer) with a different format that the compiler also can see, the compiler might generate code that assumes one format or the other, or a mix of them. Or it might assume that the pointer can't refer to the declared array because they are not the same format, and keep values cached in registers that don't match up. I expect you'd see problems most often if the compiler is able to make use of SIMD or vector registers to handle blocks of the data at a time. And you are more likely to see trouble with cross-module optimisations (LTO in gcc terms) since it leads to greater sharing of information over wider ranges of the code. As always, the advice is not to lie to your compiler - it might not bite you now, but it may well do in the future when you least expect it. > And most likely in practice it works as expected. I.e. if caller > defined the matrix as X[M][N] and caller is treating it as Y[P][Q] then > access to Y[i][j] for as long as k=i*Q+j < M*N will go to X[k/N][k%N]. > Remember that in C (and all other programming languages), if you try to do something that is not defined behaviour, there isn't any concept of "works as expected" as far as the language is concerned. What the /programmer/ expected is a different matter - but if the language (or additional information from the compiler) does not define the behaviour, then the programmer's expectations are based on a misunderstanding. > However, you have to pay attention that in practice something like that > happening by mistake with variably-modified types is far less likely > than it is with classic C multi-dimensional arrays. > I'm not sure why you'd say that. The rule for getting array code right is quite simple - don't use arrays without knowing the bounds for each dimension. You can get these by passing bounds as parameters, or using fixed constants, or wrapping fixed-size arrays in a struct and using sizeof - however you do it, make sure you know the bounds and keep them consistent.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-15 13:42 -0800 |
| Subject | Re: Segments |
| Message-ID | <878qrb92jp.fsf@nosuchdomain.example.com> |
| In reply to | #110524 |
Thomas Koenig <tkoenig@netcologne.de> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>> [...]
>>> CHERY targets C, which on the one hand, I understand (there's a
>>> ton of C code out there), but trying to retrofit a safe memory
>>> model onto C seems a bit awkward - it might have been better to
>>> target a language which has arrays in the first place, unlike C.
>> [...]
>>
>> C does have arrays.
>
> Sort of - they decay into pointers at first sight.
In most but not all contexts. For example, `sizeof arr` yields the size
of the array, not the size of a pointer.
> But what I should have written was "multi-dimensional arrays",
> with a reasonable way of handling them.
In C, multidimensional arrays are nothing more or less than arrays of
arrays. You can also build data structures using pointers that are
accessed using the same a[i][j] syntax as is used for a multidimensional
array. And yes, they can be difficult to work with.
Again, I urge anyone interested in the gory details to read section 6 of
the comp.lang.c FAQ.
--
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]
Page 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
Back to top | Article view | comp.arch
csiph-web