Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #116526 > unrolled thread
| Started by | quadi <quadibloc@ca.invalid> |
|---|---|
| First post | 2026-05-19 20:14 +0000 |
| Last post | 2026-05-30 19:03 +0000 |
| Articles | 20 on this page of 582 — 32 participants |
Back to article view | Back to comp.arch
Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-19 20:14 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-20 00:03 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-20 00:34 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-20 01:35 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-20 02:09 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-20 02:26 +0000
Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-20 05:38 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) Thomas Koenig <tkoenig@netcologne.de> - 2026-05-20 08:10 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-20 08:36 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) Thomas Koenig <tkoenig@netcologne.de> - 2026-05-20 10:37 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-20 11:04 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) Thomas Koenig <tkoenig@netcologne.de> - 2026-05-20 17:01 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-20 17:30 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) scott@slp53.sl.home (Scott Lurndal) - 2026-05-20 15:03 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) John Levine <johnl@taugh.com> - 2026-05-20 18:07 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) scott@slp53.sl.home (Scott Lurndal) - 2026-05-20 19:03 +0000
Re: Byte order and BCD Terje Mathisen <terje.mathisen@tmsw.no> - 2026-05-20 21:45 +0200
Re: Byte order and BCD scott@slp53.sl.home (Scott Lurndal) - 2026-05-21 14:36 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) quadi <quadibloc@ca.invalid> - 2026-05-20 22:50 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) John Levine <johnl@taugh.com> - 2026-05-21 00:37 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) quadi <quadibloc@ca.invalid> - 2026-05-21 02:18 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-21 06:29 +0000
Re: ancient virtual memory, Byte order and BCD (was: Concertina IV Has Arrived) John Levine <johnl@taugh.com> - 2026-05-21 15:41 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) quadi <quadibloc@ca.invalid> - 2026-05-20 15:28 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-20 15:42 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) quadi <quadibloc@ca.invalid> - 2026-05-20 17:25 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-21 11:52 +0000
Re: Byte order and BCD Terje Mathisen <terje.mathisen@tmsw.no> - 2026-05-20 21:33 +0200
Re: Byte order and BCD anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-21 10:29 +0000
Re: Byte order and BCD anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-21 12:04 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) quadi <quadibloc@ca.invalid> - 2026-06-03 00:41 +0000
Re: Byte order and BCD (was: Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-03 17:13 +0000
Re: Concertina IV Has Arrived Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> - 2026-05-20 10:42 +0200
Re: Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-05-20 15:32 +0000
Re: BCD, was Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-20 17:47 +0000
Re: BCD, was Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 01:14 +0000
Re: BCD, was Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-06-01 02:20 +0000
2s-complement and byte order (was: BCD) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-01 07:47 +0000
Re: 2s-complement and byte order (was: BCD) Thomas Koenig <tkoenig@netcologne.de> - 2026-06-01 16:04 +0000
Re: 2s-complement and byte order (was: BCD) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-01 18:01 +0000
Re: 2s-complement and byte order (was: BCD) John Levine <johnl@taugh.com> - 2026-06-01 18:26 +0000
Re: 2s-complement and byte order (was: BCD) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-02 01:22 +0000
Re: 2s-complement and byte order (was: BCD) John Levine <johnl@taugh.com> - 2026-06-02 01:57 +0000
Re: 2s-complement and byte order (was: BCD) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-02 17:04 +0000
Re: 2s-complement and byte order (was: BCD) quadi <quadibloc@ca.invalid> - 2026-06-01 18:08 +0000
Re: 2s-complement and byte order (was: BCD) John Levine <johnl@taugh.com> - 2026-06-01 18:13 +0000
Re: BCD, was Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 17:59 +0000
Re: BCD, was Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-06-01 20:00 +0000
Re: BCD, was Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 21:57 +0000
byte order (was: BCD) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-01 08:36 +0000
Re: BCD, was Concertina IV Has Arrived jgd@cix.co.uk (John Dallman) - 2026-06-02 14:00 +0100
Re: BCD, was Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-02 14:54 +0000
Re: BCD, was Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 16:13 +0000
Re: BCD, was Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-02 17:13 +0000
Re: BCD, was Concertina IV Has Arrived Thomas Koenig <tkoenig@netcologne.de> - 2026-06-02 18:25 +0000
Re: BCD, was Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-02 19:07 +0000
Re: BCD, was Concertina IV Has Arrived Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-06-02 11:44 -0700
Re: BCD, was Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-02 19:37 +0000
Re: BCD, was Concertina IV Has Arrived EricP <ThatWouldBeTelling@thevillage.com> - 2026-06-03 08:29 -0400
Re: BCD, was Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-02 17:09 +0000
bit order and byte order (was: BCD) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-02 15:59 +0000
Re: bit order and byte order (was: BCD) quadi <quadibloc@ca.invalid> - 2026-06-03 00:37 +0000
Re: bit order and byte order (was: BCD) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-03 17:44 +0000
Re: bit order and byte order (was: BCD) George Neuner <gneuner2@comcast.net> - 2026-06-03 19:05 -0400
Re: bit order and byte order (was: BCD) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-04 12:45 +0000
Re: endian history, was BCD, was Concertina John Levine <johnl@taugh.com> - 2026-06-02 22:00 +0000
Re: endian history, was BCD, was Concertina quadi <quadibloc@ca.invalid> - 2026-06-03 00:21 +0000
Re: endian history, was BCD, was Concertina MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-03 01:03 +0000
Re: endian history, was BCD, was Concertina quadi <quadibloc@ca.invalid> - 2026-06-03 01:52 +0000
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-06-03 13:54 +0000
Re: endian history, was BCD, was Concertina quadi <quadibloc@ca.invalid> - 2026-06-03 15:33 +0000
Re: endian history, was BCD, was Concertina John Levine <johnl@taugh.com> - 2026-06-03 17:36 +0000
Re: endian history, was BCD, was Concertina "Brian G. Lucas" <bagel99@gmail.com> - 2026-06-04 11:53 -0500
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-06-03 19:22 +0000
Re: endian history, was BCD, was Concertina jgd@cix.co.uk (John Dallman) - 2026-09-05 22:10 +0100
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 09:20 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-06 11:47 +0200
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 12:17 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-06 15:24 +0200
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 14:41 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-06 19:20 +0200
Re: endian history, was BCD, was Concertina MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:51 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-07 10:10 +0200
Re: endian history, was BCD, was Concertina MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:22 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-07 23:24 +0200
Re: endian history, was BCD, was Concertina MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 22:00 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-08 11:25 +0200
Re: endian history, was BCD, was Concertina scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:02 +0000
Re: endian history, was BCD, was Concertina David Brown <david.brown@hesbynett.no> - 2026-09-08 20:32 +0200
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 19:03 +0000
Re: endian history, was BCD, was Concertina scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 20:59 +0000
Re: endian history, was BCD, was Concertina Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-07 02:40 +0000
Re: endian history, was BCD, was Concertina jgd@cix.co.uk (John Dallman) - 2026-09-06 19:33 +0100
Re: endian history, was BCD, was Concertina John Levine <johnl@taugh.com> - 2026-09-07 15:57 +0000
Re: endian history, was BCD, was Concertina Thomas Koenig <tkoenig@netcologne.de> - 2026-09-07 17:00 +0000
Re: endian history, was BCD, was Concertina John Levine <johnl@taugh.com> - 2026-09-08 13:24 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-05 08:17 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-05 13:52 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-05 15:58 +0200
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-05 14:55 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-05 17:24 +0200
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-05 16:57 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-06 02:06 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 07:04 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-06 18:38 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 21:50 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-08 02:33 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-08 03:46 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-08 17:31 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 20:13 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:22 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-09 01:10 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 01:33 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-09 11:06 +0200
Re: endian history Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-08 23:57 -0400
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:57 +0000
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-06 17:31 -0700
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-06 21:46 -0700
Re: endian history Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-07 13:57 +0800
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-07 15:23 -0700
OT writing direction Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 20:15 -0700
Re: OT writing direction Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-08 03:44 +0000
Re: OT writing direction Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 17:23 +0000
Re: OT writing direction Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 07:49 -0700
Re: OT writing direction Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-15 10:09 -0700
Re: OT writing direction Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-20 07:14 -0700
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 17:16 +0000
Re: endian history George Neuner <gneuner2@comcast.net> - 2026-09-09 20:22 -0400
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 01:25 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 12:09 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 09:19 -0700
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-07 02:35 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:14 +0000
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-07 05:05 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-07 10:32 +0200
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-08 02:36 +0000
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 20:21 -0700
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-08 11:32 +0200
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-08 08:31 -0700
Re: endian history Andreas Eder <a_eder_muc@web.de> - 2026-09-17 10:23 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-07 15:25 -0700
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-06 13:57 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-09-06 12:41 -0500
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 21:53 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:12 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-09-06 23:34 -0500
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 10:29 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-07 13:56 +0200
Re: endian history Michael S <already5chosen@yahoo.com> - 2026-09-07 23:54 +0300
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 05:07 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-08 21:14 +0200
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-05 21:16 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-06 01:55 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 02:09 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-06 18:28 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:54 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-07 02:44 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 15:39 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 07:07 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-06 14:00 +0000
Re: endian history antispam@fricas.org (Waldek Hebisch) - 2026-09-07 20:24 +0000
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 16:58 -0700
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-08 02:47 +0000
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 20:23 -0700
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-08 03:49 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:00 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-08 02:45 +0000
Re: endian history John Levine <johnl@taugh.com> - 2026-09-08 08:38 +0000
Re: endian history quadibloc@invalid.com (John Savard) - 2026-09-09 01:12 +0000
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 10:56 +0000
Re: endian history John Levine <johnl@taugh.com> - 2026-09-08 13:34 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-08 21:23 +0200
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 08:04 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 23:21 +0200
Base64 ISA (was: endian history) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-14 12:39 -0400
Re: Base64 ISA Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 11:26 +0200
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 19:30 +0000
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 08:22 +0000
Re: endian history Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 14:55 -0400
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-14 10:29 -0700
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 11:32 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 08:53 -0700
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-14 17:32 +0000
Re: endian history Paul Clayton <paaronclayton@gmail.com> - 2026-09-23 21:09 -0400
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:09 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-14 23:29 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 12:49 +0200
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-15 13:01 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 16:51 +0200
Re: endian history antispam@fricas.org (Waldek Hebisch) - 2026-09-16 04:41 +0000
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-16 05:53 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-16 07:52 +0000
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 07:29 -0700
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 15:49 +0000
Re: endian history Jeroen Belleman <jeroen@nospam.please> - 2026-09-16 10:48 +0200
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-16 16:21 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 00:38 -0700
Re: endian history Michael S <already5chosen@yahoo.com> - 2026-09-18 17:29 +0300
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-18 16:48 +0200
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-18 16:47 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 15:36 -0700
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 19:51 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 08:28 -0700
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-23 18:01 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 10:47 -0700
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-23 18:41 +0000
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 13:15 -0700
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-24 15:09 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-25 02:47 -0700
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 17:00 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-24 18:35 +0000
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-25 03:19 -0700
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-26 07:41 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-27 02:48 +0000
Re: endian history Robert Finch <robfi680@gmail.com> - 2026-09-26 23:49 -0400
Re: endian history Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-27 12:06 +0300
Re: endian history Robert Finch <robfi680@gmail.com> - 2026-09-27 06:14 -0400
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-27 23:57 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-28 14:33 +0200
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-28 10:38 +0200
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-28 08:50 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-28 11:23 +0200
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 22:50 +0000
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-29 06:11 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-27 17:47 +0000
Re: endian history John Levine <johnl@taugh.com> - 2026-09-27 18:21 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:13 +0000
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-28 13:05 -0700
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-27 16:56 +0200
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-27 20:01 -0700
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 06:14 +0000
Re: arithmetic and endian history John Levine <johnl@taugh.com> - 2026-09-28 14:08 +0000
Re: arithmetic and endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-28 16:54 +0000
Re: arithmetic and endian history John Levine <johnl@taugh.com> - 2026-09-28 21:46 +0000
Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-29 08:01 +0000
Re: Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 14:26 +0000
Re: Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-29 17:21 +0000
Re: Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 17:28 +0000
Re: Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-09-29 20:16 +0000
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 09:00 +0000
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 09:30 +0000
Re: Flags (Re: arithmetic and endian history) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 06:49 -0700
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 15:05 +0000
Re: Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-01 16:04 +0000
Re: Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-02 01:30 +0000
Re: Flags (Re: arithmetic and endian history) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 19:27 -0700
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-02 02:45 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-02 09:53 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-02 19:10 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-03 17:18 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-03 19:54 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-03 20:49 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-03 22:05 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 08:09 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 15:14 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-04 18:29 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:29 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 03:20 -0700
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-06 17:24 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 01:46 -0700
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-12 17:37 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-13 21:57 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 07:50 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-14 23:08 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-03 19:55 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-04 06:50 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 15:11 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-04 19:38 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 07:30 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-06 18:07 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 21:17 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-06 23:30 +0200
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-07 10:16 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-07 19:53 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-03 23:49 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-04 01:04 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 07:47 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-04 18:02 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-11-02 09:45 -0800
Re: two's complement and Flags (Re: arithmetic and endian history) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-11-02 10:12 -0800
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-02 18:43 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-11-02 20:00 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-11-02 20:28 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-11-03 01:34 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) David Brown <david.brown@hesbynett.no> - 2026-11-03 08:35 +0100
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-11-02 20:25 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-11-05 23:36 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-06 03:22 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-06 06:24 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-11-06 12:08 +0100
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-06 15:08 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-11-06 20:50 +0100
Re: two's complement and Flags (Re: arithmetic and endian history) Jeroen Belleman <jeroen@nospam.please> - 2026-11-06 16:50 +0100
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-06 19:22 +0000
carry-in (was: two's complement and Flags) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-07 07:41 +0000
Re: carry-in (was: two's complement and Flags) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-07 12:09 +0000
Re: carry-in (was: two's complement and Flags) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-07 16:19 +0000
Re: carry-in (was: two's complement and Flags) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-07 18:20 +0000
6502 vs Z80 (was: carry-in) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-07 18:35 +0000
Re: carry-in (was: two's complement and Flags) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-07 22:38 +0000
Re: carry-in antispam@fricas.org (Waldek Hebisch) - 2026-11-08 18:52 +0000
Re: carry-in Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-11-07 10:17 -0800
Re: carry-in in history John Levine <johnl@taugh.com> - 2026-11-07 19:00 +0000
Re: carry-in Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-07 22:37 +0000
Re: carry-in (was: two's complement and Flags) John Levine <johnl@taugh.com> - 2026-11-07 18:44 +0000
Re: carry-in (was: two's complement and Flags) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-07 22:33 +0000
Re: carry-in (was: two's complement and Flags) George Neuner <gneuner2@comcast.net> - 2026-11-08 02:55 -0500
Re: carry-in Robert Finch <robfi680@gmail.com> - 2026-11-08 07:50 -0500
Re: carry-in (was: two's complement and Flags) quadibloc@invalid.com (John Savard) - 2026-11-09 02:09 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-11-06 15:28 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-07 02:36 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-11-07 13:52 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-11-06 10:51 -0800
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-02 19:14 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-11-02 20:37 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-11-03 01:36 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-11-03 15:09 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-03 06:59 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) antispam@fricas.org (Waldek Hebisch) - 2026-11-04 03:01 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-04 03:36 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 02:39 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-04 18:06 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-04 18:20 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-11-04 21:53 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-11-04 23:08 +0100
Re: two's complement and Flags (Re: arithmetic and endian history) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-11-05 08:14 -0800
Re: bad floating point, two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-11-05 17:26 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:28 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-04 07:57 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-04 08:14 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-04 09:49 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 11:22 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-02 10:01 +0000
Re: two's complement and Flags (Re: arithmetic and endian history) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 21:19 -0700
Re: two's complement and Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-03 19:40 +0000
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-02 05:45 +0000
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-02 07:54 +0000
Re: Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-02 19:07 +0000
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-02 20:33 +0000
Re: Flags (Re: arithmetic and endian history) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 09:17 -0700
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 16:45 +0000
Re: Flags (Re: arithmetic and endian history) scott@slp53.sl.home (Scott Lurndal) - 2026-10-01 18:42 +0000
Re: Flags (Re: arithmetic and endian history) moi <findlaybill@blueyonder.co.uk> - 2026-10-03 02:30 +0100
Re: Flags (Re: arithmetic and endian history) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-03 17:43 +0000
Re: Flags (Re: arithmetic and endian history) moi <findlaybill@blueyonder.co.uk> - 2026-10-04 23:44 +0100
Re: Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-01 07:45 +0000
Re: Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-01 07:51 +0000
Re: Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-02 01:31 +0000
Re: Flags (Re: arithmetic and endian history) quadibloc@invalid.com (John Savard) - 2026-10-02 02:29 +0000
Re: Flags (Re: arithmetic and endian history) John Levine <johnl@taugh.com> - 2026-10-02 02:46 +0000
Re: endian history Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-28 08:45 -0700
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:15 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:19 +0000
Re: endian history Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 14:37 -0400
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 22:47 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-30 08:39 +0200
Re: endian history aph@littlepinkcloud.invalid - 2026-09-30 08:52 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:26 +0000
Re: endian history aph@littlepinkcloud.invalid - 2026-10-01 10:44 +0000
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 21:53 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-10-02 11:11 +0200
Re: endian history BGB <cr88192@gmail.com> - 2026-10-02 16:17 -0500
Re: endian history aph@littlepinkcloud.invalid - 2026-10-02 14:25 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-02 16:46 -0500
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 02:43 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-03 00:54 -0500
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 06:15 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-03 18:51 -0500
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 02:35 +0000
Re: endian history Robert Finch <robfi680@gmail.com> - 2026-10-03 10:25 -0400
Re: endian history BGB <cr88192@gmail.com> - 2026-10-03 16:59 -0500
Re: endian history George Neuner <gneuner2@comcast.net> - 2026-10-03 15:04 -0400
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 21:53 +0000
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 07:34 +0000
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:00 -0700
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 15:20 +0000
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 09:15 -0700
Re: endian history Michael S <already5chosen@yahoo.com> - 2026-10-01 19:23 +0300
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 21:31 -0700
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-03 10:25 +0000
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 16:36 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-10-01 18:38 +0000
Re: endian history George Neuner <gneuner2@comcast.net> - 2026-10-01 15:17 -0400
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 21:20 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-01 19:55 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-10-02 11:21 +0200
Re: endian history Michael S <already5chosen@yahoo.com> - 2026-10-02 12:47 +0300
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-10-02 12:57 +0200
Re: endian history Michael S <already5chosen@yahoo.com> - 2026-10-02 14:44 +0300
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-10-02 15:28 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 05:29 -0700
Re: endian history EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-01 13:12 -0400
Re: endian history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-01 17:41 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-01 18:07 -0500
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:44 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-01 22:06 -0500
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-02 18:05 +0000
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-02 18:00 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-02 13:51 -0500
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-10-03 14:14 +0000
Re: endian history EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-04 14:19 -0400
Re: endian history EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-04 13:59 -0400
Re: endian history aph@littlepinkcloud.invalid - 2026-10-02 15:18 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-02 14:57 -0500
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 02:30 +0000
Re: endian history BGB <cr88192@gmail.com> - 2026-10-03 05:26 -0500
Re: endian history Andy Valencia <vandys@vsta.org> - 2026-10-05 15:53 -0700
Re: endian history Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:18 +0000
Re: endian history George Neuner <gneuner2@comcast.net> - 2026-10-06 13:40 -0400
Re: endian history Andy Valencia <vandys@vsta.org> - 2026-10-06 10:49 -0700
Re: endian history Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-07 08:54 -0400
Re: endian history Jim Jackson <jj@franjam.org.uk> - 2026-10-08 18:33 +0000
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 04:44 -0700
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-22 18:16 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 20:27 +0200
Re: endian history Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-22 16:55 -0700
Re: endian history Thomas Koenig <tkoenig@netcologne.de> - 2026-09-16 16:17 +0000
Re: endian history scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:01 +0000
Re: endian history Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-08 21:17 +0200
Re: endian history MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 20:15 +0000
Re: endian history David Brown <david.brown@hesbynett.no> - 2026-09-09 11:08 +0200
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-20 18:13 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-20 07:21 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 00:06 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 07:03 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 13:42 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-21 18:32 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 22:21 +0000
Re: Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-22 07:35 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-22 15:48 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-22 21:22 +0000
Re: Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-23 09:28 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-23 17:01 +0000
Re: Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-23 18:37 +0000
Re: Concertina IV Has Arrived Robert Finch <robfi680@gmail.com> - 2026-05-23 14:15 -0400
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-23 20:01 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-23 16:19 +0000
Re: Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-05-23 16:38 +0000
Re: Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-23 08:36 +0000
Re: Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-05-23 16:46 +0000
Re: condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-23 19:33 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-23 20:03 +0000
Re: condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-23 20:09 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-23 22:15 +0000
Re: base+displacement, condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-24 01:43 +0000
Re: base+displacement, condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-24 03:10 +0000
Re: base+displacement, condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-24 17:06 +0000
Re: base+displacement, condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 13:57 +0000
Re: base+displacement, condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-24 15:12 +0000
Re: base+displacement, condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 16:44 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 13:30 +0000
Re: condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-05-24 15:24 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 16:39 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-26 15:13 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 13:32 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 13:49 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 14:14 +0000
Re: condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-24 09:32 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 17:16 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-24 17:32 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 21:39 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-24 22:07 +0000
Re: condition bits, Concertina IV Has Arrived "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-24 15:22 -0700
Re: condition bits, Concertina IV Has Arrived David Brown <david.brown@hesbynett.no> - 2026-05-25 10:23 +0200
Re: condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-25 14:28 +0000
Re: condition bits, Concertina IV Has Arrived David Brown <david.brown@hesbynett.no> - 2026-05-25 17:18 +0200
Re: condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-25 16:43 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 19:20 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-25 20:32 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 22:51 +0000
Re: condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-25 20:32 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 23:00 +0000
Re: condition bits, Concertina IV Has Arrived David Brown <david.brown@hesbynett.no> - 2026-05-26 08:27 +0200
Re: condition bits, Concertina IV Has Arrived Terje Mathisen <terje.mathisen@tmsw.no> - 2026-05-26 22:09 +0200
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-26 20:54 +0000
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-05-27 10:59 -0400
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-27 18:19 +0000
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-01 14:51 -0400
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-02 06:19 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-02 07:47 +0000
Re: condition bits, Concertina IV Has Arrived Terje Mathisen <terje.mathisen@tmsw.no> - 2026-06-02 17:50 +0200
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-02 19:10 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-03 00:55 +0000
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-03 10:42 -0400
Re: condition bits, Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-06-03 18:36 +0000
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-04 23:46 -0400
Re: condition bits, Concertina IV Has Arrived Thomas Koenig <tkoenig@netcologne.de> - 2026-06-05 08:36 +0000
Re: condition bits, Concertina IV Has Arrived Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-06-07 15:05 -0700
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-08 01:19 +0000
Re: condition bits, Concertina IV Has Arrived Michael S <already5chosen@yahoo.com> - 2026-06-08 09:25 +0300
Re: condition bits, Concertina IV Has Arrived Terje Mathisen <terje.mathisen@tmsw.no> - 2026-06-08 11:45 +0200
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-08 17:44 -0400
Re: condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-06-11 15:14 +0000
Re: condition bits, Concertina IV Has Arrived George Neuner <gneuner2@comcast.net> - 2026-06-11 13:43 -0400
Re: public domain, condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-06-13 03:01 +0000
Re: public domain, condition bits, Concertina IV Has Arrived George Neuner <gneuner2@comcast.net> - 2026-06-13 05:49 -0400
Re: public domain, condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 10:52 +0000
Re: public domain, condition bits, Concertina IV Has Arrived quadibloc@invalid.com (John Savard) - 2026-06-13 14:20 +0000
Re: public domain, condition bits, Concertina IV Has Arrived antispam@fricas.org (Waldek Hebisch) - 2026-06-13 15:07 +0000
Re: public domain, condition bits, Concertina IV Has Arrived John Levine <johnl@taugh.com> - 2026-06-13 17:25 +0000
Re: public domain, condition bits, Concertina IV Has Arrived antispam@fricas.org (Waldek Hebisch) - 2026-06-15 16:32 +0000
Re: public domain, condition bits, Concertina IV Has Arrived quadibloc@invalid.com (John Savard) - 2026-06-14 19:14 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-08 17:11 +0000
Re: condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 06:05 +0000
Re: condition bits, Concertina IV Has Arrived Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-06-08 07:30 -0700
Re: condition bits, Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-06-08 15:19 +0000
Re: condition bits, Concertina IV Has Arrived Michael S <already5chosen@yahoo.com> - 2026-06-08 22:51 +0300
Free software (was: condition bits, Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 16:18 +0000
Re: Free software Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-06-08 10:40 -0700
Re: Free software (was: condition bits, Concertina IV Has Arrived) Michael S <already5chosen@yahoo.com> - 2026-06-08 22:43 +0300
Re: Free software (was: condition bits, Concertina IV Has Arrived) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-09 17:24 +0000
Re: Free software Terje Mathisen <terje.mathisen@tmsw.no> - 2026-06-09 21:15 +0200
Re: Free software Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-06-09 16:29 -0700
Re: Free software (was: condition bits, Concertina IV Has Arrived) Thomas Koenig <tkoenig@netcologne.de> - 2026-06-10 06:01 +0000
Re: Free software Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-08 18:03 -0400
Re: Free software David Brown <david.brown@hesbynett.no> - 2026-06-09 10:06 +0200
Re: Free software Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-11 15:21 -0400
Re: Free software David Brown <david.brown@hesbynett.no> - 2026-06-12 13:02 +0200
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-08 09:18 -0400
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-03 21:24 +0000
Re: condition bits, Concertina IV Has Arrived George Neuner <gneuner2@comcast.net> - 2026-06-05 15:07 -0400
Re: condition bits, Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-06 08:57 +0000
Re: condition bits, Concertina IV Has Arrived scott@slp53.sl.home (Scott Lurndal) - 2026-06-07 16:42 +0000
Re: condition bits, Concertina IV Has Arrived antispam@fricas.org (Waldek Hebisch) - 2026-06-06 01:37 +0000
Re: condition bits, Concertina IV Has Arrived Thomas Koenig <tkoenig@netcologne.de> - 2026-06-06 07:57 +0000
Re: condition bits, Concertina IV Has Arrived antispam@fricas.org (Waldek Hebisch) - 2026-06-12 01:57 +0000
Re: condition bits, Concertina IV Has Arrived David Brown <david.brown@hesbynett.no> - 2026-05-26 08:18 +0200
Re: condition bits, Concertina IV Has Arrived antispam@fricas.org (Waldek Hebisch) - 2026-06-12 01:04 +0000
Re: condition bits, Concertina IV Has Arrived Stefan Monnier <monnier@iro.umontreal.ca> - 2026-05-25 15:27 -0400
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 16:49 +0000
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-25 20:34 +0000
Re: condition bits, Concertina IV Has Arrived BGB <cr88192@gmail.com> - 2026-05-25 20:02 -0500
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-26 18:02 +0000
Re: condition bits, Concertina IV Has Arrived BGB <cr88192@gmail.com> - 2026-05-26 14:28 -0500
Re: condition bits, Concertina IV Has Arrived BGB <cr88192@gmail.com> - 2026-05-25 16:34 -0500
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 23:05 +0000
Re: condition bits, Concertina IV Has Arrived George Neuner <gneuner2@comcast.net> - 2026-05-26 15:29 -0400
Re: condition bits, Concertina IV Has Arrived BGB <cr88192@gmail.com> - 2026-05-26 19:13 -0500
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-25 20:26 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 22:49 +0000
Re: condition bits, Concertina IV Has Arrived Thomas Koenig <tkoenig@netcologne.de> - 2026-05-26 05:39 +0000
Re: condition bits, Concertina IV Has Arrived Thomas Koenig <tkoenig@netcologne.de> - 2026-05-25 20:32 +0000
Re: condition bits, Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 22:59 +0000
Re: condition bits, Concertina IV Has Arrived BGB <cr88192@gmail.com> - 2026-05-27 15:24 -0500
Re: condition bits, Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-24 17:30 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-22 15:48 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 22:14 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 23:46 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-22 02:20 +0000
Re: Concertina IV Has Arrived anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-22 07:22 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 02:33 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 06:12 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 13:13 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 13:22 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-21 18:26 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-21 23:44 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-25 01:04 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-25 01:29 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 16:45 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-25 20:45 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-25 23:03 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-30 04:02 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-30 15:47 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-30 19:15 +0000
Re: Concertina IV Has Arrived Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-05-31 11:05 -0700
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-31 18:40 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 19:56 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 23:40 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-02 06:20 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-04 04:06 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-04 04:44 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 01:40 +0000
Re: Concertina IV Has Arrived Thomas Koenig <tkoenig@netcologne.de> - 2026-06-01 05:36 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-06-01 18:10 +0000
Re: Concertina IV Has Arrived Paul Clayton <paaronclayton@gmail.com> - 2026-05-31 18:38 -0400
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-06-02 01:52 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-31 01:22 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-31 12:05 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-31 17:26 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-31 02:57 +0000
Re: Concertina IV Has Arrived quadi <quadibloc@ca.invalid> - 2026-05-30 04:06 +0000
Re: Concertina IV Has Arrived MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-05-30 19:03 +0000
Page 2 of 30 — ← Prev page 1 [2] 3 4 … 30 Next page →
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-21 02:18 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ulq1i$ej88$1@dont-email.me> |
| In reply to | #116573 |
On Thu, 21 May 2026 00:37:39 +0000, John Levine wrote: > To make this work S/370 and its successors first do a trial execution of > the instruction without storing anything to see if it causes a page > fault. If not, it then redoes the instruction for real, storing the > result. I suspect that if they had known how soon S/370 would add > paging to the 360 architecture, they might have designed these > instructions differently. When I first read that, I thought that you meant they would have designed it differently when they designed the 370, but, of course, the instructions already existed. After I realized my mistake, of course, I also knew that back in 1964 or before, there was really no way that they could possibly have known that. John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-21 06:29 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May21.082929@mips.complang.tuwien.ac.at> |
| In reply to | #116574 |
quadi <quadibloc@ca.invalid> writes: >When I first read that, I thought that you meant they would have designed >it differently when they designed the 370, but, of course, the >instructions already existed. After I realized my mistake, of course, I >also knew that back in 1964 or before, there was really no way that they >could possibly have known that. The Atlas existed in 1962 and did have paging. So it was possible. Is it excusable that the S/360 designers did not consider this development at the time? Probably, although according to <https://en.wikipedia.org/wiki/Atlas_(computer)> "it was a 1959 description of Muse [the 1959 name for Atlas] that gave CDC ideas that significantly accelerated the development of the 6600 and allowed it to be delivered earlier than originally estimated". - 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 | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-05-21 15:41 +0000 |
| Subject | Re: ancient virtual memory, Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10un92t$1ju9$1@gal.iecc.com> |
| In reply to | #116574 |
According to quadi <quadibloc@ca.invalid>: >On Thu, 21 May 2026 00:37:39 +0000, John Levine wrote: >> result. I suspect that if they had known how soon S/370 would add >> paging to the 360 architecture, they might have designed these >> instructions differently. > >When I first read that, I thought that you meant they would have designed >it differently when they designed the 370, but, of course, the >instructions already existed. After I realized my mistake, of course, I >also knew that back in 1964 or before, there was really no way that they >could possibly have known that. According to Pugh et al., IBM Research was quite aware of Atlas and was doing its own work on one-level store and time sharing. They were also close to CTSS at MIT Project MAC. Atlas' performance was terrible (later solved partly by better paging schemes but mostly by larger real memory) and I get the impression that there was an internal institutional bias that only batch was real computing and time sharing was somewhere between a niche and a fad. The MIT people were deeply disappointed when S/360 had no memory mapping at all, which led to Multics switching from IBM to GE for its new computer. IBM then came out with the 360/67 which had quite decent virtual memory but it was too late. It didn't help that its intended main operating system was TSS which was overambitious and didn't work. Lucky for them CP/67 escaped from the lab to become VM/370. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 15:28 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ukjug$2bn4$1@dont-email.me> |
| In reply to | #116540 |
On Wed, 20 May 2026 05:38:07 +0000, Anton Ertl wrote: > * The last descendent of the PDP-11 was canceled long before the most > prominent big-endien architecture (SPARC) was canceled, and long > before Power switched its Linux support to little-endian, so the > PDP-11 had little, if any, influence on the outcome. The reason I blame the PDP-11 for everything is that it was a hugely influential machine. It was widely used in academic settings, and it was also the machine for which UNIX was first widely distributed. > When you add two BCD numbers that are longer than a > byte, you don't have to first go to the end of the number and then go > backwards from there. This is especially relevant if you do not want to > completely unroll the loop that handles these bytes. This is the reason little-endian was popular for small processors. It is no longer relevant if a processor has a 64-bit data bus. And, of course, it applies equally to binary and BCD. The reason I claim that BCD support strongly favors big-endian byte order is this: Character strings are, of course, in "big endian" order; that is, normally, a character string is written in memory with successive characters at increasing addresses - and, at least in languages that are written from left to right, numerals appear in texts with the most significant digit first. So if one has a hardware instruction to convert from BCD to the string representation of numbers, such as UNPK or EDIT, then those two representations should have the same endian-ness. And if one wants to use the same ALU for binary and BCD arithmetic, then those have to have the same endianness. John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-20 15:42 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May20.174203@mips.complang.tuwien.ac.at> |
| In reply to | #116550 |
quadi <quadibloc@ca.invalid> writes: >On Wed, 20 May 2026 05:38:07 +0000, Anton Ertl wrote: > >> * The last descendent of the PDP-11 was canceled long before the most >> prominent big-endien architecture (SPARC) was canceled, and long >> before Power switched its Linux support to little-endian, so the >> PDP-11 had little, if any, influence on the outcome. > >The reason I blame the PDP-11 for everything is that it was a hugely >influential machine. It was widely used in academic settings, and it was >also the machine for which UNIX was first widely distributed. But its byte order was not influential into this century. Unix and its applications are portable, including between byte orders (or at least they were, when there were still enough machines of either byte order around that one could test that). And somehow the PDP-11 and its offspring did not capture the workstation market and the server market that involved from that, and which constituted the Unix markets. Instead, the big-endian 68000 and its offspring dominated that market for a while, and was replaced with RISCs later, which had the same byte order as the earlier machines from the same company (i.e., little-endian for DEC and big-endian for the others). And when the market for workstations and server on RISCs shrunk down to almost nothing, not only did these big-endian machine vanish, but the offspring of the PDP-11 as well (and actually before some of the big-endian RISCs). What remains of this world is AIX on Power, and I have no idea how many installations there still are. Linux on Power was switched to little-endian with the introduction of OpenPower, not because of the PDP-11 descendants, but because of the Datapoint 2200 descendants. And the Datapoint 2200 (announced in June 1970) was probably not influence by the PDP-11 (announced in January 1970). >> When you add two BCD numbers that are longer than a >> byte, you don't have to first go to the end of the number and then go >> backwards from there. This is especially relevant if you do not want to >> completely unroll the loop that handles these bytes. > >This is the reason little-endian was popular for small processors. It is >no longer relevant if a processor has a 64-bit data bus. And, of course, >it applies equally to binary and BCD. If the numbers fit in one granule, yes, that benefit does not matter. But 64 bits are not enough for all binary numbers and probably not for all BCD numbers, either: the decimal FP people were not satisfied with the 15-digit mantissa that are easily possible with their representations in 64 bits; they did not even define a decimal64 format last I checked. So will 16-digit BCD numbers be satisfactory? >The reason I claim that BCD support strongly favors big-endian byte order >is this: > >Character strings are, of course, in "big endian" order; that is, >normally, a character string is written in memory with successive >characters at increasing addresses - and, at least in languages that are >written from left to right, numerals appear in texts with the most >significant digit first. > >So if one has a hardware instruction to convert from BCD to the string >representation of numbers, such as UNPK or EDIT, then those two >representations should have the same endian-ness. Reality check: Modern architectures tend to have byte-swap and shuffle instructions. They tend not to have BCD-to-ASCII instructions, but these can be implemented easily enough with the help of shuffle and bitwise instructions. And given that you need to use shuffle anyway, the byte-swapping does not cost extra. For doing it for more than one granule, you have to pay the big-endian cost on that conversion (for storing into the string, the loading of the BCD number would still be in little-endian order), but at least not for the arithmetic operations. >And if one wants to use the same ALU for binary and BCD arithmetic, then >those have to have the same endianness. Sure, but that's not a reason to use big-endian byte order, see above. - 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 | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 17:25 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ukqq1$5pmr$1@dont-email.me> |
| In reply to | #116553 |
On Wed, 20 May 2026 15:42:03 +0000, Anton Ertl wrote: > quadi <quadibloc@ca.invalid> writes: >>Character strings are, of course, in "big endian" order; that is, >>normally, a character string is written in memory with successive >>characters at increasing addresses - and, at least in languages that are >>written from left to right, numerals appear in texts with the most >>significant digit first. >> >>So if one has a hardware instruction to convert from BCD to the string >>representation of numbers, such as UNPK or EDIT, then those two >>representations should have the same endian-ness. > > Reality check: Modern architectures tend to have byte-swap and shuffle > instructions. They tend not to have BCD-to-ASCII instructions, but > these can be implemented easily enough with the help of shuffle and > bitwise instructions. And given that you need to use shuffle anyway, > the byte-swapping does not cost extra. An additional instruction is an additional instruction! But I think you simply mean that the hardware is present. I'm not saying that BCD can't be implemented in a little-endian architecture; I'm saying it's much easier to understand and define when BCD and character strings and binary all go the same way - and the byte order of character strings is fixed. John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-21 11:52 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May21.135251@mips.complang.tuwien.ac.at> |
| In reply to | #116555 |
quadi <quadibloc@ca.invalid> writes: >On Wed, 20 May 2026 15:42:03 +0000, Anton Ertl wrote: >> quadi <quadibloc@ca.invalid> writes: >> Reality check: Modern architectures tend to have byte-swap and shuffle >> instructions. They tend not to have BCD-to-ASCII instructions, but >> these can be implemented easily enough with the help of shuffle and >> bitwise instructions. And given that you need to use shuffle anyway, >> the byte-swapping does not cost extra. > >An additional instruction is an additional instruction! There is no additional instruction. VPERMB does the byte swapping and byte duplication at the same time, see <2026May21.122912@mips.complang.tuwien.ac.at>. - 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 | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-05-20 21:33 +0200 |
| Subject | Re: Byte order and BCD |
| Message-ID | <10ul29h$8end$1@dont-email.me> |
| In reply to | #116553 |
Anton Ertl wrote: > quadi <quadibloc@ca.invalid> writes: >> On Wed, 20 May 2026 05:38:07 +0000, Anton Ertl wrote: >> >>> * The last descendent of the PDP-11 was canceled long before the most >>> prominent big-endien architecture (SPARC) was canceled, and long >>> before Power switched its Linux support to little-endian, so the >>> PDP-11 had little, if any, influence on the outcome. >> >> The reason I blame the PDP-11 for everything is that it was a hugely >> influential machine. It was widely used in academic settings, and it was >> also the machine for which UNIX was first widely distributed. > > But its byte order was not influential into this century. Unix and > its applications are portable, including between byte orders (or at > least they were, when there were still enough machines of either byte > order around that one could test that). And somehow the PDP-11 and > its offspring did not capture the workstation market and the server > market that involved from that, and which constituted the Unix > markets. > > Instead, the big-endian 68000 and its offspring dominated that market > for a while, and was replaced with RISCs later, which had the same > byte order as the earlier machines from the same company (i.e., > little-endian for DEC and big-endian for the others). And when the > market for workstations and server on RISCs shrunk down to almost > nothing, not only did these big-endian machine vanish, but the > offspring of the PDP-11 as well (and actually before some of the > big-endian RISCs). What remains of this world is AIX on Power, and I > have no idea how many installations there still are. > > Linux on Power was switched to little-endian with the introduction of > OpenPower, not because of the PDP-11 descendants, but because of the > Datapoint 2200 descendants. And the Datapoint 2200 (announced in June > 1970) was probably not influence by the PDP-11 (announced in January > 1970). > >>> When you add two BCD numbers that are longer than a >>> byte, you don't have to first go to the end of the number and then go >>> backwards from there. This is especially relevant if you do not want to >>> completely unroll the loop that handles these bytes. >> >> This is the reason little-endian was popular for small processors. It is >> no longer relevant if a processor has a 64-bit data bus. And, of course, >> it applies equally to binary and BCD. > > If the numbers fit in one granule, yes, that benefit does not matter. > But 64 bits are not enough for all binary numbers and probably not for > all BCD numbers, either: the decimal FP people were not satisfied with > the 15-digit mantissa that are easily possible with their > representations in 64 bits; they did not even define a decimal64 > format last I checked. So will 16-digit BCD numbers be satisfactory? ieee754 does define decimal64, decimal128 and even decimal32, but the first two has pretty much all the actual usage, probably (?) decimal128 as the majority, at least for all accumulators. > >> The reason I claim that BCD support strongly favors big-endian byte order >> is this: >> >> Character strings are, of course, in "big endian" order; that is, >> normally, a character string is written in memory with successive >> characters at increasing addresses - and, at least in languages that are >> written from left to right, numerals appear in texts with the most >> significant digit first. >> >> So if one has a hardware instruction to convert from BCD to the string >> representation of numbers, such as UNPK or EDIT, then those two >> representations should have the same endian-ness. > > Reality check: Modern architectures tend to have byte-swap and shuffle > instructions. They tend not to have BCD-to-ASCII instructions, but > these can be implemented easily enough with the help of shuffle and > bitwise instructions. And given that you need to use shuffle anyway, > the byte-swapping does not cost extra. BCD-to-ASCII, with the input in an AVX 32-byte register, so up to 64 digits, would start with an exchange of the high and low 16-byte halves, then a permute of each half to reverse the order. The final single-cycle operation is the only overhead of the little vs high-endian inputs. Next we duplicate the input by unpacking the high and low 16 bytes into each byte value into 16 16-bit shorts, with the leading byte 0, then (in parallel) you copy and mask the low nybble while shifting all shorts up by 4 bits, then use the same all-15 mask to save the high nybbles. OR these two back together, and do the same for the other half of the original input. About 15-20 cycles in total with well under 10% being the byte order swap. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-21 10:29 +0000 |
| Subject | Re: Byte order and BCD |
| Message-ID | <2026May21.122912@mips.complang.tuwien.ac.at> |
| In reply to | #116565 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: >Anton Ertl wrote: >> But 64 bits are not enough for all binary numbers and probably not for >> all BCD numbers, either: the decimal FP people were not satisfied with >> the 15-digit mantissa that are easily possible with their >> representations in 64 bits; they did not even define a decimal64 >> format last I checked. So will 16-digit BCD numbers be satisfactory? > >ieee754 does define decimal64, decimal128 and even decimal32, but the >first two has pretty much all the actual usage, probably (?) decimal128 >as the majority, at least for all accumulators. I should check half-known things before I make claims in a posting. Anyway, looking at <https://en.wikipedia.org/wiki/Decimal64_floating-point_format>, I see that Decimal64 even has 16 digits of mantissa. So 15 digits is not enough. (And, as an aside, they complicated things by not specifying a 54-bit mantissa, but combining the exponent with the upper bits of the mantissa). To the point: these 16 digits are not enough, as the lack of popularity of decimal64 (even relative to decimal128) shows, so 64-bit BCD numbers are not enough in all cases, either. >> Reality check: Modern architectures tend to have byte-swap and shuffle >> instructions. They tend not to have BCD-to-ASCII instructions, but >> these can be implemented easily enough with the help of shuffle and >> bitwise instructions. And given that you need to use shuffle anyway, >> the byte-swapping does not cost extra. > >BCD-to-ASCII, with the input in an AVX 32-byte register, so up to 64 >digits, would start with an exchange of the high and low 16-byte halves, >then a permute of each half to reverse the order. The final single-cycle >operation is the only overhead of the little vs high-endian inputs. > >Next we duplicate the input by unpacking the high and low 16 bytes into >each byte value into 16 16-bit shorts, with the leading byte 0, then (in >parallel) you copy and mask the low nybble while shifting all shorts up >by 4 bits, then use the same all-15 mask to save the high nybbles. >OR these two back together, and do the same for the other half of the >original input. About 15-20 cycles in total with well under 10% being >the byte order swap. My thinking was along the lines of using VPERMB to do the byte-swapping, the duplicating, and the unpacking in one step. E.g., if you have a 64-bit BCD number 1234567890123456 as the following sequence of bytes 56 34 12 90 78 56 34 12 Then you have the index vector 7 7 6 6 5 5 4 4 3 3 2 2 1 1 0 0 and VPERMB xmm1, xmm2, xmm3 (where the BCD number is in xmm3 and the index vector is in xmm2) will put the following in xmm1: 12 12 34 34 56 56 78 78 90 90 12 12 34 34 56 56 So no extra instruction for the byte swapping. The problem is that I now would like a masked parallel byte shift to shift the even-indexed bytes right by 4 bits, but I don't find parallel byte shifts. I guess the answer is to let the VPERMB arrange the result as follows 1234 1234 5678 5678 9012 9012 3456 3456 ^^^^ ^^^^ ^^^^ ^^^^ then use a masked VPSRLW for shifting the marked 16-bit pieces to the right by 4 bits, resulting in 0123 1234 0567 5678 0901 9012 0345 3456 Now use VPSHUFB or VPERMB to rearrange the bytes in the intended order: 01 12 23 34 45 56 67 78 89 90 01 12 23 34 45 56 Now mask away the top 4 bits of each byte with VPAND and turn it into ASCII by VPORing every byte with 0x30. And the whole thing can be done with BCD numbers of up to 64 digits per pass. The absence of VPSRLB caused an additional instruction, but that's also necessary for dealing with big-endian BCD numbers. So storing the BCD numbers in little-endian format costs no additional instruction. VPERMB is not in AVX2, so if you want to limit yourself to that, little-endian needs an extra instruction indeed. - 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-21 12:04 +0000 |
| Subject | Re: Byte order and BCD |
| Message-ID | <2026May21.140440@mips.complang.tuwien.ac.at> |
| In reply to | #116581 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Terje Mathisen <terje.mathisen@tmsw.no> writes: >>BCD-to-ASCII, with the input in an AVX 32-byte register, so up to 64 >>digits, would start with an exchange of the high and low 16-byte halves, >>then a permute of each half to reverse the order. The final single-cycle >>operation is the only overhead of the little vs high-endian inputs. >> >>Next we duplicate the input by unpacking the high and low 16 bytes into >>each byte value into 16 16-bit shorts, with the leading byte 0, then (in >>parallel) you copy and mask the low nybble while shifting all shorts up >>by 4 bits, then use the same all-15 mask to save the high nybbles. >>OR these two back together, and do the same for the other half of the >>original input. About 15-20 cycles in total with well under 10% being >>the byte order swap. > >My thinking was along the lines of using VPERMB to do the >byte-swapping, the duplicating, and the unpacking in one step. E.g., >if you have a 64-bit BCD number 1234567890123456 as the following >sequence of bytes > >56 34 12 90 78 56 34 12 > >Then you have the index vector > >7 7 6 6 5 5 4 4 3 3 2 2 1 1 0 0 > >and VPERMB xmm1, xmm2, xmm3 > >(where the BCD number is in xmm3 and the index vector is in xmm2) will >put the following in xmm1: > >12 12 34 34 56 56 78 78 90 90 12 12 34 34 56 56 > >So no extra instruction for the byte swapping. > >The problem is that I now would like a masked parallel byte shift to >shift the even-indexed bytes right by 4 bits, but I don't find >parallel byte shifts. I guess the answer is to let the VPERMB arrange >the result as follows > >1234 1234 5678 5678 9012 9012 3456 3456 >^^^^ ^^^^ ^^^^ ^^^^ > >then use a masked VPSRLW for shifting the marked 16-bit pieces to the >right by 4 bits, resulting in > >0123 1234 0567 5678 0901 9012 0345 3456 > >Now use VPSHUFB or VPERMB to rearrange the bytes in the intended order: > >01 12 23 34 45 56 67 78 89 90 01 12 23 34 45 56 I have a better approach: First do the shifting with, e.g. VPSRLW, with the result in a new register. So you now have 56 34 12 90 78 56 34 12 #original data 0563 0129 0785 0341 #shifted version Now you use VPERMT2B to rearrange the bytes from both registers into a third one, doing the byte-swapping while you are at it, resulting in: 41 12 03 34 85 56 07 78 29 90 01 12 63 34 05 56 The remainder uses VPAND and VPOR, as described earlier. If you have BCD numbers with more than 64, but at most 128 digits, the first step would only have to be performed once. You would then use two VPERMI2B instructions with different index inputs to produce the 64 least significant and the 64 most significant digits, and the VPAND and VPOR would also have to be duplicated. So 4 central instructions for a BCD number with up to 64 digits, and 7 for up to 128 digits. In addition, you need the VPERMT2B index, the VPSRLW shift amounts and the other operand for VPAND and VPOR in registers, but if you are converting a lot of BCD numbers, you may already have them in registers when you convert the next BCD number. - 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 | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-06-03 00:41 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10vnt87$3ab6c$1@dont-email.me> |
| In reply to | #116540 |
On Wed, 20 May 2026 05:38:07 +0000, Anton Ertl wrote: > * The last descendent of the PDP-11 was canceled long before the most > prominent big-endien architecture (SPARC) was canceled, and long > before Power switched its Linux support to little-endian, so the > PDP-11 had little, if any, influence on the outcome. The long decline of big-endian happened later. But there wouldn't have _been_ little-endian architectures to out-compete big-endian if it hadn't been for the PDP-11. That was where the idea of little-endian got started. It wasn't the first machine to store two-word numbers least-significant- word first. But it was the first machine to be little-endian in any other way but that. Little-endian, as something more than an ad-hoc way to handle one case of double-precision integers, wasn't a thing until the PDP-11 came along. John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-06-03 17:13 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026Jun3.191308@mips.complang.tuwien.ac.at> |
| In reply to | #116822 |
quadi <quadibloc@ca.invalid> writes: >But there wouldn't have _been_ little-endian architectures to out-compete >big-endian if it hadn't been for the PDP-11. That was where the idea of >little-endian got started. The Datapoint 2200 would most likely have had the little-endian encoding if the PDP-11 had been big-endian, because it was developed independently and in parallel. The 8080's call and ret instructions were the first where little-endian extended beyond instruction encoding, but I expect that, once you have jump instructions with little-endian targets, you also want return addresses to be stored in little-endian byte order (simplifies implementation). And from there it goes to the 8086 which has 16-bit data memory accesses, and where you also stick with little-endian if you already have done so for jump targets and return addresses. And following the 8086, IA-32 and AMD64 would have been little-endian, too. The 6502 would have been little-endian if the PDP-11 had been big-endian, for technical reasons. They ignored even the big-endian byte order of its predecessor, the 6800. And following the 6502, the ARM would have been little-endian even if the PDP-11 had been big-endian. So the architectures that dominate now would be little-endian even if the PDP-11 had been big-endian. Would they have been less successful if the PDP-11 had been big-endian? I doubt it. At a point around 1990, most of the Unix market was big-endian, based on the 68000 being big-endian, and it seemed that if any byte order would win, it would be big-endian. IA-32 and VAX were expected to die because they were CISCs, and ARM was just a minor player in the RISC market at the time. And yet, IA-32/AMD64 and ARM's instruction sets outlived all the highly successful RISCs of the time. This would also have happened if the PDP-11 and the VAX would have been big-endian. - 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 | Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> |
|---|---|
| Date | 2026-05-20 10:42 +0200 |
| Message-ID | <10ujs64$3rk17$1@dont-email.me> |
| In reply to | #116536 |
On 5/20/26 04:09, quadi wrote: > b) Yes, little-endian is more popular, but that's just because the PDP-11, > 8080, and 6502 happened to choose it. Little-endian doesn't work as well > *if* you also want to put packed decimal values in registers. For packed decimals that are processed in memory, little endian is superior to big endian, because you don't have to look for the LSB when performing an addition, you can proceed bytewise on ascending addresses. As a consequence should packed decimals in registers also be little endian, conceding the fact that the classic byte-wise representation is skewed (but when displaying words, the reading order is natural). -- Bernd Linsel
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-20 15:32 +0000 |
| Message-ID | <tukPR.169930$7J1.3532@fx48.iad> |
| In reply to | #116544 |
Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> writes: >On 5/20/26 04:09, quadi wrote: > > > b) Yes, little-endian is more popular, but that's just because the >PDP-11, > > 8080, and 6502 happened to choose it. Little-endian doesn't work as well > > *if* you also want to put packed decimal values in registers. > >For packed decimals that are processed in memory, little endian is >superior to big endian, because you don't have to look for the LSB when >performing an addition, you can proceed bytewise on ascending addresses. Burroughs figured that problem out a half century ago, and were able to add two big-endian BCD numbers memory-to-memory handling overflow (by counting leading 9s). Overflow was detected before the receiving field was modified (without intermediate or internal storage) by counting leading 9s.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-05-20 17:47 +0000 |
| Subject | Re: BCD, was Concertina IV Has Arrived |
| Message-ID | <10uks4f$1dqo$1@gal.iecc.com> |
| In reply to | #116544 |
According to Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com>: >For packed decimals that are processed in memory, little endian is >superior to big endian, because you don't have to look for the LSB when >performing an addition, you can proceed bytewise on ascending addresses. It depends what you're doing. If you're doing arithmetic, you need to start at the low end. If you're packing or unpacking or editing for display, you need to start at the high end. My understanding is that back in the day when performance mattered, the applications that used BCD arithmetic typically did one arithmetic operation on each value, so the pack/edit mattered more. Having looked into this in some detail, both when IBM used bigendian order on S/360 and DEC used little-endian on the PDP-11, neither documented the reasons for the byte order choice at all. Not even a litle bit. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-06-01 01:14 +0000 |
| Subject | Re: BCD, was Concertina IV Has Arrived |
| Message-ID | <10vimd4$1thlf$1@dont-email.me> |
| In reply to | #116556 |
On Wed, 20 May 2026 17:47:59 +0000, John Levine wrote: > Having looked into this in some detail, both when IBM used bigendian > order on S/360 and DEC used little-endian on the PDP-11, neither > documented the reasons for the byte order choice at all. Not even a > litle bit. I suppose that, at the time, it was something that nobody felt was important enough to document. But to people who were around back then, the reasons would have been obvious. IBM mainframes were designed to ooze quality! So here and there, an extra transistor or two was added if something seemed better. That's why the IBM 7090 used sign-magnitude arithmetic for integers. And that's why the IBM 360 jumped ahead to the end of an integer and worked backwards to add, because putting things in reverse order would have shouted cheap. Plus, the 360 came in a variety of bus widths. So when would you start putting the small part first? (They didn't know the answer the PDP-11 came up with. Nobody back then could even imagine it, it was so new.) The original PDP-11 only came with a 16-bit bus. But its designers aspired to the level of consistency that the 360 had, but they wanted to do it on a rock-bottom minicomputer budget. DEC minis, in fact, were cheaper than most other brands of minicomputer at the time. So they were going to put the most significant 16-bit word of a 32-bit integer last. But they got the brilliant idea - that more pedestrian designers would never even considered for a second, or even thought of as possible - of numbering the bytes in a word backwards too, so as to attain consistency. The PDP-11 made little-endian a thing. It was so new that the people designing the floating-point unit didn't get the memo. But the concept of making little-endian consistent, instead of something you did in one particular case, the case where something was twice the size of your biggest register... that was only born with the PDP-11. John Savard
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-06-01 02:20 +0000 |
| Subject | Re: BCD, was Concertina IV Has Arrived |
| Message-ID | <10viq9k$271t$1@gal.iecc.com> |
| In reply to | #116763 |
It appears that quadi <quadibloc@ca.invalid> said: >On Wed, 20 May 2026 17:47:59 +0000, John Levine wrote: > >> Having looked into this in some detail, both when IBM used bigendian >> order on S/360 and DEC used little-endian on the PDP-11, neither >> documented the reasons for the byte order choice at all. Not even a >> litle bit. > >I suppose that, at the time, it was something that nobody felt was >important enough to document. Evidently. >But to people who were around back then, the reasons would have been >obvious. As I may have said once or twice before, we have plenty of guesses, but since there is no documentation, the guesses are a waste of time. >IBM mainframes were designed to ooze quality! So here and there, an extra >transistor or two was added if something seemed better. That's why the IBM >7090 used sign-magnitude arithmetic for integers. The 7090 used sign-magnitude because the vacuum tube 709 used sign magnitude because the 704 used sign-magnitude and they quite reasonably wanted to keep them program compatible. The preceding 701 was also sign-magnitude but had a strange addressing scheme which let you treat memory (which was flaky Williams tubes) as either 36 bit full words or 18 bit half words. Full words were addressed by even negative addresses from -0000 to -4094 while half words were even and odd positive addresses from +0000 to +4095. The 704 did not do that, thank heavens. I presume you are aware that the 704 and successors did indexing by two's complement subtraction, which is not sign-magnitude. There is no documentation for that either, and I have looked quite hard. Pretty please, do not guess unless you can cite sources. >And that's why the IBM 360 jumped ahead to the end of an integer and >worked backwards to add, because putting things in reverse order would >have shouted cheap. IBM's 702, 705, and 7080 decimal mainframes addressed the low digit of a number and I can assure you they were not cheap. >The original PDP-11 only came with a 16-bit bus. But its designers aspired >to the level of consistency that the 360 had, but they wanted to do it on >a rock-bottom minicomputer budget. DEC minis, in fact, were cheaper than >most other brands of minicomputer at the time. I am familiar with this guess, but having looked at a lot of contemporary DEC documentation, there is no reason to believe it's true. If they saved any transistors by making it little-endian, the difference was trivial. You should look at the DG Nova, designed by some DEC renegades, really cheap due to using then-new MSI chips, and word addressed with a bigendian feel. >The PDP-11 made little-endian a thing. It was so new that the people >designing the floating-point unit didn't get the memo. Nor did the people designing the extended multiplier, but they got it mostly conssitent in the Vax. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-06-01 07:47 +0000 |
| Subject | 2s-complement and byte order (was: BCD) |
| Message-ID | <2026Jun1.094742@mips.complang.tuwien.ac.at> |
| In reply to | #116765 |
John Levine <johnl@taugh.com> writes: >I presume you are aware that the 704 and successors did indexing by two's >complement subtraction, which is not sign-magnitude. Looking at the 704 manual <https://ia802904.us.archive.org/12/items/bitsavers_ibm7042466_32932660/24-6661-2_704_Manual_1955_text.pdf>, it says: |Type A instructions use two 15 -bit fields (decrement and address) |containing numbers in the octal range 00000 to 77777. I did not find other descriptions of addresses; given this description, it seems that the addresses and the index registers are unsigned. Appendix A discusses binary arithmetic, but explains subtraction with borrows rather than addition of the 2s-complement (borrows is probably easier to understand given the background of the readers, but adding a 1s-complement and one is easier to implement). In any case, I don't think that the IBM 704 manual documents 2s-complement representation of negative numbers for any purpose. So why did the S/360 architects go for 2s-complement? One speculation is that they wanted 32-bit (unsigned) addreesses and wanted to be able to use the same adder for the addresses as for the integers. But the S/360 only has 24-bit addresses, so going for, e.g., sign-magnitude and only declaring the positive numbers <2^24 to be valid addresses would also have worked with one adder. An alternative speculation is that they really wanted to extend the range of the S/360 implementations as far as possible, also on the lower end, and the 2s-complement representation for negative numbers is cheaper to implement, in particular when you implemant a bit-serial, nybble-serial, or somesuch machine. [quadi <quadibloc@ca.invalid> said:] >>The PDP-11 made little-endian a thing. It was so new that the people >>designing the floating-point unit didn't get the memo. > >Nor did the people designing the extended multiplier, but they got it >mostly conssitent in the Vax. This all indicates that byte-ordering decisions worked like in our student group. The "right" choice seemed so obvious to everyone that we did not communicate about it nor document it nor document the reasons for it, and different contributors took different "right" choices. - 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 | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-06-01 16:04 +0000 |
| Subject | Re: 2s-complement and byte order (was: BCD) |
| Message-ID | <10vkaia$2an8m$1@dont-email.me> |
| In reply to | #116767 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > So why did the S/360 architects go for 2s-complement? Brooks (who was program manager for /360) writes about this in "The Design of Design". Unique zero and unified hardware were his main points, IIRC. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-06-01 18:01 +0000 |
| Subject | Re: 2s-complement and byte order (was: BCD) |
| Message-ID | <2026Jun1.200136@mips.complang.tuwien.ac.at> |
| In reply to | #116769 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > >> So why did the S/360 architects go for 2s-complement? > >Brooks (who was program manager for /360) writes about this in >"The Design of Design". Unique zero and unified hardware were >his main points, IIRC. This made me remember: G. M. Amdahl, G. A. Blaauw, F. P. Brooks, Jr.: "Architecture of the IBM System/ 360" <https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBM360-Amdahl_april64.pdf>, which John Levine pointed to. It says on page 92: |Sign representations. For the fixed-point arithmetic system, which is |binary,the two's complement representation for negative numbers was |selected.The well-known virtues of this system are the unique |representation of zero and the absence of recomplementation. These |substantial advantages are augmented by several properties especially |useful in address arithmetic, particularly in the large models, where |address arithmetic has its own hardware. With two's complement |notation, this indexing hardware requires no true/complement gates |and thus works faster. In the smaller, serial models, the fact that |high-order bits of address arithmetic can be elided without changing |the low-order bits also permits a gain in speed. The same truncation |property simplifies double-precision calculations. Furthermore, for |table calculation, rounding or truncation to an integer changes all |variables in the same direction, thus giving a more acceptable |distribution than does an absolute-value-plus-sign representation. | |The established commercial rounding convention made the use of |complement notation awkward for decimal data; therefore, |absolute-value-plus-sign is used here. What is "recomplementation"? As an aside: When listing authors in alphabetic order, choose your co-authors wisely: You have a name like "Brooks", and yet only get the last spot out of three:-). -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 2 of 30 — ← Prev page 1 [2] 3 4 … 30 Next page →
Back to top | Article view | comp.arch
csiph-web