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 27 of 30 — ← Prev page 1 … 25 26 [27] 28 29 30 Next page →
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-06-05 15:07 -0400 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <39562ldgeee3q64p3oitgg8b0t5hjlsrpb@4ax.com> |
| In reply to | #116823 |
On Wed, 03 Jun 2026 00:55:35 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >quadi <quadibloc@ca.invalid> posted: > >> On Tue, 02 Jun 2026 17:50:38 +0200, Terje Mathisen wrote: >> >> > In the current environment where every language is expected to be >> > compatible with a generic IDE like Visual Studio Code, via open source >> > interface specifications, having a proprietary debug format seems like a >> > good way to strongly limit your potential customer base. >> >> You appear to have understood his post in a different way than I did. >> >> I wasn't thinking of the kind of debug information provided by a compiler. >> >> I was thinking of leaving debug information in when one was distributing >> software to customers. > >Yes, you the vendor do not want random customer debugging the code, >however, you want the ability to debug the code that was distributed >on whatever medium on customer's system(s)-- > >AND you want to debug one copy of the running code while others are using >other processes running the code under normal use. That is true, but the issue at hand is how to achieve that. Leaving debug information /in/ the executable, I think, is a bad idea. However, many (most?) toolchains provide a way to separate debug symbols from the executable - either by generating a separate symbol database in the 1st place, or by allowing debug data to be stripped from the executables. If you have to debug at the client site, you simply take the symbol database with you. Another useful method is to write out debug information as the program executes and arrange that it either is suppressed or (alternatively) goes to /dev/null unless some undocumented flag is given. [Obviously where speed is paramount you can't be generating unnecessary output, so the utility of this method is situation dependent.] I have used both of these methods in the past. YMMV.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-06-06 08:57 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <2026Jun6.105709@mips.complang.tuwien.ac.at> |
| In reply to | #116864 |
George Neuner <gneuner2@comcast.net> writes: >That is true, but the issue at hand is how to achieve that. Leaving >debug information /in/ the executable, I think, is a bad idea. On the contrary, it's an excellent idea. It means that the debug information goes with the code. No chance of confusing yourself by inadvertantly associating the wrong debugging information with the code, and much less chance of not finding the correct debug information. Best of all, of course, is to deliver the source code. >Another useful method is to write out debug information as the program >executes and arrange that it either is suppressed or (alternatively) >goes to /dev/null unless some undocumented flag is given. Undocumented features are forgotten and reimplemented. There's the story of Microsoft embedding some watermark into Microsoft BASIC twice, the second time apparently because they had forgotten about the first time. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-07 16:42 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <RbhVR.4258$lmCb.1670@fx22.iad> |
| In reply to | #116864 |
George Neuner <gneuner2@comcast.net> writes: >On Wed, 03 Jun 2026 00:55:35 GMT, MitchAlsup ><user5857@newsgrouper.org.invalid> wrote: > >> >>quadi <quadibloc@ca.invalid> posted: >> >>> On Tue, 02 Jun 2026 17:50:38 +0200, Terje Mathisen wrote: >>> >>> > In the current environment where every language is expected to be >>> > compatible with a generic IDE like Visual Studio Code, via open source >>> > interface specifications, having a proprietary debug format seems like a >>> > good way to strongly limit your potential customer base. >>> >>> You appear to have understood his post in a different way than I did. >>> >>> I wasn't thinking of the kind of debug information provided by a compiler. >>> >>> I was thinking of leaving debug information in when one was distributing >>> software to customers. >> >>Yes, you the vendor do not want random customer debugging the code, >>however, you want the ability to debug the code that was distributed >>on whatever medium on customer's system(s)-- >> >>AND you want to debug one copy of the running code while others are using >>other processes running the code under normal use. > >That is true, but the issue at hand is how to achieve that. Leaving >debug information /in/ the executable, I think, is a bad idea. > >However, many (most?) toolchains provide a way to separate debug >symbols from the executable - either by generating a separate symbol >database in the 1st place, or by allowing debug data to be stripped >from the executables. If you have to debug at the client site, you >simply take the symbol database with you. Indeed, and that's been the common paradigm at my employers I'll also note that many linux distributions include the debug symbols for the distribution in optionally loaded packages. > >Another useful method is to write out debug information as the program >executes and arrange that it either is suppressed or (alternatively) >goes to /dev/null unless some undocumented flag is given. We arrange for the application to be able to be configured (both statically before startup and dynamically during runtime) to produce additional debug logging. Generally arranged in the code to avoid significant impact to non-debug performance (e.g. using __builtin_expect with GCC toolchains).
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-06 01:37 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10vvtk7$3bmmu$1@paganini.bofh.team> |
| In reply to | #116678 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>>> 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.
My guess is that GCC developers care more about -trapv than about
MIPS. AFAICS several architectures officialy supported by GCC
struggle to work at all. I suspect that maintainers of MIPS
backend are happy that -trapv works and do not have resources
to make it efficient.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-06-06 07:57 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1100jtq$1mrtr$1@dont-email.me> |
| In reply to | #116874 |
Waldek Hebisch <antispam@fricas.org> schrieb:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 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.
>
> My guess is that GCC developers care more about -trapv than about
> MIPS.
It is a common misconception to treat GCC developers as a
monolithic group. There are hobbyists (such as myself) but
I would guess only a small minority of work is done by them,
with the notable exception of some front ends such as Fortran or
(the most recent example) Algol 68. There are employees by
different companies: Linux distributors like RedHat or Suse,
Large software companies like Google, hardware vendors like
IBM, Intel or Qualcomm, ...
For MIPS, there are not so many active people and commits.
mips64-linux-gnu is a secondary platform, so if it fails
bootstrap, a release would be held up, but a wrong-code
regression will not.
Counting changes since 2025-01-01 in the gcc/config directories
can give a good idea of the relative activity for different
subdirectories; I cut this off below 7, where the PDP-11 is (note
that architecture names are often historical, so i386 includes
x86_64, s390 includes Z, rs6000 includes POWER and so on).
539 ./riscv
435 ./i386
432 ./aarch64
177 ./loongarch
100 ./arm
85 ./s390
75 ./avr
72 ./xtensa
60 ./rs6000
51 ./gcn
39 ./nvptx
25 ./sparc
25 ./mips
20 ./arc
19 ./pa
19 ./bpf
19 ./alpha
18 ./pru
15 ./sh
13 ./rx
13 ./cris
12 ./or1k
12 ./microblaze
12 ./m68k
11 ./lm32
11 ./ia64
11 ./h8300
9 ./vax
9 ./nds32
8 ./mcore
8 ./epiphany
8 ./c6x
7 ./visium
7 ./rl78
7 ./pdp11
7 ./frv
7 ./csky
> AFAICS several architectures officialy supported by GCC
> struggle to work at all. I suspect that maintainers of MIPS
> backend are happy that -trapv works and do not have resources
> to make it efficient.
First, they would need to know about this, which requires a PR,
but resources may well be lacking.
There are currently 28 open "missed-optimization" bugs with mips
in their target field. Looking at a few architectures above,
RISC-V has 118, x86 has 943, aarch64 has 305, power has 133.
(Some bugs affect more than one architecture, of course).
But it is worth submitting a PR nonetheless, if anybody cares enough :-)
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-12 01:57 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <110fp1g$1ck3s$2@paganini.bofh.team> |
| In reply to | #116877 |
Thomas Koenig <tkoenig@netcologne.de> wrote:
> Waldek Hebisch <antispam@fricas.org> schrieb:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>>> 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.
>>
>> My guess is that GCC developers care more about -trapv than about
>> MIPS.
>
> It is a common misconception to treat GCC developers as a
> monolithic group. There are hobbyists (such as myself) but
> I would guess only a small minority of work is done by them,
> with the notable exception of some front ends such as Fortran or
> (the most recent example) Algol 68. There are employees by
> different companies: Linux distributors like RedHat or Suse,
> Large software companies like Google, hardware vendors like
> IBM, Intel or Qualcomm, ...
Well, normal employees care about things that their employer
tells them to do. Whatever the reason GCC developers
(that is people contributing to GCC) each have their agenda,
care more about some things and less about other.
> For MIPS, there are not so many active people and commits.
> mips64-linux-gnu is a secondary platform, so if it fails
> bootstrap, a release would be held up, but a wrong-code
> regression will not.
>
> Counting changes since 2025-01-01 in the gcc/config directories
> can give a good idea of the relative activity for different
> subdirectories; I cut this off below 7, where the PDP-11 is (note
> that architecture names are often historical, so i386 includes
> x86_64, s390 includes Z, rs6000 includes POWER and so on).
>
> 539 ./riscv
> 435 ./i386
> 432 ./aarch64
> 177 ./loongarch
> 100 ./arm
> 85 ./s390
> 75 ./avr
> 72 ./xtensa
> 60 ./rs6000
> 51 ./gcn
> 39 ./nvptx
> 25 ./sparc
> 25 ./mips
> 20 ./arc
> 19 ./pa
> 19 ./bpf
> 19 ./alpha
> 18 ./pru
> 15 ./sh
> 13 ./rx
> 13 ./cris
> 12 ./or1k
> 12 ./microblaze
> 12 ./m68k
> 11 ./lm32
> 11 ./ia64
> 11 ./h8300
> 9 ./vax
> 9 ./nds32
> 8 ./mcore
> 8 ./epiphany
> 8 ./c6x
> 7 ./visium
> 7 ./rl78
> 7 ./pdp11
> 7 ./frv
> 7 ./csky
>
>> AFAICS several architectures officialy supported by GCC
>> struggle to work at all. I suspect that maintainers of MIPS
>> backend are happy that -trapv works and do not have resources
>> to make it efficient.
>
> First, they would need to know about this, which requires a PR,
> but resources may well be lacking.
>
> There are currently 28 open "missed-optimization" bugs with mips
> in their target field. Looking at a few architectures above,
> RISC-V has 118, x86 has 943, aarch64 has 305, power has 133.
> (Some bugs affect more than one architecture, of course).
>
> But it is worth submitting a PR nonetheless, if anybody cares enough :-)
Frankly, I do not care enough. I mean, I like fact that GCC
supports several architectures. But I have use of x86_64, arm (both
32 bit and 64-bit one), RISC-V and few embedded processors, that is
I have processors and can run GCC outout on them. I even have some
use of s390/z, that is I have emulator (Hercules) and have some
interst in software running inside emulator. But I have essentially
no use of MIPS.
And in slightly different spirit, IIRC there were cases when bug
reports caused reaction of sort "Yes, it is buggy. It would be
too much effort to fix it, so we will just remove support".
I support is removed, then work needed to revive an architecture
is likely to be significantly larger than in case of bitrotten,
but still in-tree architecture.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-26 08:18 +0200 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v3dv9$1t28e$1@dont-email.me> |
| In reply to | #116667 |
On 25/05/2026 18:43, Anton Ertl wrote:
> 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.
>
My understanding is that the GCC developers would rather deprecate
-ftrapv entirely, and encourage the use of -fsanitize instead as a way
to detect run-time errors. I don't know the details of the internals,
but I believe the GCC developers see the sanitize options as more
accurate and more likely to be further developed in the future.
> 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?
I don't know for sure. A "by default" choice has to be suitable for a
wide variety of users and a wide variety of cases, and preferably err on
the side of caution. For my own personal use, I'm happy with UB
overflow and would have preferred that as the default even for unsigned
arithmetic (but of course with a way to specify wrapping when I need
it). But that's for /my/ use - I don't think that should necessarily be
the default for others. Let those who are willing to spend the time and
effort learning the details and the care needed use compiler flags to
get the highest efficiency from their code, and let the defaults help
others catch their bugs. However, the logical endpoint of that is that
C should only be used by those that have a detailed understanding of the
language and need it for peak efficiency, while other programmers should
work with other languages that have more error handling.
>
> 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.
>
True. Can we pretend that is not the case, and still see my point? The
point is that the compiler can, during re-arrangements, introduce new
overflows as long as it knows the final results are correct (since the
compiler knows the details of how instructions are actually implemented).
> 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.
Agreed. I don't know why GCC uses a function call here. In my quick
godbolt testing, clang uses the "add, jump-on-overflow" sequence.
Using
-fsanitize=signed-integer-overflow -fsanitize-trap
gives an add followed by a jump-on-overflow sequence.
>
>> 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.
If "-ftrapv" is to have any use at all, then overflow is no longer UB -
it has to be defined to trap. But I have to conclude that in GCC,
-ftrapv is too vaguely defined and too inconsistently and inefficiently
implemented to be of any use. This matches my understanding that the
"-fsanitize=signed-integer-overflow -fsanitize-trap" flags are preferred
by the GCC developers.
>
> 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".
That is my experience too (though I expect your experience here vastly
outweighs mine).
>
>> 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.
>
Good idea :-)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-12 01:04 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <110flvj$1ck3s$1@paganini.bofh.team> |
| In reply to | #116667 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 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
That is what I expect from '-ftrapv': running code should deliver
result as if using infinite precision arithmetic or overflow trap.
More tight specification could be that optimized code should not
generate overflow trap in cases when computing naively using C
semantics does not lead to overflow. Since the result above
agrees with result obtained using infinite precision arithmetic,
the code is fine and there is no need for runtime checks.
Of course, languages like C++ which turn traps into exceptions
and allow to use this as part of computations may have problem
here. More precisely, if they specify that overflow exception
must happen at given computational step, then optimizer may be
forced to generate code which is ther only to generate trap
and serves no other purpose. But the orignal intent of
overflow trap is to signal that real machine using fixed size
numbers can not deliver the same result as ideal machine
using infinte precion. If a language respects the intent,
then compiler can do a lot of optimizations.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-05-25 15:27 -0400 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <jwvo6i3jo2i.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #116664 |
> An awkward thing about using trap on overflow is determining how > precisely it is defined. Indeed, this is a nasty part of language design. [ IMO, the only sane choice (beside wrapping and explicit `ckd_add`) is to treat overflow not as a exception (in the sense of `try..catch` thingies, not in the CPU hardware sense of the word) but as an execution error comparable to memory exhaustion. ] Luckily, for `comp.arch` the same problem doesn't plague ISAs because it's accepted that a CPU should stick religiously to the literal semantics of the machine code, no matter how far it is from what really happens inside the machine. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-25 16:49 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779727799-5857@newsgrouper.org> |
| In reply to | #116663 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > 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: ----------------- > 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). The worst of all possible semantic encodings > > - anton
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-25 20:34 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v2bp1$1l0ma$2@dont-email.me> |
| In reply to | #116666 |
On Mon, 25 May 2026 16:49:59 +0000, MitchAlsup wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> 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). > The worst of all possible semantic encodings Although I thought that making trapping on fixed-point overflow the default is a bad idea, I agree that making it impossible to do so, or even test for fixed-point overflow, is a much worse idea. John Savard
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-25 20:02 -0500 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v2rfv$1p7t4$1@dont-email.me> |
| In reply to | #116676 |
On 5/25/2026 3:34 PM, quadi wrote:
> On Mon, 25 May 2026 16:49:59 +0000, MitchAlsup wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>>> 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).
>
>> The worst of all possible semantic encodings
>
> Although I thought that making trapping on fixed-point overflow the
> default is a bad idea, I agree that making it impossible to do so, or even
> test for fixed-point overflow, is a much worse idea.
>
Possibly true.
The lack of things like ADD-with-Carry or ADD-with-Overflow are
annoyance points on RISC-V.
Though, it is less obvious what a useful behavior is at the language level:
"signal()" ? ...
Something like try/catch (mostly N/A to C)?
Something similar to FENV_ACCESS?
...
Well, and that if trapping were applied globally:
Overhead due to trap detection/handling code causing excessive bloat;
Overflows traps from any code that naively assumes wrap-on-overflow
semantics;
...
In some codebases, it is already enough of a pain to hunt and fix all
the out-of-bounds and uninitialized variables mess.
Signed integer overflows would likely "turn it up to 11";
Then, how does one fix it? Ask that people start adding a bunch of casts
to make it work?...
One might say:
Add "if()" cases to deal with the overflows, but, ... this only makes
sense for cases where the overflows are not the expected behavior.
Then again, could maybe classify code, say:
1, signed, value doesn't (or shouldn't) go out-of-range;
2, unsigned, value doesn't (or shouldn't) go out-of-range;
3, signed, value is expected to be modulo;
4, unsigned, value is expected to be modulo.
"nasal demons" types assume 1 and 4 as dominant.
Or, 1 as exclusive vs 3.
For compilers, we often need to assume 3 and 4.
Because, failure to uphold 3 results in misbehaving programs.
And, if 3 were uncommon, RISC-V's "ADDW"/etc would be pure stupidity.
Instead:
Something like plain ADD plus ADDWU would have made sense.
But, they dropped ADDWU instead (also stupid IMO).
While, granted, a lot of 1 code likely exists, 3 code tends to generate
the vast majority of overflows; and if there is any reasonable
expectation for 'int' to overflow, and it is not desired for int to
overflow.
We mostly ignore 2 vs 4, because standard specifies 4 making 2 to be
purely a programming error, in which case "2" becomes "should have used
a bigger signed type instead".
Then again, could maybe make sense to add a semantic distinction, say:
"int" (plain):
Maybe a case could be made that overflow be assumed unexpected.
"signed int":
Maybe make separate from plain case, explicitly modulo;
So, could be made distinct;
Explicitly like the "unsigned" case in being modulo.
"unsigned int":
Remains the same, no real controversy here.
Or, say:
char, short, int, long, long long:
For code, assume that overflow may be unexpected / undesirable;
signed char, signed int, signed long, signed long long:
Assume signed modulo;
Compiler should, ideally, always produce wrap-on-overflow semantics.
unsigned ...:
Unsigned modulo.
For a compiler, then:
-ftrapv:
May ideally trap on lack of "signed";
Explicit "signed", continues to wrap.
-fwrapv:
Both default and signed will wrap.
Neither:
Dunno, probably better for compiler to assume "-fwrapv" semantics;
Maybe assume UB opts are safe if no "signed".
Well, and for the programmer POV:
If assuming maximum portability:
Only unsigned overflow wrapping is "safe".
If assuming "any reasonable system":
Both will wrap in most cases;
Absent "-fwrapv", UB opts may occur in certain obscure edge cases.
Though usually in the form of "early" vs "late" type promotion;
In most cases, where it does occur, early promotion is benign.
Vs whatever "nasal demons" people may assert.
What else, that it late propmotes?
(as "-fwrapv" semantics would dictate...)
Like, say:
int x;
long z;
...
z = 42 - x;
//Oh no! UB opt has turned this into a 64-bit RSUB instruction!
Yeah...
Granted, ATM, for BGBCC, wouldn't make much difference at present. Could
maybe make sense to add a distinction either to strengthen semantic
analysis, or if I decided to change away from my existing "assume wrap
on overflow semantics as sole option" policy. Or maybe adding an
"-fno-wrapv" option, with "wrapv" remaining default but allowing an
option to opt-out, sort of like how there is an "-fptropts" option to
"opt into" strict-aliasing / TBAA semantics, vs the default semantics of
"assume every explicit store may alias" semantics. Though, may still
assume that loads may be cached and reordered, unless "volatile" is
used, which explicitly disallows caching and reordering loads, though at
present is a little "shotgun" and will basically disable caching
throughout the whole basic block; which works as a detractor to the
"casually use volatile as a way to dispel TBAA" interpretation (works on
GCC, and is less adverse for performance than the "use memcpy" option on
some other compilers, ...).
Or, say:
Bare pointer cast and deref:
GCC: averse (falls afoul of default semantics);
MSVC: benign;
BGBCC: benign.
Volatile pointer cast and deref:
GCC: benign (doesn't use TBAA on volatile pointers);
MSVC: benign;
BGBCC: detrimental, disables caching and ld/st reordering;
Using memcpy:
GCC: benign;
MSVC:
Old (15+ years):
Averse (actually calls memcpy, significant impact);
Some intermediate versions would do an inline for "REP MOVSB".
Also kinda crap, but less bad vs calling "memcpy()".
Mostly only matters if still targeting WinXP or similar.
Newer: Mild detriment in some cases.
Inline loads/stores
may fail to optimize to plain register moves for locals.
BGBCC;
Mostly similar to newer MSVC here;
Works, just less efficient than plain "cast and deref".
...
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-26 18:02 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779818571-5857@newsgrouper.org> |
| In reply to | #116687 |
BGB <cr88192@gmail.com> posted:
> On 5/25/2026 3:34 PM, quadi wrote:
> > On Mon, 25 May 2026 16:49:59 +0000, MitchAlsup wrote:
> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >
> >>> 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).
> >
> >> The worst of all possible semantic encodings
> >
> > Although I thought that making trapping on fixed-point overflow the
> > default is a bad idea, I agree that making it impossible to do so, or even
> > test for fixed-point overflow, is a much worse idea.
> >
>
> Possibly true.
>
> The lack of things like ADD-with-Carry or ADD-with-Overflow are
> annoyance points on RISC-V.
>
>
> Though, it is less obvious what a useful behavior is at the language level:
> "signal()" ? ...
> Something like try/catch (mostly N/A to C)?
> Something similar to FENV_ACCESS?
> ...
>
The important property is that overflow is detected precisely.
Whether {trap, signal, throw} is performed is an environmental choice
not an ISA choice.
>
> Well, and that if trapping were applied globally:
> Overhead due to trap detection/handling code causing excessive bloat;
> Overflows traps from any code that naively assumes wrap-on-overflow
> semantics;
> ...
>
> In some codebases, it is already enough of a pain to hunt and fix all
> the out-of-bounds and uninitialized variables mess.
> Signed integer overflows would likely "turn it up to 11";
> Then, how does one fix it? Ask that people start adding a bunch of casts
> to make it work?...
>
> One might say:
> Add "if()" cases to deal with the overflows, but, ... this only makes
> sense for cases where the overflows are not the expected behavior.
If(overflow(??)) requires some flag to carry overflow from point of
detection to if(()).
And what happens if there is more than 1 overflow ??
> Then again, could maybe classify code, say:
> 1, signed, value doesn't (or shouldn't) go out-of-range;
> 2, unsigned, value doesn't (or shouldn't) go out-of-range;
> 3, signed, value is expected to be modulo;
> 4, unsigned, value is expected to be modulo.
5, a language hint about in-range, wrap, trap, signal, throw
>
> "nasal demons" types assume 1 and 4 as dominant.
> Or, 1 as exclusive vs 3.
>
> For compilers, we often need to assume 3 and 4.
> Because, failure to uphold 3 results in misbehaving programs.
> And, if 3 were uncommon, RISC-V's "ADDW"/etc would be pure stupidity.
You would prefer::
AND R7,Rleft,#~(~0<<31)
AND R8,Rright,#~(~0<<31)
ADD Rd,R7,R8
AND Rd,Rd,#~(~0<<31)
That is ADDW range limits operands and performs a shorter ADD.
Matching C's int a,b; semantic. In general the integer instructions
ending with W apply C's int properties to the arithmetic. If compilers
were (WERE) really good at range determination those instructions would
be unnecessary--but they are not.
I (My 66000) had to put in sized integer calculation reasons, and by
doing so, gained 2%-4% in code density and a bit more in latency.
-----------------------
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-26 14:28 -0500 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v4s9s$29ppm$1@dont-email.me> |
| In reply to | #116700 |
On 5/26/2026 1:02 PM, MitchAlsup wrote:
>
> BGB <cr88192@gmail.com> posted:
>
>> On 5/25/2026 3:34 PM, quadi wrote:
>>> On Mon, 25 May 2026 16:49:59 +0000, MitchAlsup wrote:
>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>>
>>>>> 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).
>>>
>>>> The worst of all possible semantic encodings
>>>
>>> Although I thought that making trapping on fixed-point overflow the
>>> default is a bad idea, I agree that making it impossible to do so, or even
>>> test for fixed-point overflow, is a much worse idea.
>>>
>>
>> Possibly true.
>>
>> The lack of things like ADD-with-Carry or ADD-with-Overflow are
>> annoyance points on RISC-V.
>>
>>
>> Though, it is less obvious what a useful behavior is at the language level:
>> "signal()" ? ...
>> Something like try/catch (mostly N/A to C)?
>> Something similar to FENV_ACCESS?
>> ...
>>
> The important property is that overflow is detected precisely.
> Whether {trap, signal, throw} is performed is an environmental choice
> not an ISA choice.
Yeah.
Say:
ADDV Rs, Rt, Rd
BT __trap_overflow
Which is how I would assume doing it, if I were to re-add ADDV to my ISA
(this had existed in SuperH and BJX1, but got lost along the way, but
could re-add if needed; just it was less often needed than even ADC/ADDC).
>>
>> Well, and that if trapping were applied globally:
>> Overhead due to trap detection/handling code causing excessive bloat;
>> Overflows traps from any code that naively assumes wrap-on-overflow
>> semantics;
>> ...
>>
>> In some codebases, it is already enough of a pain to hunt and fix all
>> the out-of-bounds and uninitialized variables mess.
>> Signed integer overflows would likely "turn it up to 11";
>> Then, how does one fix it? Ask that people start adding a bunch of casts
>> to make it work?...
>>
>> One might say:
>> Add "if()" cases to deal with the overflows, but, ... this only makes
>> sense for cases where the overflows are not the expected behavior.
>
> If(overflow(??)) requires some flag to carry overflow from point of
> detection to if(()).
>
> And what happens if there is more than 1 overflow ??
>
Dunno.
You would need to set a start point and an end/detection point, and have
some way for the compiler to know to track overflows.
Say:
ADDV ...
OR?T Re, 0x100, Re
Then a way to feed Re back into C land to act upon.
There could maybe either be a 32-bit variant (ADDV.L), or some shorthand
way to detect that the value has gone outside of 32-bit range.
>> Then again, could maybe classify code, say:
>> 1, signed, value doesn't (or shouldn't) go out-of-range;
>> 2, unsigned, value doesn't (or shouldn't) go out-of-range;
>> 3, signed, value is expected to be modulo;
>> 4, unsigned, value is expected to be modulo.
> 5, a language hint about in-range, wrap, trap, signal, throw
Well, possible, but C doesn't have any hints here...
But, yeah:
Leaving plain 'int' as the "probably shouldn't overflow" and 'signed
int' and 'unsigned int' as "wrap on overflow expected" could make sense.
>>
>> "nasal demons" types assume 1 and 4 as dominant.
>> Or, 1 as exclusive vs 3.
>>
>> For compilers, we often need to assume 3 and 4.
>> Because, failure to uphold 3 results in misbehaving programs.
>> And, if 3 were uncommon, RISC-V's "ADDW"/etc would be pure stupidity.
>
> You would prefer::
>
> AND R7,Rleft,#~(~0<<31)
> AND R8,Rright,#~(~0<<31)
> ADD Rd,R7,R8
> AND Rd,Rd,#~(~0<<31)
>
> That is ADDW range limits operands and performs a shorter ADD.
> Matching C's int a,b; semantic. In general the integer instructions
> ending with W apply C's int properties to the arithmetic. If compilers
> were (WERE) really good at range determination those instructions would
> be unnecessary--but they are not.
>
> I (My 66000) had to put in sized integer calculation reasons, and by
> doing so, gained 2%-4% in code density and a bit more in latency.
> -----------------------
OK.
Ironically, the 4-op sequence above would have been a single "ADDWU"
instruction in the RV BitManip drafts, but ADDWU was dropped as arguably
it didn't make a big enough difference on SPEC scores. They decided to
keep a whole bunch of other random crap though that serves no real
purpose other than to micro-optimize the benchmarks...
I revived this for my own extensions, but left out ADDIWU as it was
still not common enough to justify the encoding space cost (if one has
jumbo-prefixes, this could be handled well enough via
immediate-synthesis, and the 64-bit encoding wasn't too bad for
something that is comparably infrequent).
...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-25 16:34 -0500 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v2f9s$1m5tn$1@dont-email.me> |
| In reply to | #116663 |
On 5/25/2026 9:28 AM, 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.
>
Many just go Inf...
Division by zero is usually handled by going NaN.
Contrast with integer division by zero which does usually trap.
>>>> 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).
>
Integer overflow happens far too often for trapping to be a good solution.
We almost need a separate "integer that should not overflow" type, with
more explicit "do something special if it does" semantics.
Though, more likely to be useful would be a "detect if an overflow had
happened" mechanism.
errno_t ovfstate;
__int_no_overflow x, y, z;
...
__start_errsense(&ovfstate);
z=x+y;
__end_errsense(&ovfstate);
if(ovfstate&ERRSENSE_FLAG_OVERFLOW)
...
Which would be awkward, but probably more useful than, say, raising a
signal and/or terminating the program.
>> 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).
>
In practice, given:
We have instructions like ADDW, etc, whose behavior is explicitly to
sign-extend the results of 32-bit ADD;
Behavior in practice is often to meticulously follow wrap-on-overflow
semantics;
Exceptions to wrap-on-overflow usually exist as edge cases;
Various programs exist that will actively break if wrap-on-overflow is
not the observed behavior in C land;
...
The expectation that 'int' can or meaningfully do something other than
wrap on overflow is more of a fantasy.
Or like some other some other "portability boogeymen":
Non two's complement integer arithmetic;
Big endian machines;
Machines that don't allow unaligned loads and stores;
Types with sizes other than the "usually accepted" set;
...
The argument has often been, "but, 64-bit machines might not provide
native 32-bit arithmetic".
But, often in 64-bit machines, a pattern emerges:
Most ops are full 64-bit;
A subset of instructions have variants that produce sign and/or zero
extended results;
The instructions which produce these results, typically being, the ones
needed to preserve the usual wrap-on-overflow semantics in those places
where something could happen that would produce a deviation from the
expected semantics.
The ones that have zero-extension usually treating signed integers as
zero-extended.
The reverse has also been done; treating unsigned as sign-extended, as
in the standard RISC-V ABI, but IMO this is stupid. Even in the absence
of a native zero-extension op (as in plain RV64G), the mess that results
from sign-extending unsigned is worse than the cost of explicit zero
extension.
Best case here being to keep values using "native extension":
'int' : Always sign extended;
'unsigned int': Always zero extended.
Then 32-bit types are a strict subset of the 64-bit range, and
up-promotion becomes free. Not sure why some people don't see this as
obvious though. Well, and people keep making the choice of adding
garbage edge cases to RISC-V that would have been entirely unnecessary
if people weren't being stupid about the ABI rules.
But yeah...
But, all this would not be expected to happen unless one accepts that it
is already generally accepted that wrap-on-overflow for 'int' and
similar is the only really practical or viable solution here.
Otherwise, recently:
In my case I decided to live with a "breaking change" in XG3 and to
change some things that may matter later. Then ended up tweaking some
other things on my annoyance list (since I was already breaking existing
binaries, better to cluster breakage to a singular event if doing it).
ADD, ADDS.L, and ADDU.L have all been changed from Imm10u/n to Imm10s.
The Imm10u cases are now Imm10s;
The Imm10n sub-case is now dropped/reserved.
May be reused later.
This reclaims 3 out of the 20 Imm10 spots.
Was mostly a case of it being harder to justify the encoding space.
Old behavior will need to remain for XG1 and XG2.
In this case, XG3 will explicitly deviate from XG1 and XG2 here.
Does mean that XG3 now had less ADD/SUB Imm range than XG2, but...
Only goes from 97.1% hit rate to 95.9%,
no significant effect on overall code density.
Could use the RV Imm12 ops (ADDI / ADDIW), but:
Hit rate for the RV ops here is negligible;
Much of these also happen to miss on one or both registers.
The MULS.L and MULU.L ops were also switched to Imm10s.
This means all of the Imm10 ALU ops are now unified on Imm10s.
Relocated TST and TSTN from the F0-8 block (with the XMOV instructions)
to the F0-9 block (with the other CMPxx 3R ops).
A few very rarely used instructions were demoted from 32-bit to 64-bit
encodings.
Have experimentally added some 32-bit:
Bcc Rm, Imm6s, (PC, Disp6s)
instructions, where:
Imm6s: Hits ~ 80% of these cases;
Disp6s: Hits ~ 60% of these cases;
Imm5s + Disp7s would hit slightly better, but,
would have needed more new decoder logic...
Resulting in it hitting about half over the:
Bcc Rm, Imm17s, (PC, Disp10s)
Cases, for an overall code-density improvement of ~ 0.5%, ...
Dominant use-case: Final compare-and-branch in a short "for()" loop.
Secondary use-case: Short non-predicated "if()" branches.
But, is out-weighed by said predicated "if()" branches.
Would likely see more use here if not using predication.
If it would have hit for 100% of these, would have saved ~ 1%.
This is debatable.
This reused the encoding spots previously used for the Load-Disp5us ops,
which still exist for XG1 and XG2 (decoder special-case handling), but
were N/A in XG3 (they would be in effect entirely redundant with the
Disp10s forms in XG3; but had non-redundant edge-cases in XG1 and XG2).
Like with the Imm17s+Disp10s ops, these will still depend on the IMMB
extension, as they still need the same basic mechanism.
Was a fairly low-priority feature, in any case.
Seemingly running low on obvious optimization paths.
> - anton
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-25 23:05 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779750306-5857@newsgrouper.org> |
| In reply to | #116679 |
BGB <cr88192@gmail.com> posted: > On 5/25/2026 9:28 AM, Anton Ertl wrote: -------------- > Integer overflow happens far too often for trapping to be a good solution. Even on 64-bit variables/machines ??
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-05-26 15:29 -0400 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <avsb1l5kmb8c94rdnecptdmhi51jg7lerq@4ax.com> |
| In reply to | #116685 |
On Mon, 25 May 2026 23:05:06 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >BGB <cr88192@gmail.com> posted: > >> On 5/25/2026 9:28 AM, Anton Ertl wrote: >-------------- >> Integer overflow happens far too often for trapping to be a good solution. > >Even on 64-bit variables/machines ?? Yes if there are options for 8/16/32 bit ops in 64 bit registers.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-26 19:13 -0500 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v5cv5$2e2k9$1@dont-email.me> |
| In reply to | #116703 |
On 5/26/2026 2:29 PM, George Neuner wrote: > On Mon, 25 May 2026 23:05:06 GMT, MitchAlsup > <user5857@newsgrouper.org.invalid> wrote: > >> >> BGB <cr88192@gmail.com> posted: >> >>> On 5/25/2026 9:28 AM, Anton Ertl wrote: >> -------------- >>> Integer overflow happens far too often for trapping to be a good solution. >> >> Even on 64-bit variables/machines ?? > > Yes if there are options for 8/16/32 bit ops in 64 bit registers. 32-bit overflow is the dominant scenario here. While 8 and 16-bit ranges do overflow readily, the normal semantics are for them to auto-promote to 32 bits before then being narrowed back down to 8 or 16 bits, so they don't count. Ironically, for my BS2 language, the semantics were in cases like this to instead auto-promote to 64 bits; but can't really do this for C as it gives different results in some cases (and early promotion is itself a bug, even if early promotion would often be the most natural semantics for a 64-bit machine). Well, and there is the usual thing that one can't usually allow a variable to hold values outside the range of what would be allowed for that variable. Well, except for floating-point types, where typically code doesn't care about out of ranges of values (if a value fails to go to 0 or Inf in a computation in local variables, typically no one cares). For float, it isn't obvious because the dynamic range of Binary32 is already quite large. A "short float" effectively having Binary64's dynamic range when used in scalar computations is a bit incredulous, but given these smaller formats are non-standard anyways, it reasonable to be like "these formats are only necessarily confined to their formal range when in-memory, otherwise all bets are off". Or: precision and dynamic range >= requested format. Code can't entirely rely on the higher precision though, as the format may also revert to its defined precision without warning (even if intermediate computations may potentially wildly exceed it). But, then again, this would be analogous to if one has an FPU with native Binary128, occasionally performing "double" calculations at Binary128 precision even though "double" is stated as Binary64. Well, or implementing some operations by widening temporarily to a higher-precision format before narrowing the result. Though, OTOH, the main use-case for things like scalar "short float" is more for saving memory in structs and arrays, not for trying to rely on its crappy range and precision. So, floating point math is very different from integer math in this regard. ...
[toc] | [prev] | [next] | [standalone]
| From | quadi <quadibloc@ca.invalid> |
|---|---|
| Date | 2026-05-25 20:26 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <10v2b9g$1kvdo$1@dont-email.me> |
| In reply to | #116662 |
On Mon, 25 May 2026 10:23:00 +0200, David Brown wrote: > The hardware, of course, cannot always enable trapping on overflow if it > is going to efficiently support a range of programming languages. Yes. And I am used to FORTRAN, which did not trap on integer overflows. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-05-25 22:49 +0000 |
| Subject | Re: condition bits, Concertina IV Has Arrived |
| Message-ID | <1779749398-5857@newsgrouper.org> |
| In reply to | #116673 |
quadi <quadibloc@ca.invalid> posted: > On Mon, 25 May 2026 10:23:00 +0200, David Brown wrote: > > > The hardware, of course, cannot always enable trapping on overflow if it > > is going to efficiently support a range of programming languages. > > Yes. And I am used to FORTRAN, which did not trap on integer overflows. WATfor and WATfive trapped on integer overflows. > John Savard
[toc] | [prev] | [next] | [standalone]
Page 27 of 30 — ← Prev page 1 … 25 26 [27] 28 29 30 Next page →
Back to top | Article view | comp.arch
csiph-web