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 20 of 30 — ← Prev page 1 … 18 19 [20] 21 22 … 30 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-01 16:36 +0000 |
| Subject | Re: endian history |
| Message-ID | <2026Oct1.183612@mips.complang.tuwien.ac.at> |
| In reply to | #118356 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>>> With wrapping signed arithmetic, all of the semantics of unsigned >>>> arithmetic is the same, except for right shift and division >>>> operations. >>> >>> Also left shift >> >> No. The funny thing is that AMD64 has both SHL and SAL mnemonics, but >> they encode the same opcodes. E.g.: >> >> D3 /4 SAL r/m32, CL >> D3 /4 SHL r/m32, CL > >That may be true for AMD64. It is not true for other >two's complement architectures. Care to name one? In particular one with modulo (aka wrapping) arithmetic? IIRC VAX shifts are perverse, but they trap on overflow. - 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-10-01 18:38 +0000 |
| Subject | Re: endian history |
| Message-ID | <EMxvS.2$WhQb.1@fx22.iad> |
| In reply to | #118360 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>>> With wrapping signed arithmetic, all of the semantics of unsigned >>>>> arithmetic is the same, except for right shift and division >>>>> operations. >>>> >>>> Also left shift >>> >>> No. The funny thing is that AMD64 has both SHL and SAL mnemonics, but >>> they encode the same opcodes. E.g.: >>> >>> D3 /4 SAL r/m32, CL >>> D3 /4 SHL r/m32, CL >> >>That may be true for AMD64. It is not true for other >>two's complement architectures. > >Care to name one? In particular one with modulo (aka wrapping) >arithmetic? IIRC VAX shifts are perverse, but they trap on overflow. Motorola 88100 had both sign-extending and zero-extending left-shift and right-shift instructions (EXT, EXTU).
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-10-01 15:17 -0400 |
| Subject | Re: endian history |
| Message-ID | <25ctbld38d1de1ste15lec3rgf3e14je6q@4ax.com> |
| In reply to | #118364 |
On Thu, 01 Oct 2026 18:38:28 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> >>>>>> With wrapping signed arithmetic, all of the semantics of unsigned >>>>>> arithmetic is the same, except for right shift and division >>>>>> operations. >>>>> >>>>> Also left shift >>>> >>>> No. The funny thing is that AMD64 has both SHL and SAL mnemonics, but >>>> they encode the same opcodes. E.g.: >>>> >>>> D3 /4 SAL r/m32, CL >>>> D3 /4 SHL r/m32, CL >>> >>>That may be true for AMD64. It is not true for other >>>two's complement architectures. >> >>Care to name one? In particular one with modulo (aka wrapping) >>arithmetic? IIRC VAX shifts are perverse, but they trap on overflow. > >Motorola 88100 had both sign-extending and zero-extending >left-shift and right-shift instructions (EXT, EXTU). But those are doing 2 operations - shifting /and/ extending. Left shift of an already extended number works the same regardless of whether there are zeros or ones in the high bits.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-01 21:20 +0000 |
| Subject | Re: endian history |
| Message-ID | <2026Oct1.232032@mips.complang.tuwien.ac.at> |
| In reply to | #118364 |
scott@slp53.sl.home (Scott Lurndal) writes: >Motorola 88100 had both sign-extending and zero-extending >left-shift and right-shift instructions (EXT, EXTU). If you look into the manual, you will find that it says about ext with width 32 that it operates as an arithmetic shift RIGHT (and for extu as a logic shift RIGHT). You can then look at the MAK instruction, and find that with width 32 it operates as a shift left. There is no MAKU, because for left shifts on 2s-complement machines with modulo arithmetics, there is no difference between signed and unsigned left shift. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-01 19:55 +0000 |
| Subject | Re: endian history |
| Message-ID | <1790884534-5857@newsgrouper.org> |
| In reply to | #118360 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>
> >>>> With wrapping signed arithmetic, all of the semantics of unsigned
> >>>> arithmetic is the same, except for right shift and division
> >>>> operations.
> >>>
> >>> Also left shift
> >>
> >> No. The funny thing is that AMD64 has both SHL and SAL mnemonics, but
> >> they encode the same opcodes. E.g.:
> >>
> >> D3 /4 SAL r/m32, CL
> >> D3 /4 SHL r/m32, CL
> >
> >That may be true for AMD64. It is not true for other
> >two's complement architectures.
>
> Care to name one? In particular one with modulo (aka wrapping)
> arithmetic? IIRC VAX shifts are perverse, but they trap on overflow.
Which means you cannot write::
for( int i = 1; i; i<<=1 )
{ ... }
// never gets here--traps instead.
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-02 11:21 +0200 |
| Subject | Re: endian history |
| Message-ID | <119nt2j$1rmn1$5@dont-email.me> |
| In reply to | #118367 |
On 01/10/2026 21:55, MitchAlsup wrote:
>
> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>>> With wrapping signed arithmetic, all of the semantics of unsigned
>>>>>> arithmetic is the same, except for right shift and division
>>>>>> operations.
>>>>>
>>>>> Also left shift
>>>>
>>>> No. The funny thing is that AMD64 has both SHL and SAL mnemonics, but
>>>> they encode the same opcodes. E.g.:
>>>>
>>>> D3 /4 SAL r/m32, CL
>>>> D3 /4 SHL r/m32, CL
>>>
>>> That may be true for AMD64. It is not true for other
>>> two's complement architectures.
>>
>> Care to name one? In particular one with modulo (aka wrapping)
>> arithmetic? IIRC VAX shifts are perverse, but they trap on overflow.
>
> Which means you cannot write::
>
> for( int i = 1; i; i<<=1 )
> { ... }
> // never gets here--traps instead.
You can write it if you like - but it is UB on all platforms.
Use "unsigned int" here. Then there is no problem.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-02 12:47 +0300 |
| Subject | Re: endian history |
| Message-ID | <20261002124718.000076c1@yahoo.com> |
| In reply to | #118386 |
On Fri, 2 Oct 2026 11:21:23 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 01/10/2026 21:55, MitchAlsup wrote:
> >
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>>
> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>>
> >>>>>> With wrapping signed arithmetic, all of the semantics of
> >>>>>> unsigned arithmetic is the same, except for right shift and
> >>>>>> division operations.
> >>>>>
> >>>>> Also left shift
> >>>>
> >>>> No. The funny thing is that AMD64 has both SHL and SAL
> >>>> mnemonics, but they encode the same opcodes. E.g.:
> >>>>
> >>>> D3 /4 SAL r/m32, CL
> >>>> D3 /4 SHL r/m32, CL
> >>>
> >>> That may be true for AMD64. It is not true for other
> >>> two's complement architectures.
> >>
> >> Care to name one? In particular one with modulo (aka wrapping)
> >> arithmetic? IIRC VAX shifts are perverse, but they trap on
> >> overflow.
> >
> > Which means you cannot write::
> >
> > for( int i = 1; i; i<<=1 )
> > { ... }
> > // never gets here--traps instead.
>
> You can write it if you like - but it is UB on all platforms.
>
> Use "unsigned int" here. Then there is no problem.
>
It is not UB if compiler defines the meaning.
AFAIK, it is defined for gcc, even in absence of special flags.
From the manual:
"The results of some bitwise operations on signed integers (C90 6.3, C99
and C11 6.5, C23 6.5.1).
Bitwise operators act on the representation of the value including both
the sign and value bits, where the sign bit is considered immediately
above the highest-value value bit. Signed ‘>>’ acts on negative numbers
by sign extension.
As an extension to the C language, GCC does not use the latitude given
in C99 and later to treat certain aspects of signed ‘<<’ as undefined.
However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such
cases. They are also diagnosed where constant expressions are required."
I don't like the style of writing of the last paragraph, but the
meanaing seems to be that gcc defines 'i << e' to be the same as
'(int)((unsigned)i << e)'
clang tends to copy gcc, so it is most likely defined here too.
It's unlikely that you will find text that defines it in MSVC docs, but
it's even less likely that it will generate code with diffeerent
semanatics from those of gcc.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-02 12:57 +0200 |
| Subject | Re: endian history |
| Message-ID | <119o2md$20o6t$1@dont-email.me> |
| In reply to | #118387 |
On 02/10/2026 11:47, Michael S wrote:
> On Fri, 2 Oct 2026 11:21:23 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 01/10/2026 21:55, MitchAlsup wrote:
>>>
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>
>>>>>>>> With wrapping signed arithmetic, all of the semantics of
>>>>>>>> unsigned arithmetic is the same, except for right shift and
>>>>>>>> division operations.
>>>>>>>
>>>>>>> Also left shift
>>>>>>
>>>>>> No. The funny thing is that AMD64 has both SHL and SAL
>>>>>> mnemonics, but they encode the same opcodes. E.g.:
>>>>>>
>>>>>> D3 /4 SAL r/m32, CL
>>>>>> D3 /4 SHL r/m32, CL
>>>>>
>>>>> That may be true for AMD64. It is not true for other
>>>>> two's complement architectures.
>>>>
>>>> Care to name one? In particular one with modulo (aka wrapping)
>>>> arithmetic? IIRC VAX shifts are perverse, but they trap on
>>>> overflow.
>>>
>>> Which means you cannot write::
>>>
>>> for( int i = 1; i; i<<=1 )
>>> { ... }
>>> // never gets here--traps instead.
>>
>> You can write it if you like - but it is UB on all platforms.
>>
>> Use "unsigned int" here. Then there is no problem.
>>
>
> It is not UB if compiler defines the meaning.
Of course. (Well, it is still UB in C - but it is fine to use if you
know you are sticking to that one particular compiler that documents
behaviour you want.)
In this case, there are no advantages in using "int", regardless of what
a compiler may or may not document.
> AFAIK, it is defined for gcc, even in absence of special flags.
> From the manual:
> "The results of some bitwise operations on signed integers (C90 6.3, C99
> and C11 6.5, C23 6.5.1).
>
> Bitwise operators act on the representation of the value including both
> the sign and value bits, where the sign bit is considered immediately
> above the highest-value value bit. Signed ‘>>’ acts on negative numbers
> by sign extension.
>
That bit is all about implementation-defined behaviour - things that the
implementation is required to document. So far, so good - but not
relevant to the case of left-shifting a signed integer value "x << e"
when "x" is negative or when "x * 2^e" does not fit in the type of "x".
> As an extension to the C language, GCC does not use the latitude given
> in C99 and later to treat certain aspects of signed ‘<<’ as undefined.
> However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such
> cases. They are also diagnosed where constant expressions are required."
>
> I don't like the style of writing of the last paragraph, but the
> meanaing seems to be that gcc defines 'i << e' to be the same as
> '(int)((unsigned)i << e)'
I think your interpretation here is the perhaps the most reasonable
definition, but it is not what the text says here. It does not document
the behaviour. Other plausible (but I think less likely) candidates
would be giving an unspecified value, or treated it as you describe for
non-negative x while leaving it undefined for negative x.
If the gcc manual were to say explicitly that it handles left shifts in
the way you described, then I would agree the behaviour is defined and
the code with "int i" would be correct and save as long as you are using
it with gcc. (It might possibly be inefficient on the VAX, if its shift
instructions trap on overflow and therefore could not be used here - but
I know nothing of the ISA of the VAX. And of course "i <<= 1;" can be
implemented as "i = i + i;".)
However, I know I am not comfortably relying on behaviour that is so
poorly and vaguely documented - especially when the obvious fix is fully
defined and fully portable.
>
> clang tends to copy gcc, so it is most likely defined here too.
Clang is terrible here in regard to its documentation. It does not even
attempt document the implementation-defined behaviour, as required for C
standards compliance. (gcc is not great - many things just say they are
"according to the target ABI" rather than giving details.) So while I
agree that clang probably does what gcc does here, it's very far from
being defined and documented behaviour.
>
> It's unlikely that you will find text that defines it in MSVC docs, but
> it's even less likely that it will generate code with diffeerent
> semanatics from those of gcc.
>
Agreed on both counts.
The practical reality is that Mitch's code probably does what he wants
it to do, on any compiler and target. But it is still UB, and I don't
see good enough information in the gcc manual to consider it defined
behaviour - I would still flag it in a code review. And the fix of
changing to "unsigned int" is clear, simple, and unequivocally correct,
defined and portable. What's not to like?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-02 14:44 +0300 |
| Subject | Re: endian history |
| Message-ID | <20261002144444.00003c3d@yahoo.com> |
| In reply to | #118390 |
On Fri, 2 Oct 2026 12:57:17 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 02/10/2026 11:47, Michael S wrote:
> > On Fri, 2 Oct 2026 11:21:23 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 01/10/2026 21:55, MitchAlsup wrote:
> >>>
> >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> >>>
> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>>>>
> >>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>>>>
> >>>>>>>> With wrapping signed arithmetic, all of the semantics of
> >>>>>>>> unsigned arithmetic is the same, except for right shift and
> >>>>>>>> division operations.
> >>>>>>>
> >>>>>>> Also left shift
> >>>>>>
> >>>>>> No. The funny thing is that AMD64 has both SHL and SAL
> >>>>>> mnemonics, but they encode the same opcodes. E.g.:
> >>>>>>
> >>>>>> D3 /4 SAL r/m32, CL
> >>>>>> D3 /4 SHL r/m32, CL
> >>>>>
> >>>>> That may be true for AMD64. It is not true for other
> >>>>> two's complement architectures.
> >>>>
> >>>> Care to name one? In particular one with modulo (aka wrapping)
> >>>> arithmetic? IIRC VAX shifts are perverse, but they trap on
> >>>> overflow.
> >>>
> >>> Which means you cannot write::
> >>>
> >>> for( int i = 1; i; i<<=1 )
> >>> { ... }
> >>> // never gets here--traps instead.
> >>
> >> You can write it if you like - but it is UB on all platforms.
> >>
> >> Use "unsigned int" here. Then there is no problem.
> >>
> >
> > It is not UB if compiler defines the meaning.
>
> Of course. (Well, it is still UB in C - but it is fine to use if you
> know you are sticking to that one particular compiler that documents
> behaviour you want.)
>
> In this case, there are no advantages in using "int", regardless of
> what a compiler may or may not document.
>
> > AFAIK, it is defined for gcc, even in absence of special flags.
> > From the manual:
> > "The results of some bitwise operations on signed integers (C90
> > 6.3, C99 and C11 6.5, C23 6.5.1).
> >
> > Bitwise operators act on the representation of the value including
> > both the sign and value bits, where the sign bit is considered
> > immediately above the highest-value value bit. Signed ‘>>’ acts on
> > negative numbers by sign extension.
> >
>
> That bit is all about implementation-defined behaviour - things that
> the implementation is required to document. So far, so good - but
> not relevant to the case of left-shifting a signed integer value "x
> << e" when "x" is negative or when "x * 2^e" does not fit in the type
> of "x".
>
> > As an extension to the C language, GCC does not use the latitude
> > given in C99 and later to treat certain aspects of signed ‘<<’ as
> > undefined. However, -fsanitize=shift (and -fsanitize=undefined)
> > will diagnose such cases. They are also diagnosed where constant
> > expressions are required."
> >
> > I don't like the style of writing of the last paragraph, but the
> > meanaing seems to be that gcc defines 'i << e' to be the same as
> > '(int)((unsigned)i << e)'
>
> I think your interpretation here is the perhaps the most reasonable
> definition, but it is not what the text says here. It does not
> document the behaviour. Other plausible (but I think less likely)
> candidates would be giving an unspecified value, or treated it as you
> describe for non-negative x while leaving it undefined for negative x.
>
It seems that you are making mistake of reading the last paragraph as
separate from the previous one. The author meant the two be read
together.
Of course, it would be even better if gcc manual, and especially so
Chapter 4, was written by person with decent technical writing skills,
but even as it is it is relatively comprehensible.
BTW, apart from official GCC manual there is also "GNU C Language
Introduction and Reference Manual" written by RMS, which is in theory
a work in progress, but in practice he seems to lose interest 3-4 years
ago. RMS is actually a decent writer even if not very technical.
In that manual you can find the following sentence that looks
pretty unequivocal: "-1 << LOWBITS is a clever way to make an integer
whose LOWBITS lowest bits are all 0 and the rest are all 1."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-02 15:28 +0200 |
| Subject | Re: endian history |
| Message-ID | <119obic$245ls$1@dont-email.me> |
| In reply to | #118391 |
On 02/10/2026 13:44, Michael S wrote:
> On Fri, 2 Oct 2026 12:57:17 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 02/10/2026 11:47, Michael S wrote:
>>> On Fri, 2 Oct 2026 11:21:23 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>> On 01/10/2026 21:55, MitchAlsup wrote:
>>>>>
>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>>
>>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>>>
>>>>>>>>>> With wrapping signed arithmetic, all of the semantics of
>>>>>>>>>> unsigned arithmetic is the same, except for right shift and
>>>>>>>>>> division operations.
>>>>>>>>>
>>>>>>>>> Also left shift
>>>>>>>>
>>>>>>>> No. The funny thing is that AMD64 has both SHL and SAL
>>>>>>>> mnemonics, but they encode the same opcodes. E.g.:
>>>>>>>>
>>>>>>>> D3 /4 SAL r/m32, CL
>>>>>>>> D3 /4 SHL r/m32, CL
>>>>>>>
>>>>>>> That may be true for AMD64. It is not true for other
>>>>>>> two's complement architectures.
>>>>>>
>>>>>> Care to name one? In particular one with modulo (aka wrapping)
>>>>>> arithmetic? IIRC VAX shifts are perverse, but they trap on
>>>>>> overflow.
>>>>>
>>>>> Which means you cannot write::
>>>>>
>>>>> for( int i = 1; i; i<<=1 )
>>>>> { ... }
>>>>> // never gets here--traps instead.
>>>>
>>>> You can write it if you like - but it is UB on all platforms.
>>>>
>>>> Use "unsigned int" here. Then there is no problem.
>>>>
>>>
>>> It is not UB if compiler defines the meaning.
>>
>> Of course. (Well, it is still UB in C - but it is fine to use if you
>> know you are sticking to that one particular compiler that documents
>> behaviour you want.)
>>
>> In this case, there are no advantages in using "int", regardless of
>> what a compiler may or may not document.
>>
>>> AFAIK, it is defined for gcc, even in absence of special flags.
>>> From the manual:
>>> "The results of some bitwise operations on signed integers (C90
>>> 6.3, C99 and C11 6.5, C23 6.5.1).
>>>
>>> Bitwise operators act on the representation of the value including
>>> both the sign and value bits, where the sign bit is considered
>>> immediately above the highest-value value bit. Signed ‘>>’ acts on
>>> negative numbers by sign extension.
>>>
>>
>> That bit is all about implementation-defined behaviour - things that
>> the implementation is required to document. So far, so good - but
>> not relevant to the case of left-shifting a signed integer value "x
>> << e" when "x" is negative or when "x * 2^e" does not fit in the type
>> of "x".
>>
>>> As an extension to the C language, GCC does not use the latitude
>>> given in C99 and later to treat certain aspects of signed ‘<<’ as
>>> undefined. However, -fsanitize=shift (and -fsanitize=undefined)
>>> will diagnose such cases. They are also diagnosed where constant
>>> expressions are required."
>>>
>>> I don't like the style of writing of the last paragraph, but the
>>> meanaing seems to be that gcc defines 'i << e' to be the same as
>>> '(int)((unsigned)i << e)'
>>
>> I think your interpretation here is the perhaps the most reasonable
>> definition, but it is not what the text says here. It does not
>> document the behaviour. Other plausible (but I think less likely)
>> candidates would be giving an unspecified value, or treated it as you
>> describe for non-negative x while leaving it undefined for negative x.
>>
>
> It seems that you are making mistake of reading the last paragraph as
> separate from the previous one. The author meant the two be read
> together.
>
Perhaps.
My preference is not to guess what the author meant, but read what the
author says. If I /were/ to guess, my guess would agree with yours.
Maybe I am just too fussy.
> Of course, it would be even better if gcc manual, and especially so
> Chapter 4, was written by person with decent technical writing skills,
> but even as it is it is relatively comprehensible.
>
> BTW, apart from official GCC manual there is also "GNU C Language
> Introduction and Reference Manual" written by RMS, which is in theory
> a work in progress, but in practice he seems to lose interest 3-4 years
> ago. RMS is actually a decent writer even if not very technical.
> In that manual you can find the following sentence that looks
> pretty unequivocal: "-1 << LOWBITS is a clever way to make an integer
> whose LOWBITS lowest bits are all 0 and the rest are all 1."
>
You can also find it saying "-10 << 4" is equivalent to -10 * 2*2*2*2,
and that "For signed integers, the result of overflow in C is in
principle undefined, meaning that anything whatsoever could happen.
Therefore, C compilers can do optimizations that treat the overflow with
total unconcern." At best, you could argue that it claims a particular
behaviour for left shifts of negative signed integers that do not
overflow. (This would, again, match the actual GCC manual saying that
"/certain/ aspects of signed <<" would not be treated as UB.)
It is not an "official GCC manual". It is written by RMS and published
on the GNU site, but not on the GCC site. RMS started GNU (and I have
enormous respect for his accomplishments with GNU and open source in
general) and wrote the initial versions of GCC, but he has not been
active in GCC for a decades.
So that manual is inconsistent and written by someone who is perhaps
unfamiliar with the current state of the compiler he is referring to.
It does not, IMHO, add any weight to an interpretation of the GCC
documentation.
It is an understatement that this RMS manual is "not very technical".
I've only had a brief look, and there is plenty in it that I think is
bad. It has a random mixture of gcc extensions and standard C without
any explanation of the difference and rarely even a note that something
is an extension. It is woefully inadequate about talking about
undefined behaviour, and regularly implies that it is basically okay but
might cause you trouble when optimising. (It even goes as far as
suggesting that dereferencing random pointers is a good way to tell if
they point to unallocated memory, as long as you first set up a signal
handler for SIGSEGV!) It was released in 2023 but does not cover
anything beyond C99 except, bizarrely, _Static_assert(), and it does not
give any description about C standards. The list goes on.
To be fair, I would probably have complaints about any manual or guide
to C programming, and I have seen far worse. Maybe I just expect better
from such a "big name" as RMS. The writing itself is nice and clear,
however.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-03 05:29 -0700 |
| Subject | Re: endian history |
| Message-ID | <86qzi7m0g9.fsf@linuxsc.com> |
| In reply to | #118387 |
Michael S <already5chosen@yahoo.com> writes:
> On Fri, 2 Oct 2026 11:21:23 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 01/10/2026 21:55, MitchAlsup wrote:
[...]
>>> Which means you cannot write::
>>>
>>> for( int i = 1; i; i<<=1 )
>>> { ... }
>>> // never gets here--traps instead.
>>
>> You can write it if you like - but it is UB on all platforms.
>>
>> Use "unsigned int" here. Then there is no problem.
>
> It is not UB if compiler defines the meaning.
This isn't right. In the context of C, "undefined behavior" has
a specific meaning, defined by the ISO standard. If the standard
says a particular construct has undefined behavior, it still has
undefined behavior even if an implementation documents what the
concrete behavior would be. "Undefined behavior" does not mean
the concrete behavior is unpredictable; it means only that each
implementation is free to do as it chooses.
> AFAIK, it is defined for gcc, even in absence of special flags.
> From the manual:
>
> "The results of some bitwise operations on signed integers (C90
> 6.3, C99 and C11 6.5, C23 6.5.1).
>
> Bitwise operators act on the representation of the value including
> both the sign and value bits, where the sign bit is considered
> immediately above the highest-value value bit. Signed >> acts
> on negative numbers by sign extension.
>
> As an extension to the C language, GCC does not use the latitude
> given in C99 and later to treat certain aspects of signed << as
> undefined. However, -fsanitize=shift (and -fsanitize=undefined)
> will diagnose such cases. They are also diagnosed where constant
> expressions are required."
It looks like the gcc documentation is making the same mistake of
interpreting "undefined behavior" as meaning "unpredictable
behavior". In fact gcc IS taking advantage of signed << having
undefined behavior in certain cases, to implement a particular
concrete behavior in those cases.
> I don't like the style of writing of the last paragraph, but the
> meanaing seems to be that gcc defines 'i << e' to be the same as
> '(int)((unsigned)i << e)'
The gcc writing is informal rather than being technically precise.
That might be a better choice considering the expected audience.
That said, I think a more faithful interpretation of what the
documentation says, assuming that a type definition
typedef union { signed int si; unsigned int ui; } SIUI;
has been done, is that 'i << e' is taken to mean
(SIUI){ .ui = (SIUI){ .si = i }.ui << e }.si
so as to act on representations rather than having to deal with the
uncertainties of inter-type conversions.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-01 13:12 -0400 |
| Subject | Re: endian history |
| Message-ID | <ZvwvS.52$IrH6.43@fx05.iad> |
| In reply to | #118354 |
On 2026-Oct-01 11:20, Anton Ertl wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> With wrapping signed arithmetic, all of the semantics of unsigned >>> arithmetic is the same, except for right shift and division >>> operations. >> >> Also left shift > > No. The funny thing is that AMD64 has both SHL and SAL mnemonics, but > they encode the same opcodes. E.g.: > > D3 /4 SAL r/m32, CL > D3 /4 SHL r/m32, CL > > - anton x64 SAL/SHL sets the overflow flag if the sign changes but only for 1 bit shifts. VAX only had ASHL (32 bit) and ASHQ (64 bit). A positive count shifted left and zero filled the lsb's, a negative count shifted right and sign filled the msb's. On left shift the overflow status flag is set if any bits shifted out were different from the final sign bit. If overflow flag set and the PSW trap-on-overflow flag was enabled then an overflow exception was raised. This is probably why C defines (int) << as Undefined Behavior. VAX had no equivalent to x86 Shift Logical Right but a bit field extract with zero fill EXTZV would accomplish the same result. I would have separate shift instructions for logical, arithmetic and numeric shift left and right. Shift Numeric Left faults on signed overflow, and Shift Numeric Right rounds toward 0 so -1 SNR 1 => 0 and they can be used as replacements for signed integer multiple and divide.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-01 17:41 +0000 |
| Subject | Re: endian history |
| Message-ID | <2026Oct1.194121@mips.complang.tuwien.ac.at> |
| In reply to | #118362 |
EricP <ThatWouldBeTelling@thevillage.com> writes:
>On 2026-Oct-01 11:20, Anton Ertl wrote:
>x64 SAL/SHL sets the overflow flag if the sign changes
>but only for 1 bit shifts.
According to <https://www.felixcloutier.com/x86/sal:sar:shl:shr>:
ELSE (* COUNT not 1 or 0 *)
OF := undefined;
Oh boy.
>I would have separate shift instructions for logical,
>arithmetic and numeric shift left and right.
Separate left and right is mainstream. For right, signed (arithmetic)
and unsigned (locgical).
>Shift Numeric Left faults on signed overflow,
It will live the life of MIPS add and Alpha addv:-)
>and Shift Numeric Right rounds toward 0
>so -1 SNR 1 => 0 and they can be used as replacements
>for signed integer multiple and divide.
Certainly is useful for the C99 definition of division.
The Forth standard still sits on the fence. Gforth does:
-1 2 / . \ output: -1
-1 1 arshift . \ output: -1
If you want symmetric division, use
-1 2 /s . \ output: 0
- 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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-01 18:07 -0500 |
| Subject | Re: endian history |
| Message-ID | <119mp4m$1jsgb$1@dont-email.me> |
| In reply to | #118363 |
On 10/1/2026 12:41 PM, Anton Ertl wrote: > EricP <ThatWouldBeTelling@thevillage.com> writes: >> On 2026-Oct-01 11:20, Anton Ertl wrote: >> x64 SAL/SHL sets the overflow flag if the sign changes >> but only for 1 bit shifts. > > According to <https://www.felixcloutier.com/x86/sal:sar:shl:shr>: > > ELSE (* COUNT not 1 or 0 *) > OF := undefined; > > Oh boy. > >> I would have separate shift instructions for logical, >> arithmetic and numeric shift left and right. > > Separate left and right is mainstream. For right, signed (arithmetic) > and unsigned (locgical). > >> Shift Numeric Left faults on signed overflow, > > It will live the life of MIPS add and Alpha addv:-) > Pretty much no one does this... Also for some cases, the non-trapping left-shift is needed a lot more often than a trapping left shift would be. Seems like a sort of preoccupation where people worry about unexpected overflows being a problem where one hasn't provisioned for having a value type large enough; where in practice it is more common to have storage types that are excessively large relative to the actual range of values they need to hold. Though, if someone wanted to be pedantic, they could instead define some policy that "general use arithmetic" numeric types be at least twice the size of that needed to hold the expected value range. Could almost work, except that 64-bit range types would need 128-bit integers, which some compilers (cough, MSVC) still fail to provide. One could argue that "general arithmetic" (or, not fixed point or bit manipulation) is typically much less likely to go outside of 32-bit range anyways. Some people would probably try to argue that the signed/unsigned distinction is also the arithmetic / bit-manipulation distinction, but in practice it tends to be much less clear cut IME. >> and Shift Numeric Right rounds toward 0 >> so -1 SNR 1 => 0 and they can be used as replacements >> for signed integer multiple and divide. > > Certainly is useful for the C99 definition of division. > I guess could maybe save something over essentially turning: y=x/(1<<N); Into: y=(x+((x&(1<<(N-1))&(x>>63)))>>N); Where N is constant. But, trap on overflow or rounding towards zero would add a bit of hardware cost for what are effectively obscure edge cases (well, since probably most people will already know to turn x/C into x>>N when they know x is positive and/or don't care which direction it rounds). Well, even if sometimes it may escape notice, say in RCT: Y=(2*G+R+B)/4; Actually needs to be: Y=(2*G+R+B)>>2; But, is traditionally written as the former even when the latter is needed, both for speed, or the (even more obscure) edge case of reversibility in the face out-of-gamut colors. Though, usually need for reversibility and out-of-gamut colors don't exist at the same time. Well, and for the same reason why: A=(X+Y)/2; B=X-Y; And: A=(X+Y)>>1; B=X-Y; Are not exactly the same. But, I think it may be a case of visual preference for why one may write the former when, practically, they may actually need to use the latter for the correct semantics. Where: Y=A-(B>>1); X=Y+B; Failing to give X/Y back exactly if one had actually used "/2" here... > The Forth standard still sits on the fence. Gforth does: > > -1 2 / . \ output: -1 > -1 1 arshift . \ output: -1 > > If you want symmetric division, use > > -1 2 /s . \ output: 0 > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-02 02:44 +0000 |
| Subject | Re: endian history |
| Message-ID | <119n5qq$1ni9u$4@dont-email.me> |
| In reply to | #118371 |
On Thu, 1 Oct 2026 18:07:59 -0500, BGB wrote: > Some people would probably try to argue that the signed/unsigned > distinction is also the arithmetic / bit-manipulation distinction, > but in practice it tends to be much less clear cut IME. Arithmetic uses of integers could be signed or unsigned. I think the unsigned uses might be more to do with e.g. hash computations, encryption, that kind of thing. For bitfield manipulation, I can’t understand why you would want sign extension -- or at least, automatic sign extension. Much easier to insert/extract fields with unsigned operations. If a field is to be interpreted as a signed value, you should have to explicitly extend the sign bit after extraction (and perhaps also verify that the bits being thrown away are all 0s or all 1s before insertion). Much less error-prone that way.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-01 22:06 -0500 |
| Subject | Re: endian history |
| Message-ID | <119n743$1o4a6$1@dont-email.me> |
| In reply to | #118376 |
On 10/1/2026 9:44 PM, Lawrence D’Oliveiro wrote: > On Thu, 1 Oct 2026 18:07:59 -0500, BGB wrote: > >> Some people would probably try to argue that the signed/unsigned >> distinction is also the arithmetic / bit-manipulation distinction, >> but in practice it tends to be much less clear cut IME. > > Arithmetic uses of integers could be signed or unsigned. I think the > unsigned uses might be more to do with e.g. hash computations, > encryption, that kind of thing. > > For bitfield manipulation, I can’t understand why you would want sign > extension -- or at least, automatic sign extension. Much easier to > insert/extract fields with unsigned operations. If a field is to be > interpreted as a signed value, you should have to explicitly extend > the sign bit after extraction (and perhaps also verify that the bits > being thrown away are all 0s or all 1s before insertion). Much less > error-prone that way. Not just bitfields, but bit manipulation in general. Consider zigzag sign folding: uval=(val<<1)^(val>>63); sval=(uval>>1)^(((s64)(uval<<63))>>63); This sort of thing depends on using signed values in ways that don't align well with traditional assumptions about signed integer arithmetic, but are none the less useful. But, this is just one thing among many. ...
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-02 18:05 +0000 |
| Subject | Re: endian history |
| Message-ID | <1790964310-5857@newsgrouper.org> |
| In reply to | #118376 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted: > On Thu, 1 Oct 2026 18:07:59 -0500, BGB wrote: > > > Some people would probably try to argue that the signed/unsigned > > distinction is also the arithmetic / bit-manipulation distinction, > > but in practice it tends to be much less clear cut IME. > > Arithmetic uses of integers could be signed or unsigned. I think the > unsigned uses might be more to do with e.g. hash computations, > encryption, that kind of thing. > > For bitfield manipulation, I can’t understand why you would want sign > extension -- or at least, automatic sign extension. Much easier to > insert/extract fields with unsigned operations. The left shift is unsigned (no overflow), the right shift can be signed for signed bit-fields (seldom) or unsigned for unsigned fields (mostly). And in HW that does the extract in one operation, the addition of signed is a small number of gates (3rd input to a 2-way mux). > If a field is to be > interpreted as a signed value, you should have to explicitly extend > the sign bit after extraction (and perhaps also verify that the bits > being thrown away are all 0s or all 1s before insertion). Much less > error-prone that way.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-02 18:00 +0000 |
| Subject | Re: endian history |
| Message-ID | <1790964051-5857@newsgrouper.org> |
| In reply to | #118371 |
BGB <cr88192@gmail.com> posted:
> On 10/1/2026 12:41 PM, Anton Ertl wrote:
> > EricP <ThatWouldBeTelling@thevillage.com> writes:
> >> On 2026-Oct-01 11:20, Anton Ertl wrote:
> >> x64 SAL/SHL sets the overflow flag if the sign changes
> >> but only for 1 bit shifts.
> >
> > According to <https://www.felixcloutier.com/x86/sal:sar:shl:shr>:
> >
> > ELSE (* COUNT not 1 or 0 *)
> > OF := undefined;
> >
> > Oh boy.
> >
> >> I would have separate shift instructions for logical,
> >> arithmetic and numeric shift left and right.
> >
> > Separate left and right is mainstream. For right, signed (arithmetic)
> > and unsigned (locgical).
> >
> >> Shift Numeric Left faults on signed overflow,
> >
> > It will live the life of MIPS add and Alpha addv:-)
> >
>
> Pretty much no one does this...
>
> Also for some cases, the non-trapping left-shift is needed a lot more
> often than a trapping left shift would be.
Consider using shift instruction to isolate a field within a register::
field = ((register << 64-offset-width ) >> 64-offset);
Nobody would want the left shift to overflow even when the field is signed.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-02 13:51 -0500 |
| Subject | Re: endian history |
| Message-ID | <119oug6$2cfe7$1@dont-email.me> |
| In reply to | #118395 |
On 10/2/2026 1:00 PM, MitchAlsup wrote: > > BGB <cr88192@gmail.com> posted: > >> On 10/1/2026 12:41 PM, Anton Ertl wrote: >>> EricP <ThatWouldBeTelling@thevillage.com> writes: >>>> On 2026-Oct-01 11:20, Anton Ertl wrote: >>>> x64 SAL/SHL sets the overflow flag if the sign changes >>>> but only for 1 bit shifts. >>> >>> According to <https://www.felixcloutier.com/x86/sal:sar:shl:shr>: >>> >>> ELSE (* COUNT not 1 or 0 *) >>> OF := undefined; >>> >>> Oh boy. >>> >>>> I would have separate shift instructions for logical, >>>> arithmetic and numeric shift left and right. >>> >>> Separate left and right is mainstream. For right, signed (arithmetic) >>> and unsigned (locgical). >>> >>>> Shift Numeric Left faults on signed overflow, >>> >>> It will live the life of MIPS add and Alpha addv:-) >>> >> >> Pretty much no one does this... >> >> Also for some cases, the non-trapping left-shift is needed a lot more >> often than a trapping left shift would be. > > Consider using shift instruction to isolate a field within a register:: > > field = ((register << 64-offset-width ) >> 64-offset); > > Nobody would want the left shift to overflow even when the field is signed. > Well, nobody would want it to trap. The bits that go off the end, they are gone, such is the nature of shift. ...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-03 14:14 +0000 |
| Subject | Re: endian history |
| Message-ID | <_48wS.2385$w7wb.830@fx17.iad> |
| In reply to | #118395 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>BGB <cr88192@gmail.com> posted:
>
>> On 10/1/2026 12:41 PM, Anton Ertl wrote:
>> > EricP <ThatWouldBeTelling@thevillage.com> writes:
>> >> On 2026-Oct-01 11:20, Anton Ertl wrote:
>> >> x64 SAL/SHL sets the overflow flag if the sign changes
>> >> but only for 1 bit shifts.
>> >
>> > According to <https://www.felixcloutier.com/x86/sal:sar:shl:shr>:
>> >
>> > ELSE (* COUNT not 1 or 0 *)
>> > OF := undefined;
>> >
>> > Oh boy.
>> >
>> >> I would have separate shift instructions for logical,
>> >> arithmetic and numeric shift left and right.
>> >
>> > Separate left and right is mainstream. For right, signed (arithmetic)
>> > and unsigned (locgical).
>> >
>> >> Shift Numeric Left faults on signed overflow,
>> >
>> > It will live the life of MIPS add and Alpha addv:-)
>> >
>>
>> Pretty much no one does this...
>>
>> Also for some cases, the non-trapping left-shift is needed a lot more
>> often than a trapping left shift would be.
>
>Consider using shift instruction to isolate a field within a register::
>
> field = ((register << 64-offset-width ) >> 64-offset);
IME, shift-right and mask are the normal operations used to
isolate a field within a register.
template<class T> static inline T extract(T input, size_t stop_bit, size_t start_bit)
{
input >>= start_bit;
input &= maskT<T>(stop_bit - start_bit + 1);
return input;
}
[toc] | [prev] | [next] | [standalone]
Page 20 of 30 — ← Prev page 1 … 18 19 [20] 21 22 … 30 Next page →
Back to top | Article view | comp.arch
csiph-web