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 21 of 23 — ← Prev page 1 … 19 20 [21] 22 23 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-15 22:39 +0000 |
| Subject | Re: Segments |
| Message-ID | <vm9dft$353n1$1@dont-email.me> |
| In reply to | #110531 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> schrieb: > 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. Jep. >> 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. A pointer forest is also Not Good (TM) for efficiency...
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-16 10:11 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmaig9$3ehn7$1@dont-email.me> |
| In reply to | #110524 |
Thomas Koenig 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. > Rust provides an interesting data point here: It has Vec<> which is always implemented as a dope vector, i.e. a header which contains the starting point and current length, along with allocated size. For multidimendional work, the natural mapping is Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with boundary checking. However, in my own testing I have found that it is often faster to flatten those multi-dim vectors, and instead use explicit multiplication to get the actual position: array[y][x] -> array[y*width + x] Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-16 13:11 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmat2e$3geg9$1@dont-email.me> |
| In reply to | #110535 |
On 16/01/2025 10:11, Terje Mathisen wrote: > Thomas Koenig 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. >> > Rust provides an interesting data point here: > > It has Vec<> which is always implemented as a dope vector, i.e. a header > which contains the starting point and current length, along with > allocated size. For multidimendional work, the natural mapping is > Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with > boundary checking. > > However, in my own testing I have found that it is often faster to > flatten those multi-dim vectors, and instead use explicit multiplication > to get the actual position: > > array[y][x] -> array[y*width + x] > That does not surprise me. Vec<> in Rust is very similar to std::vector<> in C++, as far as I know (correct me if that's wrong). So a vector of vectors of int is not contiguous or consistent - each subvector can have a different current size and capacity. Doing a bounds check for accessing xs[i][j] (or in C++ syntax, xs.at(i).at(j) when you want bounds checking) means first reading the current size member of the outer vector, and checking "i" against that. Then xs[i] is found (by adding "i * sizeof(vector)" to the data pointer stored in the outer vector). That is looked up to find the current size of this inner vector for bounds checking, then the actual data can be found. This is /completely/ different from classic C multi-dimensional arrays. It is more akin to a one-dimensional C array of pointers to individually allocated one-dimensional C arrays - but even less efficient due to an extra layer of indirection. If you know the size of the data at compile time, then in C++ you have std::array<> where the information about size is carried in the type, with no run-time cost. A nested std::array<> is a perfectly good and efficient multi-dimensional array with runtime bounds checking if you want to use it, as well as having value semantics (no decay to pointer types in expressions). I would guess there is something equivalent in Rust ?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-16 13:10 -0800 |
| Subject | Re: Segments |
| Message-ID | <874j1y8nxy.fsf@nosuchdomain.example.com> |
| In reply to | #110538 |
David Brown <david.brown@hesbynett.no> writes:
> On 16/01/2025 10:11, Terje Mathisen wrote:
>> Thomas Koenig 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.
>>>
>> Rust provides an interesting data point here:
>> It has Vec<> which is always implemented as a dope vector, i.e. a
>> header which contains the starting point and current length, along
>> with allocated size. For multidimendional work, the natural mapping
>> is Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with
>> boundary checking.
>> However, in my own testing I have found that it is often faster to
>> flatten those multi-dim vectors, and instead use explicit
>> multiplication to get the actual position:
>> array[y][x] -> array[y*width + x]
Note that this will inhibit bounds checking on the inner dimension.
That might be part of the reason for the improvement in speed.
For example, given int array[10][10], array[0][11] is out of bounds,
even if it logically refers to the same location as array[1][0]. This
results in undefined behavior in C, and perhaps some kind of exception
in a language that requires bounds checking. If you do this manually by
defining a 1d array, any checking applies only to the entire array.
> That does not surprise me. Vec<> in Rust is very similar to
> std::vector<> in C++, as far as I know (correct me if that's wrong).
> So a vector of vectors of int is not contiguous or consistent - each
> subvector can have a different current size and capacity. Doing a
> bounds check for accessing xs[i][j] (or in C++ syntax, xs.at(i).at(j)
> when you want bounds checking) means first reading the current size
> member of the outer vector, and checking "i" against that. Then xs[i]
> is found (by adding "i * sizeof(vector)" to the data pointer stored in
> the outer vector). That is looked up to find the current size of this
> inner vector for bounds checking, then the actual data can be found.
I'm not familiar with Rust's Vec<>, but C++'s std::vector<> guarantees
that the elements are stored contiguously. But the std::vector<> object
itself doesn't contain those elements; it's a fixed-size chunk of data
(basically a struct in C terms) whose size doesn't change regardless of
the number of elements (and typically regardless of the element type).
So a std::vector<std::vector<int>> will result in the data for each row
being stored contiguously, but the rows themselves will be allocated
dynamically.
> This is /completely/ different from classic C multi-dimensional
> arrays. It is more akin to a one-dimensional C array of pointers to
> individually allocated one-dimensional C arrays - but even less
> efficient due to an extra layer of indirection.
>
> If you know the size of the data at compile time, then in C++ you have
> std::array<> where the information about size is carried in the type,
> with no run-time cost. A nested std::array<> is a perfectly good and
> efficient multi-dimensional array with runtime bounds checking if you
> want to use it, as well as having value semantics (no decay to pointer
> types in expressions). I would guess there is something equivalent in
> Rust ?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-16 22:23 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmbtcq$3lp99$1@dont-email.me> |
| In reply to | #110556 |
On 16/01/2025 22:10, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 16/01/2025 10:11, Terje Mathisen wrote: >>> Thomas Koenig 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. >>>> >>> Rust provides an interesting data point here: >>> It has Vec<> which is always implemented as a dope vector, i.e. a >>> header which contains the starting point and current length, along >>> with allocated size. For multidimendional work, the natural mapping >>> is Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >>> boundary checking. >>> However, in my own testing I have found that it is often faster to >>> flatten those multi-dim vectors, and instead use explicit >>> multiplication to get the actual position: >>> array[y][x] -> array[y*width + x] > > Note that this will inhibit bounds checking on the inner dimension. > That might be part of the reason for the improvement in speed. > > For example, given int array[10][10], array[0][11] is out of bounds, > even if it logically refers to the same location as array[1][0]. This > results in undefined behavior in C, and perhaps some kind of exception > in a language that requires bounds checking. If you do this manually by > defining a 1d array, any checking applies only to the entire array. > >> That does not surprise me. Vec<> in Rust is very similar to >> std::vector<> in C++, as far as I know (correct me if that's wrong). >> So a vector of vectors of int is not contiguous or consistent - each >> subvector can have a different current size and capacity. Doing a >> bounds check for accessing xs[i][j] (or in C++ syntax, xs.at(i).at(j) >> when you want bounds checking) means first reading the current size >> member of the outer vector, and checking "i" against that. Then xs[i] >> is found (by adding "i * sizeof(vector)" to the data pointer stored in >> the outer vector). That is looked up to find the current size of this >> inner vector for bounds checking, then the actual data can be found. > > I'm not familiar with Rust's Vec<>, but C++'s std::vector<> guarantees > that the elements are stored contiguously. But the std::vector<> object > itself doesn't contain those elements; it's a fixed-size chunk of data > (basically a struct in C terms) whose size doesn't change regardless of > the number of elements (and typically regardless of the element type). > So a std::vector<std::vector<int>> will result in the data for each row > being stored contiguously, but the rows themselves will be allocated > dynamically. > Yes, exactly. Of course you could do as Terje did in Rust - make a std::vector<> of size N x M and do the "i * N + j" calculation manually. Now that C++23 has a multi-parameter subscript operator, you can do that quite neatly in a little wrapper class around a std::vector<> with a nice access operator. But it's still more efficient to use a std::array<> if you know the sizes at compile time. >> This is /completely/ different from classic C multi-dimensional >> arrays. It is more akin to a one-dimensional C array of pointers to >> individually allocated one-dimensional C arrays - but even less >> efficient due to an extra layer of indirection. >> >> If you know the size of the data at compile time, then in C++ you have >> std::array<> where the information about size is carried in the type, >> with no run-time cost. A nested std::array<> is a perfectly good and >> efficient multi-dimensional array with runtime bounds checking if you >> want to use it, as well as having value semantics (no decay to pointer >> types in expressions). I would guess there is something equivalent in >> Rust ? >
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-01-16 09:15 -0800 |
| Subject | Re: Segments |
| Message-ID | <vmbesc$3d6n7$1@dont-email.me> |
| In reply to | #110535 |
On 1/16/2025 1:11 AM, Terje Mathisen wrote: > Thomas Koenig 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. >> > Rust provides an interesting data point here: > > It has Vec<> which is always implemented as a dope vector, i.e. a header > which contains the starting point and current length, along with > allocated size. For multidimendional work, the natural mapping is > Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with > boundary checking. > > However, in my own testing I have found that it is often faster to > flatten those multi-dim vectors, and instead use explicit multiplication > to get the actual position: > > array[y][x] -> array[y*width + x] > > Terje I am obviously missing something, but why doesn't the compiler generate code for that itself? -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-16 17:24 +0000 |
| Subject | Re: Segments |
| Message-ID | <d008a990495541dd44758357552d44d4@www.novabbs.org> |
| In reply to | #110544 |
On Thu, 16 Jan 2025 17:15:55 +0000, Stephen Fuld wrote: > On 1/16/2025 1:11 AM, Terje Mathisen wrote: >> Thomas Koenig 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. >>> >> Rust provides an interesting data point here: >> >> It has Vec<> which is always implemented as a dope vector, i.e. a header >> which contains the starting point and current length, along with >> allocated size. For multidimendional work, the natural mapping is >> Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >> boundary checking. >> >> However, in my own testing I have found that it is often faster to >> flatten those multi-dim vectors, and instead use explicit multiplication >> to get the actual position: >> >> array[y][x] -> array[y*width + x] >> >> Terje > > I am obviously missing something, but why doesn't the compiler generate > code for that itself? The compiler does; but with a dope-vector in view, the compiler inserts additional checks on the arithmetic and addressing.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-01-16 09:55 -0800 |
| Subject | Re: Segments |
| Message-ID | <vmbh77$3d6n6$1@dont-email.me> |
| In reply to | #110545 |
On 1/16/2025 9:24 AM, MitchAlsup1 wrote: > On Thu, 16 Jan 2025 17:15:55 +0000, Stephen Fuld wrote: > >> On 1/16/2025 1:11 AM, Terje Mathisen wrote: >>> Thomas Koenig 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. >>>> >>> Rust provides an interesting data point here: >>> >>> It has Vec<> which is always implemented as a dope vector, i.e. a header >>> which contains the starting point and current length, along with >>> allocated size. For multidimendional work, the natural mapping is >>> Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >>> boundary checking. >>> >>> However, in my own testing I have found that it is often faster to >>> flatten those multi-dim vectors, and instead use explicit multiplication >>> to get the actual position: >>> >>> array[y][x] -> array[y*width + x] >>> >>> Terje >> >> I am obviously missing something, but why doesn't the compiler generate >> code for that itself? > > The compiler does; but with a dope-vector in view, the compiler > inserts additional checks on the arithmetic and addressing. OK, so Terje's observation of it being faster doing the calculation himself is due to him not doing these additional checks? -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-16 18:23 +0000 |
| Subject | Re: Segments |
| Message-ID | <220911290c733a265f8fd4db424decd6@www.novabbs.org> |
| In reply to | #110546 |
On Thu, 16 Jan 2025 17:55:50 +0000, Stephen Fuld wrote: > On 1/16/2025 9:24 AM, MitchAlsup1 wrote: >> On Thu, 16 Jan 2025 17:15:55 +0000, Stephen Fuld wrote: >> >>> On 1/16/2025 1:11 AM, Terje Mathisen wrote: >>>> Thomas Koenig 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. >>>>> >>>> Rust provides an interesting data point here: >>>> >>>> It has Vec<> which is always implemented as a dope vector, i.e. a header >>>> which contains the starting point and current length, along with >>>> allocated size. For multidimendional work, the natural mapping is >>>> Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >>>> boundary checking. >>>> >>>> However, in my own testing I have found that it is often faster to >>>> flatten those multi-dim vectors, and instead use explicit multiplication >>>> to get the actual position: >>>> >>>> array[y][x] -> array[y*width + x] >>>> >>>> Terje >>> >>> I am obviously missing something, but why doesn't the compiler generate >>> code for that itself? >> >> The compiler does; but with a dope-vector in view, the compiler >> inserts additional checks on the arithmetic and addressing. > > OK, so Terje's observation of it being faster doing the calculation > himself is due to him not doing these additional checks? > Most likely.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-16 20:22 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmbm9s$3kr0b$1@dont-email.me> |
| In reply to | #110546 |
Stephen Fuld wrote: > On 1/16/2025 9:24 AM, MitchAlsup1 wrote: >> On Thu, 16 Jan 2025 17:15:55 +0000, Stephen Fuld wrote: >> >>> On 1/16/2025 1:11 AM, Terje Mathisen wrote: >>>> Thomas Koenig 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. >>>>> >>>> Rust provides an interesting data point here: >>>> >>>> It has Vec<> which is always implemented as a dope vector, i.e. a >>>> header >>>> which contains the starting point and current length, along with >>>> allocated size. For multidimendional work, the natural mapping is >>>> Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >>>> boundary checking. >>>> >>>> However, in my own testing I have found that it is often faster to >>>> flatten those multi-dim vectors, and instead use explicit >>>> multiplication >>>> to get the actual position: >>>> >>>> Â Â array[y][x] -> array[y*width + x] >>>> >>>> Terje >>> >>> I am obviously missing something, but why doesn't the compiler generate >>> code for that itself? >> >> The compiler does; but with a dope-vector in view, the compiler >> inserts additional checks on the arithmetic and addressing. > > OK, so Terje's observation of it being faster doing the calculation > himself is due to him not doing these additional checks? No, more like one of the Advent of Code problems that naively looked like a nice little hash table problem, with strings as the keys: "-4,0,3,6" I.e. 4 integers, all in the -9 to 9 range, used to verify that this was the first time this particular combination was seen. The first speedup (compared to my original Perl code) was from converting this to 4 signed byte values all packed into a u32 variable, then on each iteration I would shift the key up by 8 (getting rid of the oldest delta) and add in the new delta as the new bottom byte, then use that u32 as the hash table key. My code became an order of magnitude faster when I instead allocated a single vector with 19*19*19*19 elements, then biased each of those four delta values by +9 so that they would all be in the [0..18] range instead of [-9..9], and do the addressing as ((d3*19+d2)*19+d1)*19+d0. Rust would still verify that the final value was in range, but this becomes a single (never taken) CMP/JA combination. 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-16 19:14 +0000 |
| Subject | Re: Segments |
| Message-ID | <vmblq0$3knhc$1@dont-email.me> |
| In reply to | #110545 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > On Thu, 16 Jan 2025 17:15:55 +0000, Stephen Fuld wrote: > >> On 1/16/2025 1:11 AM, Terje Mathisen wrote: >>> However, in my own testing I have found that it is often faster to >>> flatten those multi-dim vectors, and instead use explicit multiplication >>> to get the actual position: >>> >>> array[y][x] -> array[y*width + x] >>> That is what any Fortran compiler does under the hood, of course. >>> Terje >> >> I am obviously missing something, but why doesn't the compiler generate >> code for that itself? It should. > > The compiler does; but with a dope-vector in view, the compiler > inserts additional checks on the arithmetic and addressing. Depends on the relevant flag for bounds checking (at least for Fortran).
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-16 20:12 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmblm4$3kno9$1@dont-email.me> |
| In reply to | #110544 |
Stephen Fuld wrote: > On 1/16/2025 1:11 AM, Terje Mathisen wrote: >> Thomas Koenig 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. >>> >> Rust provides an interesting data point here: >> >> It has Vec<> which is always implemented as a dope vector, i.e. a >> header which contains the starting point and current length, along >> with allocated size. For multidimendional work, the natural mapping is >> Vec<Vec<>>, i.e. similar to classic C arrays of arrays, but with >> boundary checking. >> >> However, in my own testing I have found that it is often faster to >> flatten those multi-dim vectors, and instead use explicit >> multiplication to get the actual position: >> >> Â array[y][x] -> array[y*width + x] >> >> Terje > > I am obviously missing something, but why doesn't the compiler generate > code for that itself? > Because Rust really doesn't have multi-dim vectors, instead using vectors of pointers to vectors? OTOH, it is perfectly OK to create your own multi-dim data structure, and using macros you can probably get the compiler to generate near-optimal code as well, but afaik, nothing like that is part of the core language. I do know that several people have created fast string libraries, where any string that is short enough ends up entirely inside the dope vector, so no heap allocation. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-16 15:18 -0800 |
| Subject | Re: Segments |
| Message-ID | <87zfjq73gh.fsf@nosuchdomain.example.com> |
| In reply to | #110551 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
[...]
> I do know that several people have created fast string libraries,
> where any string that is short enough ends up entirely inside the dope
> vector, so no heap allocation.
Some implementations of C++ std::string do this. For example, the GNU
implementation appears to store up to 16 characters (including the
trailing null character) in the std::string object.
--
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 | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-16 23:39 +0000 |
| Subject | Re: Segments |
| Message-ID | <84d10252cc7b0435cd5f4d6232397371@www.novabbs.org> |
| In reply to | #110560 |
On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: > [...] >> I do know that several people have created fast string libraries, >> where any string that is short enough ends up entirely inside the dope >> vector, so no heap allocation. > > Some implementations of C++ std::string do this. For example, the GNU > implementation appears to store up to 16 characters (including the > trailing null character) in the std::string object. Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-16 17:04 -0800 |
| Subject | Re: Segments |
| Message-ID | <87v7ue6ykc.fsf@nosuchdomain.example.com> |
| In reply to | #110561 |
mitchalsup@aol.com (MitchAlsup1) writes:
> On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> [...]
>>> I do know that several people have created fast string libraries,
>>> where any string that is short enough ends up entirely inside the dope
>>> vector, so no heap allocation.
>>
>> Some implementations of C++ std::string do this. For example, the GNU
>> implementation appears to store up to 16 characters (including the
>> trailing null character) in the std::string object.
>
> Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !!
I don't understand. What pointer are you referring to?
In the implementation I'm referring to, std::string happens to be 32
bytes in size. If the string has a length of 15 or less, the string
data is stored directly in the std::string object (in the last 16 bytes
as it happens). If the string is longer than that it's stored
elsewhere, and that 16 bytes is presumably use to manage the
heap-allocated data.
--
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 | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-17 02:10 +0000 |
| Subject | Re: Segments |
| Message-ID | <17e99d7483b1c62954212fe599a8cb95@www.novabbs.org> |
| In reply to | #110562 |
On Fri, 17 Jan 2025 1:04:03 +0000, Keith Thompson wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >> On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote: >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> [...] >>>> I do know that several people have created fast string libraries, >>>> where any string that is short enough ends up entirely inside the dope >>>> vector, so no heap allocation. >>> >>> Some implementations of C++ std::string do this. For example, the GNU >>> implementation appears to store up to 16 characters (including the >>> trailing null character) in the std::string object. >> >> Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !! > > I don't understand. What pointer are you referring to? The pointer which would have had to point elsewhere had the string not been contained within. > In the implementation I'm referring to, std::string happens to be 32 > bytes in size. If the string has a length of 15 or less, the string > data is stored directly in the std::string object (in the last 16 bytes > as it happens). If the string is longer than that it's stored > elsewhere, and that 16 bytes is presumably use to manage the > heap-allocated data.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-01-17 16:15 +0100 |
| Subject | Re: Segments |
| Message-ID | <vmds6o$32ji$2@dont-email.me> |
| In reply to | #110563 |
On 17/01/2025 03:10, MitchAlsup1 wrote:
> On Fri, 17 Jan 2025 1:04:03 +0000, Keith Thompson wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>> On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote:
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>> [...]
>>>>> I do know that several people have created fast string libraries,
>>>>> where any string that is short enough ends up entirely inside the dope
>>>>> vector, so no heap allocation.
>>>>
>>>> Some implementations of C++ std::string do this. For example, the GNU
>>>> implementation appears to store up to 16 characters (including the
>>>> trailing null character) in the std::string object.
>>>
>>> Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !!
>>
>> I don't understand. What pointer are you referring to?
>
> The pointer which would have had to point elsewhere had the string
> not been contained within.
>
There are a couple of ways you can do "small string optimisation". One
would be to have a structure something like this :
struct String1 {
size_t capacity;
char * data;
char small_string[16];
}
Then "data" would point to "small_string" for a capacity of 16, and if
that's not enough, use malloc to allocate more space.
An alternative would be to have something like this (I'm being /really/
sloppy with alignments, rules for unions, and so on - this is
illustrative only, not real code!) :
struct String2 {
bool is_small;
union {
char small_string[31];
struct {
size_t capacity;
char * data;
}
}
}
This second version lets you put more characters in the local
small_string area, reusing space that would otherwise be used for the
pointer and capacity. But it has more runtime overhead when using the
string :
void print1(String1 s) {
printf(s.data);
}
void print2(String2 s) {
if (s.is_small) {
printf(s.small_string);
} else {
printf(s.data);
}
}
There are, of course, many other ways to make string types (such as
supporting copy-on-write), but I suspect that Mitch is thinking of style
String2 while Keith is thinking of style String1.
>> In the implementation I'm referring to, std::string happens to be 32
>> bytes in size. If the string has a length of 15 or less, the string
>> data is stored directly in the std::string object (in the last 16 bytes
>> as it happens). If the string is longer than that it's stored
>> elsewhere, and that 16 bytes is presumably use to manage the
>> heap-allocated data.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-01-17 18:02 +0100 |
| Subject | Re: Segments |
| Message-ID | <vme2f5$4nes$1@dont-email.me> |
| In reply to | #110570 |
David Brown wrote:
> On 17/01/2025 03:10, MitchAlsup1 wrote:
>> On Fri, 17 Jan 2025 1:04:03 +0000, Keith Thompson wrote:
>>
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>> On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote:
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>> [...]
>>>>>> I do know that several people have created fast string libraries,
>>>>>> where any string that is short enough ends up entirely inside the
>>>>>> dope
>>>>>> vector, so no heap allocation.
>>>>>
>>>>> Some implementations of C++ std::string do this. For example, the
>>>>> GNU
>>>>> implementation appears to store up to 16 characters (including the
>>>>> trailing null character) in the std::string object.
>>>>
>>>> Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !!
>>>
>>> I don't understand. What pointer are you referring to?
>>
>> The pointer which would have had to point elsewhere had the string
>> not been contained within.
>>
>
> There are a couple of ways you can do "small string optimisation". One
> would be to have a structure something like this :
>
> struct String1 {
> size_t capacity;
> char * data;
> char small_string[16];
> }
>
> Then "data" would point to "small_string" for a capacity of 16, and if
> that's not enough, use malloc to allocate more space.
>
>
> An alternative would be to have something like this (I'm being /really/
> sloppy with alignments, rules for unions, and so on - this is
> illustrative only, not real code!) :
>
> struct String2 {
> bool is_small;
> union {
> char small_string[31];
> struct {
> size_t capacity;
> char * data;
> }
> }
> }
>
> This second version lets you put more characters in the local
> small_string area, reusing space that would otherwise be used for the
> pointer and capacity. But it has more runtime overhead when using the
> string :
>
> void print1(String1 s) {
> printf(s.data);
> }
>
> void print2(String2 s) {
> if (s.is_small) {
> printf(s.small_string);
> } else {
> printf(s.data);
> }
> }
>
> There are, of course, many other ways to make string types (such as
> supporting copy-on-write), but I suspect that Mitch is thinking of style
> String2 while Keith is thinking of style String1.
All Vec<> types have a 3-word descriptor, with the first and second word
being a pointer to the data and the current length, while the allocated
size is stored in the third word.
This is a total of 24 bytes, so quite a bit of overhead if you just need
a few bytes.
In the Rust Fast/Small vector type, they could use the top bit of the
size field (no Vec<> object can be larger or equal to 2^63 bytes), then
they need 4 or 5 bits for the actual length (but using 7 is easier),
leaving 23 bytes for the embedded data. With little-endian storage this
corresponds to the last byte of the 24-byte block.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-01-17 10:55 -0800 |
| Subject | Re: Segments |
| Message-ID | <87msfp6zix.fsf@nosuchdomain.example.com> |
| In reply to | #110570 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> There are a couple of ways you can do "small string optimisation".
> One would be to have a structure something like this :
>
> struct String1 {
> size_t capacity;
> char * data;
> char small_string[16];
> }
>
> Then "data" would point to "small_string" for a capacity of 16, and if
> that's not enough, use malloc to allocate more space.
>
>
> An alternative would be to have something like this (I'm being
> /really/ sloppy with alignments, rules for unions, and so on - this is
> illustrative only, not real code!) :
>
> struct String2 {
> bool is_small;
> union {
> char small_string[31];
> struct {
> size_t capacity;
> char * data;
> }
> }
> }
[...]
> There are, of course, many other ways to make string types (such as
> supporting copy-on-write), but I suspect that Mitch is thinking of
> style String2 while Keith is thinking of style String1.
I wasn't particularly thinking of either. I was reporting results
I got from experimenting with the std::string type in the GNU
implementation I use on Ubuntu. Dumping the raw data showed string
data in the last 16 bytes of the 32-byte std::string object when
the length is no more than 15. For longer strings, I suspect that
16-byte area is used for other purposes, so it's probably similar
to String2, but I haven't examined the source code.
--
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 | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-01-17 19:27 +0000 |
| Subject | Re: Segments |
| Message-ID | <5420d17582d6e18ec19550d61af721ad@www.novabbs.org> |
| In reply to | #110562 |
On Fri, 17 Jan 2025 1:04:03 +0000, Keith Thompson wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >> On Thu, 16 Jan 2025 23:18:22 +0000, Keith Thompson wrote: >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> [...] >>>> I do know that several people have created fast string libraries, >>>> where any string that is short enough ends up entirely inside the dope >>>> vector, so no heap allocation. >>> >>> Some implementations of C++ std::string do this. For example, the GNU >>> implementation appears to store up to 16 characters (including the >>> trailing null character) in the std::string object. >> >> Why use an 8-byte pointer to store a string 16 or fewer bytes long ? !! > > I don't understand. What pointer are you referring to? > > In the implementation I'm referring to, std::string happens to be 32 > bytes in size. If the string has a length of 15 or less, the string > data is stored directly in the std::string object (in the last 16 bytes > as it happens). If the string is longer than that it's stored > elsewhere, and that 16 bytes is presumably use to manage the > heap-allocated data. So, when it is stored elsewhere, how do you get from the struct to the string ?? You use a pointer !!
[toc] | [prev] | [next] | [standalone]
Page 21 of 23 — ← Prev page 1 … 19 20 [21] 22 23 Next page →
Back to top | Article view | comp.arch
csiph-web