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 24 of 30 — ← Prev page 1 … 22 23 [24] 25 26 … 30 Next page →
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-24 21:39 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10uvr6u$rqif$1@dont-email.me> |
| In reply to | #116654 |
On Sun, 24 May 2026 17:32:10 +0000, MitchAlsup wrote: > quadi <quadibloc@ca.invalid> posted: >> It makes sense to trap on a floating-point overflow, but trapping on an >> integer overflow is usually a terrible idea. > > So, detecting something went wrong and you should inform the programmer > is a bad idea ??? No, so being able to turn the trap for integer overflow on should definitely be allowed. But that shouldn't be the default behavior. Otherwise, programs like random number generators wouldn't work. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-24 22:07 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779660438-5857@newsgrouper.org> |
| In reply to | #116656 |
quadi <quadibloc@ca.invalid> posted: > On Sun, 24 May 2026 17:32:10 +0000, MitchAlsup wrote: > > quadi <quadibloc@ca.invalid> posted: > > >> It makes sense to trap on a floating-point overflow, but trapping on an > >> integer overflow is usually a terrible idea. > > > > So, detecting something went wrong and you should inform the programmer > > is a bad idea ??? > > No, so being able to turn the trap for integer overflow on should > definitely be allowed. But that shouldn't be the default behavior. > Otherwise, programs like random number generators wouldn't work. They work just fine using unSigned integers. > > John Savard
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-24 15:22 -0700 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10uvtnn$shan$1@dont-email.me> |
| In reply to | #116657 |
On 5/24/2026 3:07 PM, MitchAlsup wrote: > > quadi <quadibloc@ca.invalid> posted: > >> On Sun, 24 May 2026 17:32:10 +0000, MitchAlsup wrote: >>> quadi <quadibloc@ca.invalid> posted: >> >>>> It makes sense to trap on a floating-point overflow, but trapping on an >>>> integer overflow is usually a terrible idea. >>> >>> So, detecting something went wrong and you should inform the programmer >>> is a bad idea ??? >> >> No, so being able to turn the trap for integer overflow on should >> definitely be allowed. But that shouldn't be the default behavior. >> Otherwise, programs like random number generators wouldn't work. > > They work just fine using unSigned integers. Ditto! [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-25 10:23 +0200 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v10t4$161c6$1@dont-email.me> |
| In reply to | #116656 |
On 24/05/2026 23:39, quadi wrote: > On Sun, 24 May 2026 17:32:10 +0000, MitchAlsup wrote: >> quadi <quadibloc@ca.invalid> posted: > >>> It makes sense to trap on a floating-point overflow, but trapping on an >>> integer overflow is usually a terrible idea. >> >> So, detecting something went wrong and you should inform the programmer >> is a bad idea ??? > > No, so being able to turn the trap for integer overflow on should > definitely be allowed. But that shouldn't be the default behavior. > Otherwise, programs like random number generators wouldn't work. > > John Savard That does not make sense. Code such as random number generators should be written so that they are correct in the language they are written in. If that is C, signed integer overflow is UB while unsigned integers have wrapping behaviour - thus if your code depends on wrapping, and it is written in C, it needs to use unsigned types or compiler-specific extensions, flags, etc. (Or C23 ckd_add and other checked arithmetic functions.) If it is written in Zig, you need to use the specific modulo arithmetic functions even for unsigned arithmetic. If it is written in Java, signed integer arithmetic is fine. It all depends on the language and/or any options the language and tools might support - and code should be written to work correctly according to the language rules. The hardware, of course, cannot always enable trapping on overflow if it is going to efficiently support a range of programming languages. But as an optional feature it can be helpful for catching a few bugs in code, so it can be a good idea (both for signed and unsigned overflow).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-25 14:28 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <2026May25.162821@mips.complang.tuwien.ac.at> |
| In reply to | #116662 |
David Brown <david.brown@hesbynett.no> writes:
>On 24/05/2026 23:39, quadi wrote:
>> On Sun, 24 May 2026 17:32:10 +0000, MitchAlsup wrote:
>>> quadi <quadibloc@ca.invalid> posted:
>>
>>>> It makes sense to trap on a floating-point overflow, but trapping on an
>>>> integer overflow is usually a terrible idea.
Most programming environments I have had contact with don't trap on
floating-point overflow.
>>> So, detecting something went wrong and you should inform the programmer
>>> is a bad idea ???
The question is if an integer overflow means that something went
wrong. Despite their eagerness to "optimize" based on the assumption
that signed integer overflow does not happen, the GCC developers have
avoided making -ftrap the default, even on platforms like MIPS and
Alpha where the implementation of -ftrapv just means to use different
instructions (e.g., add instead of addu on MIPS, and addv instead of
add on Alpha).
>The hardware, of course, cannot always enable trapping on overflow if it
>is going to efficiently support a range of programming languages. But
>as an optional feature it can be helpful for catching a few bugs in
>code, so it can be a good idea (both for signed and unsigned overflow).
This supposedly helpful feature has been neglected by C compiler
developers, and you see in the progression from MIPS (1986) to Alpha
(1992) and then RISC-V (2011) that the hardware architects have
accepted that:
MIPS: add traps on signed overflow, you need to write addu if you
don't want that.
Alpha: add ignores signed overflow, you need to write addv if you want
the trapping.
RISC-V: add ignores signed overflow, there is no add that traps on
signed overflow (and detecting signed overflow is pretty
involved if both operands are unknown to the compiler).
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-25 17:18 +0200 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v1p7q$1ei96$1@dont-email.me> |
| In reply to | #116663 |
On 25/05/2026 16:28, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 24/05/2026 23:39, quadi wrote: >>> On Sun, 24 May 2026 17:32:10 +0000, MitchAlsup wrote: >>>> quadi <quadibloc@ca.invalid> posted: >>> >>>>> It makes sense to trap on a floating-point overflow, but trapping on an >>>>> integer overflow is usually a terrible idea. > > Most programming environments I have had contact with don't trap on > floating-point overflow. > >>>> So, detecting something went wrong and you should inform the programmer >>>> is a bad idea ??? > > The question is if an integer overflow means that something went > wrong. At the source code level, that is often the case - but not always. I think it is quite clear that if you do something the language does not allow, the code is wrong, but it might give the correct results for some tools nonetheless. And overflow will often mean something went wrong even when the language (or compiler options) specifically allow it. At the object code level, things may be different again. (For an obvious example, if you are using a double-width integer type then the source code may have no overflow but the implementation might use two "add-with-carry" instructions where overflow is a natural part of the implementation.) > Despite their eagerness to "optimize" based on the assumption > that signed integer overflow does not happen, the GCC developers have > avoided making -ftrap the default, even on platforms like MIPS and > Alpha where the implementation of -ftrapv just means to use different > instructions (e.g., add instead of addu on MIPS, and addv instead of > add on Alpha). An awkward thing about using trap on overflow is determining how precisely it is defined. Supposing you have the expression "a + b - a". Perhaps "a + b" overflows. I would hope than when using debug-related compiler flags such as "-fsanitize=signed-integer-overflow", a compiler would check for overflow on "a + b", and report it at runtime. (Unfortunately, gcc does not do that unless the partial expression is assigned to a variable.) But in "normal" usage, I'd expect the expression to be simplified, resulting in just "b" and no overflow. If "trap on overflow" has precise semantics in the code, then this disables a range of useful optimisations and re-arrangements. If it is just "use trapping arithmetic instructions", then it will miss many possible cases of actual overflow in the code, which we might want to catch. And "trap on overflow" might either trigger when there is no overflow in the original code, or hinder optimisations. (Consider the expression "x / 2 + y / 2" - the compiler could implement that as a combined "(x + y) / 2", but that might introduce overflow.) It is not easy to see how a tool can avoid false positives and false negatives and also conveniently optimise and re-arrange code. > >> The hardware, of course, cannot always enable trapping on overflow if it >> is going to efficiently support a range of programming languages. But >> as an optional feature it can be helpful for catching a few bugs in >> code, so it can be a good idea (both for signed and unsigned overflow). > > This supposedly helpful feature has been neglected by C compiler > developers, and you see in the progression from MIPS (1986) to Alpha > (1992) and then RISC-V (2011) that the hardware architects have > accepted that: > > MIPS: add traps on signed overflow, you need to write addu if you > don't want that. > > Alpha: add ignores signed overflow, you need to write addv if you want > the trapping. > > RISC-V: add ignores signed overflow, there is no add that traps on > signed overflow (and detecting signed overflow is pretty > involved if both operands are unknown to the compiler). > > - anton Compilers have not always been good at taking advantage of all the features provided by hardware - nor have languages been good at exposing the possibilities in the language so that programmers can take advantage of them.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-25 16:43 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <2026May25.184307@mips.complang.tuwien.ac.at> |
| In reply to | #116664 |
David Brown <david.brown@hesbynett.no> writes:
>On 25/05/2026 16:28, Anton Ertl wrote:
>> Despite their eagerness to "optimize" based on the assumption
>> that signed integer overflow does not happen, the GCC developers have
>> avoided making -ftrap the default, even on platforms like MIPS and
>> Alpha where the implementation of -ftrapv just means to use different
>> instructions (e.g., add instead of addu on MIPS, and addv instead of
>> add on Alpha).
>
>An awkward thing about using trap on overflow is determining how
>precisely it is defined. Supposing you have the expression "a + b - a".
> Perhaps "a + b" overflows. I would hope than when using debug-related
>compiler flags such as "-fsanitize=signed-integer-overflow", a compiler
>would check for overflow on "a + b", and report it at runtime.
>(Unfortunately, gcc does not do that unless the partial expression is
>assigned to a variable.) But in "normal" usage, I'd expect the
>expression to be simplified, resulting in just "b" and no overflow.
OTOH, cases like a+b+c where the result is in range, while an
intermediate result is out of range are one of the reasons why I
prefer -fwrapv over -ftrapv. As for your preference of nasal demons,
given enough information, the compiler might "optimize" "a+b-a" into,
e.g., 0.
Anyway, the definition of -ftrapv is not very precise; for gcc-12.2:
|'-ftrapv'
| This option generates traps for signed overflow on addition,
| subtraction, multiplication operations.
As for what gcc-12.2 does for your example on AMD64:
long foo(long a, long b)
{
return a+b-a;
}
is compiled with gcc -O3 -ftrapv to:
0: 48 89 f0 mov %rsi,%rax
3: c3 ret
>If "trap on overflow" has precise semantics in the code, then this
>disables a range of useful optimisations and re-arrangements. If it is
>just "use trapping arithmetic instructions", then it will miss many
>possible cases of actual overflow in the code, which we might want to
>catch.
Which would you prefer by default?
The gcc developers apparently took the latter approach, even when you
ask for -ftrapv explicitly. So what, IYO, speaks against doing that
by default on machines like MIPS and Alpha.
>And "trap on overflow" might either trigger when there is no
>overflow in the original code, or hinder optimisations. (Consider the
>expression "x / 2 + y / 2" - the compiler could implement that as a
>combined "(x + y) / 2", but that might introduce overflow.)
x/2+y/2 produces a different result from (x+y)/2 when both x and y are
odd integers.
gcc-12.2 compiles
long bar(long x, long y)
{
return x/2+y/2;
}
on AMD64 to:
gcc -O3 -ftrapv gcc -O3
mov %rdi,%rax mov %rdi,%rax
sub $0x8,%rsp mov %rsi,%rdx
shr $0x3f,%rax shr $0x3f,%rax
add %rax,%rdi shr $0x3f,%rdx
mov %rsi,%rax add %rdi,%rax
shr $0x3f,%rax add %rsi,%rdx
sar %rdi sar %rax
add %rax,%rsi sar %rdx
sar %rsi add %rdx,%rax
call __addvdi3@PLT ret
add $0x8,%rsp
ret
so the -ftrapv introduces an additional mov and a call; I would have
expected that the + would be compiled to an ADD instruction followed
by a JO instruction.
Trying the same on a MIPS64 machine with gcc-8.3 (which apparently
produces ILP32 code) produces a call to __addvsi3 instead of the
expected add instruction:
gcc -O3 -ftrapv gcc -O3
lui gp,0x0 srl v0,a0,0x1f
addiu gp,gp,0 srl v1,a1,0x1f
addu gp,gp,t9 addu v0,v0,a0
srl v1,a0,0x1f addu a1,v1,a1
lw t9,__addvsi3(gp) sra v0,v0,0x1
srl v0,a1,0x1f sra a1,a1,0x1
addiu sp,sp,-32 jr ra
addu a0,v1,a0 addu v0,v0,a1
addu a1,v0,a1
sra a0,a0,0x1
sw ra,28(sp)
sw gp,16(sp)
jalr t9
sra a1,a1,0x1
lw ra,28(sp)
jr ra
addiu sp,sp,32
The call costs a lot of overhead.
>It is not easy to see how a tool can avoid false positives and false
>negatives and also conveniently optimise and re-arrange code.
It can't. But it does not try to avoid false negatives even when
explicitly asked for trapping on overflow.
If some overflow trapping when it can be done without additional
instructions would be preferable over no overflow, gcc would compile
signed adds that survive after optimization into add on MIPS rather
than addu, by default. Given that it does not, the GCC developers
probably found out that it is not preferable. I guess they would get
too many customer complaints, including for "relevant" code, i.e.,
code where the usual "it's UB, so your code is broken" excuse does not
work.
The fact that they don't even try to make -ftrapv produce efficient
code indicates that there is no "relevant" interest in efficient
-ftrapv. It would be interesting to know who came up with the idea of
adding -ftrapv, and why they are still keeping it.
>Compilers have not always been good at taking advantage of all the
>features provided by hardware
GCC is pretty good at implementing -fwrapv. For the two examples
above, "gcc -O3 -fwrapv" produces the same code on AMD64 and MIPS as
"gcc -O3".
> nor have languages been good at exposing
>the possibilities in the language so that programmers can take advantage
>of them.
Yes. But I leave that for another day.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-25 19:20 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779736801-5857@newsgrouper.org> |
| In reply to | #116667 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> David Brown <david.brown@hesbynett.no> writes:
> >On 25/05/2026 16:28, Anton Ertl wrote:
> >> Despite their eagerness to "optimize" based on the assumption
> >> that signed integer overflow does not happen, the GCC developers have
> >> avoided making -ftrap the default, even on platforms like MIPS and
> >> Alpha where the implementation of -ftrapv just means to use different
> >> instructions (e.g., add instead of addu on MIPS, and addv instead of
> >> add on Alpha).
> >
> >An awkward thing about using trap on overflow is determining how
> >precisely it is defined. Supposing you have the expression "a + b - a".
> > Perhaps "a + b" overflows. I would hope than when using debug-related
> >compiler flags such as "-fsanitize=signed-integer-overflow", a compiler
> >would check for overflow on "a + b", and report it at runtime.
> >(Unfortunately, gcc does not do that unless the partial expression is
> >assigned to a variable.) But in "normal" usage, I'd expect the
> >expression to be simplified, resulting in just "b" and no overflow.
>
> OTOH, cases like a+b+c where the result is in range, while an
> intermediate result is out of range are one of the reasons why I
> prefer -fwrapv over -ftrapv. As for your preference of nasal demons,
> given enough information, the compiler might "optimize" "a+b-a" into,
> e.g., 0.
a/0/b/
>
> Anyway, the definition of -ftrapv is not very precise; for gcc-12.2:
>
> |'-ftrapv'
> | This option generates traps for signed overflow on addition,
> | subtraction, multiplication operations.
>
> As for what gcc-12.2 does for your example on AMD64:
>
> long foo(long a, long b)
> {
> return a+b-a;
> }
>
> is compiled with gcc -O3 -ftrapv to:
>
> 0: 48 89 f0 mov %rsi,%rax
> 3: c3 ret
>
> >If "trap on overflow" has precise semantics in the code, then this
> >disables a range of useful optimisations and re-arrangements. If it is
> >just "use trapping arithmetic instructions", then it will miss many
> >possible cases of actual overflow in the code, which we might want to
> >catch.
>
> Which would you prefer by default?
What you do want is compiled code that can trap on overflow and avoid
trapping on overflow without code substitution or being re-compiled.
This way production code can avoid trapping but if the debugger is
turned on, you can trap.
> The gcc developers apparently took the latter approach, even when you
> ask for -ftrapv explicitly. So what, IYO, speaks against doing that
> by default on machines like MIPS and Alpha.
Both architectures got this one wrong--IMO--and so does RISC-V.
> >And "trap on overflow" might either trigger when there is no
> >overflow in the original code, or hinder optimisations. (Consider the
> >expression "x / 2 + y / 2" - the compiler could implement that as a
> >combined "(x + y) / 2", but that might introduce overflow.)
>
> x/2+y/2 produces a different result from (x+y)/2 when both x and y are
> odd integers.
>
> gcc-12.2 compiles
>
> long bar(long x, long y)
> {
> return x/2+y/2;
> }
>
>
> on AMD64 to:
>
> gcc -O3 -ftrapv gcc -O3
> mov %rdi,%rax mov %rdi,%rax
> sub $0x8,%rsp mov %rsi,%rdx
> shr $0x3f,%rax shr $0x3f,%rax
> add %rax,%rdi shr $0x3f,%rdx
> mov %rsi,%rax add %rdi,%rax
> shr $0x3f,%rax add %rsi,%rdx
> sar %rdi sar %rax
> add %rax,%rsi sar %rdx
> sar %rsi add %rdx,%rax
> call __addvdi3@PLT ret
> add $0x8,%rsp
> ret
>
> so the -ftrapv introduces an additional mov and a call; I would have
> expected that the + would be compiled to an ADD instruction followed
> by a JO instruction.
>
> Trying the same on a MIPS64 machine with gcc-8.3 (which apparently
> produces ILP32 code) produces a call to __addvsi3 instead of the
> expected add instruction:
>
> gcc -O3 -ftrapv gcc -O3
> lui gp,0x0 srl v0,a0,0x1f
> addiu gp,gp,0 srl v1,a1,0x1f
> addu gp,gp,t9 addu v0,v0,a0
> srl v1,a0,0x1f addu a1,v1,a1
> lw t9,__addvsi3(gp) sra v0,v0,0x1
> srl v0,a1,0x1f sra a1,a1,0x1
> addiu sp,sp,-32 jr ra
> addu a0,v1,a0 addu v0,v0,a1
> addu a1,v0,a1
> sra a0,a0,0x1
> sw ra,28(sp)
> sw gp,16(sp)
> jalr t9
> sra a1,a1,0x1
> lw ra,28(sp)
> jr ra
> addiu sp,sp,32
>
> The call costs a lot of overhead.
Architectures without overflow traps are notorious for excess instruction
count when overflow detection is desired or mandated.
> >It is not easy to see how a tool can avoid false positives and false
> >negatives and also conveniently optimise and re-arrange code.
>
> It can't. But it does not try to avoid false negatives even when
> explicitly asked for trapping on overflow.
Granted, Optimization can do a lot of strange code emission and movement
when one does not care about precise overflow semantics. But, as a whole,
we are a society where we want high HP automobiles more than we want safe
automobiles ('we' not including *.gov's).
> If some overflow trapping when it can be done without additional
> instructions would be preferable over no overflow, gcc would compile
> signed adds that survive after optimization into add on MIPS rather
> than addu, by default. Given that it does not, the GCC developers
> probably found out that it is not preferable. I guess they would get
> too many customer complaints, including for "relevant" code, i.e.,
> code where the usual "it's UB, so your code is broken" excuse does not
> work.
It is much harder than that. For example: does a signed shift left
overflow when significant bits are shifted out ?? What if the sub-
sequent instruction shifts the result back and the pair are acting
as a bit-field extract ?? My 66000 has bit field extracts for exactly
this reason. Floating-point has a lot of these cases, too.
> The fact that they don't even try to make -ftrapv produce efficient
> code indicates that there is no "relevant" interest in efficient
> -ftrapv. It would be interesting to know who came up with the idea of
> adding -ftrapv, and why they are still keeping it.
>
> >Compilers have not always been good at taking advantage of all the
> >features provided by hardware
>
> GCC is pretty good at implementing -fwrapv. For the two examples
> above, "gcc -O3 -fwrapv" produces the same code on AMD64 and MIPS as
> "gcc -O3".
>
> > nor have languages been good at exposing
> >the possibilities in the language so that programmers can take advantage
> >of them.
>
> Yes. But I leave that for another day.
A whole new kettle of fish...
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-25 20:32 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v2bkf$1l0ma$1@dont-email.me> |
| In reply to | #116670 |
On Mon, 25 May 2026 19:20:01 +0000, MitchAlsup wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> David Brown <david.brown@hesbynett.no> writes: >> >On 25/05/2026 16:28, Anton Ertl wrote: >> >> Despite their eagerness to "optimize" based on the assumption >> >> that signed integer overflow does not happen, the GCC developers >> >> have avoided making -ftrap the default, even on platforms like MIPS >> >> and Alpha where the implementation of -ftrapv just means to use >> >> different instructions (e.g., add instead of addu on MIPS, and addv >> >> instead of add on Alpha). > Both architectures got this one wrong--IMO--and so does RISC-V. You may not have been replying to what Anton Ertl wrote above, since there was a lot in between that I snipped. But it does mention two architectures that took an approach to trapping on integer overflow... that I also tend to disagree with. What I'm used to is the System/360. While it made the mistake of having two condition code bits instead of NZVC, the idea of having "trap on overflow" controlled by a bit in the PSW is... what I assumed to be normal and correct. I could be wrong, as I haven't examined that approach critically and given full consideration to the alternatives. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-25 22:51 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779749502-5857@newsgrouper.org> |
| In reply to | #116674 |
quadi <quadibloc@ca.invalid> posted: > On Mon, 25 May 2026 19:20:01 +0000, MitchAlsup wrote: > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> David Brown <david.brown@hesbynett.no> writes: > >> >On 25/05/2026 16:28, Anton Ertl wrote: > > >> >> Despite their eagerness to "optimize" based on the assumption > >> >> that signed integer overflow does not happen, the GCC developers > >> >> have avoided making -ftrap the default, even on platforms like MIPS > >> >> and Alpha where the implementation of -ftrapv just means to use > >> >> different instructions (e.g., add instead of addu on MIPS, and addv > >> >> instead of add on Alpha). > > > Both architectures got this one wrong--IMO--and so does RISC-V. > > You may not have been replying to what Anton Ertl wrote above, since there > was a lot in between that I snipped. But it does mention two architectures > that took an approach to trapping on integer overflow... that I also tend > to disagree with. > > What I'm used to is the System/360. While it made the mistake of having > two condition code bits instead of NZVC, the idea of having "trap on > overflow" controlled by a bit in the PSW is... what I assumed to be normal > and correct. And what My 66000 does.... I purport that ANY Industrial quality ISA should provide a means to trap on integer overflow. > I could be wrong, as I haven't examined that approach critically and given > full consideration to the alternatives. > > John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-05-25 20:32 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <2026May25.223235@mips.complang.tuwien.ac.at> |
| In reply to | #116670 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>What you do want is compiled code that can trap on overflow and avoid
>trapping on overflow without code substitution or being re-compiled.
>This way production code can avoid trapping but if the debugger is
>turned on, you can trap.
Why do you consider that desirable?
>> long bar(long x, long y)
>> {
>> return x/2+y/2;
>> }
...
>> Trying the same on a MIPS64 machine with gcc-8.3 (which apparently
>> produces ILP32 code) produces a call to __addvsi3 instead of the
>> expected add instruction:
>>
>> gcc -O3 -ftrapv gcc -O3
>> lui gp,0x0 srl v0,a0,0x1f
>> addiu gp,gp,0 srl v1,a1,0x1f
>> addu gp,gp,t9 addu v0,v0,a0
>> srl v1,a0,0x1f addu a1,v1,a1
>> lw t9,__addvsi3(gp) sra v0,v0,0x1
>> srl v0,a1,0x1f sra a1,a1,0x1
>> addiu sp,sp,-32 jr ra
>> addu a0,v1,a0 addu v0,v0,a1
>> addu a1,v0,a1
>> sra a0,a0,0x1
>> sw ra,28(sp)
>> sw gp,16(sp)
>> jalr t9
>> sra a1,a1,0x1
>> lw ra,28(sp)
>> jr ra
>> addiu sp,sp,32
>>
>> The call costs a lot of overhead.
>
>Architectures without overflow traps are notorious for excess instruction
>count when overflow detection is desired or mandated.
MIPS' add traps on overflow. gcc could have emitted almost the same
code for gcc -O3 -trapv as for gcc -O3, except that the last
instruction would be an add, not an addu. But apparently nobody gives
a damn about the efficiency of -trapv, possibly rightly so.
>> If some overflow trapping when it can be done without additional
>> instructions would be preferable over no overflow, gcc would compile
>> signed adds that survive after optimization into add on MIPS rather
>> than addu, by default. Given that it does not, the GCC developers
>> probably found out that it is not preferable. I guess they would get
>> too many customer complaints, including for "relevant" code, i.e.,
>> code where the usual "it's UB, so your code is broken" excuse does not
>> work.
>
>It is much harder than that. For example: does a signed shift left
>overflow when significant bits are shifted out ??
-ftrapv specifies trapping on overflow only for additions,
subtractions, and multiplications.
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-25 23:00 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779750032-5857@newsgrouper.org> |
| In reply to | #116678 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >What you do want is compiled code that can trap on overflow and avoid
> >trapping on overflow without code substitution or being re-compiled.
> >This way production code can avoid trapping but if the debugger is
> >turned on, you can trap.
>
> Why do you consider that desirable?
So you can debug production/released code to find subtle errors.
> >> long bar(long x, long y)
> >> {
> >> return x/2+y/2;
> >> }
> ...
> >> Trying the same on a MIPS64 machine with gcc-8.3 (which apparently
> >> produces ILP32 code) produces a call to __addvsi3 instead of the
> >> expected add instruction:
> >>
> >> gcc -O3 -ftrapv gcc -O3
> >> lui gp,0x0 srl v0,a0,0x1f
> >> addiu gp,gp,0 srl v1,a1,0x1f
> >> addu gp,gp,t9 addu v0,v0,a0
> >> srl v1,a0,0x1f addu a1,v1,a1
> >> lw t9,__addvsi3(gp) sra v0,v0,0x1
> >> srl v0,a1,0x1f sra a1,a1,0x1
> >> addiu sp,sp,-32 jr ra
> >> addu a0,v1,a0 addu v0,v0,a1
> >> addu a1,v0,a1
> >> sra a0,a0,0x1
> >> sw ra,28(sp)
> >> sw gp,16(sp)
> >> jalr t9
> >> sra a1,a1,0x1
> >> lw ra,28(sp)
> >> jr ra
> >> addiu sp,sp,32
> >>
> >> The call costs a lot of overhead.
> >
> >Architectures without overflow traps are notorious for excess instruction
> >count when overflow detection is desired or mandated.
>
> MIPS' add traps on overflow. gcc could have emitted almost the same
> code for gcc -O3 -trapv as for gcc -O3, except that the last
> instruction would be an add, not an addu. But apparently nobody gives
> a damn about the efficiency of -trapv, possibly rightly so.
>
> >> If some overflow trapping when it can be done without additional
> >> instructions would be preferable over no overflow, gcc would compile
> >> signed adds that survive after optimization into add on MIPS rather
> >> than addu, by default. Given that it does not, the GCC developers
> >> probably found out that it is not preferable. I guess they would get
> >> too many customer complaints, including for "relevant" code, i.e.,
> >> code where the usual "it's UB, so your code is broken" excuse does not
> >> work.
> >
> >It is much harder than that. For example: does a signed shift left
> >overflow when significant bits are shifted out ??
>
> -ftrapv specifies trapping on overflow only for additions,
> subtractions, and multiplications.
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-26 08:27 +0200 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v3egg$1t28e$2@dont-email.me> |
| In reply to | #116683 |
On 26/05/2026 01:00, MitchAlsup wrote: > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>> >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >>> What you do want is compiled code that can trap on overflow and avoid >>> trapping on overflow without code substitution or being re-compiled. >>> This way production code can avoid trapping but if the debugger is >>> turned on, you can trap. >> >> Why do you consider that desirable? > > So you can debug production/released code to find subtle errors. > I think that when an unexpected error is detected (whether it is with hardware acceleration, like trap on overflow, or via explicit generated code), the way to handle it depends strongly on the situation. If a debugger is present, then it is most helpful to lead to a debugger break so that the developer can figure out what went wrong. When not debugging, there is no sensible default handling that works for jet engine controllers and video game frame generators. But I do support the aim of having the same generated code when debugging and when shipping - I am not a fan of "release" builds and "debug" builds. (Of course you might temporarily do builds with different flags while chasing down a particular bug.)
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-05-26 22:09 +0200 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v4ulo$2b0dg$1@dont-email.me> |
| In reply to | #116692 |
David Brown wrote: > On 26/05/2026 01:00, MitchAlsup wrote: >> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> >>> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >>>> >>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >>>> What you do want is compiled code that can trap on overflow and avoid >>>> trapping on overflow without code substitution or being re-compiled. >>>> This way production code can avoid trapping but if the debugger is >>>> turned on, you can trap. >>> >>> Why do you consider that desirable? >> >> So you can debug production/released code to find subtle errors. > I think that when an unexpected error is detected (whether it is with > hardware acceleration, like trap on overflow, or via explicit generated > code), the way to handle it depends strongly on the situation. If a > debugger is present, then it is most helpful to lead to a debugger break > so that the developer can figure out what went wrong. When not > debugging, there is no sensible default handling that works for jet > engine controllers and video game frame generators. > > But I do support the aim of having the same generated code when > debugging and when shipping - I am not a fan of "release" builds and > "debug" builds. (Of course you might temporarily do builds with > different flags while chasing down a particular bug.) I tend to like "Release with sometimes hard-to-grok debug info", typically resulting in a separate file with a best effort debug map of the executable. Then I can at least get some help when running the debugger and trying to binary search my way into the spot where the bug resides. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-26 20:54 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779828870-5857@newsgrouper.org> |
| In reply to | #116705 |
Terje Mathisen <terje.mathisen@tmsw.no> posted:
> David Brown wrote:
> > On 26/05/2026 01:00, MitchAlsup wrote:
> >>
> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >>
> >>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >>>>
> >>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >>>> What you do want is compiled code that can trap on overflow and avoid
> >>>> trapping on overflow without code substitution or being re-compiled.
> >>>> This way production code can avoid trapping but if the debugger is
> >>>> turned on, you can trap.
> >>>
> >>> Why do you consider that desirable?
> >>
> >> So you can debug production/released code to find subtle errors.
> > I think that when an unexpected error is detected (whether it is with
> > hardware acceleration, like trap on overflow, or via explicit generated
> > code), the way to handle it depends strongly on the situation. If a
> > debugger is present, then it is most helpful to lead to a debugger break
> > so that the developer can figure out what went wrong. When not
> > debugging, there is no sensible default handling that works for jet
> > engine controllers and video game frame generators.
> >
> > But I do support the aim of having the same generated code when
> > debugging and when shipping - I am not a fan of "release" builds and
> > "debug" builds. (Of course you might temporarily do builds with
> > different flags while chasing down a particular bug.)
>
> I tend to like "Release with sometimes hard-to-grok debug info",
> typically resulting in a separate file with a best effort debug map of
> the executable.
Encrypt the debug information (and put it in a {1234-5678-9101-1121-...}
folder) so that only the owner (not licensee) of the code can debug
it.
> Then I can at least get some help when running the debugger and trying
> to binary search my way into the spot where the bug resides.
>
> Terje
>
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-05-27 10:59 -0400 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <jwvmrxkc30v.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #116706 |
MitchAlsup [2026-05-26 20:54:30] wrote:
> Encrypt the debug information (and put it in
> a {1234-5678-9101-1121-...} folder) so that only the owner (not
> licensee) of the code can debug it.
I resent that. All code should be Free Software.
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-27 18:19 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v7ck5$2ul9d$1@dont-email.me> |
| In reply to | #116711 |
On Wed, 27 May 2026 10:59:31 -0400, Stefan Monnier wrote:
> MitchAlsup [2026-05-26 20:54:30] wrote:
>> Encrypt the debug information (and put it in a
>> {1234-5678-9101-1121-...} folder) so that only the owner (not
>> licensee) of the code can debug it.
> I resent that. All code should be Free Software.
It is wonderful that we have the open-source software movement.
However, people have the right to the fruit of their labors. To give them
away for free is generous, but it should remain a personal choice.
Of course, copyright has been misused, and deserves a critical
examination, not the sort of uncritical expansion given to it by
legislators in the United States - and imposed on the rest of the world by
trade threats.
John Savard
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-06-01 14:51 -0400 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <jwva4tef63p.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #116714 |
quadi [2026-05-27 18:19:49] wrote:
> On Wed, 27 May 2026 10:59:31 -0400, Stefan Monnier wrote:
>> MitchAlsup [2026-05-26 20:54:30] wrote:
>>> Encrypt the debug information (and put it in a
>>> {1234-5678-9101-1121-...} folder) so that only the owner (not
>>> licensee) of the code can debug it.
>> I resent that. All code should be Free Software.
[...]
> However, people have the right to the fruit of their labors. To give them
> away for free is generous, but it should remain a personal choice.
You don't need to encrypt the debug information of your programs in
order to earn a decent living.
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-06-02 06:19 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10vlskp$2o62a$1@dont-email.me> |
| In reply to | #116792 |
On Mon, 01 Jun 2026 14:51:14 -0400, Stefan Monnier wrote: > quadi [2026-05-27 18:19:49] wrote: >> However, people have the right to the fruit of their labors. To give >> them away for free is generous, but it should remain a personal choice. > > You don't need to encrypt the debug information of your programs in > order to earn a decent living. Perhaps. But if someone can write a program that is so useful that it could make him wealthy beyond the dreams of avarice, who am I to judge him for seeking to maximize its revenue potential? John Savard
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-06-02 07:47 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10vm1qn$2pae4$1@dont-email.me> |
| In reply to | #116794 |
On Tue, 02 Jun 2026 06:19:05 +0000, quadi wrote: > On Mon, 01 Jun 2026 14:51:14 -0400, Stefan Monnier wrote: >> quadi [2026-05-27 18:19:49] wrote: >>> However, people have the right to the fruit of their labors. To give >>> them away for free is generous, but it should remain a personal >>> choice. >> You don't need to encrypt the debug information of your programs in >> order to earn a decent living. > Perhaps. But if someone can write a program that is so useful that it > could make him wealthy beyond the dreams of avarice, who am I to judge > him for seeking to maximize its revenue potential? Perhaps this answer was too casual, and a more detailed and serious answer is needed. To say that one doesn't "need" to encrypt debug information "to earn a decent living" is true enough, but you're also implying that this is all anyone has the right to expect. To me, this implies a mindset that says that everyone should remain a laborer, and that it's wrong to transition to rent-seeking. I don't share that view. While there are excesses in the free-enterprise system as we have it now, I have no quarrel with its basic principles. I see the ownership of property, including intellectual property, and including capital property, as fully legitimate. So a person can write a program once and make a living from selling copies of it, instead of just from providing services to its users. If the program is good, there's nothing illegitimate about that. And to defend the program against piracy and reverse-engineering is also basically legitimate. However, to encrypt debug information is strange. Why would a copy of the debug information in any form be included with distributed copies of software? I suppose it could be there in an encrypted form to be used in conjunction with remote diagnostic tools, in the case of software which has to be maintained on customer premises, unlike mass-market applications. John Savard
[toc] | [prev] | [next] | [standalone]
Page 24 of 30 — ← Prev page 1 … 22 23 [24] 25 26 … 30 Next page →
Back to top | Article view | comp.arch
csiph-web