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 1 of 30 [1] 2 3 … 30 Next page →
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-19 20:14 +0000 |
| Subject | Concertina IV Has Arrived |
| Message-ID | <10uigbd$3gvqi$1@dont-email.me> |
It had to happen? I was not sure if it ever could happen. There was Concertina II - an attempt at a practical ISA, unlike the original Concertina, which was merely illustrative. But it had a block structure, which was highly criticized. And I had to admit it was overly complicated. And so I went on and used the Concertina III designation again - for a CISC-like instruction set with variable- length instructions. The price was, though, switching to register banks of 16 registers instead of 32. The IBM 360 had banks of 16 registers, and more modern CISC designs, like the 680x0 and the x86 have banks of only eight. Only RISC designs can offer banks of 32 registers. And yet it seemed so tantalizingly close - that it might just be possible, using what I've learned about squeezing an ISA into the available opcode space, to go back to banks of 32 registers. I found it to be possible - at a price. It could be done, but I wouldn't have much space left for 16-bit short instructions. Even if I had lots of space for 16-bit short instructions, though, they would still, just by being 16 bits long, where the banks of registers have 32 registers in them, be badly compromised. And so I decided to offer only a very limited set of 16-bit short instructions, and to chiefly provide... 24-bit short instructions. I didn't want to depart from the example of the 680x0 and the System/360 to allow instructions to start on odd bytes, but it seemed like I had no choice if I wanted to offer a reasonably complete set of short instructions at all. Concertina IV is described at: http://www.quadibloc.com/arch/cw01int.htm John Savard
[toc] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 00:03 +0000 |
| Message-ID | <10uitof$3kbcs$1@dont-email.me> |
| In reply to | #116526 |
I've made my first change to Concertina IV. I'm not happy with the way things were before the change or the way they are now, so I may change it again. The 16-bit short instructions only have 12 free bits available. That's not much to work with when there are 32 registers in each register bank. Initially, I settled on four bits of opcode, along with the basic register specification scheme used for the 15-bit paired short instructions in Concertina II. But choosing single and double precision floating-point as the only two types supported didn't rest easily with me. Single precision isn't really precise enough to be useful, or so I've heard. The alternative of supporting 48-bit intermediate precision and double precision, while it appeals to me personally... is clearly untenable. Medium is a nonstandard data type, and so it would not be widely used. So instead I decided to only support double precision, and use the extra bits to allow additional ways to specify registers. The result, of course, is messy. So I'm considering going back to the earlier format, but instead of supporting two floating-point data types, to support one integer type and one floating type. But which integer type? 32-bit integer, or 64-bit long? I could get more bits by going to _paired_ instructions. But I have some free space between 32-bit instructions so that I could just add those while keeping 16-bit short instructions. And this also led me to thinking about something else. I align different integer types on the right, even while aligning different floating-point types on the left like everyone else. So integer operations must sign-extend if they're on values shorter than 64 bits. Propagating a bit takes time. So should I design the ALU so that the sign extension takes place after the rest of the instruction, and allow another 32-bit (or shorter) integer instruction to use results when they're ready, before sign extension? Is that just normal efficiency, or wasteful complexity? In any case, I think I've come up with something that is a reasonable compromise I can live with after all. John Savard
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 00:34 +0000 |
| Message-ID | <10uivjj$3kvqj$1@dont-email.me> |
| In reply to | #116531 |
On Wed, 20 May 2026 00:03:27 +0000, quadi wrote: > In any case, I think I've come up with something that is a reasonable > compromise I can live with after all. And what was that compromise? When it comes to floating-point types, there was only one that I valued above all the rest, so I couldn't decide what second one to use. With integer types, on the other hand, there were two types that I couldn't decide between. So go with it! Support two integer types - even with room for logical as well as arithmetic operations - but with a more limited specification of source and destination registers... and one floating-point type. Done! John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-20 01:35 +0000 |
| Message-ID | <1779240901-5857@newsgrouper.org> |
| In reply to | #116531 |
quadi <quadibloc@ca.invalid> posted:
> I've made my first change to Concertina IV. I'm not happy with the way
> things were before the change or the way they are now, so I may change it
> again.
>
> The 16-bit short instructions only have 12 free bits available. That's not
> much to work with when there are 32 registers in each register bank.
>
> Initially, I settled on four bits of opcode, along with the basic register
> specification scheme used for the 15-bit paired short instructions in
> Concertina II.
>
> But choosing single and double precision floating-point as the only two
> types supported didn't rest easily with me. Single precision isn't really
> precise enough to be useful, or so I've heard.
Everything you have heard is both true and false::
There are many applications where DP is de rigueur {galactic simulations}
smaller precision simply will not do. Many of these would like to go
FP128 but performance is not there yet.
There is a growing demand for FP16 and FP8 data types for memory-size
and BW reasons.
There is a growing background need for FP128, too.
> The alternative of supporting 48-bit intermediate precision and double
> precision, while it appeals to me personally... is clearly untenable.
> Medium is a nonstandard data type, and so it would not be widely used.
>
> So instead I decided to only support double precision, and use the extra
> bits to allow additional ways to specify registers.
My 66000 started out that way and the compiler showed that this choice sucks.
> The result, of course, is messy.
No it becomes unacceptable when FP32 takes 3 instructions while FP64
takes but 1.
> So I'm considering going back to the earlier format, but instead of
> supporting two floating-point data types, to support one integer type and
> one floating type. But which integer type? 32-bit integer, or 64-bit long?
You will find you have no <marketable> choice; you need to support::
Integer{S8, S16, S32, S64, U8, U16, U32, U64}
Float {FP8, FP16, FP32, FP64 and some way to get FP128}
> I could get more bits by going to _paired_ instructions. But I have some
> free space between 32-bit instructions so that I could just add those
> while keeping 16-bit short instructions.
>
> And this also led me to thinking about something else.
>
> I align different integer types on the right, even while aligning
> different floating-point types on the left like everyone else. So integer
> operations must sign-extend if they're on values shorter than 64 bits.
Go LE all the way. LE won get over BE thinking.
As far as integers go: all calculations produce proper integer values
in the 64-bit destination register.
S8 has range [-128..127]
u8 has range [0..255]
...
> Propagating a bit takes time.
A solved HW gate-level problem.
> So should I design the ALU so that the sign extension takes place after
> the rest of the instruction, and allow another 32-bit (or shorter) integer
> instruction to use results when they're ready, before sign extension? Is
> that just normal efficiency, or wasteful complexity?
All the sign and zero stuff goes "in the CARRY chain".
> In any case, I think I've come up with something that is a reasonable
> compromise I can live with after all.
>
> John Savard
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 02:09 +0000 |
| Message-ID | <10uj544$3m3j5$1@dont-email.me> |
| In reply to | #116534 |
On Wed, 20 May 2026 01:35:01 +0000, MitchAlsup wrote: > quadi <quadibloc@ca.invalid> posted: >> I align different integer types on the right, even while aligning >> different floating-point types on the left like everyone else. So >> integer operations must sign-extend if they're on values shorter than >> 64 bits. > Go LE all the way. LE won get over BE thinking. a) I didn't think this really had anything to do with little-endian versus big-endian. 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. > As far as integers go: all calculations produce proper integer values in > the 64-bit destination register. > S8 has range [-128..127] > u8 has range [0..255] > ... If you have 64 bit registers, then if you want to avoid a gap between the sign in a 32-bit number and the sign of a 64-bit number by placing the 32- bit number on the most significant side, a 32-bit 1 is equal to a 64-bit 8,589,934,592. >> Propagating a bit takes time. > > A solved HW gate-level problem. That's good news, then I don't have a problem. I figured the solution would be to use slightly slower gates with larger current output. John Savard
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 02:26 +0000 |
| Message-ID | <10uj652$3mcp3$1@dont-email.me> |
| In reply to | #116536 |
On Wed, 20 May 2026 02:09:08 +0000, quadi wrote: > On Wed, 20 May 2026 01:35:01 +0000, MitchAlsup wrote: >> quadi <quadibloc@ca.invalid> posted: > >>> I align different integer types on the right, even while aligning >>> different floating-point types on the left like everyone else. So >>> integer operations must sign-extend if they're on values shorter than >>> 64 bits. > >> Go LE all the way. LE won get over BE thinking. > > a) I didn't think this really had anything to do with little-endian > versus big-endian. > > 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. > >> As far as integers go: all calculations produce proper integer values >> in the 64-bit destination register. >> S8 has range [-128..127] >> u8 has range [0..255] >> ... > > If you have 64 bit registers, then if you want to avoid a gap between > the sign in a 32-bit number and the sign of a 64-bit number by placing > the 32- > bit number on the most significant side, a 32-bit 1 is equal to a 64-bit > 8,589,934,592. While the majority of computers nowadays are little-endian, back in the old days only a very few computers treated fixed-point numbers as fractions in the range [-1,1) instead of as integers. Those that did that either wasted a bit in double-word integers, or required one to do a right shift by one bit after doing a multiplication if you wanted the result of the multiplication to correspond with treating the numbers as integers instead. This, not little-endian versus big-endian, was what I was talking about not doing. John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-20 05:38 +0000 |
| Subject | Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May20.073807@mips.complang.tuwien.ac.at> |
| In reply to | #116536 |
quadi <quadibloc@ca.invalid> writes: >b) Yes, little-endian is more popular, but that's just because the PDP-11, >8080, and 6502 happened to choose it. Thinking about it: * 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. * 8080: Yes, because AMD64 inherited its byte order from it. But if we go to the origin here, it's not the 8080 and not the 8008, but the Datapoint 2200, which is remarkable, because it was designed as a terminal for mainframes, and S/360 is big-endian. <https://en.wikipedia.org/wiki/Datapoint_2200#Technical_description> says: |The fact that most laptops and cloud computers today store numbers |in little-endian format is carried forward from the original |Datapoint 2200. Because the original Datapoint 2200 had a serial |processor, it needed to start with the lowest bit of the lowest byte |in order to handle carries. Microprocessors descended from the |Datapoint 2200 (the 8008, Z80, and the x86 chips used in most |laptops and cloud computers today) kept the little-endian format |used by that original Datapoint 2200. * 6502: Yes, because ARM A64 inherited its byte order from it. The 6502 is remarkable because it is a child of the 6800, which is big-endian. So the choice of little-endian byte order was deliberate. RISC-V inherits its original byte order from the descendents of 8080 and 6502. The ISA manual comments on this: |We originally chose little-endian byte ordering for the RISC-V memory |system because little-endian systems are currently dominant |commercially (all x86 systems; iOS, Android, and Windows for ARM). A |minor point is that we have also found little-endian memory systems to |be more natural for hardware designers. However, certain application |areas, such as IP networking, operate on big-endian data structures, |and certain legacy code bases have been built assuming big-endian |processors, so we have defined big-endian and bi-endian variants of |RISC-V. [...] |We further make the instruction parcels themselves little-endian to |decouple the instruction encoding from the memory system endianness |altogether. I expect that big-endian RISC-V's will be as common as big-endian Alphas and big-endian ARMs (all Alphas and ARMs after a certain point in time support a big-endian mode), i.e., not at all. > Little-endian doesn't work as well >*if* you also want to put packed decimal values in registers. It certainly does. I know it because we had a group exercise in assembly language on 80286s that dealt with BCD numbers, and we split the project into submodules, one for each student. In integration testing we found that we had forgotten to specify the byte order in our interface descriptions. Two in our group, two students (including me) had chosen little-endian and IIRC two had chosen big-endian. I did not find that doing the BCD stuff in little-endian byte order did not work well. With the BCD support of instruction sets typically requiring piecing together the complete operation of suboperations of less than full length (e.g., bytes on the 6502 and the 80(2)86), little-endian is actually easier. 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. Note that the 6502 includes BCD support with its decimal mode, and the designers of the 6502 obviously did not agree with the claim you made above. When the 8080 added BCD support in form of the DAA instruction (the 8086 added DAS), the byte order decision had already been made with the Datapoint 2200, but if they really thought that decimal operation is a good reason for big-endian byte order, they could have done what the 6502 had done and switched the byte order around from its ancestors. On the other hand, given that the 6502 and 8080 BCD support worked on bytes, the programmers were free to choose any byte order they prefer, as our student project proved. Maybe some (how many?) of the programmers who wrote BCD code for the 6502 and for the 8080 and its descendants actually chose a big-endian format. Things get more interesting if the granularity of BCD support is bigger than a byte, e.g., on the HPPA or IIRC S/360. - 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-05-20 08:10 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ujq92$3qu4e$1@dont-email.me> |
| In reply to | #116540 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > * 8080: Yes, because AMD64 inherited its byte order from it. But if > we go to the origin here, it's not the 8080 and not the 8008, but > the Datapoint 2200, which is remarkable, because it was designed as > a terminal for mainframes, and S/360 is big-endian. > <https://en.wikipedia.org/wiki/Datapoint_2200#Technical_description> > says: > > |The fact that most laptops and cloud computers today store numbers > |in little-endian format is carried forward from the original > |Datapoint 2200. Because the original Datapoint 2200 had a serial > |processor, it needed to start with the lowest bit of the lowest byte > |in order to handle carries. Microprocessors descended from the > |Datapoint 2200 (the 8008, Z80, and the x86 chips used in most > |laptops and cloud computers today) kept the little-endian format > |used by that original Datapoint 2200. For the Datapoint 2200, there was a solid technical reason: It used shift register memory which supplied one bit at a time, so the adder *had* to be little-endian. See https://www.righto.com/2014/12/inside-intel-1405-die-photos-of-shift.html -- 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-05-20 08:36 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May20.103605@mips.complang.tuwien.ac.at> |
| In reply to | #116543 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> <https://en.wikipedia.org/wiki/Datapoint_2200#Technical_description> >> says: >> >> |[...] Because the original Datapoint 2200 had a serial >> |processor, it needed to start with the lowest bit of the lowest byte >> |in order to handle carries. [...] >For the Datapoint 2200, there was a solid technical reason: >It used shift register memory which supplied one bit at a time, >so the adder *had* to be little-endian. Looks plausible at first, but when I think about it some more, both claims are wrong. Yes, you start with the least significant bit, but given that the architecture is not bit-addressed, this is irrelevant. The architecture is byte-addressed, and the ALU only works on a single byte, so the ALU does not work any better for little-endian than for big-endian. For the 6502 dealing with carries in addressing, both in the relative addressing of conditional branches, and in the indexed addressing modes with 16-bit base addresses, little-endian made the implementation a little simpler. The Datapoint 2200 does not have indexed addressing modes, so relative branches may have been the issue (if the DataPoint 2200 has them). Did I miss any other reason why little-endian byte order is easier to implement on these processors than 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 | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-05-20 10:37 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10uk2tj$3t6sk$2@dont-email.me> |
| In reply to | #116545 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>> <https://en.wikipedia.org/wiki/Datapoint_2200#Technical_description> >>> says: >>> >>> |[...] Because the original Datapoint 2200 had a serial >>> |processor, it needed to start with the lowest bit of the lowest byte >>> |in order to handle carries. > [...] >>For the Datapoint 2200, there was a solid technical reason: >>It used shift register memory which supplied one bit at a time, >>so the adder *had* to be little-endian. > > Looks plausible at first, but when I think about it some more, both > claims are wrong. Unfortunately, you are mistaken. > Yes, you start with the least significant bit, but given that the > architecture is not bit-addressed, this is irrelevant. JMP with a two-byte address was little-endian on the Datapoint 2200, and so had to be on the Intel 8808, which had to be binary compatible with the TTL CPU of the 2200. -- 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-05-20 11:04 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May20.130444@mips.complang.tuwien.ac.at> |
| In reply to | #116547 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> Thomas Koenig <tkoenig@netcologne.de> writes: >>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>>> <https://en.wikipedia.org/wiki/Datapoint_2200#Technical_description> >>>> says: >>>> >>>> |[...] Because the original Datapoint 2200 had a serial >>>> |processor, it needed to start with the lowest bit of the lowest byte >>>> |in order to handle carries. >> [...] >>>For the Datapoint 2200, there was a solid technical reason: >>>It used shift register memory which supplied one bit at a time, >>>so the adder *had* to be little-endian. >> >> Looks plausible at first, but when I think about it some more, both >> claims are wrong. > >Unfortunately, you are mistaken. A claim without any supporting argument. >> Yes, you start with the least significant bit, but given that the >> architecture is not bit-addressed, this is irrelevant. > >JMP with a two-byte address was little-endian on the Datapoint 2200, Yes, but is the bit-serial memory the reason for that? No, the ALU is not involved, and they could just have decided to represent the address in big-endian byte order, and the 16 bits into the PC (or next-PC) register. The conditional jump instructions of the Datapoint 2200 also have absolute target addresses and don't involve the ALU. - 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-05-20 17:01 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ukpe4$49f3$1@dont-email.me> |
| In reply to | #116552 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>>>> <https://en.wikipedia.org/wiki/Datapoint_2200#Technical_description> >>>>> says: >>>>> >>>>> |[...] Because the original Datapoint 2200 had a serial >>>>> |processor, it needed to start with the lowest bit of the lowest byte >>>>> |in order to handle carries. >>> [...] >>>>For the Datapoint 2200, there was a solid technical reason: >>>>It used shift register memory which supplied one bit at a time, >>>>so the adder *had* to be little-endian. >>> >>> Looks plausible at first, but when I think about it some more, both >>> claims are wrong. >> >>Unfortunately, you are mistaken. > > A claim without any supporting argument. Then maybe some more explanation is needed. It is sometimes difficult to think back to the limitations those designers faced. The 2200 did not have byte-addressable memory; memory contents only could be used when they bubbled up through the shift registers. Otherwise, the CPU had to wait. (It was a silicon version of the mercury delay lines of the UNIVAC I). So, how do you add or subtract values in memory? From low to high value, saving carries. You then have a choice of either loading them in sequence, in a single go, or to load the high value, wait for half a microsecond and then load the low value. Would you build such a machine in big-endian or little-endian? (And yes, it seems negative branches could take ~ 500 cycles, as well.) -- 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-05-20 17:30 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <2026May20.193049@mips.complang.tuwien.ac.at> |
| In reply to | #116554 |
Thomas Koenig <tkoenig@netcologne.de> writes: >The 2200 did not have byte-addressable memory; memory contents only >could be used when they bubbled up through the shift registers. >Otherwise, the CPU had to wait. (It was a silicon version of the >mercury delay lines of the UNIVAC I). > >So, how do you add or subtract values in memory? From low to high >value, saving carries. You then have a choice of either loading >them in sequence, in a single go, or to load the high value, >wait for half a microsecond and then load the low value. The Datapoint 2200 has only instructions for adding or subtracting the bits of a byte. For adding two 16-bit values X and Y, you load the LSB of X and the LSB of Y, add them, store the result, load the MSB of X and MSB of Y, adc them, and store the result. Given that you have only HL for memory access, and several registers, if the LSBs and MSBs are adjacent, you probably first want to load the LSB and MSB of X (and in that case, there is no preferred order), and add the LSB of Y, move A to some other register, then move the MSB of X into A, and adc the MSB of Y, then store the LSB and MSB of the result (again, no preferred order). And note that for any new address you access, you have to change at least L between the memory accesses, and maybe also H. Even with that kind of drum-like memory, how will little-endian provide a benefit? At best in the memory accesses to Y, but only if the other stuff that is going on between these two memory accesses does not advance the memory chip across the MSB (if the MSB is actually in the same memory chip as the LSB). And in any case, this is pure software convention. There is nothing in the architecture that tells programmers how to arrange the two bytes of a 16-bit data number. They could also do an array for the LSBs and an array for the MSBs (structure-of-array style), and then one would not need so many registers for intermediate storage. Load LSB of X, (update L), add LSB of Y, (update L), store LSB of the result, then (update L and maybe H), load MSB of X, (update L), adc MSB of Y, (update L) store the MSB of the result. The only thing in the architecture that actually specifies little-endian byte order is in the control-flow instructions where the byte order of the target address is little-endian. But bit-serial memory is not the reason for that, implementing these instructions with a big-endian target address would have been just as fast and just as hard. >Would you build such a machine in big-endian or little-endian? It's not about what I would do, but about what is little-endian about the Datapoint 2200, and if there were technical reasons for that. I don't see any. - 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-20 15:03 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <_2kPR.53170$5u1.25982@fx34.iad> |
| In reply to | #116540 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >quadi <quadibloc@ca.invalid> writes: >>b) Yes, little-endian is more popular, but that's just because the PDP-11, >>8080, and 6502 happened to choose it. > >Thinking about it: > > >With the BCD support of instruction sets typically requiring piecing >together the complete operation of suboperations of less than full >length (e.g., bytes on the 6502 and the 80(2)86), little-endian is >actually easier. 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. The B3500 had a clever algorithm for adding BCD numbers. The addend and augend could each be from 1 to 100 digits in length. The algorithm would start adding from the lowest (most significant digit in the longested operand) address of each operand adding each digit in turn. "The processor uses an adder that accumulates two fields from the most significant to the least significant digit positions. Reverse addition, as incorporated in the B2500 and B3500 systems has the advantage of detecting an overflow condition prior to altering the receiving field" The algorithm used a 9's counter to track the leading digits.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-05-20 18:07 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ukt8i$1dqo$3@gal.iecc.com> |
| In reply to | #116549 |
According to Scott Lurndal <slp53@pacbell.net>: >The B3500 had a clever algorithm for adding BCD numbers. The >addend and augend could each be from 1 to 100 digits in length. >The algorithm would start adding from the lowest (most significant >digit in the longested operand) address of each operand adding >each digit in turn. > > "The processor uses an adder that accumulates two fields > from the most significant to the least significant digit > positions. Reverse addition, as incorporated in the > B2500 and B3500 systems has the advantage of detecting > an overflow condition prior to altering the receiving field" > >The algorithm used a 9's counter to track the leading >digits. How did it handle carries? Let's say you're adding 099999999999999999999999999999999999999999999999999 000000000000000000000000000000000000000000000000001 If it starts at the high digit, it won't know until it gets to the end that it has to propagate carries all the way back to the beginning. S/360 had operand lengths in the instructions so even though it addresed the high byte, it could do one add and get the address of the low byte. On S/370 and later machines with virtual memory it was more complicated since it had to check and be sure that all of the pages where the operands resided were available. -- 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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-20 19:03 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <FznPR.35802$5G1.4133@fx35.iad> |
| In reply to | #116558 |
John Levine <johnl@taugh.com> writes: >According to Scott Lurndal <slp53@pacbell.net>: >>The B3500 had a clever algorithm for adding BCD numbers. The >>addend and augend could each be from 1 to 100 digits in length. >>The algorithm would start adding from the lowest (most significant >>digit in the longested operand) address of each operand adding >>each digit in turn. >> >> "The processor uses an adder that accumulates two fields >> from the most significant to the least significant digit >> positions. Reverse addition, as incorporated in the >> B2500 and B3500 systems has the advantage of detecting >> an overflow condition prior to altering the receiving field" >> >>The algorithm used a 9's counter to track the leading >>digits. > >How did it handle carries? Let's say you're adding > > 099999999999999999999999999999999999999999999999999 > 000000000000000000000000000000000000000000000000001 A value that overflows the size of the receiving field cannot be represented, so the overflow toggle is set and the instruction terminates _without modifying the receiving field_. The size of the receiving field is the larger of the two source fields. So ADD 0508 000000 100000 200000 would add the 5 digit value at address 0 to the 8 digit value at address 100000 and store the result at address 200000. > >If it starts at the high digit, it won't know until it gets to the end >that it has to propagate carries all the way back to the beginning. Actually, that's the clever part. They count 9s. Example 1: 10 digit receiving field, 10 digit addend, 1 digit augend: Memory contents before: 000000: 9999999999 000010: 1 ADD 1001 000000 000010 000020 The result of the instruction is that the overflow toggle will be set and the destination field will remain unmodified. The algorithm implicitly fills leading zeros into the shorter operand. The first digit of the addend operand is read. '9' in this case. The first digit of the augend is added (in this case, implicitly zero) and the result is 9. A special register (the 9's counter) is incremented and the algorithm proceeds to the next digit. Wash, rinse and repeat until reaching the last digit, where the sum of 9 + 1 will overflow a single digit, so the instruction terminates with overflow. If in the case you showed above, there was a zero in the first digit of both operands, there is no posibility of overflow and the algorithm will simply process each digit of the addend+augend sequentially from higher magnitude to lower magnitude. It delays writing each digit of the sum (other than the last) until it knows the following digit doesn't overflow. If it does overflow, it increments the delayed value before writing. To the extent that there multiple sequential 9s in the sum, when the next digit would overflow, the processor uses the 9's counter and the saved digit to store the correct digits to the receiving field. There's a flow chart in 1025475_B2500_B3500_RefMan_Oct69.pdf which is available on bitsavers.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-05-20 21:45 +0200 |
| Subject | Re: Byte order and BCD |
| Message-ID | <10ul31m$8lqb$1@dont-email.me> |
| In reply to | #116564 |
Scott Lurndal wrote: > John Levine <johnl@taugh.com> writes: >> According to Scott Lurndal <slp53@pacbell.net>: >>> The B3500 had a clever algorithm for adding BCD numbers. The >>> addend and augend could each be from 1 to 100 digits in length. >>> The algorithm would start adding from the lowest (most significant >>> digit in the longested operand) address of each operand adding >>> each digit in turn. >>> >>> "The processor uses an adder that accumulates two fields >>> from the most significant to the least significant digit >>> positions. Reverse addition, as incorporated in the >>> B2500 and B3500 systems has the advantage of detecting >>> an overflow condition prior to altering the receiving field" >>> >>> The algorithm used a 9's counter to track the leading >>> digits. >> >> How did it handle carries? Let's say you're adding >> >> 099999999999999999999999999999999999999999999999999 >> 000000000000000000000000000000000000000000000000001 > > A value that overflows the size of the receiving field > cannot be represented, so the overflow toggle is set and > the instruction terminates _without modifying the > receiving field_. > > The size of the receiving field is the larger of the > two source fields. So > > ADD 0508 000000 100000 200000 > > would add the 5 digit value at address 0 to the > 8 digit value at address 100000 and store the > result at address 200000. > >> >> If it starts at the high digit, it won't know until it gets to the end >> that it has to propagate carries all the way back to the beginning. > > Actually, that's the clever part. They count 9s. > > Example 1: 10 digit receiving field, 10 digit addend, 1 digit augend: > > Memory contents before: > > 000000: 9999999999 > 000010: 1 > > ADD 1001 000000 000010 000020 The example he showed had an 11 digit receive field so it would not overflow, but the two inputs would cause a full carry propagate all the way to the top digit. > > The result of the instruction is that the overflow toggle > will be set and the destination field will remain unmodified. > > The algorithm implicitly fills leading zeros into > the shorter operand. > > The first digit of the addend operand is read. '9' in > this case. The first digit of the augend is added (in this > case, implicitly zero) and the result is 9. A special > register (the 9's counter) is incremented and the algorithm > proceeds to the next digit. Wash, rinse and repeat until > reaching the last digit, where the sum of 9 + 1 will overflow > a single digit, so the instruction terminates with overflow. > > If in the case you showed above, there was a zero in the > first digit of both operands, there is no posibility of That's what he showed afair? > overflow and the algorithm will simply process each > digit of the addend+augend sequentially from higher > magnitude to lower magnitude. It delays writing each > digit of the sum (other than the last) until it knows > the following digit doesn't overflow. If it does > overflow, it increments the delayed value before > writing. To the extent that there multiple sequential > 9s in the sum, when the next digit would overflow, the > processor uses the 9's counter and the saved digit to > store the correct digits to the receiving field. > > There's a flow chart in 1025475_B2500_B3500_RefMan_Oct69.pdf > which is available on bitsavers. > So it did process them top-down, but delayed writing the anything to the output field until it was known that it would not overflow, and the same happened for every subsequent partial sum of 9. Yeah, that works but it probably caused some output hickups when a long chain of potential carries finally resolved. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-21 14:36 +0000 |
| Subject | Re: Byte order and BCD |
| Message-ID | <xLEPR.1144157$U733.281635@fx16.iad> |
| In reply to | #116566 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: >Scott Lurndal wrote: <snip> > >> overflow and the algorithm will simply process each >> digit of the addend+augend sequentially from higher >> magnitude to lower magnitude. It delays writing each >> digit of the sum (other than the last) until it knows >> the following digit doesn't overflow. If it does >> overflow, it increments the delayed value before >> writing. To the extent that there multiple sequential >> 9s in the sum, when the next digit would overflow, the >> processor uses the 9's counter and the saved digit to >> store the correct digits to the receiving field. >> >> There's a flow chart in 1025475_B2500_B3500_RefMan_Oct69.pdf >> which is available on bitsavers. >> > >So it did process them top-down, but delayed writing the anything to the >output field until it was known that it would not overflow, and the same >happened for every subsequent partial sum of 9. > >Yeah, that works but it probably caused some output hickups when a long >chain of potential carries finally resolved. :-) The maximum size of an operand was 100 digits. To add to the potential for a long hickup, each of the operands could be indirect, which in turn could point to indirect operands ad infinitum. A processor timer was started with each instruction, and if it expired before the instruction finished, the processor would raise a fault and the application would be terminated. There was also search table and linked list instructions, which had variable timing depending on the number of entries in the list or table (the instruction timer would handle infinite loops in the list).
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-20 22:50 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10uldqs$bv45$1@dont-email.me> |
| In reply to | #116558 |
On Wed, 20 May 2026 18:07:14 +0000, John Levine wrote: > On S/370 and later machines with virtual memory it was more complicated > since it had to check and be sure that all of the pages where the > operands resided were available. Yes, since while the System/360 gave you an error if you tried to use unaligned operands in memory, this restriction was abolished with the System/370. Only an unaligned operand can possibly cross a page boundary, since pages have a power-of-two size greater than the size of any data type. But this means that even on the System/370, it's a rare event that an instruction will refer to an unaligned operand. So that there is some extra overhead for unaligned values might well have been considered acceptable. John Savard
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-05-21 00:37 +0000 |
| Subject | Re: Byte order and BCD (was: Concertina IV Has Arrived) |
| Message-ID | <10ulk4j$viv$1@gal.iecc.com> |
| In reply to | #116570 |
It appears that quadi <quadibloc@ca.invalid> said:
>On Wed, 20 May 2026 18:07:14 +0000, John Levine wrote:
>
>> On S/370 and later machines with virtual memory it was more complicated
>> since it had to check and be sure that all of the pages where the
>> operands resided were available.
>
>Yes, since while the System/360 gave you an error if you tried to use
>unaligned operands in memory, this restriction was abolished with the
>System/370. Only an unaligned operand can possibly cross a page boundary,
>since pages have a power-of-two size greater than the size of any data
>type.
While that is true for the RX and RS instructions that do loads and
stores and arithmetic operations, it is not at all true for the SS
instructions common in commercial code.
Yhey have two storage operands with the length specified in the second
byte of the instruction. Even on S/360 there is no alignment
requirement for any of the operands. In most cases it can tell the
sizes of the operands at the time the instruction is decoded, e.g.,
decimal add (AP) has two four-bit length codes that say how long each
operand is and move characters (MVC) has a single 8-bit length code
that applies to both operands.
But sometimes it is not that simple. Translate and test (TRT) has
a string operand with a length, and a second 256 byte table operand.
It fetches the bytes from the string one at a time, looks them up
in the table, and stops as soon as the looked up value is non-zero,
putting the address of the source byte and the lookup values in
R1 and R2. Only the bytes actually fetched have to be resident.
The Edit instruction (ED) takes a packed decimal operand and
a pattern, with the length specifying the length of the pattern.
It goes through the pattern a byte at a time with some pattern
bytes ("digit selector") taking the next digit from the input
operand and others just copied literally. The length of the
input operand depends on the contents of the pattern.
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.
--
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]
Page 1 of 30 [1] 2 3 … 30 Next page →
Back to top | Article view | comp.arch
csiph-web