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 1 of 23 [1] 2 3 … 23 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-01 19:02 +0000 |
| Subject | Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) |
| Message-ID | <550600971b1a36b4b630c496cb21b96b@www.novabbs.org> |
On Tue, 16 Apr 2024 6:23:47 +0000, David Brown wrote: > On 16/04/2024 02:35, Lawrence D'Oliveiro wrote: >> On Sun, 14 Jan 2024 14:30:51 -0500, EricP wrote: >> >>> Furthermore, the address and data registers and buses are 16 bits and >>> the high 16-bits are shared ... >> >> No, in the 68000 family the A- and D- registers are 32 bits. >> >> If you compare the earlier members with the 68020 and later, it becomes >> clear that the architecture was designed as full 32-bit from the >> beginning, and then implemented in a cut-down form for the initial >> 16-bit >> products. Going full 32-bit was just a matter of filling in the gaps. > > Yes, the 68000 was designed to have full support for 32-bit types and a > 32-bit future, but (primarily for cost reasons) used a 16-bit ALU and > 16-bit buses internally and externally. A 32-bit bus would have priced the 68K at 30%-50% higher simply due to the number of pins on available packages. This would have eliminated any chance at competing for the broad markets at that time. > Some 68000 compilers had 16-bit > int, some had 32-bit int, and some let you choose either, since 16-bit > types could be significantly faster on the 68000 even though the > general-purpose registers were 32-bit. Just count the bus cycles.
[toc] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-10-01 20:00 +0000 |
| Message-ID | <vdhkcs$2s651$1@dont-email.me> |
| In reply to | #109362 |
MitchAlsup1 <mitchalsup@aol.com> schrieb: > A 32-bit bus would have priced the 68K at 30%-50% higher simply > due to the number of pins on available packages. This would have > eliminated any chance at competing for the broad markets at that > time. Would have an external 16-bit bus and an internal 32-bit bus have been advantageous, or would this have blown a likely transistor budget for little gain?
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-01 21:04 +0000 |
| Message-ID | <0194054dac788f7e3a163726e84d72ac@www.novabbs.org> |
| In reply to | #109365 |
On Tue, 1 Oct 2024 20:00:28 +0000, Thomas Koenig wrote: > MitchAlsup1 <mitchalsup@aol.com> schrieb: > >> A 32-bit bus would have priced the 68K at 30%-50% higher simply >> due to the number of pins on available packages. This would have >> eliminated any chance at competing for the broad markets at that >> time. > > Would have an external 16-bit bus and an internal 32-bit bus have > been advantageous, or would this have blown a likely transistor > budget for little gain? It was pin limited and internal area limited; and close to being power limited (NMOS).
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2024-10-01 23:38 +0000 |
| Message-ID | <vdi152$2u3v4$1@dont-email.me> |
| In reply to | #109366 |
MitchAlsup1 <mitchalsup@aol.com> wrote: > On Tue, 1 Oct 2024 20:00:28 +0000, Thomas Koenig wrote: > >> MitchAlsup1 <mitchalsup@aol.com> schrieb: >> >>> A 32-bit bus would have priced the 68K at 30%-50% higher simply >>> due to the number of pins on available packages. This would have >>> eliminated any chance at competing for the broad markets at that >>> time. >> >> Would have an external 16-bit bus and an internal 32-bit bus have >> been advantageous, or would this have blown a likely transistor >> budget for little gain? > > It was pin limited and internal area limited; and close to being > power limited (NMOS). > My wish list for the 68k was a barrel roller for fast shifts, would have made a HUGE difference for the first Macintosh.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-03 00:31 +0000 |
| Message-ID | <vdkolv$3ed1r$3@dont-email.me> |
| In reply to | #109372 |
On Tue, 1 Oct 2024 23:38:10 -0000 (UTC), Brett wrote: > My wish list for the 68k was a barrel roller for fast shifts, would have > made a HUGE difference for the first Macintosh. The 68020 certainly had that. It also added bit-field instructions, on top of the single-bit instructions of the original 68000. And in typical big-endian fashion, they added yet another inconsistency to the way the bits were numbered ...
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2024-10-03 01:26 +0000 |
| Message-ID | <vdkrsk$3er6f$1@dont-email.me> |
| In reply to | #109387 |
Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Tue, 1 Oct 2024 23:38:10 -0000 (UTC), Brett wrote: > >> My wish list for the 68k was a barrel roller for fast shifts, would have >> made a HUGE difference for the first Macintosh. > > The 68020 certainly had that. It also added bit-field instructions, on top > of the single-bit instructions of the original 68000. > > And in typical big-endian fashion, they added yet another inconsistency to > the way the bits were numbered ... I noticed that, there is a tiny chance that Apple wanted that to make QuickDraw one cycle faster. But other changes hint that the clue train was not sharp at Motorola. Everyone was muddling back in that era, and being quick to market was the rule, hard to blame them. I can see myself making the very same choices, or much more likely seeing my coworkers make bad choices and not being able to do anything about it. You do what you can with what you have.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-03 06:28 +0000 |
| Message-ID | <2024Oct3.082821@mips.complang.tuwien.ac.at> |
| In reply to | #109387 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >The 68020 certainly had that. It also added bit-field instructions, on top >of the single-bit instructions of the original 68000. > >And in typical big-endian fashion, they added yet another inconsistency to >the way the bits were numbered ... How typical is that? Certainly the Power(PC) numbers its bits in big-endian fashion. But does PowerPC have instructions where that matters? If so, I expect that's not so great with the switch to little-endian in Linux-PPC (IIRC AIX is still big-endian). I expect that the s390x uses the same bit numbering as Power. Does it have instructions where that matters? The 88000 has instructions where that matters and has little-endian bit-ordering (like the 68000, so Motorola is stubborn in its mistakes; OTOH, with Apple as a prospective customer, they probbly did not want to require software changes, even if those changes would make the code shorter). It supports both byte orders, but AFAIK all 88K systems are big-endian. MIPS-I has no instructions where the bit numbering plays a role. It was available in big- and little-endian systems. SPARC uses little-endian bit ordering, but AFAICS has no instructions where that plays a role. AFAIK there is no little-endian SPARC system. So, yes, using little-endian bit ordering with big-endian byte ordering is frequent, but OTOH instructions that actually use bit numbers exist only in few instruction sets. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-03 09:21 +0200 |
| Message-ID | <vdlgl9$3kq50$2@dont-email.me> |
| In reply to | #109387 |
On 03/10/2024 02:31, Lawrence D'Oliveiro wrote: > On Tue, 1 Oct 2024 23:38:10 -0000 (UTC), Brett wrote: > >> My wish list for the 68k was a barrel roller for fast shifts, would have >> made a HUGE difference for the first Macintosh. > > The 68020 certainly had that. It also added bit-field instructions, on top > of the single-bit instructions of the original 68000. > > And in typical big-endian fashion, they added yet another inconsistency to > the way the bits were numbered ... Since you mentioned POWER and PowerPC elsewhere, the bit numbering challenges of the m68k world are nothing compared to the PowerPC world. Originally, the PowerPC was 32-bit and numbered bits from 0 as the MSB down to 31 as the LSB. So your 32-bit address bus had lines from A0 down to A31. Then it got extended to 64-bit (some devices had only partial 64-bit extensions), and the chips got a wider address bus (you never need all 64-bit lines physically) - the pins for the higher address lines were numbered A-1, A-2, and so on. For the internal registers, some are 64-bit numbered bit 0 (MSB) down to bit 63. Some were original 32-bit and got extended to 64-bit, and so are numbered bit -32 down to bit 31 for consistency. Others are 32-bit but numbered from bit 32 down to bit 63. I am not really complaining - one of our customers hired us precisely because they wanted to use a particular PowerPC microcontroller but after one look at the ten thousand page reference manual full of this kind of thing, they paid us to write a library and drivers for the peripherals they wanted so that they never had to think about that mess.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-03 09:39 +0000 |
| Subject | Byte ordering (was: Whether something is RISC or not) |
| Message-ID | <2024Oct3.113903@mips.complang.tuwien.ac.at> |
| In reply to | #109397 |
David Brown <david.brown@hesbynett.no> writes: >Since you mentioned POWER and PowerPC elsewhere, the bit numbering >challenges of the m68k world are nothing compared to the PowerPC world. >Originally, the PowerPC was 32-bit and numbered bits from 0 as the MSB >down to 31 as the LSB. So your 32-bit address bus had lines from A0 >down to A31. Then it got extended to 64-bit (some devices had only >partial 64-bit extensions), and the chips got a wider address bus (you >never need all 64-bit lines physically) - the pins for the higher >address lines were numbered A-1, A-2, and so on. For the internal >registers, some are 64-bit numbered bit 0 (MSB) down to bit 63. Some >were original 32-bit and got extended to 64-bit, and so are numbered bit >-32 down to bit 31 for consistency. Others are 32-bit but numbered from >bit 32 down to bit 63. Maybe they should have started with the MSB as bit -31 or -63, which would have allowed them to always use bit 0 for the LSB while having big-endian bit ordering. For bit ordering big-endian (as in the PowerPC manual) looked more wrong to me than for byte ordering; I thought that that was just a matter of getting used to the unfamiliar bit ordering, but maybe the advantage of little-endian becomes more apparent in bit ordering, and maybe that's why Motorola and Sun chose little-endian bit ordering despite having big-endian byte ordering. For both bit and byte ordering, the advantage of little-endian shows up when there are several widths involved. So why is it more obvious for bit-ordering? BTW, at least in my 32-bit PowerPC manual the claim is that PowerPC is a 64-bit architecture, and that the manual describes only the 32-bit subset. Maybe the original Power was 32-bit. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-03 14:34 +0200 |
| Subject | Re: Byte ordering (was: Whether something is RISC or not) |
| Message-ID | <vdm30r$3nrof$1@dont-email.me> |
| In reply to | #109402 |
On 03/10/2024 11:39, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> Since you mentioned POWER and PowerPC elsewhere, the bit numbering >> challenges of the m68k world are nothing compared to the PowerPC world. >> Originally, the PowerPC was 32-bit and numbered bits from 0 as the MSB >> down to 31 as the LSB. So your 32-bit address bus had lines from A0 >> down to A31. Then it got extended to 64-bit (some devices had only >> partial 64-bit extensions), and the chips got a wider address bus (you >> never need all 64-bit lines physically) - the pins for the higher >> address lines were numbered A-1, A-2, and so on. For the internal >> registers, some are 64-bit numbered bit 0 (MSB) down to bit 63. Some >> were original 32-bit and got extended to 64-bit, and so are numbered bit >> -32 down to bit 31 for consistency. Others are 32-bit but numbered from >> bit 32 down to bit 63. > > Maybe they should have started with the MSB as bit -31 or -63, which > would have allowed them to always use bit 0 for the LSB while having > big-endian bit ordering. > That's a very "outside the box thinking" solution! > For bit ordering big-endian (as in the PowerPC manual) looked more > wrong to me than for byte ordering; I thought that that was just a > matter of getting used to the unfamiliar bit ordering, but maybe the > advantage of little-endian becomes more apparent in bit ordering, and > maybe that's why Motorola and Sun chose little-endian bit ordering > despite having big-endian byte ordering. > > For both bit and byte ordering, the advantage of little-endian shows > up when there are several widths involved. So why is it more obvious > for bit-ordering? I have certainly found big-endian bit numbering harder to get my head around than big-endian byte ordering. One possible explanation is that with little-endian ordering, (1 << bit_no) gives you a 1 in the right bit number. Another is that with little-endian bit ordering, the same bit number has the same value regardless of the size of the type. And I work with electronics as well as software - virtually everything in hardware (except PowerPC microcontrollers!) uses little-endian bit numbering. Smallest to largest, counting upwards from 0 or 1, is just more natural. > > BTW, at least in my 32-bit PowerPC manual the claim is that PowerPC is > a 64-bit architecture, and that the manual describes only the 32-bit > subset. Maybe the original Power was 32-bit. > As I understand it - and my history here might not be completely accurate - PowerPC was specified for both 32-bit and 64-bit from early on, but first made in the 32-bit version. There were quite a number of optional parts of the PowerPC architecture, including 64-bit width, floating point units, and support for little-endian data modes - IIRC these were referred to as books of various colours. And yes, you could then have weird things like it being a 64-bit architecture where none of the 64-bit features were actually implemented. One microcontroller I used had 64-bit GPRs, but almost no 64-bit instructions - I don't think you could even load or save all 64 bits at a time. The only use of them was for transferring to and from the 64-bit double precision floating point registers (which could be loaded and saved in full).
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-03 22:17 +0000 |
| Subject | Re: Byte ordering (was: Whether something is RISC or not) |
| Message-ID | <vdn55j$3ssv4$11@dont-email.me> |
| In reply to | #109402 |
On Thu, 03 Oct 2024 09:39:03 GMT, Anton Ertl wrote: > BTW, at least in my 32-bit PowerPC manual the claim is that PowerPC is a > 64-bit architecture, and that the manual describes only the 32-bit > subset. Maybe the original Power was 32-bit. I would say IBM designed 32-bit POWER/PowerPC as a cut-down 64-bit architecture, needing only a few gaps filled to make it fully 64-bit. The PowerPC 601 was first shown publicly in 1993; I can’t remember when the fully 64-bit 620 came out, but it can’t have been long after. Motorola did a similar thing with the 68000 family: if you compare the original 68000 instruction set with the 68020, you will see the latter only needed to fill in a few gaps to become fully 32-bit. Compare this with the pain the x86 world went through, over a much longer time, to move to 32-bit.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2024-10-03 15:33 -1000 |
| Subject | Re: Byte ordering |
| Message-ID | <87frpcslbx.fsf@localhost> |
| In reply to | #109412 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > I would say IBM designed 32-bit POWER/PowerPC as a cut-down 64-bit > architecture, needing only a few gaps filled to make it fully 64-bit. > > The PowerPC 601 was first shown publicly in 1993; I can’t remember when > the fully 64-bit 620 came out, but it can’t have been long after. > > Motorola did a similar thing with the 68000 family: if you compare the > original 68000 instruction set with the 68020, you will see the latter > only needed to fill in a few gaps to become fully 32-bit. > > Compare this with the pain the x86 world went through, over a much longer > time, to move to 32-bit. power/pc was done at Somerset ... part of AIM; apple, ibm, motorola ... and some of amount of motorola risc 88k contributed to power/pc https://en.wikipedia.org/wiki/PowerPC https://en.wikipedia.org/wiki/PowerPC_600 https://en.wikipedia.org/wiki/PowerPC_600#60x_bus Using the 88110 bus as the basis for the 60x bus helped schedules in a number of ways. It helped the Apple Power Macintosh team by reducing the amount of redesign of their support ASICs and it reduced the amount of time required for the processor designers and architects to propose, document, negotiate, and close a new bus interface (successfully avoiding the "Bus Wars" expected by the 601 management team if the 88110 bus or the previous RSC buses hadn't been adopted). Worthy to note is that accepting the 88110 bus for the benefit of Apple's efforts and the alliance was at the expense of the first IBM RS/6000 system design team's efforts who had their support ASICs already implemented around the RSC's totally different bus structure. ... note that RS/6000 didn't have design that supported cache consistency, shared-memory multiprocessing ... (one of the reason ha/cmp had to resort to cluster operation for scale-up) https://en.wikipedia.org/wiki/PowerPC_600#PowerPC_620 https://wiki.preterhuman.net/The_Somerset_Design_Center the executive we reported to when we were doing HA/CMP https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_Multiprocessing went over to head up Somerset -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-04 11:23 +0200 |
| Subject | Re: Byte ordering (was: Whether something is RISC or not) |
| Message-ID | <vdoc76$5cna$2@dont-email.me> |
| In reply to | #109412 |
On 04/10/2024 00:17, Lawrence D'Oliveiro wrote: > On Thu, 03 Oct 2024 09:39:03 GMT, Anton Ertl wrote: > >> BTW, at least in my 32-bit PowerPC manual the claim is that PowerPC is a >> 64-bit architecture, and that the manual describes only the 32-bit >> subset. Maybe the original Power was 32-bit. > > I would say IBM designed 32-bit POWER/PowerPC as a cut-down 64-bit > architecture, needing only a few gaps filled to make it fully 64-bit. > > The PowerPC 601 was first shown publicly in 1993; I can’t remember when > the fully 64-bit 620 came out, but it can’t have been long after. > I don't remember the history well enough here. > Motorola did a similar thing with the 68000 family: if you compare the > original 68000 instruction set with the 68020, you will see the latter > only needed to fill in a few gaps to become fully 32-bit. > The m68k was always designed as a 32-bit ISA. But the first 68000 implementation used a 16-bit ALU and internal buses for size and cost reasons. I would not describe the additional instructions in the 68020 as "filling gaps to 32-bit", but merely a natural expansion of the ISA with a few more useful instructions. > Compare this with the pain the x86 world went through, over a much longer > time, to move to 32-bit. The x86 started from 8-bit roots, and increased width over time, which is a very different path. And much of the reason for it being a slow development is that the world was held back by MS's lack of progress in using new features. The 80386 was produced in 1986, but the MS world was firmly at 16-bit under it gained a bit of 32-bit features with Windows 95. (Windows NT was 32-bit from 1993, and Win32s was from around the same time, but these were relatively small in the market.)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-10-04 17:30 +0000 |
| Subject | Re: Byte ordering (was: Whether something is RISC or not) |
| Message-ID | <2024Oct4.193007@mips.complang.tuwien.ac.at> |
| In reply to | #109428 |
David Brown <david.brown@hesbynett.no> writes: >On 04/10/2024 00:17, Lawrence D'Oliveiro wrote: >> Compare this with the pain the x86 world went through, over a much longer >> time, to move to 32-bit. > >The x86 started from 8-bit roots, and increased width over time, which >is a very different path. Still, the question is why they did the 286 (released 1982) with its protected mode instead of adding IA-32 to the architecture, maybe at the start with a 386SX-like package and with real-mode only, or with the MMU in a separate chip (like the 68020/68551). >And much of the reason for it being a slow development is that the world >was held back by MS's lack of progress in using new features. The 80386 >was produced in 1986, but the MS world was firmly at 16-bit under it >gained a bit of 32-bit features with Windows 95. (Windows NT was 32-bit >from 1993, and Win32s was from around the same time, but these were >relatively small in the market.) At that time the market was moving much slower than nowadays. Systems with a 286 (and maybe even the 8088) were sold for a long time after the 386 was introduced. E.g., the IBM PS/1 Model 2011 was released in 1990 with a 10MHz 286, and the successor Model 2121 with a 386SX was not introduced until 1992. I think it's hard to blame MS for targeting the machines that were out there. And looking at <https://en.wikipedia.org/wiki/Windows_2.1x>, Windows 2.1 in 1988 already was available in a Windows/386 version (but the programs were running in virtual 8086 mode, i.e., were still 16-bit programs). And it was not just MS who was going in that direction. MS and IBM worked on OS/2, and despite ambitious goals IBM insisted that the software had to run on a 286. The fact that the 386SX only appeared in 1988 also did not help. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-10-04 14:05 -0500 |
| Subject | Re: Byte ordering |
| Message-ID | <vdpe9c$a94i$2@dont-email.me> |
| In reply to | #109432 |
On 10/4/2024 12:30 PM, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 04/10/2024 00:17, Lawrence D'Oliveiro wrote: >>> Compare this with the pain the x86 world went through, over a much longer >>> time, to move to 32-bit. >> >> The x86 started from 8-bit roots, and increased width over time, which >> is a very different path. > > Still, the question is why they did the 286 (released 1982) with its > protected mode instead of adding IA-32 to the architecture, maybe at > the start with a 386SX-like package and with real-mode only, or with > the MMU in a separate chip (like the 68020/68551). > >> And much of the reason for it being a slow development is that the world >> was held back by MS's lack of progress in using new features. The 80386 >> was produced in 1986, but the MS world was firmly at 16-bit under it >> gained a bit of 32-bit features with Windows 95. (Windows NT was 32-bit >>from 1993, and Win32s was from around the same time, but these were >> relatively small in the market.) > > At that time the market was moving much slower than nowadays. Systems > with a 286 (and maybe even the 8088) were sold for a long time after > the 386 was introduced. E.g., the IBM PS/1 Model 2011 was released in > 1990 with a 10MHz 286, and the successor Model 2121 with a 386SX was > not introduced until 1992. I think it's hard to blame MS for > targeting the machines that were out there. And looking at > <https://en.wikipedia.org/wiki/Windows_2.1x>, Windows 2.1 in 1988 > already was available in a Windows/386 version (but the programs were > running in virtual 8086 mode, i.e., were still 16-bit programs). > > And it was not just MS who was going in that direction. MS and IBM > worked on OS/2, and despite ambitious goals IBM insisted that the > software had to run on a 286. > > The fact that the 386SX only appeared in 1988 also did not help. > If old stuff is still around and usable, it works... Meanwhile, nowadays stuff is starting to decide that my Zen+ is too old... Win 11 apparently regards my system as incompatible (not that I would really want to run it anyways; would almost rather jump over to Linux land at this point if Win10 becomes unusable, which possibly isn't really a good sign). I am left still running WSL1 and needing to resort to FOSS emulators when needed (like DOSBox and QEMU), because WSL2 and most commercially made VMs had gone over to requiring hardware virtualization, which doesn't work on my PC for whatever reason (despite being supported by the CPU and enabled in the BIOS, *). If stuff isn't cheap, people aren't going to just drop whatever they have and buy something new as soon as it appears on the market. So, conservatism makes sense here: Delay requiring new thing until pretty much everything in the wild is new enough to support it. *: WSL1 works apparently by emulating Linux syscalls on top of the Windows kernel, whereas WSL2 runs a Linux kernel in a VM apparently with a translation glue layer to interface with the underlying OS. Ironically, a use-case for DOSBox is using it to run Win 3.11, which amusingly is able to run most Win16 era software, in the cases where one feels inclined to run Win16 era software. There are some tools from this era that ironically lack good modern equivalents. Say, pretty much none of the modern graphics programs (that I am aware of) really support working with 16-color and 256-color bitmap images with a manually specified color palette. Typically, any modern programs are true-color internally, typically only supporting 256-color as an import/export format with an automatically generated "optimized" palette, and often not bothering with 16-color images at all. Not so useful if one is doing something that does actually have a need for an explicit color palette (and does not have so much need for any "photo manipulation" features). And, most people generally haven't bothered with this stuff since the Win16 era (even the people doing "pixel art" are still generally doing so using true-color PNGs or similar). Could theoretically make my own, but had thus far not bothered. Well, and in some cases it is less effort to use modern image editing tools and then convert the images into 4 or 8 bit BMP images as needed (so, for reasons of internal wonk, besides just being a compiler, BGBCC also has some image and audio conversion functionality; mostly in relation to working with resource sections and WADs). Theoretically, there is also a BMP editor hidden in Visual Studio somewhere, but not really an easy/obvious way to get to it. Trying to invoke Visual Studio on image files does not appear to work. > - anton
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2024-10-04 23:06 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <2b3512684d535c1e56d0d7b8ddac51a8@www.novabbs.org> |
| In reply to | #109435 |
On Fri, 4 Oct 2024 19:05:15 +0000, BGB wrote:
> On 10/4/2024 12:30 PM, Anton Ertl wrote:
>
> Say, pretty much none of the modern graphics programs (that I am aware
> of) really support working with 16-color and 256-color bitmap images
> with a manually specified color palette.
>
> Typically, any modern programs are true-color internally, typically only
> supporting 256-color as an import/export format with an automatically
> generated "optimized" palette, and often not bothering with 16-color
> images at all. Not so useful if one is doing something that does
> actually have a need for an explicit color palette (and does not have so
> much need for any "photo manipulation" features).
1996 version of CorelDraw 3 suffers from none of this, supporting all
sorts of pallets {RGB, CYM, CYMK, at least 3 more) with various
user specified limitations, 24-bit, 32-bit, ... with all sorts of
fillers mixing any 2 colors previous mentioned with various patterns
{gradient, polka dot, you define which pixel gets from which color}.
Still have the CD-ROM if anyone wants to try.
>
> And, most people generally haven't bothered with this stuff since the
> Win16 era (even the people doing "pixel art" are still generally doing
> so using true-color PNGs or similar).
Blame PowerPoint ... No more evil tool ever existed.
>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-10-04 19:44 -0500 |
| Subject | Re: Byte ordering |
| Message-ID | <vdq25r$f1qq$1@dont-email.me> |
| In reply to | #109444 |
On 10/4/2024 6:06 PM, MitchAlsup1 wrote:
> On Fri, 4 Oct 2024 19:05:15 +0000, BGB wrote:
>
>> On 10/4/2024 12:30 PM, Anton Ertl wrote:
>>
>> Say, pretty much none of the modern graphics programs (that I am aware
>> of) really support working with 16-color and 256-color bitmap images
>> with a manually specified color palette.
>>
>> Typically, any modern programs are true-color internally, typically only
>> supporting 256-color as an import/export format with an automatically
>> generated "optimized" palette, and often not bothering with 16-color
>> images at all. Not so useful if one is doing something that does
>> actually have a need for an explicit color palette (and does not have so
>> much need for any "photo manipulation" features).
>
> 1996 version of CorelDraw 3 suffers from none of this, supporting all
> sorts of pallets {RGB, CYM, CYMK, at least 3 more) with various
> user specified limitations, 24-bit, 32-bit, ... with all sorts of
> fillers mixing any 2 colors previous mentioned with various patterns
> {gradient, polka dot, you define which pixel gets from which color}.
>
> Still have the CD-ROM if anyone wants to try.
>
I didn't mean "colorspace" here, but say if one wants to use a 16-color
palette, like, say:
0=Black (000000), 1=DarkBlue (0000AA),
2=DarkGreen (00AA00), 3=DarkCyan (00AAAA),
4=DarkRed (AA0000), 5=Magenta (AA00AA)
6=Brown* (AA5500), 7=LightGray (AAAAAA),
8=DarkGray (555555), 9=LightBlue (5555FF),
10=LightGreen (55FF55), ...
15=White (FFFFFF)
And then save as a 16-color BMP image with these specific colors at
these specific indices.
*: Where there is variability in convention here between sort of a
sickly dark yellow color and brown (Say: AAAA00 or AA5500).
1990s era versions of MS PaintBrush or MS BitEdit, "Yeah, sure".
Modern tools: "What even are you asking?..."
Or, say, one has a 256 color palette with N shades of M colors, and
needs to draw an image specifically with those colors, ...
And one wants to draw at a low resolution by plotting individual pixels, ...
But, the old tools don't really run on anything newer than 32-bit WinXP.
Or, one can run them in Win 3.11 inside DOSBOx, but this is inconvenient.
One can draw with the colors they want in newer tools (in an RGB sense),
but can't generally save in specific BMP variant with a specific
manually-specified color palette.
Typically the tools only allow for an automatically generated
"optimized" palette.
>>
>> And, most people generally haven't bothered with this stuff since the
>> Win16 era (even the people doing "pixel art" are still generally doing
>> so using true-color PNGs or similar).
>
> Blame PowerPoint ... No more evil tool ever existed.
Dunno.
MS had some specialized tools in this era:
BitEdit: Like PaintBrush but more versatile;
PalEdit: Could specify color-palettes for use with BitEdit;
IcoEdit: Like BitEdit but worked with icon / ICO files.
Which, were like BMP but hard-wired to 32x32 16-color and similar.
...
MS PaintBrush became MS Paint and seemingly mostly got dumbed down as
time went on. Modern versions of Paint can open PNG and JPG but is in
most regards inferior to the early versions at pixel-editing tasks.
Closest modern alternative is Paint.NET, but still doesn't allow manual
palette control in the same way as BitEdit.
But, then again, in contexts where I need such files, I can generally
use converter tools.
>>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-05 06:35 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vdqmoc$lo51$10@dont-email.me> |
| In reply to | #109447 |
On Fri, 4 Oct 2024 19:44:40 -0500, BGB wrote: > MS PaintBrush became MS Paint and seemingly mostly got dumbed down as > time went on. Side excursion into 3D Paint (or is that Paint 3D?), which failed to take off, and is now being abandoned. > Closest modern alternative is Paint.NET, but still doesn't allow manual > palette control in the same way as BitEdit. Inkscape has good palette control. It does scalable vector graphics natively. Give it a try.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-05 06:34 +0000 |
| Subject | Re: Byte ordering |
| Message-ID | <vdqmlk$lo51$9@dont-email.me> |
| In reply to | #109444 |
On Fri, 4 Oct 2024 23:06:21 +0000, MitchAlsup1 wrote: > Blame PowerPoint ... No more evil tool ever existed. Competitors existed, at one time, e.g. Adobe Persuasion, Harvard Graphics, others I’ve forgotten. Somehow Microsoft made PowerPoint the most attractive of the lot ... were the others even worse? Actually, it’s not that it doesn’t produce pretty graphics, it’s that people end up believing in the prettiness of the graphics, instead of considering the facts they’re supposed to (mis)represent. Edward Tufte, come back, all is forgiven!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-10-05 06:31 +0000 |
| Subject | Re: Byte ordering (was: Whether something is RISC or not) |
| Message-ID | <vdqmf6$lo51$8@dont-email.me> |
| In reply to | #109432 |
On Fri, 04 Oct 2024 17:30:07 GMT, Anton Ertl wrote: > The fact that the 386SX only appeared in 1988 also did not help. As a software guy, I liked the idea of the 386SX, and encouraged friends/ colleagues to choose it over a 286. Of course, they wanted to compare price/performance, but I saw things in terms of future software compatibility, and the sooner the move away from braindead x86 segmentation towards a nice, flat, expansive, linear address space, the better for everybody. Sometimes I felt like a voice crying in the wilderness ...
[toc] | [prev] | [next] | [standalone]
Page 1 of 23 [1] 2 3 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web