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 14 of 23 — ← Prev page 1 … 12 13 [14] 15 16 … 23 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-06 19:41 +0000 |
| Subject | Re: Segments |
| Message-ID | <e4f31608052ddccb20d1fd8c83a60e96@www.novabbs.org> |
| In reply to | #110404 |
On Mon, 6 Jan 2025 15:05:02 +0000, Terje Mathisen wrote: > Anton Ertl wrote: >> George Neuner <gneuner2@comcast.net> writes: >>> The bad taste of segments is from exposure to Intel's half-assed >>> implementation which exposed the segment selector as part of the >>> address. >>> >>> Segments /should/ have been implemented similar to the way paging is >>> done: the program using flat 32-bit addresses and the MMU (SMU?) >>> consulting some kind of segment "database" [using the term loosely]. >> >> What benefits do you expect from segments? One benefit usually >> mentioned is security, in particular, protection against out-of-bounds >> accesses (e.g., buffer overflow exploits). > > The best idea I have seen to help detect out of bounds accesses, is to > round all requested memory blocks up to the next 4K boundary and mark > the next page as unavailable, then return a skewed pointer back, so that > the end of the requested region coincides with the end of the (last) > allocated page. > This does require at least 8kB for every allocation, but > I guess they can all share a single trapping segment? You allocate no more actual memory, but you do consume an additional virtual address PTE on those pages marked no-access. If, later, you expand that allocated area, you can THEN allocate a page and update the PTE. > (This idea does not help locate negative buffer overruns (underruns?) > but they seem to be much less common?) Use an unallocated page prior to the buffer, too. > Terje
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-07 11:45 +0100 |
| Subject | Re: Segments |
| Message-ID | <vlj0k5$25kp9$1@dont-email.me> |
| In reply to | #110410 |
MitchAlsup1 wrote: > On Mon, 6 Jan 2025 15:05:02 +0000, Terje Mathisen wrote: > >> Anton Ertl wrote: >>> George Neuner <gneuner2@comcast.net> writes: >>>> The bad taste of segments is from exposure to Intel's half-assed >>>> implementation which exposed the segment selector as part of the >>>> address. >>>> >>>> Segments /should/ have been implemented similar to the way paging is >>>> done: the program using flat 32-bit addresses and the MMU (SMU?) >>>> consulting some kind of segment "database" [using the term loosely]. >>> >>> What benefits do you expect from segments? One benefit usually >>> mentioned is security, in particular, protection against out-of-bounds >>> accesses (e.g., buffer overflow exploits). >> >> The best idea I have seen to help detect out of bounds accesses, is to >> round all requested memory blocks up to the next 4K boundary and mark >> the next page as unavailable, then return a skewed pointer back, so that >> the end of the requested region coincides with the end of the (last) >> allocated page. >> This does require at least 8kB for every allocation, but >> I guess they can all share a single trapping segment? > > You allocate no more actual memory, but you do consume an additional > virtual address PTE on those pages marked no-access. If, later, you > expand that allocated area, you can THEN allocate a page and update > the PTE. > >> (This idea does not help locate negative buffer overruns (underruns?) >> but they seem to be much less common?) > > Use an unallocated page prior to the buffer, too. Yeah, of course, but you do lose the exact trap ability. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-06 22:02 +0000 |
| Subject | Re: Segments |
| Message-ID | <vlhjtm$1qrs5$1@dont-email.me> |
| In reply to | #110404 |
Terje Mathisen <terje.mathisen@tmsw.no> schrieb: > The best idea I have seen to help detect out of bounds accesses, is to > round all requested memory blocks up to the next 4K boundary and mark > the next page as unavailable, then return a skewed pointer back, so that > the end of the requested region coincides with the end of the (last) > allocated page. This does require at least 8kB for every allocation, but > I guess they can all share a single trapping segment? > (This idea does not help locate negative buffer overruns (underruns?) > but they seem to be much less common?) It is also problematic to allocate 8K (or more) for a small entity, or on the stack. Bounds checking should ideally impart minimum overhead so that it can be enabled in production code. Hmm... a beginning of an idea (for which I am ready to be shot down, this is comp.arch :-) This would work best for languages which explicitly pass array bounds or sizes (like Fortran's assumed size arrays, or, if I read this correctly, Rust's slices). Assume a class of load and store instructions containing - One source or destination register - One base register - One index register - One ubound register Memory access is to base + index, with one additional point: If index > ubound, then the instruction raises an exception. This works less well with C's pointers, for which you would have to pass some sort of fat pointer. Compilers would have to make sure that the address of the base object is passed. Comments?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-06 22:57 +0000 |
| Subject | Re: Segments |
| Message-ID | <bdZeP.23664$Hfb1.16566@fx46.iad> |
| In reply to | #110415 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Terje Mathisen <terje.mathisen@tmsw.no> schrieb: > >> The best idea I have seen to help detect out of bounds accesses, is to >> round all requested memory blocks up to the next 4K boundary and mark >> the next page as unavailable, then return a skewed pointer back, so that >> the end of the requested region coincides with the end of the (last) >> allocated page. This does require at least 8kB for every allocation, but >> I guess they can all share a single trapping segment? > >> (This idea does not help locate negative buffer overruns (underruns?) >> but they seem to be much less common?) > >It is also problematic to allocate 8K (or more) for a small entity, or >on the stack. > >Bounds checking should ideally impart minimum overhead so that it >can be enabled in production code. > >Hmm... a beginning of an idea (for which I am ready to be shot >down, this is comp.arch :-) > >This would work best for languages which explicitly pass >array bounds or sizes (like Fortran's assumed size arrays, >or, if I read this correctly, Rust's slices). > >Assume a class of load and store instructions containing > >- One source or destination register >- One base register >- One index register >- One ubound register See aforementioned CHERI.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-07 11:05 +0000 |
| Subject | Re: Segments |
| Message-ID | <vlj1pg$25p0e$1@dont-email.me> |
| In reply to | #110416 |
Scott Lurndal <scott@slp53.sl.home> schrieb:
>>Assume a class of load and store instructions containing
>>
>>- One source or destination register
>>- One base register
>>- One index register
>>- One ubound register
>
> See aforementioned CHERI.
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.
The floating point size is weird (and also does not catch all
errors, such as writing one element past a huge array).
I haven't seen any consideration of how CHERI would integrate
with languages which have multidimensional arrays. How would
do j=1,10
do i=1,11
a(i,j) = 42.
end do
end do
interact with Cheri if a was a 10*10 array ? Would it be
necessary to create a capability for a(:,j)?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-07 14:43 +0000 |
| Subject | Re: Segments |
| Message-ID | <W3bfP.515961$DYF8.447613@fx14.iad> |
| In reply to | #110426 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Scott Lurndal <scott@slp53.sl.home> schrieb: > >>>Assume a class of load and store instructions containing >>> >>>- One source or destination register >>>- One base register >>>- One index register >>>- One ubound register >> >> See aforementioned CHERI. > >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. > >The floating point size is weird (and also does not catch all >errors, such as writing one element past a huge array). > >I haven't seen any consideration of how CHERI would integrate >with languages which have multidimensional arrays. How would > > do j=1,10 > do i=1,11 > a(i,j) = 42. > end do > end do > >interact with Cheri if a was a 10*10 array ? Would it be >necessary to create a capability for a(:,j)? A multidimensional array is a single contiguous blob of memory, the capability would encompass the entire region of memory containing the array.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-07 17:04 +0200 |
| Subject | Re: Segments |
| Message-ID | <20250107170429.00003de2@yahoo.com> |
| In reply to | #110427 |
On Tue, 07 Jan 2025 14:43:02 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Thomas Koenig <tkoenig@netcologne.de> writes: > >Scott Lurndal <scott@slp53.sl.home> schrieb: > > > >>>Assume a class of load and store instructions containing > >>> > >>>- One source or destination register > >>>- One base register > >>>- One index register > >>>- One ubound register > >> > >> See aforementioned CHERI. > > > >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. > > > >The floating point size is weird (and also does not catch all > >errors, such as writing one element past a huge array). > > > >I haven't seen any consideration of how CHERI would integrate > >with languages which have multidimensional arrays. How would > > > > do j=1,10 > > do i=1,11 > > a(i,j) = 42. > > end do > > end do > > > >interact with Cheri if a was a 10*10 array ? Would it be > >necessary to create a capability for a(:,j)? > > A multidimensional array is a single contiguous > blob of memory, the capability would encompass the > entire region of memory containing the array. Then out of bound access like a(9,11) would not be caught. I don't know if it has to be caught by Fortran rules. It is certainly caught both in Matlab and in Octave. And Matlab has Fortran roots.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-07 15:28 +0000 |
| Subject | Re: Segments |
| Message-ID | <bKbfP.54358$XfF8.12736@fx04.iad> |
| In reply to | #110428 |
Michael S <already5chosen@yahoo.com> writes: >On Tue, 07 Jan 2025 14:43:02 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Thomas Koenig <tkoenig@netcologne.de> writes: >> >Scott Lurndal <scott@slp53.sl.home> schrieb: >> > >> >>>Assume a class of load and store instructions containing >> >>> >> >>>- One source or destination register >> >>>- One base register >> >>>- One index register >> >>>- One ubound register >> >> >> >> See aforementioned CHERI. >> > >> >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. >> > >> >The floating point size is weird (and also does not catch all >> >errors, such as writing one element past a huge array). >> > >> >I haven't seen any consideration of how CHERI would integrate >> >with languages which have multidimensional arrays. How would >> > >> > do j=1,10 >> > do i=1,11 >> > a(i,j) = 42. >> > end do >> > end do >> > >> >interact with Cheri if a was a 10*10 array ? Would it be >> >necessary to create a capability for a(:,j)? >> >> A multidimensional array is a single contiguous >> blob of memory, the capability would encompass the >> entire region of memory containing the array. > >Then out of bound access like a(9,11) would not be caught. >I don't know if it has to be caught by Fortran rules. It is certainly >caught both in Matlab and in Octave. And Matlab has Fortran roots. A compiler is free to create row or column capabilities for C or FORTRAN if the goal is more than just memory safety.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-07 16:41 +0000 |
| Subject | Re: Segments |
| Message-ID | <vljlg0$29ogo$1@dont-email.me> |
| In reply to | #110429 |
Scott Lurndal <scott@slp53.sl.home> schrieb:
> Michael S <already5chosen@yahoo.com> writes:
>>On Tue, 07 Jan 2025 14:43:02 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> >Scott Lurndal <scott@slp53.sl.home> schrieb:
>>> >
>>> >>>Assume a class of load and store instructions containing
>>> >>>
>>> >>>- One source or destination register
>>> >>>- One base register
>>> >>>- One index register
>>> >>>- One ubound register
>>> >>
>>> >> See aforementioned CHERI.
>>> >
>>> >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.
>>> >
>>> >The floating point size is weird (and also does not catch all
>>> >errors, such as writing one element past a huge array).
>>> >
>>> >I haven't seen any consideration of how CHERI would integrate
>>> >with languages which have multidimensional arrays. How would
>>> >
>>> > do j=1,10
>>> > do i=1,11
>>> > a(i,j) = 42.
>>> > end do
>>> > end do
>>> >
>>> >interact with Cheri if a was a 10*10 array ? Would it be
>>> >necessary to create a capability for a(:,j)?
>>>
>>> A multidimensional array is a single contiguous
>>> blob of memory, the capability would encompass the
>>> entire region of memory containing the array.
>>
>>Then out of bound access like a(9,11) would not be caught.
>>I don't know if it has to be caught by Fortran rules. It is certainly
>>caught both in Matlab and in Octave. And Matlab has Fortran roots.
And vice versa, Fortran 90 borrowed heavily from Matlab :-)
Out-of-bounds-accesses are an error in Fortran, but the language
does not require.
> A compiler is free to create row or column capabilities for C or
> FORTRAN if the goal is more than just memory safety.
Would this be reasonably efficient?
Looking at an extreme case, the straightforward matrix
multiplication below (including some initialization so it's
self-contained)
program main
implicit none
real a(0:2,0:2), b(0:2,0:2), c(0:2,0:2)
integer i,j,k
do i=0,2
do j=0,2
a(i,j) = 2*i + j
b(i,j) = i - j
c(i,j) = 0
end do
end do
do j = 0, 2
do k = 0,2
do i = 0, 2
c(i,j) = c(i,j) + a(i,k) * b(k,j)
end do
end do
end do
print *,c
end
gives us, in f2c translation to C of the three nested matmul loops,
for (j = 0; j <= 2; ++j) {
for (k = 0; k <= 2; ++k) {
for (i__ = 0; i__ <= 2; ++i__) {
c__[i__ + j * 3] += a[i__ + k * 3] * b[k + j * 3];
}
}
}
(yes, any bounds checking should have been moved outside the loops :-)
how could capabilities be used to detect bounds violations for all
indices on each access?
And what would the effort be? Can they be created in the time
for a simple pointer addition, or is something from the OS required?
Would this require something like a "pointer to pointer"?
(I have to admit that I haven't read a lot of CHERI, but what I
have read makes me supect that the designers didn't really have
multi-dimensional arrays in mind; but then neither did the
designers of C, and CHERI is certainly C-centered).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-07 20:16 +0000 |
| Subject | Re: Segments |
| Message-ID | <18cc69cf39bb7b0df7fc8733f9ccaab6@www.novabbs.org> |
| In reply to | #110428 |
On Tue, 7 Jan 2025 15:04:29 +0000, Michael S wrote: > On Tue, 07 Jan 2025 14:43:02 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Thomas Koenig <tkoenig@netcologne.de> writes: >>>Scott Lurndal <scott@slp53.sl.home> schrieb: >>> >>>>>Assume a class of load and store instructions containing >>>>> >>>>>- One source or destination register >>>>>- One base register >>>>>- One index register >>>>>- One ubound register >>>> >>>> See aforementioned CHERI. >>> >>>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. >>> >>>The floating point size is weird (and also does not catch all >>>errors, such as writing one element past a huge array). >>> >>>I haven't seen any consideration of how CHERI would integrate >>>with languages which have multidimensional arrays. How would >>> >>> do j=1,10 >>> do i=1,11 >>> a(i,j) = 42. >>> end do >>> end do >>> >>>interact with Cheri if a was a 10*10 array ? Would it be >>>necessary to create a capability for a(:,j)? >> >> A multidimensional array is a single contiguous >> blob of memory, the capability would encompass the >> entire region of memory containing the array. > > Then out of bound access like a(9,11) would not be caught. > I don't know if it has to be caught by Fortran rules. It is certainly > caught both in Matlab and in Octave. And Matlab has Fortran roots. WATFIV would catch a(9,11)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-01-07 21:26 +0000 |
| Subject | Re: Segments |
| Message-ID | <TZgfP.54361$XfF8.16575@fx04.iad> |
| In reply to | #110434 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Tue, 7 Jan 2025 15:04:29 +0000, Michael S wrote: > >> On Tue, 07 Jan 2025 14:43:02 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: >> >>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>Scott Lurndal <scott@slp53.sl.home> schrieb: >>>> >>>>>>Assume a class of load and store instructions containing >>>>>> >>>>>>- One source or destination register >>>>>>- One base register >>>>>>- One index register >>>>>>- One ubound register >>>>> >>>>> See aforementioned CHERI. >>>> >>>>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. >>>> >>>>The floating point size is weird (and also does not catch all >>>>errors, such as writing one element past a huge array). >>>> >>>>I haven't seen any consideration of how CHERI would integrate >>>>with languages which have multidimensional arrays. How would >>>> >>>> do j=1,10 >>>> do i=1,11 >>>> a(i,j) = 42. >>>> end do >>>> end do >>>> >>>>interact with Cheri if a was a 10*10 array ? Would it be >>>>necessary to create a capability for a(:,j)? >>> >>> A multidimensional array is a single contiguous >>> blob of memory, the capability would encompass the >>> entire region of memory containing the array. >> >> Then out of bound access like a(9,11) would not be caught. >> I don't know if it has to be caught by Fortran rules. It is certainly >> caught both in Matlab and in Octave. And Matlab has Fortran roots. > >WATFIV would catch a(9,11) So would any compiler that generates bounds checking code.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-07 22:01 +0000 |
| Subject | Re: Segments |
| Message-ID | <vlk88j$2d9j6$1@dont-email.me> |
| In reply to | #110434 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > On Tue, 7 Jan 2025 15:04:29 +0000, Michael S wrote: > >> On Tue, 07 Jan 2025 14:43:02 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: >> >>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>Scott Lurndal <scott@slp53.sl.home> schrieb: >>>> >>>>>>Assume a class of load and store instructions containing >>>>>> >>>>>>- One source or destination register >>>>>>- One base register >>>>>>- One index register >>>>>>- One ubound register >>>>> >>>>> See aforementioned CHERI. >>>> >>>>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. >>>> >>>>The floating point size is weird (and also does not catch all >>>>errors, such as writing one element past a huge array). >>>> >>>>I haven't seen any consideration of how CHERI would integrate >>>>with languages which have multidimensional arrays. How would >>>> >>>> do j=1,10 >>>> do i=1,11 >>>> a(i,j) = 42. >>>> end do >>>> end do >>>> >>>>interact with Cheri if a was a 10*10 array ? Would it be >>>>necessary to create a capability for a(:,j)? >>> >>> A multidimensional array is a single contiguous >>> blob of memory, the capability would encompass the >>> entire region of memory containing the array. >> >> Then out of bound access like a(9,11) would not be caught. >> I don't know if it has to be caught by Fortran rules. It is certainly >> caught both in Matlab and in Octave. And Matlab has Fortran roots. > > WATFIV would catch a(9,11) Every Fortran compiler I know has a bounds checking, but it is optional for all of them. People still leave it off for production code because it is too slow. It would really be great if the performance degradation was small enough so people would simply leave on the checks for production code. (Side question: What does CHERI do with SIMD-vectorized code?)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-07 23:16 +0000 |
| Subject | Re: Segments |
| Message-ID | <95be976a187a0424bc1f9a52c9a1f06b@www.novabbs.org> |
| In reply to | #110437 |
On Tue, 7 Jan 2025 22:01:55 +0000, Thomas Koenig wrote: > MitchAlsup1 <mitchalsup@aol.com> schrieb: ----------------- >> WATFIV would catch a(9,11) > > Every Fortran compiler I know has a bounds checking, but it is > optional for all of them. People still leave it off for production > code because it is too slow. > > It would really be great if the performance degradation was > small enough so people would simply leave on the checks > for production code. (Side question: What does CHERI > do with SIMD-vectorized code?) How long does it take SW to construct the kinds of slices a FORTRAN subroutine can hand off to another subroutine ?? That is a CHERRI capability that allows for access to every even byte in a structure but no odd byte in the same structure ??
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-08 11:53 +0000 |
| Subject | Re: Segments |
| Message-ID | <vllp0f$2p0rr$1@dont-email.me> |
| In reply to | #110438 |
MitchAlsup1 <mitchalsup@aol.com> schrieb:
> On Tue, 7 Jan 2025 22:01:55 +0000, Thomas Koenig wrote:
>
>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
> -----------------
>>> WATFIV would catch a(9,11)
>>
>> Every Fortran compiler I know has a bounds checking, but it is
>> optional for all of them. People still leave it off for production
>> code because it is too slow.
>>
>> It would really be great if the performance degradation was
>> small enough so people would simply leave on the checks
>> for production code. (Side question: What does CHERI
>> do with SIMD-vectorized code?)
>
> How long does it take SW to construct the kinds of slices
> a FORTRAN subroutine can hand off to another subroutine ??
For the snippet
subroutine bar
interface
subroutine foo(a)
real, intent(in), dimension(:,:) :: a
end subroutine foo
end interface
real, dimension(10,10) :: a
call foo(a)
end
(which calls foo with an assumed-shape array) gfortran hands this
to the middle end:
__attribute__((fn spec (". ")))
void bar ()
{
real(kind=4) a[100];
{
struct array02_real(kind=4) parm.0;
parm.0.span = 4;
parm.0.dtype = {.elem_len=4, .version=0, .rank=2, .type=3};
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 10;
parm.0.dim[0].stride = 1;
parm.0.dim[1].lbound = 1;
parm.0.dim[1].ubound = 10;
parm.0.dim[1].stride = 10;
parm.0.data = (void *) &a[0];
parm.0.offset = -11;
foo (&parm.0);
}
}
The middle and back ends are then free to optimize.
> That is a CHERRI capability that allows for access to every
> even byte in a structure but no odd byte in the same structure ??
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-11 22:31 +0000 |
| Subject | Re: Segments |
| Message-ID | <25830195ddbf39cca3002ed944177194@www.novabbs.org> |
| In reply to | #110444 |
On Wed, 8 Jan 2025 11:53:51 +0000, Thomas Koenig wrote:
> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>> On Tue, 7 Jan 2025 22:01:55 +0000, Thomas Koenig wrote:
>>
>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>> -----------------
>>>> WATFIV would catch a(9,11)
>>>
>>> Every Fortran compiler I know has a bounds checking, but it is
>>> optional for all of them. People still leave it off for production
>>> code because it is too slow.
>>>
>>> It would really be great if the performance degradation was
>>> small enough so people would simply leave on the checks
>>> for production code. (Side question: What does CHERI
>>> do with SIMD-vectorized code?)
>>
>> How long does it take SW to construct the kinds of slices
>> a FORTRAN subroutine can hand off to another subroutine ??
>
> For the snippet
>
> subroutine bar
> interface
> subroutine foo(a)
> real, intent(in), dimension(:,:) :: a
> end subroutine foo
> end interface
> real, dimension(10,10) :: a
> call foo(a)
> end
>
> (which calls foo with an assumed-shape array) gfortran hands this
> to the middle end:
>
> __attribute__((fn spec (". ")))
> void bar ()
> {
> real(kind=4) a[100];
>
> {
> struct array02_real(kind=4) parm.0;
>
> parm.0.span = 4;
> parm.0.dtype = {.elem_len=4, .version=0, .rank=2, .type=3};
> parm.0.dim[0].lbound = 1;
> parm.0.dim[0].ubound = 10;
> parm.0.dim[0].stride = 1;
> parm.0.dim[1].lbound = 1;
> parm.0.dim[1].ubound = 10;
> parm.0.dim[1].stride = 10;
> parm.0.data = (void *) &a[0];
> parm.0.offset = -11;
> foo (&parm.0);
> }
> }
>
>
> The middle and back ends are then free to optimize.
Thank you for this example.
>> That is a CHERRI capability that allows for access to every
>> even byte in a structure but no odd byte in the same structure ??
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-14 17:46 -0800 |
| Subject | Re: Segments |
| Message-ID | <87cygo97dl.fsf@nosuchdomain.example.com> |
| In reply to | #110426 |
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.
Admittedly its handling of them is odd and low-level. For example,
there are no parameters of array type, and most array manipulation code
works with a pointer to the initial element, with no built-in way to
specify the number of elements.
Suggested reading: https://www.c-faq.com/ section 6.
--
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 | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-15 07:09 +0000 |
| Subject | Re: Segments |
| Message-ID | <vm7mvi$2rr87$1@dont-email.me> |
| In reply to | #110522 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-15 14:00 +0200 |
| Subject | Re: Segments |
| Message-ID | <20250115140026.00003f4f@yahoo.com> |
| In reply to | #110524 |
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. Relatively to F90, support for multi-dimensional arrays in C23 is primitive. There are no array descriptors generated automatically by compiler. But saying that there is no support is incorrect.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-15 18:00 +0000 |
| Subject | Re: Segments |
| Message-ID | <vm8t42$3221i$1@dont-email.me> |
| In reply to | #110526 |
Michael S <already5chosen@yahoo.com> schrieb: > On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: >> > Thomas Koenig <tkoenig@netcologne.de> writes: >> > [...] >> >> CHERY targets C, which on the one hand, I understand (there's a >> >> ton of C code out there), but trying to retrofit a safe memory >> >> model onto C seems a bit awkward - it might have been better to >> >> target a language which has arrays in the first place, unlike C. >> > [...] >> > >> > C does have arrays. >> >> Sort of - they decay into pointers at first sight. >> >> But what I should have written was "multi-dimensional arrays", >> with a reasonable way of handling them. > > C language always had multi-dimensional arrays, with limitation that > dimensions have to be known in compile time. > C99 lifted that limitation, making C support for multi-dimensional > arrays comparable to that in old Fortran. > C11 said that lifting is optional. > Now C23 makes part of the lifting (variably-modified types) again > mandatory. I'd missed that one. > Relatively to F90, support for multi-dimensional arrays in C23 is > primitive. From what you describe, support for multi-dimensional arrays in C23 now reached the level of Fortran II, released in 1958. Only a bit more than six decades, can't complain about that. > 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?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-01-15 22:28 +0200 |
| Subject | Re: Segments |
| Message-ID | <20250115222824.000034d6@yahoo.com> |
| In reply to | #110528 |
On Wed, 15 Jan 2025 18:00:34 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Michael S <already5chosen@yahoo.com> schrieb: > > On Wed, 15 Jan 2025 07:09:38 -0000 (UTC) > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: > >> > Thomas Koenig <tkoenig@netcologne.de> writes: > >> > [...] > >> >> CHERY targets C, which on the one hand, I understand (there's a > >> >> ton of C code out there), but trying to retrofit a safe memory > >> >> model onto C seems a bit awkward - it might have been better to > >> >> target a language which has arrays in the first place, unlike > >> >> C. > >> > [...] > >> > > >> > C does have arrays. > >> > >> Sort of - they decay into pointers at first sight. > >> > >> But what I should have written was "multi-dimensional arrays", > >> with a reasonable way of handling them. > > > > C language always had multi-dimensional arrays, with limitation that > > dimensions have to be known in compile time. > > C99 lifted that limitation, making C support for multi-dimensional > > arrays comparable to that in old Fortran. > > C11 said that lifting is optional. > > Now C23 makes part of the lifting (variably-modified types) again > > mandatory. > > I'd missed that one. > > > Relatively to F90, support for multi-dimensional arrays in C23 is > > primitive. > > From what you describe, support for multi-dimensional arrays > in C23 now reached the level of Fortran II, released in > 1958. Only a bit more than six decades, can't complain > about that. Well, apart from playing with what is mandatory and what is not, arrays stuff in C had not changed (AFAIK) since C99. So, more like four decades. Or 33 years since Fortran got its first standard. > > > 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? 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. 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]. 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.
[toc] | [prev] | [next] | [standalone]
Page 14 of 23 — ← Prev page 1 … 12 13 [14] 15 16 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web