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 11 of 30 — ← Prev page 1 … 9 10 [11] 12 13 … 30 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-18 15:36 -0700 |
| Subject | Re: endian history |
| Message-ID | <86ik42tcf4.fsf@linuxsc.com> |
| In reply to | #118090 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>> [...]
>>
>>> There was an Advent of Code puzzle in 2022 (last day) where you had to
>>> work in symmetrical base-5, using '-' and '=' for -1 and -2, along
>>> with '0', '1', '2'.
>>>
>>> You had to parse 113 such numbers, all happened to be positive, but
>>> they did of course not need to be. With symmetrical encoding, there is
>>> no extra minus sign in front, just a negative first digit.
>>>
>>> The fast solutions did each input line/number in about 4-5 us, then
>>> you had to return the (decimal) sum, before converting that back to
>>> the same base-5 system.
>>
>> I'm wondering why a seemingly simple problem took as much time as
>> this. Maybe I'm misunderstanding the problem statement. Is there
>> one (base negative 5) input number per line? Surely converting such
>> an input to binary can be done more quickly than 4 microseconds.
>
> Oops!
>
> I meant 4-5 ns not microseconds.
>
> 3 orders of magnitude does make a small difference...
Just a little... :)
>>> Just like decimal, it is a lot easier to convert ascii to binary than
>>> binary to ascii, the difference between div/mod every digit and a
>>> single mul.
>>
>> Now I'm curious to see how you implemented the binary-to-ascii part
>> of the problem. Do you still have the code around?
>
> Sure:
>
> const BASE:i64 = 5;
> const VALUE:[i8;256] = [
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>
> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>
> fn tobase(n:i64) -> String
> {
> let mut n = n;
> let mut buf:[u8;32] = [0;32];
> let mut p = buf.len();
> loop {
> let r = n % BASE; // positive remainder for positive $BASE
> let d = DIGITS[r as usize];
> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
> p -= 1;
> buf[p] = d;
> if n == 0 {break;}
> }
> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
> }
I'm guessing this code is in Rust. Can I ask you to translate it
to C for me? Mostly I can guess at the meaning, but as I am only
a novice with Rust I worry that my guessing would be wrong in some
cases, and wrong functionality would result.
> In order to be really fast, the compiler has to recognize that both
> the div and mod should use reciprocal mul (standard), and if possible,
> only do it once.
> ...
> Checking Godbolt:
>
> Turns out it is actually generating two IMULs, but it should work for
> both positive and negative inputs...
I suspect the two multiplys are a consequence of the usual way for
producing a quotient and remainder:
quotient = n / BASE;
remainder = n - quotient*BASE
So one of the multiplys is doing a divide by BASE, and the other
multiply is doing a multiply by BASE. That is plausible anyway.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-22 19:51 +0200 |
| Subject | Re: endian history |
| Message-ID | <118uf6m$12tta$1@dont-email.me> |
| In reply to | #118093 |
Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>> [...]
>>>
>>>> There was an Advent of Code puzzle in 2022 (last day) where you had to
>>>> work in symmetrical base-5, using '-' and '=' for -1 and -2, along
>>>> with '0', '1', '2'.
>>>>
>>>> You had to parse 113 such numbers, all happened to be positive, but
>>>> they did of course not need to be. With symmetrical encoding, there is
>>>> no extra minus sign in front, just a negative first digit.
>>>>
>>>> The fast solutions did each input line/number in about 4-5 us, then
>>>> you had to return the (decimal) sum, before converting that back to
>>>> the same base-5 system.
>>>
>>> I'm wondering why a seemingly simple problem took as much time as
>>> this. Maybe I'm misunderstanding the problem statement. Is there
>>> one (base negative 5) input number per line? Surely converting such
>>> an input to binary can be done more quickly than 4 microseconds.
>>
>> Oops!
>>
>> I meant 4-5 ns not microseconds.
>>
>> 3 orders of magnitude does make a small difference...
>
> Just a little... :)
>
>>>> Just like decimal, it is a lot easier to convert ascii to binary than
>>>> binary to ascii, the difference between div/mod every digit and a
>>>> single mul.
>>>
>>> Now I'm curious to see how you implemented the binary-to-ascii part
>>> of the problem. Do you still have the code around?
>>
>> Sure:
>>
>> const BASE:i64 = 5;
>> const VALUE:[i8;256] = [
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>>
>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>>
>> fn tobase(n:i64) -> String
>> {
>> let mut n = n;
>> let mut buf:[u8;32] = [0;32];
>> let mut p = buf.len();
>> loop {
>> let r = n % BASE; // positive remainder for positive $BASE
>> let d = DIGITS[r as usize];
>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
>> p -= 1;
>> buf[p] = d;
>> if n == 0 {break;}
>> }
>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
>> }
>
> I'm guessing this code is in Rust. Can I ask you to translate it
> to C for me? Mostly I can guess at the meaning, but as I am only
> a novice with Rust I worry that my guessing would be wrong in some
> cases, and wrong functionality would result.
The only non-C part here is the final library call to convert a slice of
bytes into a Rust String, the rest is simply what it seems like for a C
programmer.
>
>> In order to be really fast, the compiler has to recognize that both
>> the div and mod should use reciprocal mul (standard), and if possible,
>> only do it once.
>> ...
>> Checking Godbolt:
>>
>> Turns out it is actually generating two IMULs, but it should work for
>> both positive and negative inputs...
>
> I suspect the two multiplys are a consequence of the usual way for
> producing a quotient and remainder:
>
> quotient = n / BASE;
> remainder = n - quotient*BASE
>
> So one of the multiplys is doing a divide by BASE, and the other
> multiply is doing a multiply by BASE. That is plausible anyway.
>
No, it was actually doing two IMULs by the reciprocal, the multipy by 5
is just a regular LEA reg,[reg+reg*4] which only takes a cycle.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-23 08:28 -0700 |
| Subject | Re: endian history |
| Message-ID | <86ld8srnq9.fsf@linuxsc.com> |
| In reply to | #118127 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>> [...]
>>>>
>>>>> There was an Advent of Code puzzle in 2022 (last day) where you
>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
>>>>> -2, along with '0', '1', '2'.
>>>>>
>>>>> You had to parse 113 such numbers, all happened to be positive,
>>>>> but they did of course not need to be. With symmetrical encoding,
>>>>> there is no extra minus sign in front, just a negative first
>>>>> digit.
[...]
>>>>> Just like decimal, it is a lot easier to convert ascii to binary
>>>>> than binary to ascii, the difference between div/mod every digit
>>>>> and a single mul.
>>>>
>>>> Now I'm curious to see how you implemented the binary-to-ascii part
>>>> of the problem. Do you still have the code around?
>>>
>>> Sure:
>>>
>>> const BASE:i64 = 5;
>>> const VALUE:[i8;256] = [
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>>>
>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>>>
>>> fn tobase(n:i64) -> String
>>> {
>>> let mut n = n;
>>> let mut buf:[u8;32] = [0;32];
>>> let mut p = buf.len();
>>> loop {
>>> let r = n % BASE; // positive remainder for positive $BASE
>>> let d = DIGITS[r as usize];
>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
>>> p -= 1;
>>> buf[p] = d;
>>> if n == 0 {break;}
>>> }
>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
>>> }
>>
>> I'm guessing this code is in Rust. Can I ask you to translate it
>> to C for me? Mostly I can guess at the meaning, but as I am only
>> a novice with Rust I worry that my guessing would be wrong in some
>> cases, and wrong functionality would result.
>
> The only non-C part here is the final library call to convert a
> slice of bytes into a Rust String, the rest is simply what it seems
> like for a C programmer.
It looks like this statement cannot be right. In C, if n is
negative and not a multiple of 5, then n%5 is negative. But after
giving r the value of n % BASE, r is used to index an array. That
doesn't work if the value of r is negative (to be clear, taking
the code as C code). So something is off.
>>> In order to be really fast, the compiler has to recognize that
>>> both the div and mod should use reciprocal mul (standard), and
>>> if possible, only do it once.
>>> ...
>>> Checking Godbolt:
>>>
>>> Turns out it is actually generating two IMULs, but it should
>>> work for both positive and negative inputs...
>>
>> I suspect the two multiplys are a consequence of the usual way for
>> producing a quotient and remainder:
>>
>> quotient = n / BASE;
>> remainder = n - quotient*BASE
>>
>> So one of the multiplys is doing a divide by BASE, and the other
>> multiply is doing a multiply by BASE. That is plausible anyway.
I realized later this idea is wrong. The two IMULs are a result
of the two numerators being different, in one case being just n,
and in the other case being n-<something>. An IMUL is needed for
each of the two numerators (with one being implied for n%BASE).
> No, it was actually doing two IMULs by the reciprocal, the multipy
> by 5 is just a regular LEA reg,[reg+reg*4] which only takes a
> cycle.
Here is a way of converting that needs only one mul, although it
does have an additional multiply-by-five LEA in the first loop
(the name UL is a typedef for unsigned long):
char *
string_for_balanced_base_5( long x, char *p ){
UL u = x < 0 ? -x : x;
UL v = 0;
UL k = -1;
do k++, v = v*5 + 2; while( v < u );
v += x;
*--p = 0;
do {
*--p = "=-012"[ v%5 ];
v /= 5;
} while( k-- > 0 );
return p;
}
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-23 18:01 +0200 |
| Subject | Re: endian history |
| Message-ID | <1190t4j$1u067$1@dont-email.me> |
| In reply to | #118152 |
Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>> There was an Advent of Code puzzle in 2022 (last day) where you
>>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
>>>>>> -2, along with '0', '1', '2'.
>>>>>>
>>>>>> You had to parse 113 such numbers, all happened to be positive,
>>>>>> but they did of course not need to be. With symmetrical encoding,
>>>>>> there is no extra minus sign in front, just a negative first
>>>>>> digit.
>
> [...]
>
>>>>>> Just like decimal, it is a lot easier to convert ascii to binary
>>>>>> than binary to ascii, the difference between div/mod every digit
>>>>>> and a single mul.
>>>>>
>>>>> Now I'm curious to see how you implemented the binary-to-ascii part
>>>>> of the problem. Do you still have the code around?
>>>>
>>>> Sure:
>>>>
>>>> const BASE:i64 = 5;
>>>> const VALUE:[i8;256] = [
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>>>>
>>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>>>>
>>>> fn tobase(n:i64) -> String
>>>> {
>>>> let mut n = n;
>>>> let mut buf:[u8;32] = [0;32];
>>>> let mut p = buf.len();
>>>> loop {
>>>> let r = n % BASE; // positive remainder for positive $BASE
>>>> let d = DIGITS[r as usize];
>>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
>>>> p -= 1;
>>>> buf[p] = d;
>>>> if n == 0 {break;}
>>>> }
>>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
>>>> }
>>>
>>> I'm guessing this code is in Rust. Can I ask you to translate it
>>> to C for me? Mostly I can guess at the meaning, but as I am only
>>> a novice with Rust I worry that my guessing would be wrong in some
>>> cases, and wrong functionality would result.
>>
>> The only non-C part here is the final library call to convert a
>> slice of bytes into a Rust String, the rest is simply what it seems
>> like for a C programmer.
>
> It looks like this statement cannot be right. In C, if n is
> negative and not a multiple of 5, then n%5 is negative. But after
As my original comments stated, in both Perl and Rust n % BASE will
always return a positive remainder when the BASE is positive.
I.e not like C where I believe this used to be implementation-defined.
> giving r the value of n % BASE, r is used to index an array. That
> doesn't work if the value of r is negative (to be clear, taking
> the code as C code). So something is off.
>
>>>> In order to be really fast, the compiler has to recognize that
>>>> both the div and mod should use reciprocal mul (standard), and
>>>> if possible, only do it once.
>>>> ...
>>>> Checking Godbolt:
>>>>
>>>> Turns out it is actually generating two IMULs, but it should
>>>> work for both positive and negative inputs...
>>>
>>> I suspect the two multiplys are a consequence of the usual way for
>>> producing a quotient and remainder:
>>>
>>> quotient = n / BASE;
>>> remainder = n - quotient*BASE
>>>
>>> So one of the multiplys is doing a divide by BASE, and the other
>>> multiply is doing a multiply by BASE. That is plausible anyway.
>
> I realized later this idea is wrong. The two IMULs are a result
> of the two numerators being different, in one case being just n,
> and in the other case being n-<something>. An IMUL is needed for
> each of the two numerators (with one being implied for n%BASE).
Right!
I know that both divisions should return the same result, with the
second intentionally have zero remainder, but that does leave the door
open for an optimized version. Thanks!
>
>> No, it was actually doing two IMULs by the reciprocal, the multipy
>> by 5 is just a regular LEA reg,[reg+reg*4] which only takes a
>> cycle.
>
> Here is a way of converting that needs only one mul, although it
> does have an additional multiply-by-five LEA in the first loop
> (the name UL is a typedef for unsigned long):
>
> char *
> string_for_balanced_base_5( long x, char *p ){
> UL u = x < 0 ? -x : x;
> UL v = 0;
> UL k = -1;
>
> do k++, v = v*5 + 2; while( v < u );
> v += x;
>
> *--p = 0;
> do {
> *--p = "=-012"[ v%5 ];
> v /= 5;
> } while( k-- > 0 );
>
> return p;
> }
>
I'll see if this translates, and if it is faster...
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-23 10:47 -0700 |
| Subject | Re: endian history |
| Message-ID | <86h5jfsvvm.fsf@linuxsc.com> |
| In reply to | #118153 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Tim Rentsch wrote:
>>>>>
>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> There was an Advent of Code puzzle in 2022 (last day) where you
>>>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
>>>>>>> -2, along with '0', '1', '2'.
>>>>>>>
>>>>>>> You had to parse 113 such numbers, all happened to be positive,
>>>>>>> but they did of course not need to be. With symmetrical encoding,
>>>>>>> there is no extra minus sign in front, just a negative first
>>>>>>> digit.
>>
>> [...]
>>
>>>>>>> Just like decimal, it is a lot easier to convert ascii to binary
>>>>>>> than binary to ascii, the difference between div/mod every digit
>>>>>>> and a single mul.
>>>>>>
>>>>>> Now I'm curious to see how you implemented the binary-to-ascii part
>>>>>> of the problem. Do you still have the code around?
>>>>>
>>>>> Sure:
>>>>>
>>>>> const BASE:i64 = 5;
>>>>> const VALUE:[i8;256] = [
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>>>>>
>>>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>>>>>
>>>>> fn tobase(n:i64) -> String
>>>>> {
>>>>> let mut n = n;
>>>>> let mut buf:[u8;32] = [0;32];
>>>>> let mut p = buf.len();
>>>>> loop {
>>>>> let r = n % BASE; // positive remainder for positive $BASE
>>>>> let d = DIGITS[r as usize];
>>>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
>>>>> p -= 1;
>>>>> buf[p] = d;
>>>>> if n == 0 {break;}
>>>>> }
>>>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
>>>>> }
>>>>
>>>> I'm guessing this code is in Rust. Can I ask you to translate it
>>>> to C for me? Mostly I can guess at the meaning, but as I am only
>>>> a novice with Rust I worry that my guessing would be wrong in some
>>>> cases, and wrong functionality would result.
>>>
>>> The only non-C part here is the final library call to convert a
>>> slice of bytes into a Rust String, the rest is simply what it seems
>>> like for a C programmer.
>>
>> It looks like this statement cannot be right. In C, if n is
>> negative and not a multiple of 5, then n%5 is negative. But after
>
> As my original comments stated, in both Perl and Rust n % BASE will
> always return a positive remainder when the BASE is positive.
The original post did have a comment saying that the remainder
would be positive (i.e., non-negative), but it didn't mention
either Perl or Rust. It's because of this kind of possible
incongruities that I asked for a C version.
> I.e not like C where I believe this used to be implementation-defined.
In the original C standard division and remainder were indeed
implementation-defined for negative operands. That was changed
in C99.
>> giving r the value of n % BASE, r is used to index an array. That
>> doesn't work if the value of r is negative (to be clear, taking
>> the code as C code). So something is off.
>>
>>>>> In order to be really fast, the compiler has to recognize that
>>>>> both the div and mod should use reciprocal mul (standard), and
>>>>> if possible, only do it once.
>>>>> ...
>>>>> Checking Godbolt:
>>>>>
>>>>> Turns out it is actually generating two IMULs, but it should
>>>>> work for both positive and negative inputs...
>>>>
>>>> I suspect the two multiplys are a consequence of the usual way for
>>>> producing a quotient and remainder:
>>>>
>>>> quotient = n / BASE;
>>>> remainder = n - quotient*BASE
>>>>
>>>> So one of the multiplys is doing a divide by BASE, and the other
>>>> multiply is doing a multiply by BASE. That is plausible anyway.
>>
>> I realized later this idea is wrong. The two IMULs are a result
>> of the two numerators being different, in one case being just n,
>> and in the other case being n-<something>. An IMUL is needed for
>> each of the two numerators (with one being implied for n%BASE).
>
> Right!
>
> I know that both divisions should return the same result, with the
> second intentionally have zero remainder, but that does leave the door
> open for an optimized version. Thanks!
The point is that the two divisions can give different results, even
when both operands are positive -- one rounds down, the other might
round up.
>>> No, it was actually doing two IMULs by the reciprocal, the multipy
>>> by 5 is just a regular LEA reg,[reg+reg*4] which only takes a
>>> cycle.
>>
>> Here is a way of converting that needs only one mul, although it
>> does have an additional multiply-by-five LEA in the first loop
>> (the name UL is a typedef for unsigned long):
>>
>> char *
>> string_for_balanced_base_5( long x, char *p ){
>> UL u = x < 0 ? -x : x;
>> UL v = 0;
>> UL k = -1;
>>
>> do k++, v = v*5 + 2; while( v < u );
>> v += x;
>>
>> *--p = 0;
>> do {
>> *--p = "=-012"[ v%5 ];
>> v /= 5;
>> } while( k-- > 0 );
>>
>> return p;
>> }
>
> I'll see if this translates, and if it is faster...
Please tweak it up to improve any platform-specific weaknesses
that might be there. I'm sure you are better at doing that than
I am (plus you are running on hardware with different performance
characteristics).
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-23 18:41 +0000 |
| Subject | Re: endian history |
| Message-ID | <1790188863-5857@newsgrouper.org> |
| In reply to | #118152 |
Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
> > Tim Rentsch wrote:
> >
> >> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >>
> >>> Tim Rentsch wrote:
> >>>
> >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >>>>
> >>>> [...]
> >>>>
> >>>>> There was an Advent of Code puzzle in 2022 (last day) where you
> >>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
> >>>>> -2, along with '0', '1', '2'.
> >>>>>
> >>>>> You had to parse 113 such numbers, all happened to be positive,
> >>>>> but they did of course not need to be. With symmetrical encoding,
> >>>>> there is no extra minus sign in front, just a negative first
> >>>>> digit.
>
> [...]
>
> >>>>> Just like decimal, it is a lot easier to convert ascii to binary
> >>>>> than binary to ascii, the difference between div/mod every digit
> >>>>> and a single mul.
> >>>>
> >>>> Now I'm curious to see how you implemented the binary-to-ascii part
> >>>> of the problem. Do you still have the code around?
> >>>
> >>> Sure:
> >>>
> >>> const BASE:i64 = 5;
> >>> const VALUE:[i8;256] = [
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
> >>>
> >>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
> >>>
> >>> fn tobase(n:i64) -> String
> >>> {
> >>> let mut n = n;
> >>> let mut buf:[u8;32] = [0;32];
> >>> let mut p = buf.len();
> >>> loop {
> >>> let r = n % BASE; // positive remainder for positive $BASE
> >>> let d = DIGITS[r as usize];
> >>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
> >>> p -= 1;
> >>> buf[p] = d;
> >>> if n == 0 {break;}
> >>> }
> >>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
> >>> }
> >>
> >> I'm guessing this code is in Rust. Can I ask you to translate it
> >> to C for me? Mostly I can guess at the meaning, but as I am only
> >> a novice with Rust I worry that my guessing would be wrong in some
> >> cases, and wrong functionality would result.
> >
> > The only non-C part here is the final library call to convert a
> > slice of bytes into a Rust String, the rest is simply what it seems
> > like for a C programmer.
>
> It looks like this statement cannot be right. In C, if n is
> negative and not a multiple of 5, then n%5 is negative. But after
An obvious case where n should be unsigned not signed.
> giving r the value of n % BASE, r is used to index an array. That
> doesn't work if the value of r is negative (to be clear, taking
> the code as C code). So something is off.
>
> >>> In order to be really fast, the compiler has to recognize that
> >>> both the div and mod should use reciprocal mul (standard), and
> >>> if possible, only do it once.
> >>> ...
> >>> Checking Godbolt:
> >>>
> >>> Turns out it is actually generating two IMULs, but it should
> >>> work for both positive and negative inputs...
> >>
> >> I suspect the two multiplys are a consequence of the usual way for
> >> producing a quotient and remainder:
> >>
> >> quotient = n / BASE;
> >> remainder = n - quotient*BASE
> >>
> >> So one of the multiplys is doing a divide by BASE, and the other
> >> multiply is doing a multiply by BASE. That is plausible anyway.
>
> I realized later this idea is wrong. The two IMULs are a result
> of the two numerators being different, in one case being just n,
> and in the other case being n-<something>. An IMUL is needed for
> each of the two numerators (with one being implied for n%BASE).
>
> > No, it was actually doing two IMULs by the reciprocal, the multipy
> > by 5 is just a regular LEA reg,[reg+reg*4] which only takes a
> > cycle.
>
> Here is a way of converting that needs only one mul, although it
> does have an additional multiply-by-five LEA in the first loop
> (the name UL is a typedef for unsigned long):
>
> char *
> string_for_balanced_base_5( long x, char *p ){
> UL u = x < 0 ? -x : x;
> UL v = 0;
> UL k = -1;
>
> do k++, v = v*5 + 2; while( v < u );
> v += x;
>
> *--p = 0;
> do {
> *--p = "=-012"[ v%5 ];
> v /= 5;
> } while( k-- > 0 );
>
> return p;
> }
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-23 13:15 -0700 |
| Subject | Re: endian history |
| Message-ID | <86cxu3sp11.fsf@linuxsc.com> |
| In reply to | #118159 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Tim Rentsch wrote:
>>>>>
>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> There was an Advent of Code puzzle in 2022 (last day) where you
>>>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
>>>>>>> -2, along with '0', '1', '2'.
>>>>>>>
>>>>>>> You had to parse 113 such numbers, all happened to be positive,
>>>>>>> but they did of course not need to be. With symmetrical encoding,
>>>>>>> there is no extra minus sign in front, just a negative first
>>>>>>> digit.
>>
>> [...]
>>
>>>>>>> Just like decimal, it is a lot easier to convert ascii to binary
>>>>>>> than binary to ascii, the difference between div/mod every digit
>>>>>>> and a single mul.
>>>>>>
>>>>>> Now I'm curious to see how you implemented the binary-to-ascii part
>>>>>> of the problem. Do you still have the code around?
>>>>>
>>>>> Sure:
>>>>>
>>>>> const BASE:i64 = 5;
>>>>> const VALUE:[i8;256] = [
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>>>>>
>>>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>>>>>
>>>>> fn tobase(n:i64) -> String
>>>>> {
>>>>> let mut n = n;
>>>>> let mut buf:[u8;32] = [0;32];
>>>>> let mut p = buf.len();
>>>>> loop {
>>>>> let r = n % BASE; // positive remainder for positive $BASE
>>>>> let d = DIGITS[r as usize];
>>>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
>>>>> p -= 1;
>>>>> buf[p] = d;
>>>>> if n == 0 {break;}
>>>>> }
>>>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
>>>>> }
>>>>
>>>> I'm guessing this code is in Rust. Can I ask you to translate it
>>>> to C for me? Mostly I can guess at the meaning, but as I am only
>>>> a novice with Rust I worry that my guessing would be wrong in some
>>>> cases, and wrong functionality would result.
>>>
>>> The only non-C part here is the final library call to convert a
>>> slice of bytes into a Rust String, the rest is simply what it seems
>>> like for a C programmer.
>>
>> It looks like this statement cannot be right. In C, if n is
>> negative and not a multiple of 5, then n%5 is negative. But after
>
> An obvious case where n should be unsigned not signed.
Yes and no. It is possible to solve this problem where the
divisions and remainders are always done on non-negative values
(and so could be unsigned rather than signed). I did in fact
code up a solution that has this property. But such code can be
harder to write and harder to understand. In contrast, it's
fairly easy to solve this problem using signed quantities and
simply deals with the negative remainders appropriately. Which
approach is better? As usual that can depend on other factors,
including performance.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-24 15:09 +0200 |
| Subject | Re: endian history |
| Message-ID | <11937ek$2moih$1@dont-email.me> |
| In reply to | #118162 |
Tim Rentsch wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>>> Tim Rentsch wrote:
>>>>>>
>>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> There was an Advent of Code puzzle in 2022 (last day) where you
>>>>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
>>>>>>>> -2, along with '0', '1', '2'.
>>>>>>>>
>>>>>>>> You had to parse 113 such numbers, all happened to be positive,
>>>>>>>> but they did of course not need to be. With symmetrical encoding,
>>>>>>>> there is no extra minus sign in front, just a negative first
>>>>>>>> digit.
>>>
>>> [...]
>>>
>>>>>>>> Just like decimal, it is a lot easier to convert ascii to binary
>>>>>>>> than binary to ascii, the difference between div/mod every digit
>>>>>>>> and a single mul.
>>>>>>>
>>>>>>> Now I'm curious to see how you implemented the binary-to-ascii part
>>>>>>> of the problem. Do you still have the code around?
>>>>>>
>>>>>> Sure:
>>>>>>
>>>>>> const BASE:i64 = 5;
>>>>>> const VALUE:[i8;256] = [
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
>>>>>>
>>>>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
>>>>>>
>>>>>> fn tobase(n:i64) -> String
>>>>>> {
>>>>>> let mut n = n;
>>>>>> let mut buf:[u8;32] = [0;32];
>>>>>> let mut p = buf.len();
>>>>>> loop {
>>>>>> let r = n % BASE; // positive remainder for positive $BASE
>>>>>> let d = DIGITS[r as usize];
>>>>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
>>>>>> p -= 1;
>>>>>> buf[p] = d;
>>>>>> if n == 0 {break;}
>>>>>> }
>>>>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
>>>>>> }
>>>>>
>>>>> I'm guessing this code is in Rust. Can I ask you to translate it
>>>>> to C for me? Mostly I can guess at the meaning, but as I am only
>>>>> a novice with Rust I worry that my guessing would be wrong in some
>>>>> cases, and wrong functionality would result.
>>>>
>>>> The only non-C part here is the final library call to convert a
>>>> slice of bytes into a Rust String, the rest is simply what it seems
>>>> like for a C programmer.
>>>
>>> It looks like this statement cannot be right. In C, if n is
>>> negative and not a multiple of 5, then n%5 is negative. But after
>>
>> An obvious case where n should be unsigned not signed.
>
> Yes and no. It is possible to solve this problem where the
> divisions and remainders are always done on non-negative values
> (and so could be unsigned rather than signed). I did in fact
> code up a solution that has this property. But such code can be
> harder to write and harder to understand. In contrast, it's
> fairly easy to solve this problem using signed quantities and
> simply deals with the negative remainders appropriately. Which
> approach is better? As usual that can depend on other factors,
> including performance.
>
When using a balanced encoding like I was asked to use here, any digit
can be negative, for both positive and negative inputs: Only the first6
digit must have the same sign as the input value to be converted.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-25 02:47 -0700 |
| Subject | Re: endian history |
| Message-ID | <864ifdslwh.fsf@linuxsc.com> |
| In reply to | #118169 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: > Tim Rentsch wrote: > >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: [converting a signed value to a balanced base 5 representation] >>> An obvious case where n should be unsigned not signed. >> >> Yes and no. It is possible to solve this problem where the >> divisions and remainders are always done on non-negative values >> (and so could be unsigned rather than signed). I did in fact >> code up a solution that has this property. But such code can be >> harder to write and harder to understand. In contrast, it's >> fairly easy to solve this problem using signed quantities and >> simply deals with the negative remainders appropriately. Which >> approach is better? As usual that can depend on other factors, >> including performance. > > When using a balanced encoding like I was asked to use here, any > digit can be negative, for both positive and negative inputs: > Only the first digit must have the same sign as the input value > to be converted. I get that. But to represent all the values in the range we must deal with the possibility that other digits may also be negative.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-24 17:00 +0000 |
| Subject | Re: endian history |
| Message-ID | <1790269240-5857@newsgrouper.org> |
| In reply to | #118162 |
Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
> > Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
> >
> >> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >>
> >>> Tim Rentsch wrote:
> >>>
> >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >>>>
> >>>>> Tim Rentsch wrote:
> >>>>>
> >>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>> There was an Advent of Code puzzle in 2022 (last day) where you
> >>>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and
> >>>>>>> -2, along with '0', '1', '2'.
> >>>>>>>
> >>>>>>> You had to parse 113 such numbers, all happened to be positive,
> >>>>>>> but they did of course not need to be. With symmetrical encoding,
> >>>>>>> there is no extra minus sign in front, just a negative first
> >>>>>>> digit.
> >>
> >> [...]
> >>
> >>>>>>> Just like decimal, it is a lot easier to convert ascii to binary
> >>>>>>> than binary to ascii, the difference between div/mod every digit
> >>>>>>> and a single mul.
> >>>>>>
> >>>>>> Now I'm curious to see how you implemented the binary-to-ascii part
> >>>>>> of the problem. Do you still have the code around?
> >>>>>
> >>>>> Sure:
> >>>>>
> >>>>> const BASE:i64 = 5;
> >>>>> const VALUE:[i8;256] = [
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
> >>>>>
> >>>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-'];
> >>>>>
> >>>>> fn tobase(n:i64) -> String
> >>>>> {
> >>>>> let mut n = n;
> >>>>> let mut buf:[u8;32] = [0;32];
> >>>>> let mut p = buf.len();
> >>>>> loop {
> >>>>> let r = n % BASE; // positive remainder for positive $BASE
> >>>>> let d = DIGITS[r as usize];
> >>>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division!
> >>>>> p -= 1;
> >>>>> buf[p] = d;
> >>>>> if n == 0 {break;}
> >>>>> }
> >>>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string()
> >>>>> }
> >>>>
> >>>> I'm guessing this code is in Rust. Can I ask you to translate it
> >>>> to C for me? Mostly I can guess at the meaning, but as I am only
> >>>> a novice with Rust I worry that my guessing would be wrong in some
> >>>> cases, and wrong functionality would result.
> >>>
> >>> The only non-C part here is the final library call to convert a
> >>> slice of bytes into a Rust String, the rest is simply what it seems
> >>> like for a C programmer.
> >>
> >> It looks like this statement cannot be right. In C, if n is
> >> negative and not a multiple of 5, then n%5 is negative. But after
> >
> > An obvious case where n should be unsigned not signed.
>
> Yes and no. It is possible to solve this problem where the
> divisions and remainders are always done on non-negative values
> (and so could be unsigned rather than signed). I did in fact
> code up a solution that has this property. But such code can be
> harder to write and harder to understand. In contrast, it's
> fairly easy to solve this problem using signed quantities and
> simply deals with the negative remainders appropriately. Which
> approach is better? As usual that can depend on other factors,
> including performance.
In my own code, 90%-odd of integer variables are unsigned. So,
perhaps, over the decades, I have developed a way of coding that
works better in unsigned space than in signed space. {{Almost
every field in almost every CPU control register is inherently
unsigned, as are the use of these as memory indexes, method-
call indexes, and switch variables.}}
I got to the point where if a negative value is not absolutely
necessary, the variable is simply unsigned.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-24 18:35 +0000 |
| Subject | Re: endian history |
| Message-ID | <X3etS.2$xN2.0@fx46.iad> |
| In reply to | #118174 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
>
>>
>> Yes and no. It is possible to solve this problem where the
>> divisions and remainders are always done on non-negative values
>> (and so could be unsigned rather than signed). I did in fact
>> code up a solution that has this property. But such code can be
>> harder to write and harder to understand. In contrast, it's
>> fairly easy to solve this problem using signed quantities and
>> simply deals with the negative remainders appropriately. Which
>> approach is better? As usual that can depend on other factors,
>> including performance.
>
>In my own code, 90%-odd of integer variables are unsigned. So,
>perhaps, over the decades, I have developed a way of coding that
>works better in unsigned space than in signed space. {{Almost
>every field in almost every CPU control register is inherently
>unsigned, as are the use of these as memory indexes, method-
>call indexes, and switch variables.}}
>
>I got to the point where if a negative value is not absolutely
>necessary, the variable is simply unsigned.
That's true in my code as well[*]. The only place where FP is
used is when emulating ARM64 floating point instructions, and only
then if the host FP instructions will provide identical results to similar ARM64
FP instructions.
[*] Although I prefer not to use unadorned 'unsigned' - I use
the stdint.h types (uint64_t, uint32_t, uint16_t and uint8_t).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-25 03:19 -0700 |
| Subject | Re: endian history |
| Message-ID | <86zex5r5tl.fsf@linuxsc.com> |
| In reply to | #118174 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
>
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> posted:
[considering a function to convert a signed argument, n, to
a balanced base 5 representation]
>>>> It looks like this statement cannot be right. In C, if n is
>>>> negative and not a multiple of 5, then n%5 is negative.
>>>
>>> An obvious case where n should be unsigned not signed.
>>
>> Yes and no. It is possible to solve this problem where the
>> divisions and remainders are always done on non-negative values
>> (and so could be unsigned rather than signed). I did in fact
>> code up a solution that has this property. But such code can be
>> harder to write and harder to understand. In contrast, it's
>> fairly easy to solve this problem using signed quantities and
>> simply deals with the negative remainders appropriately. Which
>> approach is better? As usual that can depend on other factors,
>> including performance.
First I misunderstood what you were suggesting; sorry about that.
The parameter n cannot be unsigned, because the purpose of the
function to produce a representation of a range of values, with
roughly half of them being negative.
> In my own code, 90%-odd of integer variables are unsigned. So,
> perhaps, over the decades, I have developed a way of coding that
> works better in unsigned space than in signed space. {{Almost
> every field in almost every CPU control register is inherently
> unsigned, as are the use of these as memory indexes, method-
> call indexes, and switch variables.}}
>
> I got to the point where if a negative value is not absolutely
> necessary, the variable is simply unsigned.
I get that. I'm pretty much the same in terms of preferring
unsigned types for integer values, and see similar ratios.
The point here is that this problem is inherently signed in at
least one aspect, because what is being converted is a signed
value. There is no point in using a balanced base encoding if all
the values being represented are non-negative.
Given that the input argument will be signed, the question is how
should the code be written to carry out the conversion? It can be
written using signed variables, like what Terje did. It also can be
written using unsigned variables, like the example function that I
posted. Which one is better? I wouldn't choose an unsigned-only
writing just because it doesn't used signed types (not counting the
signed argument). In most cases I give a higher weight to which
writing is easier to understand and easier to see how it works.
Other things being equal, I prefer using unsigned types. Here I am
not yet convinced that other factors are indeed equal.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-26 07:41 +0000 |
| Subject | Re: endian history |
| Message-ID | <1197sug$9dah$1@dont-email.me> |
| In reply to | #118174 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > In my own code, 90%-odd of integer variables are unsigned. Standard Fortran has ony signed integers. Unfortunately, my attempt at introducing them into the standard was passed by J3 (the US standards body which does most of the work) but not taken up by WG5, the overarching ISO standards body. I went ahead and implemented it in gfortran anyway, in cooperation with flang. So, in Fortran code, the existing use of unsigned integers is extremely low. I use it privately, so it is not zero :-) -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-27 02:48 +0000 |
| Subject | Re: endian history |
| Message-ID | <119a05n$10eok$1@dont-email.me> |
| In reply to | #118227 |
On Sat, 26 Sep 2026 07:41:04 -0000 (UTC), Thomas Koenig wrote: > MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > >> In my own code, 90%-odd of integer variables are unsigned. > > Standard Fortran has ony signed integers. Unfortunately, my attempt > at introducing them into the standard was passed by J3 (the US > standards body which does most of the work) but not taken up by WG5, > the overarching ISO standards body. I went ahead and implemented it > in gfortran anyway, in cooperation with flang. > > So, in Fortran code, the existing use of unsigned integers is > extremely low. I use it privately, so it is not zero :-) Good for you. ;) I’m trying to understand the mindset that believes that signed integers are all you need, you don’t need unsigned ones; is this a difference between mathematicians and computer scientists, perhaps? Computer scientists are accustomed to thinking in terms of bitfields, where sign-extension is often a nuisance; mathematicians are not.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2026-09-26 23:49 -0400 |
| Subject | Re: endian history |
| Message-ID | <119a3nv$11e4r$1@dont-email.me> |
| In reply to | #118242 |
On 2026-09-26 10:48 p.m., Lawrence D’Oliveiro wrote: > On Sat, 26 Sep 2026 07:41:04 -0000 (UTC), Thomas Koenig wrote: > >> MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: >> >>> In my own code, 90%-odd of integer variables are unsigned. >> >> Standard Fortran has ony signed integers. Unfortunately, my attempt >> at introducing them into the standard was passed by J3 (the US >> standards body which does most of the work) but not taken up by WG5, >> the overarching ISO standards body. I went ahead and implemented it >> in gfortran anyway, in cooperation with flang. >> >> So, in Fortran code, the existing use of unsigned integers is >> extremely low. I use it privately, so it is not zero :-) > > Good for you. ;) > > I’m trying to understand the mindset that believes that signed > integers are all you need, you don’t need unsigned ones; is this a > difference between mathematicians and computer scientists, perhaps? > Computer scientists are accustomed to thinking in terms of bitfields, > where sign-extension is often a nuisance; mathematicians are not. I have a version of TinyBasic that only supports floats. Floats are all you need 😊 Signed vs unsigned is just a way of expressing commonly used number sets. I wonder if it is worth it to define a "prime" number type indicating the var only holds prime numbers. Types are shortcuts representing the rules used to form numbers. May be useful sometimes to have a way to define the rules for the numbers?
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-09-27 12:06 +0300 |
| Subject | Re: endian history |
| Message-ID | <nhs4l7F4rt2U1@mid.individual.net> |
| In reply to | #118244 |
On 2026-09-27 6:49, Robert Finch wrote:
> Signed vs unsigned is just a way of expressing commonly used number
> sets. I wonder if it is worth it to define a "prime" number type
> indicating the var only holds prime numbers.
Can do that in Ada:
subtype Prime_Number is Integer
with Dynamic_Predicate => Is_Prime (Prime_Number);
where Is_Prime is some user-written Boolean-valued primality-checking
function taking one Integer parameter. But the primality check is likely
to be expensive, so this would be useful mostly for documentation, or as
part of "ghost code" for program proof (the prover sees the ghost code,
but the compiler omits it from the executable).
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2026-09-27 06:14 -0400 |
| Subject | Re: endian history |
| Message-ID | <119aqa1$181e2$1@dont-email.me> |
| In reply to | #118245 |
On 2026-09-27 5:06 a.m., Niklas Holsti wrote: > On 2026-09-27 6:49, Robert Finch wrote: > >> Signed vs unsigned is just a way of expressing commonly used number >> sets. I wonder if it is worth it to define a "prime" number type >> indicating the var only holds prime numbers. > > Can do that in Ada: > > subtype Prime_Number is Integer > with Dynamic_Predicate => Is_Prime (Prime_Number); > > where Is_Prime is some user-written Boolean-valued primality-checking > function taking one Integer parameter. But the primality check is likely > to be expensive, so this would be useful mostly for documentation, or as > part of "ghost code" for program proof (the prover sees the ghost code, > but the compiler omits it from the executable). > Writing code to support number types seems non-mathematical. But I suppose it is just a different way of expressing mathematical rules. Integers are just a set of numbers in a line where the next and previous number can be found using increment or decrement operations. Or I suppose one could say increment and decrement linearize the number set. But there also should be a rule that the number line is “flat” so it cannot intersect with itself. “Super” primes are more primitive and do not have any such rules other than each number is unique. They just floating in number space. Prime numbers have the rule that they are on the number line; they are linearized. I suppose operator overloading in C++ might also be used. An enum in Arpl supports arithmetic and power series for the enumerated type which would work for some number sets. Testing for a prime could just be a lookup table if the prime < 16 bits. There would be no increment / decrement operation defined for a prime number. Add, sub, mul, and div would result in integers. “Tiny”Basic also supports strings and local variables. There are floating-point instructions in hardware so it was easy to modify the parser from ints to floats. Floats are 96-bit triple precision decimal floats.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-27 23:57 +0000 |
| Subject | Re: endian history |
| Message-ID | <119cagv$1sihs$1@dont-email.me> |
| In reply to | #118246 |
On Sun, 27 Sep 2026 06:14:24 -0400, Robert Finch wrote:
> Writing code to support number types seems non-mathematical. But I
> suppose it is just a different way of expressing mathematical rules.
Rules are code.
> Testing for a prime could just be a lookup table if the prime < 16
> bits.
The primality of the first one million positive integers can be easily
and efficiently encoded into (i.e. fast to do lookups on) a block of
data of about 33K bytes in size.
I remember going to an early talk by Stephen Wolfram where he was
introducing this whizzy new maths program called “Mathematica”; he
mentioned that they used a Cray super to generate the table. Nowadays
you can do it with a bit of Python code on your own PC.
(My own program took a bit under 9 minutes to find all 78498 primes.)
And then there are the Gaussian primes.
>>> a = 3 + 2j
>>> a * a.conjugate() == 13
True
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-28 14:33 +0200 |
| Subject | Re: endian history |
| Message-ID | <119dmqn$2b30u$1@dont-email.me> |
| In reply to | #118265 |
Lawrence D’Oliveiro wrote: > On Sun, 27 Sep 2026 06:14:24 -0400, Robert Finch wrote: > >> Writing code to support number types seems non-mathematical. But I >> suppose it is just a different way of expressing mathematical rules. > > Rules are code. > >> Testing for a prime could just be a lookup table if the prime < 16 >> bits. > > The primality of the first one million positive integers can be easily > and efficiently encoded into (i.e. fast to do lookups on) a block of > data of about 33K bytes in size. Encode it mod 30, one bit per possible prime location, so 33 kB. This is the method I used in my last Sieve program, which I wrote almost 3 decades ago. > > I remember going to an early talk by Stephen Wolfram where he was > introducing this whizzy new maths program called “Mathematicaâ€; he > mentioned that they used a Cray super to generate the table. Nowadays > you can do it with a bit of Python code on your own PC. > > (My own program took a bit under 9 minutes to find all 78498 primes.) That's stupidly slow! I just ressurrected that old (Feb 1998) 32-bit C code and ran the original binary. I had to go to 1E9 just to get something that took more than a second: h:\terjem\c2\PRIME>SIEVE0.EXE 1000000000 Searching prime numbers to : 1000000000 50847534 prime numbers foundn 4 secs. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 10:38 +0200 |
| Subject | Re: endian history |
| Message-ID | <119d926$23bo0$4@dont-email.me> |
| In reply to | #118246 |
On 27/09/2026 12:14, Robert Finch wrote: > “Tiny”Basic also supports strings and local variables. There are > floating-point instructions in hardware so it was easy to modify the > parser from ints to floats. Floats are 96-bit triple precision decimal > floats. > Most "home computers" of the 1980's had BASIC interpreters integral to the system, with support for strings and numbers that were integer/floating point hybrids. On the ZX Spectrum these were 3 bytes, IIRC, where one byte was the exponent and sign, the other two were the mantissa. One exponent value was used to indicate that the mantissa word was an integer. Exceptions include the BBC Micro where you could also have integer variables that were significantly faster, and of course the Jupiter Ace that had Forth instead of BASIC as its built-in language.
[toc] | [prev] | [next] | [standalone]
Page 11 of 30 — ← Prev page 1 … 9 10 [11] 12 13 … 30 Next page →
Back to top | Article view | comp.arch
csiph-web