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 19 of 30 — ← Prev page 1 … 17 18 [19] 20 21 … 30 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-02 11:11 +0200 |
| Subject | Re: endian history |
| Message-ID | <119nsgn$1rmn1$4@dont-email.me> |
| In reply to | #118370 |
On 01/10/2026 23:53, Lawrence D’Oliveiro wrote: > On Thu, 01 Oct 2026 10:44:32 +0000, aph wrote: > >> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>> >>> But now you see why other programming languages keep the unsigned >>> integers. It just saves a certain amount of irritation and >>> occasional outright pain. >> >> Some languages do, some don't. > > Apart from Java, who else was that stupid? Most versions of BASIC, as far as I am aware. I think Lua only has one integer type, a 64-bit signed integer. > > Python avoids the problem by incorporating arbitrary-precision > integers. So you can deal with them as signed or unsigned, that’s up > to you. > >> In C, there are *three* byte types. I'm not aware of any language >> not derived from C which does that. Whatever you do with bytes, >> someone will make mistakes because it's not what they expect. The key mistake, IME, is that some people write code assuming "char" in C is a signed integer type. A few write code that assumes it is an unsigned integer type, but I think that is a lot rarer. Whether it is signed or unsigned is implementation-dependent. > > stdint.h defines int8_t which is signed, and uint8_t which is > unsigned. Similarly for other sizes. Also some “least” types, I think > for compatibility with platforms where things don’t break down cleanly > into exact multiples of 8-bit bytes. C only has one "byte" type - "unsigned char". (C++ adds "std::byte".) In C, a "byte" is defined as "addressable unit of data storage large enough to hold any member of the basic character set", and it is of width CHAR_BIT bits. CHAR_BIT must be at least 8, but can be bigger - on some DSP processors, for example, you might have 16-bit, 24-bit or 32-bit bytes. It has three standard integer types whose size is always 1 "byte" - char, signed char and unsigned char. Only "unsigned char" is guaranteed not to have any padding, and therefore work for accessing "raw" memory. "char" must have the same range, representation and behaviour as either "signed char" or "unsigned char", but it is still a separate type. It has a large number of typedef types defined in the standard library headers that contain the number 8, and are 8-bit on most systems. The only ones that are actually guaranteed to be 8 bits are "uint8_t" and "int8_t" - and those are not guaranteed to exist. (On a CHAR_BIT==16 DSP, for example, they would not exist.) For all the others - char8_t, [u]int_least8_t, [u]int_fast8_t, atomic_[u]int_least8_t, atomic_[u]int_fast8_t, atomic_char8_t - 8 bits is just the minimum size. These names are all typedefs of existing types (usually signed char, unsigned char, or their _Atomic versions - but they could also be implementation-specific extended integer types). And there is now also _BitInt(8) and unsigned _BitInt(8). > > The point is, you use the right one for the job, you know what it does, > no possibility of confusion, end of story. You /should/ do that - but it is not that simple. If you are doing arithmetic on a small number, the types "int8_t" and "uint8_t" often make more sense than "signed char" and "unsigned char", simply because they are named as integer types rather than having a name that suggests character data. But they are not as portable, unless being exactly 8 bits is a requirement. So "[u]int_least8_t" is a better choice for storing small data (such as in an array, where you want to minimise size to maximise cache hit ratio) while "[u]int_fast8_t" is a better choice for local variables and calculations. But those are both undeniably ugly. There are many factors that affect the final "best" choice. Character data is best kept in "char" if it is ASCII, and "char8_t" arrays if it is UTF-8. But the later is only for C23 - prior to that, "unsigned char" array would usually be the best choice. C has a whole lot of character and integer types that are optimised for different purposes, with different trade-offs. Different programs use different subsets of them. The one thing to avoid is unwarranted assumptions that don't match reality - or at least, that don't cause compile-time hard failures if they turn out to be wrong. For example, I think it's fine to use "uint8_t" and assume it exists - it does on most platforms, and if anyone uses your code on an TMS320 or SHARC, they get a compile-time failure rather than silent bad code. And if your code is specific to modern *nix or Windows, then it's fine to assume "int" is at least 32-bit. But for more portable code, or code that is likely to be used by others, don't make assumptions beyond the guarantees of the language. And specifically don't write code that assumes "char" is signed!
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-02 16:17 -0500 |
| Subject | Re: endian history |
| Message-ID | <119p71c$2fqm0$1@dont-email.me> |
| In reply to | #118385 |
On 10/2/2026 4:11 AM, David Brown wrote:
> On 01/10/2026 23:53, Lawrence D’Oliveiro wrote:
>> On Thu, 01 Oct 2026 10:44:32 +0000, aph wrote:
>>
>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> But now you see why other programming languages keep the unsigned
>>>> integers. It just saves a certain amount of irritation and
>>>> occasional outright pain.
>>>
>>> Some languages do, some don't.
>>
>> Apart from Java, who else was that stupid?
>
> Most versions of BASIC, as far as I am aware.
>
> I think Lua only has one integer type, a 64-bit signed integer.
>
This sort of thing is common in many of these types of HLLs.
Many provide signed-only, or variable sizes of signed-only types, rather
than explicit unsigned types.
So, if you are working on a theoretically unsigned 64-bit value inside a
128-bit boxed integer or similar, this is assumed to not really matter
(general interpreter overhead being large enough to outweigh the
relative inefficiency of using an oversized boxed value).
Depends on the VM, but in many of mine, the dynamic "fixnum" range is
signed 62 bit (with the high 2 bits cut off for the type-tag).
This actually happened in my case before fully making the 64-bit
transition, as (at the time) I had realized that the theoretical
overhead of 64-bit tag-refs on a 32-bit machine was less than the
overhead and drawback of trying to deal with 30-bit fixnum and similar.
Where, in this case 62-bit fixnum can represent the full range of 32-bit
integers. Also 62-bit flonum was much less bad than (at the time) a
28-bit flonum (doesn't take much before the limitations of a 19 bit
mantissa became evident).
Say:
(31:2): Address/Data
( 1:0): Top level Tag
00: Object Pointer
01: Fixnum
10: CONS
11: Misc (Small Values, Flonum)
Also, going to a 64-bit tagref allows the optimization of being able to
stash the object's type type in the HOBs, rather than needing to access
memory and look at an object header to be like "What type of object is
this?..."
If done well, 64-bit MSB tagging can be less annoying than LSB tagging
as well.
...
>>
>> Python avoids the problem by incorporating arbitrary-precision
>> integers. So you can deal with them as signed or unsigned, that’s up
>> to you.
>>
>>> In C, there are *three* byte types. I'm not aware of any language
>>> not derived from C which does that. Whatever you do with bytes,
>>> someone will make mistakes because it's not what they expect.
>
> The key mistake, IME, is that some people write code assuming "char" in
> C is a signed integer type. A few write code that assumes it is an
> unsigned integer type, but I think that is a lot rarer. Whether it is
> signed or unsigned is implementation-dependent.
>
The original code releases for Doom and friends (also Heretic and Hexen)
also fall into this trap, but it isn't a hard fix.
The most obvious symptom of this bug is when one builds for ARM and then
they can find that the player can only turn right and run forwards.
Trying to turn left or move backwards merely causes them to turn right
or move forwards but at a much higher speed.
I think it is a fairly trivial fix located in "doomdef.h" / "h2def.h",
but I forget now.
Still better than ROTT:
Slaps hood: "You don't know how many bugs this code contains!"
Well, out-of-bounds accesses all over the place, uninitialized
variables, etc.
Well, and gray areas: Code that is overly particular to the relative
over of implicit truncation in integer operations that promote to a
wider type:
Depends on truncate-first then promote ordering, breaks on early
promotion to the wider type (before applying the operator).
Say (general idea):
long z;
int x, y;
...
z=x+y; //overflows
...
//Some code that uses 'z' and assumes it is still 32-bit.
//And that the addition resulted in wrapping behavior.
Granted, this code was written for a target where long was 32 bit.
Had to verify with several other compilers that the correct behavior was
necessarily to generate an overflowed/wrapped result rather than quietly
"early promote" to 64 bits (which is what BGBCC had done initially,
noting as how on the target in question; "int" is a strict subset of
"long", *1).
*1: It keeps 'int' in a form where it is sign-extended to 64 bits, and
'unsigned int' as always zero-extended (even on RV64G; it was IMO less
bad to zero-extend ADD and similar on 'unsigned int' than to deal with
the mess that is "sign-extended unsigned int").
Well, along with the variation that scalar floating point types are
always Binary64 in registers (with smaller types used exclusively for
memory or SIMD operations).
Though, does sort of mean that things like:
float f, g;
*(int *)(&f)=0x3FEEDBAD;
g=sqrt(f);
Do sort of need to special case being 32-bit in memory (normally, BGBCC
operates under a "if no one looks, they can't see it isn't 32 bits"
approach).
Does penalize the variable though, since if it can't trivially verify
the scope of the '&f', it may need to load 'f' from memory and spill
whenever it is used (and spill 'f' whenever certain operations occur).
This applies generally to taking the addresses of local variables, but
is arguably worse for "float".
IIRC, did add a special case where, say:
float *pu, *pv;
...
pu[3]=pv[1]; //general pattern, not these specific indices
Will perform a direct 32-bit load and store, rather than:
Load; Convert to double; Convert back to single; Store.
But, this was more because this sort of pattern is common in Quake and
similar.
...
>>
>> stdint.h defines int8_t which is signed, and uint8_t which is
>> unsigned. Similarly for other sizes. Also some “least” types, I think
>> for compatibility with platforms where things don’t break down cleanly
>> into exact multiples of 8-bit bytes.
>
> C only has one "byte" type - "unsigned char". (C++ adds "std::byte".)
> In C, a "byte" is defined as "addressable unit of data storage large
> enough to hold any member of the basic character set", and it is of
> width CHAR_BIT bits. CHAR_BIT must be at least 8, but can be bigger -
> on some DSP processors, for example, you might have 16-bit, 24-bit or
> 32-bit bytes.
>
> It has three standard integer types whose size is always 1 "byte" -
> char, signed char and unsigned char. Only "unsigned char" is guaranteed
> not to have any padding, and therefore work for accessing "raw" memory.
> "char" must have the same range, representation and behaviour as either
> "signed char" or "unsigned char", but it is still a separate type.
>
> It has a large number of typedef types defined in the standard library
> headers that contain the number 8, and are 8-bit on most systems. The
> only ones that are actually guaranteed to be 8 bits are "uint8_t" and
> "int8_t" - and those are not guaranteed to exist. (On a CHAR_BIT==16
> DSP, for example, they would not exist.) For all the others - char8_t,
> [u]int_least8_t, [u]int_fast8_t, atomic_[u]int_least8_t,
> atomic_[u]int_fast8_t, atomic_char8_t - 8 bits is just the minimum size.
>
> These names are all typedefs of existing types (usually signed char,
> unsigned char, or their _Atomic versions - but they could also be
> implementation-specific extended integer types).
>
>
> And there is now also _BitInt(8) and unsigned _BitInt(8).
>
>>
>> The point is, you use the right one for the job, you know what it does,
>> no possibility of confusion, end of story.
>
> You /should/ do that - but it is not that simple.
>
> If you are doing arithmetic on a small number, the types "int8_t" and
> "uint8_t" often make more sense than "signed char" and "unsigned char",
> simply because they are named as integer types rather than having a name
> that suggests character data. But they are not as portable, unless
> being exactly 8 bits is a requirement. So "[u]int_least8_t" is a better
> choice for storing small data (such as in an array, where you want to
> minimise size to maximise cache hit ratio) while "[u]int_fast8_t" is a
> better choice for local variables and calculations. But those are both
> undeniably ugly. There are many factors that affect the final "best"
> choice.
>
> Character data is best kept in "char" if it is ASCII, and "char8_t"
> arrays if it is UTF-8. But the later is only for C23 - prior to that,
> "unsigned char" array would usually be the best choice.
>
> C has a whole lot of character and integer types that are optimised for
> different purposes, with different trade-offs. Different programs use
> different subsets of them.
>
> The one thing to avoid is unwarranted assumptions that don't match
> reality - or at least, that don't cause compile-time hard failures if
> they turn out to be wrong. For example, I think it's fine to use
> "uint8_t" and assume it exists - it does on most platforms, and if
> anyone uses your code on an TMS320 or SHARC, they get a compile-time
> failure rather than silent bad code. And if your code is specific to
> modern *nix or Windows, then it's fine to assume "int" is at least 32-
> bit. But for more portable code, or code that is likely to be used by
> others, don't make assumptions beyond the guarantees of the language.
>
> And specifically don't write code that assumes "char" is signed!
>
[toc] | [prev] | [next] | [standalone]
| From | aph@littlepinkcloud.invalid |
|---|---|
| Date | 2026-10-02 14:25 +0000 |
| Subject | Re: endian history |
| Message-ID | <tI2dnWL31KxKIyL3nZ2dnZfqn_ednZ2d@supernews.com> |
| In reply to | #118370 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Thu, 01 Oct 2026 10:44:32 +0000, aph wrote: > >> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>> >>> But now you see why other programming languages keep the unsigned >>> integers. It just saves a certain amount of irritation and >>> occasional outright pain. >> >> Some languages do, some don't. > > Apart from Java, who else was that stupid? Python, Javascript, PHP, ... >> In C, there are *three* byte types. I'm not aware of any language >> not derived from C which does that. Whatever you do with bytes, >> someone will make mistakes because it's not what they expect. > >> I guess the java compiler itself could have done the masking, but >> the question is whether it was worth complexifying the language by >> replicating C's zoo of numeric types. > > You say that with a straight face How do you know? :-P > ... yet the Java language manual (just the core language, not even > any of the standard classes, like those in java.lang) is already > getting close to 900 pages, not far short of the complexity of C++ > already. Even the latest C-language spec, including standard > library, is not much more than half that. And adding more numeric types would have made it more complicated, obvs. The idea of Java was to have a high-level portable object-oriented language with classes, interfaces, exceptions, and threads. Every programming language is a compromise of some kind. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-02 16:46 -0500 |
| Subject | Re: endian history |
| Message-ID | <119p8nc$2fqm0$2@dont-email.me> |
| In reply to | #118393 |
On 10/2/2026 9:25 AM, aph@littlepinkcloud.invalid wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> On Thu, 01 Oct 2026 10:44:32 +0000, aph wrote: >> >>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>>> >>>> But now you see why other programming languages keep the unsigned >>>> integers. It just saves a certain amount of irritation and >>>> occasional outright pain. >>> >>> Some languages do, some don't. >> >> Apart from Java, who else was that stupid? > > Python, Javascript, PHP, ... > >>> In C, there are *three* byte types. I'm not aware of any language >>> not derived from C which does that. Whatever you do with bytes, >>> someone will make mistakes because it's not what they expect. >> >>> I guess the java compiler itself could have done the masking, but >>> the question is whether it was worth complexifying the language by >>> replicating C's zoo of numeric types. >> >> You say that with a straight face > > How do you know? :-P > >> ... yet the Java language manual (just the core language, not even >> any of the standard classes, like those in java.lang) is already >> getting close to 900 pages, not far short of the complexity of C++ >> already. Even the latest C-language spec, including standard >> library, is not much more than half that. > > And adding more numeric types would have made it more complicated, > obvs. The idea of Java was to have a high-level portable > object-oriented language with classes, interfaces, exceptions, and > threads. Every programming language is a compromise of some kind. > Ironically, despite multi-core CPUs, I infrequently use multi-threading, as I have usually found it preferable to try to make the single-threaded code "fast enough" rather than deal with the hassles of multithreading. As for me, I disagree with the dumbing down of the integer types and similar. Do agree with Java in a few areas though: Making all signed integer math modulo and with consistent rules made sense; The class/interface system and general approach to exceptions (*1) made sense (and a slight improvement over the C++ approach here). Where, in the case of C++, there is needless complexity due to MI, and then they just sort of pile on more needless complexity trying to work around the previous needless complexity. Single inheritance with interfaces is a reasonably clean and effective solution to that particular mess. OTOH: Java's handling of packages and "one class per file" were needless pain IMO. Though, it was nice in a way to have a compiler with the cleverness to locate what code it needed to pull in without having to list everything in a Makefile... Though, you can sorta do something vaguely similar in C via "unity builds" (just including other C files and treating them sorta like headers), which is generally faster and gives better results on modern targets (partly compensating for the sometimes excessive bloat of OS headers; it being slow to compile stuff if one pulls in 1M lines of random header stuff for every 1k lines of code). *1: Both approaches still carrying the unavoidable drawback that exceptions generally add global non-zero cost (such as exception metadata tables and typical necessity of dummy handlers to deal with unwinding even for functions that don't actually need any cleanup on unwind; just because otherwise stuff is SOL if an exception is thrown and it happens to come this way). > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-03 02:43 +0000 |
| Subject | Re: endian history |
| Message-ID | <119pq4f$2l2ql$3@dont-email.me> |
| In reply to | #118405 |
On Fri, 2 Oct 2026 16:46:12 -0500, BGB wrote: > Ironically, despite multi-core CPUs, I infrequently use > multi-threading, as I have usually found it preferable to try to > make the single-threaded code "fast enough" rather than deal with > the hassles of multithreading. This is very common. It’s why coroutines have made a comeback, in the form of async/await constructs (pioneered by Microsoft, to give them credit). When the bottleneck is not the CPU, multithreading buys you little or nothing apart from complexity. > Do agree with Java in a few areas though: Making all signed integer > math modulo and with consistent rules made sense; The > class/interface system and general approach to exceptions (*1) made > sense (and a slight improvement over the C++ approach here). Like a lot of things in C++, the multiple-inheritance system was prone to (unpleasantly) surprising behaviour. So it’s no surprise the Java folks saw fit to try to compromise, inventing the “interface” system as their approach to “multiple inheritance lite”, a.k.a. “every superclass except one must be an abstract base class”, to try to keep things under control. But then the Dylan folks invented C3 linearization, which turned out to be quite a reasonable way to implement multiple inheritance with minimum surprises. So this was adopted for the class mechanism in Python, for example <https://python-history.blogspot.com/2010/06/method-resolution-order.html>. And so Python gets to do clever stuff like use multiple inheritance to implement its enum types. > OTOH: > Java's handling of packages and "one class per file" were needless > pain IMO. I’ve done multiple top-level class definitions per file. I think you’re only allowed one “public” top-level class definition, though. One thing I soon discovered was that there was no need to create endless hierarchies of subdirectories to reflect the package namespace hierarchy. You could group your source files more rationally than that, and the project would still build just fine. ;)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-03 00:54 -0500 |
| Subject | Re: endian history |
| Message-ID | <119q5ag$2oidh$1@dont-email.me> |
| In reply to | #118411 |
On 10/2/2026 9:43 PM, Lawrence D’Oliveiro wrote:
> On Fri, 2 Oct 2026 16:46:12 -0500, BGB wrote:
>
>> Ironically, despite multi-core CPUs, I infrequently use
>> multi-threading, as I have usually found it preferable to try to
>> make the single-threaded code "fast enough" rather than deal with
>> the hassles of multithreading.
>
> This is very common. It’s why coroutines have made a comeback, in the
> form of async/await constructs (pioneered by Microsoft, to give them
> credit). When the bottleneck is not the CPU, multithreading buys you
> little or nothing apart from complexity.
>
There are relatively few things that are meaningfully CPU bound at present.
There is slow / inefficient coding, but the better fix is usually to
optimize the code, not to use threads.
There are some tasks that could be made faster with threads, like
running genetic algorithms or training neural nets, but I prefer not to
bog down my PC in the name of faster NN training (so, this sort of thing
more often ends up as a long-running "slow-burn").
Though, I think part of the issue sometimes is that many people write
code that is sometimes horribly inefficient and then blame the hardware
for not being faster, rather than their code for being inefficient or
their approach for being wrong.
Well, and the recent rise of "vibe coding" doesn't really help. But, now
you have "programmers" who don't even know how the program is supposed
to work, just yelling at their AI agents to fix the bugs.
Well, and then crying on social media about how they burnt through their
token budget for that month and they now need $k to get more tokens (I
guess the sentiment is something like the base plans give a certain
token budget per-month, but then to exceed this requires paying a fair
bit more).
Ironically, I don't really know.
In the stuff I interact with, haven't really gone beyond free tier; nor
seen much reason to pay. Sometimes feedback on things is nice, but
otherwise I can write my own code for free...
>> Do agree with Java in a few areas though: Making all signed integer
>> math modulo and with consistent rules made sense; The
>> class/interface system and general approach to exceptions (*1) made
>> sense (and a slight improvement over the C++ approach here).
>
> Like a lot of things in C++, the multiple-inheritance system was prone
> to (unpleasantly) surprising behaviour. So it’s no surprise the Java
> folks saw fit to try to compromise, inventing the “interface” system
> as their approach to “multiple inheritance lite”, a.k.a. “every
> superclass except one must be an abstract base class”, to try to keep
> things under control.
>
> But then the Dylan folks invented C3 linearization, which turned out
> to be quite a reasonable way to implement multiple inheritance with
> minimum surprises. So this was adopted for the class mechanism in
> Python, for example
> <https://python-history.blogspot.com/2010/06/method-resolution-order.html>.
> And so Python gets to do clever stuff like use multiple inheritance to
> implement its enum types.
>
But, isn't really compatible with the "just append stuff onto the end of
the parent class".
The Java model can be implemented in terms of this property:
Every child class can have its members glued onto the end of the parent;
Or, new methods glued onto the end;
Interfaces either add nothing, or just have their contents glued on
implicitly.
The C++ model works in terms of append, but diamond inheritance creates
a mess here.
Meanwhile, C3 would create another problem:
The in memory layout of a subclass will not necessarily match that of
the parent class in the MI case.
In one of my languages (BS2) I had instead used an approach I called
"delegation scoping", which among other things, allowed faking C++ style
multiple and virtual inheritance on top of a SI model.
But, this existed more as a scoping trick (and the basic form of the
mechanism came from a language known as Self, which was a Smalltalk
derivative).
Arguably, this model had also influenced JavaScript, but the version in
JS was far more limited.
Though, the model used in BS2 was more limited than that used in BS, in
that BS effectively treated the scope as dynamically mutable, whereas in
BS2 it was static (would typically only follow paths that exist at
compile time except in the case of "dynamic classes").
So, say for, "obj.x":
Will be a normal member load if this exists as part of the class hierarchy;
Will check delegation paths if no direct path exists and the
corresponding (actual) member is not NULL (else it will return NULL or 0
or similar);
Will check the dynamic part if one of the classes were dynamic.
Ironically, have ended up not using BS2 much in my current projects,
partly as it is still hard-pressed to compete 1:1 with C; and it also
has some design flaws of its own (like its handling of strings isn't
quite C compatible).
It is possible I could decode to rework it to just use UTF-8 for its
strings (vs "either 1252 or UTF-16, depending on contents"), which would
at least make things less of a mess here.
Syntactically though, BS2 was very similar to Java 1.x, so:
public class Foo extents Bar implements IBaz {
public int foo() { ... }
...
}
Just sort of like Java but with laxer rules, more quirks, and no garbage
collector.
Well, and some differences:
int[128] arr; //array with 128 elements, like a C array, 1D only.
int[] arr=new int[128]; //new array, unbounded lifespan
int[] arr=new! int[128]; //new array, automatic lifespan
If something is allocated with plain 'new', you also need to 'delete'
it, else the memory leaks.
Where "new!" doesn't need "delete", but the object will not outlive the
function that created it.
There was also "new(zoneid) Type" which as intended to use zone
allocation, but use of the language mostly fizzled out before I got as
far as really making much use of zones with it. In the case of zones,
they are basically magic 16-bit integers, and deleting a zone also
auto-deletes any objects associated with that zone.
I had imagined a more advanced tree-like system, so deleting a parent
zone also deletes any child zones. But things fizzled before this.
The language did have pointers, like:
T* name;
Did differ some from C in that the pointer was a part of the type and
not part of the name following the type.
So:
byte* cs, ct;
And not:
byte *cs, *ct;
But, yeah...
Functionally, they were basically analogous to C pointers though (and,
unlike C#, there was no concept of "unsafe" blocks).
Doesn't really use any of the Java class library though, rather more had
imported / wrapped parts of the normal C library (like "stdio" and similar).
Well, say, one could have a file API, but it would take a form more like:
File fd;
long sz;
byte[] buf;
fd=File.fopen(name, mode);
sz=fd.fseek(0, 2);
buf=new byte[sz];
fd.fseek(0, 0);
fd.fread(buf, sz);
fd.fclose();
return buf;
...
Though, code thus far had typically used raw imported stdio functions
(without a class wrapper).
But, in any case, would probably just have 'File' for all the normal
file IO tasks, maybe 'Dir' for directory tasks
(opendir/closedir/readdir), etc.
My most advanced project to use a variant of this language was parts of
my "BGBTech2" 3D engine; where it was used for things like game logic,
physics, and NPC/mob behavior, etc. Serving a similar sort of role to
"QuakeC" in Quake.
But, this project faded out when I started doing my ISA projects, and C
has had a lot more staying power at this.
Well, and I am not particularly compelled to write non-trivial parts of
the TestKern OS in a Java-like language (vs just gluing whatever I want
onto C).
Though, TestKern does have a few small test parts written in BS2.
Note that (unlike Java), BS2 doesn't use JNI, rather it uses the
'native' keyword in a way more like that of P/Invoke in C#.
Or, say:
native int foo(int x); //just call 'foo' in C land.
Also, "native" is also used for functions intended to be exported to C
land (if the function has both native and a body, it is understood as an
export).
Also, like C, it can use the C preprocessor and similar...
Just not a strong reason to use it, when pretty much anything I care
about is C; well, and not really a good way to use it for native
development (though using XG3 as a VM had been partly explored for the
BGBTech3 engine; but in this case, it is still a case of C vs BS2).
And, ironically, both this form of C and BS2 would still be subject to
similar drawbacks as why BGBCC lost as a VM to the original BGBScript
VM. Though, I don't have a direct equivalent of the original VM ATM, and
wouldn't want to revive the original as the VM had become too large and
complicated (and was heavyweight with fairly high memory usage, *).
*: Though, in terms of code footprint, was in a similar area to V8 or
SpiderMonkey. Ironically ending up in a similar sort of space:
A JS-like language is compiled to a sort of stack based bytecode, which
is then converted internally to 3AC and then JIT compiled to native code
(with type inference and similar, so the 3AC stage only ever sees static
types).
But, slightly better to *not* compile a big chunk of code every time the
program starts up.
Ironically, as a VM emulating a CPU ISA being a much lighter weight
option in comparison to throwing a compiler at the problem.
But don't necessarily want to go around in circles. I have now a newer
interpreter for a similar language, but am trying to keep it more
minimal (dynamically typed plain interpreter only).
Or, type inference and JIT aren't really worth it...
Well, and also the hassle that the interfacing between the VM and the
outside world when using an XG3 interpreter as a VM, is via an interface
similar to COM objects, which is kind of a pain.
Note that the VM and host would share the same VAS in this case, though
the VM can uses "windows" to control access to main memory (so, would
only have write access to its own working memory and to areas of memory
shared with it).
>> OTOH:
>> Java's handling of packages and "one class per file" were needless
>> pain IMO.
>
> I’ve done multiple top-level class definitions per file. I think
> you’re only allowed one “public” top-level class definition, though.
>
I prefer it more when you can stick however much stuff you want in a
file, but "one class" then becomes more an aesthetic thing.
Also I prefer to still be able to have plain functions as well, rather
than trying to shoehorn everything into class methods.
> One thing I soon discovered was that there was no need to create
> endless hierarchies of subdirectories to reflect the package namespace
> hierarchy. You could group your source files more rationally than that,
> and the project would still build just fine. ;)
OK.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-03 06:15 +0000 |
| Subject | Re: endian history |
| Message-ID | <119q6ht$2ok2l$1@dont-email.me> |
| In reply to | #118417 |
On Sat, 3 Oct 2026 00:54:16 -0500, BGB wrote: > On 10/2/2026 9:43 PM, Lawrence D’Oliveiro wrote: >> >> Like a lot of things in C++, the multiple-inheritance system was >> prone to (unpleasantly) surprising behaviour. So it’s no surprise >> the Java folks saw fit to try to compromise, inventing the >> “interface” system as their approach to “multiple inheritance >> lite”, a.k.a. “every superclass except one must be an abstract base >> class”, to try to keep things under control. >> >> But then the Dylan folks invented C3 linearization, which turned >> out to be quite a reasonable way to implement multiple inheritance >> with minimum surprises. So this was adopted for the class mechanism >> in Python, for example >> <https://python-history.blogspot.com/2010/06/method-resolution-order.html>. >> And so Python gets to do clever stuff like use multiple inheritance >> to implement its enum types. > > But, isn't really compatible with the "just append stuff onto the > end of the parent class". Sure that works. It’s just you now have a choice of “parent class” ;). Remember also that Python, unlike Java, doesn’t typically insist on strict class hierarchies anyway. It has a tradition called “duck typing”, from the phrase “if it looks like a duck and quacks like a duck, it must be a duck”. > The Java model can be implemented in terms of this property: Every > child class can have its members glued onto the end of the parent; > Or, new methods glued onto the end; Interfaces either add nothing, > or just have their contents glued on implicitly. That’s just down to the language rules, that say that interfaces can’t “implement” anything. It doesn’t really mean much more than that. > The C++ model works in terms of append, but diamond inheritance > creates a mess here. C3 helps. > Meanwhile, C3 would create another problem: The in memory layout of > a subclass will not necessarily match that of the parent class in > the MI case. That’s something that C++ programmers care about a lot, I guess. But I think mixing high-level and low-level issues in the same constructs like this is an unwise idea, since it leads to exactly the sort of complications that bother C++ and Java programmers alike. Python keeps high-level and low-level issues quite separate. The typical programmer will work at a high level and not worry too much about things like memory layout. If you want to have low-level control, typically because you are interfacing to code or protocol layouts defined elsewhere, there are mechanisms for that (ctypes, struct). Typically you would wrap such details in higher-level types, so a client programmer can use your library with minimal intellectual effort, and take for granted that the memory-layout details, calling conventions etc will be handled automatically. And also hopefully storage allocations. > Well, and some differences: > int[128] arr; //array with 128 elements, like a C array, 1D only. > int[] arr=new int[128]; //new array, unbounded lifespan > int[] arr=new! int[128]; //new array, automatic lifespan C++ does the latter by simply leaving out the word “new”. How come you didn’t do the same? > If something is allocated with plain 'new', you also need to > 'delete' it, else the memory leaks. > > Where "new!" doesn't need "delete", but the object will not outlive > the function that created it. Fun fact: in Java, all objects are allocated on the heap anyway, so the word “new” should be redundant (indeed, Python has done away with it). Yet Java still insists on your saying “new”. Why?
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-03 18:51 -0500 |
| Subject | Re: endian history |
| Message-ID | <119s4e7$3evfj$1@dont-email.me> |
| In reply to | #118418 |
On 10/3/2026 1:15 AM, Lawrence D’Oliveiro wrote:
> On Sat, 3 Oct 2026 00:54:16 -0500, BGB wrote:
>
>> On 10/2/2026 9:43 PM, Lawrence D’Oliveiro wrote:
>>>
>>> Like a lot of things in C++, the multiple-inheritance system was
>>> prone to (unpleasantly) surprising behaviour. So it’s no surprise
>>> the Java folks saw fit to try to compromise, inventing the
>>> “interface” system as their approach to “multiple inheritance
>>> lite”, a.k.a. “every superclass except one must be an abstract base
>>> class”, to try to keep things under control.
>>>
>>> But then the Dylan folks invented C3 linearization, which turned
>>> out to be quite a reasonable way to implement multiple inheritance
>>> with minimum surprises. So this was adopted for the class mechanism
>>> in Python, for example
>>> <https://python-history.blogspot.com/2010/06/method-resolution-order.html>.
>>> And so Python gets to do clever stuff like use multiple inheritance
>>> to implement its enum types.
>>
>> But, isn't really compatible with the "just append stuff onto the
>> end of the parent class".
>
> Sure that works. It’s just you now have a choice of “parent class” ;).
>
> Remember also that Python, unlike Java, doesn’t typically insist on
> strict class hierarchies anyway. It has a tradition called “duck
> typing”, from the phrase “if it looks like a duck and quacks like a
> duck, it must be a duck”.
>
FWIW: My BS2 language can have duct-typing for "dynamic classes" and
"variant".
But, in its normal model, it is static, and assumes a strictly
append-only object layout.
Well, say, typical layout for classes being like:
VTable Pointer;
Members for top-level class;
Interfaces for top level class;
Members for derived class;
Interfaces for derived class;
...
This means that if a pointer to a child-class is cast to a parent class,
everything still matches up in terms of layout.
So, "obj.x" can still be a single memory-load operation or similar.
>> The Java model can be implemented in terms of this property: Every
>> child class can have its members glued onto the end of the parent;
>> Or, new methods glued onto the end; Interfaces either add nothing,
>> or just have their contents glued on implicitly.
>
> That’s just down to the language rules, that say that interfaces can’t
> “implement” anything. It doesn’t really mean much more than that.
>
I was allowing for things like default methods in an interface, which
can be quietly be added to a class.
Eg:
public interface IFoo {
default void someMethod() {
...
};
}
Could maybe leave out needing 'default' here, with the presence of a
method body implying that it is default.
>> The C++ model works in terms of append, but diamond inheritance
>> creates a mess here.
>
> C3 helps.
>
Possibly, though would likely decay into an assumption that the MI
behaves like virtual inheritance as a universal default.
Would necessarily penalize MI, as then accessing members in any parent
class requires implicit pointer walks. This is avoided by SI only.
Faking MI using delegate scoping also works and could have roughly
comparable overhead to the virtual inheritance case, if the compiler
assumes that the delegates are always non-null.
>> Meanwhile, C3 would create another problem: The in memory layout of
>> a subclass will not necessarily match that of the parent class in
>> the MI case.
>
> That’s something that C++ programmers care about a lot, I guess. But I
> think mixing high-level and low-level issues in the same constructs
> like this is an unwise idea, since it leads to exactly the sort of
> complications that bother C++ and Java programmers alike.
>
Possibly, would also matter for BS2.
But, as noted, the rough level of abstraction for BS2 isn't that far off
from C++.
In the original BS-VM, there was a mechanism where in cases where a
non-trivial layout was used; it would form a hash of the ClassID and
MemberID numbers (global magic numbers in the VM) and look up in a
hash-table where the member was at in the object (falling back to a
search if the hash misses).
Current runtime doesn't have this, and instead the compiler assumes all
member locations are statically known at compile time (excluding dynamic
classes, but then any statically visible paths always take precedence
over a dynamic path even if the dynamic path is technically shorter).
Or:
Search backwards from current class upwards;
Then search delegate paths (also nearest first);
Then check for dynamic members (if a dynamic class);
Else (not dynamic): Compile error, missing variable.
If the class is marked dynamic (at the highest level marked dynamic):
It adds a hidden member pointing to an ex-nihilo object;
The ex-nihilo object holds any dynamically added members;
Marking child classes has no effect;
Marking a parent class dynamic makes all descendants dynamic.
Unlike the statically visible members, dynamic members require an
internal runtime call (with the ex-nihilo objects implemented as small
B-Trees).
Or, something to the effect of:
struct ExNihiloObject_s {
u64 vals[16];
u16 keys[16];
byte nkeys; //how many keys in this node
byte depth; //is this a node or leaf
}
The key in this case being a dynamic member ID, which combines the
member name and type (it is an index number into an array, not bit-packed).
Any smaller type is padded up to 64 bits. A 128-bit type will implicitly
need 2 spots.
But, most of the time, any dynamic members are "variant".
Eg:
variant obj = {x: 3, y: 4}; //ex-nihilo object
obj["z"] = obj.x + obj.y; //creates 'z' if it doesn't exist.
Generally, this stuff is better avoided when not needed, as the
performance is much slower than for normal objects (likewise for dynamic
types in general).
Typically, the closer one stays to normal "plain C style", the faster it
can be.
IIRC, as an early test for BS2 (long ago) I had ported a JPEG decoder to
it as a test, but noted that the fastest case was to basically do
everything roughly 1:1 with how it would be done in C (the compiler
worked, but this was at a time before my compiler tech was able to match
1:1 speeds with native C compilers).
Well, then again, this is arguably still true if limiting to X64:
BGBCC doesn't have an X64 target;
XG3 in a emulator doesn't match native speeds.
It does beat GCC targeting RV64G within the same VM though.
And, in theory an X64 backend could be written if I had a strong enough
reason to do so.
> Python keeps high-level and low-level issues quite separate. The
> typical programmer will work at a high level and not worry too much
> about things like memory layout. If you want to have low-level
> control, typically because you are interfacing to code or protocol
> layouts defined elsewhere, there are mechanisms for that (ctypes,
> struct). Typically you would wrap such details in higher-level types,
> so a client programmer can use your library with minimal intellectual
> effort, and take for granted that the memory-layout details, calling
> conventions etc will be handled automatically.
>
> And also hopefully storage allocations.
>
Python performance also tends to be kinda "hot dog crap" if one tries to
do any non-trivial computational work in it.
>> Well, and some differences:
>> int[128] arr; //array with 128 elements, like a C array, 1D only.
>> int[] arr=new int[128]; //new array, unbounded lifespan
>> int[] arr=new! int[128]; //new array, automatic lifespan
>
> C++ does the latter by simply leaving out the word “new”. How come you
> didn’t do the same?
>
Partly syntactic reasons.
Foo obj!();
Would map to:
Foo obj = new! Foo();
And:
Foo obj();
Would map to:
Foo obj = new Foo();
But, in the case of local arrays:
int[128] arr;
Is the effective shorthand for:
int[] arr=new! int[128];
Partly because (in terms of syntax and parser rules) BS2 descends from
JS and Java (with C# influences) and not from C++.
However, can note that leaving out the 'new' keyword would leave a
potential for syntactic ambiguity in a parser for a language where the
parser doesn't necessarily know all the types in advance (unlike C and C++).
Where, like C#, BS2 had relied primarily on syntactic pattern matching
for parsing (and not on the ability to see declarations in advance), and
adds another intermediate compilation stage to propagate the visibility
of types and declarations between translation units (this stage is
skipped if just compiling C).
>> If something is allocated with plain 'new', you also need to
>> 'delete' it, else the memory leaks.
>>
>> Where "new!" doesn't need "delete", but the object will not outlive
>> the function that created it.
>
> Fun fact: in Java, all objects are allocated on the heap anyway, so
> the word “new” should be redundant (indeed, Python has done away with
> it). Yet Java still insists on your saying “new”. Why?
Ironically, in BGBCC, "new!" is also still allocated on the heap (also
C's "alloca()" and C99 VLAs, with the same underlying mechanism).
There is just sort of a mechanism in-place to auto-free all the objects
for the current frame on function return (the relevant runtime calls are
not emitted for functions which don't use this feature).
In a way though, it is kinda funny:
BGBCC does a whole lot of stuff that theoretically should negatively
impact performance, and has some obvious weaknesses as well (weak
register allocator, etc);
Yet still manages to be competitive with GCC when targeting the same
basic ISA (though, GCC still tends to hold a performance lead with bare
RV64G though; but not if competing against an ISA that is "slightly less
crippled");
If GCC was targeting XG3 though, with a non-stupid ABI, very possibly it
could win.
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-04 02:35 +0000 |
| Subject | Re: endian history |
| Message-ID | <119se18$3hj08$1@dont-email.me> |
| In reply to | #118446 |
On Sat, 3 Oct 2026 18:51:26 -0500, BGB wrote: > Would necessarily penalize MI, as then accessing members in any > parent class requires implicit pointer walks. This is avoided by SI > only. Requiring methods to be declared “virtual” as in C++ may increase efficiency, but it just contributes to the surprise factor when common OO conventions don’t work right. > Python performance also tends to be kinda "hot dog crap" if one > tries to do any non-trivial computational work in it. That’s solved by moving all the low-level CPU-intensive manipulations to numeric engines like NumPy/SciPy. This makes it very easy to express complex manipulations on lots of data in just a few lines of Python code, and have it done efficiently. This is why Python is so popular in data science/analytics applications, particularly when combined with other tools like Pandas for ETL, Matplotlib for charting, Jupyter for “scratchpad” programming etc. Even Microsoft is offering Python access to Excel users. And it charges for that: seems like its target market is unable to figure out that they can bypass Microsoft (and Office) and use the Python stuff for free. > However, can note that leaving out the 'new' keyword would leave a > potential for syntactic ambiguity in a parser for a language where > the parser doesn't necessarily know all the types in advance (unlike > C and C++). In Python, the parser doesn’t know *any* of the types in advance. Yet it gets by just fine without “new”. A class instantiation looks like a function call, and is treated the same by the runtime. One obvious issue with stack allocation is, which of the surrounding scopes controls the lifetime of the allocation? The case can be made for letting the programmer choose any of them. But then, if you can have an allocation in an inner scope followed by another in an outer one, that complicates the runtime management. But *not* allowing that becomes an irritating restriction in many situations. This is probably why lots of languages just give up and go to heap allocation, as being simpler to manage all round.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2026-10-03 10:25 -0400 |
| Subject | Re: endian history |
| Message-ID | <119r396$33009$1@dont-email.me> |
| In reply to | #118417 |
On 2026-10-03 1:54 a.m., BGB wrote:
> On 10/2/2026 9:43 PM, Lawrence D’Oliveiro wrote:
>> On Fri, 2 Oct 2026 16:46:12 -0500, BGB wrote:
>>
>>> Ironically, despite multi-core CPUs, I infrequently use
>>> multi-threading, as I have usually found it preferable to try to
>>> make the single-threaded code "fast enough" rather than deal with
>>> the hassles of multithreading.
>>
>> This is very common. It’s why coroutines have made a comeback, in the
>> form of async/await constructs (pioneered by Microsoft, to give them
>> credit). When the bottleneck is not the CPU, multithreading buys you
>> little or nothing apart from complexity.
>>
>
> There are relatively few things that are meaningfully CPU bound at present.
>
>
> There is slow / inefficient coding, but the better fix is usually to
> optimize the code, not to use threads.
>
> There are some tasks that could be made faster with threads, like
> running genetic algorithms or training neural nets, but I prefer not to
> bog down my PC in the name of faster NN training (so, this sort of thing
> more often ends up as a long-running "slow-burn").
>
>
> Though, I think part of the issue sometimes is that many people write
> code that is sometimes horribly inefficient and then blame the hardware
> for not being faster, rather than their code for being inefficient or
> their approach for being wrong.
>
> Well, and the recent rise of "vibe coding" doesn't really help. But, now
> you have "programmers" who don't even know how the program is supposed
> to work, just yelling at their AI agents to fix the bugs.
>
>
> Well, and then crying on social media about how they burnt through their
> token budget for that month and they now need $k to get more tokens (I
> guess the sentiment is something like the base plans give a certain
> token budget per-month, but then to exceed this requires paying a fair
> bit more).
>
> Ironically, I don't really know.
>
> In the stuff I interact with, haven't really gone beyond free tier; nor
> seen much reason to pay. Sometimes feedback on things is nice, but
> otherwise I can write my own code for free...
>
>
>
>>> Do agree with Java in a few areas though: Making all signed integer
>>> math modulo and with consistent rules made sense; The
>>> class/interface system and general approach to exceptions (*1) made
>>> sense (and a slight improvement over the C++ approach here).
>>
>> Like a lot of things in C++, the multiple-inheritance system was prone
>> to (unpleasantly) surprising behaviour. So it’s no surprise the Java
>> folks saw fit to try to compromise, inventing the “interface” system
>> as their approach to “multiple inheritance lite”, a.k.a. “every
>> superclass except one must be an abstract base class”, to try to keep
>> things under control.
>>
>> But then the Dylan folks invented C3 linearization, which turned out
>> to be quite a reasonable way to implement multiple inheritance with
>> minimum surprises. So this was adopted for the class mechanism in
>> Python, for example
>> <https://python-history.blogspot.com/2010/06/method-resolution-
>> order.html>.
>> And so Python gets to do clever stuff like use multiple inheritance to
>> implement its enum types.
>>
>
> But, isn't really compatible with the "just append stuff onto the end of
> the parent class".
>
> The Java model can be implemented in terms of this property:
> Every child class can have its members glued onto the end of the parent;
> Or, new methods glued onto the end;
> Interfaces either add nothing, or just have their contents glued on
> implicitly.
>
>
> The C++ model works in terms of append, but diamond inheritance creates
> a mess here.
>
> Meanwhile, C3 would create another problem:
> The in memory layout of a subclass will not necessarily match that of
> the parent class in the MI case.
>
>
>
> In one of my languages (BS2) I had instead used an approach I called
> "delegation scoping", which among other things, allowed faking C++ style
> multiple and virtual inheritance on top of a SI model.
>
> But, this existed more as a scoping trick (and the basic form of the
> mechanism came from a language known as Self, which was a Smalltalk
> derivative).
>
> Arguably, this model had also influenced JavaScript, but the version in
> JS was far more limited.
>
> Though, the model used in BS2 was more limited than that used in BS, in
> that BS effectively treated the scope as dynamically mutable, whereas in
> BS2 it was static (would typically only follow paths that exist at
> compile time except in the case of "dynamic classes").
>
> So, say for, "obj.x":
> Will be a normal member load if this exists as part of the class hierarchy;
> Will check delegation paths if no direct path exists and the
> corresponding (actual) member is not NULL (else it will return NULL or 0
> or similar);
> Will check the dynamic part if one of the classes were dynamic.
>
>
>
> Ironically, have ended up not using BS2 much in my current projects,
> partly as it is still hard-pressed to compete 1:1 with C; and it also
> has some design flaws of its own (like its handling of strings isn't
> quite C compatible).
>
> It is possible I could decode to rework it to just use UTF-8 for its
> strings (vs "either 1252 or UTF-16, depending on contents"), which would
> at least make things less of a mess here.
>
>
> Syntactically though, BS2 was very similar to Java 1.x, so:
> public class Foo extents Bar implements IBaz {
> public int foo() { ... }
> ...
> }
>
>
> Just sort of like Java but with laxer rules, more quirks, and no garbage
> collector.
>
> Well, and some differences:
> int[128] arr; //array with 128 elements, like a C array, 1D only.
> int[] arr=new int[128]; //new array, unbounded lifespan
> int[] arr=new! int[128]; //new array, automatic lifespan
>
>
> If something is allocated with plain 'new', you also need to 'delete'
> it, else the memory leaks.
>
> Where "new!" doesn't need "delete", but the object will not outlive the
> function that created it.
I would be inclined to the "auto" keyword here, finding it harder to
understand or recollect what the '!' does.>
> There was also "new(zoneid) Type" which as intended to use zone
> allocation, but use of the language mostly fizzled out before I got as
> far as really making much use of zones with it. In the case of zones,
> they are basically magic 16-bit integers, and deleting a zone also auto-
> deletes any objects associated with that zone.
Interesting idea. I can see where it may be useful in some
circumstances. But rather than a zone have new refer to the heap the
allocation is taking place on. The heap could have its own
characteristics like garbage collection.
int[] arr=new(auto) int[128]; // array allocated on the stack
int[] arr=new(gcheap) int[128]; // array allocated in garbage collected
heap
int[] arr=new(glbheap) int[128]; // array allocated on a global heap
If there is a heap type in the OS it could be made visible to the compiler.
heap[] heaparr=new heap[10];
int[] arr=new(heaparr[1]) int[20];>
> I had imagined a more advanced tree-like system, so deleting a parent
> zone also deletes any child zones. But things fizzled before this.
>
> The language did have pointers, like:
> T* name;
> Did differ some from C in that the pointer was a part of the type and
> not part of the name following the type.
>
> So:
> byte* cs, ct;
> And not:
> byte *cs, *ct;
>
> But, yeah...
>
> Functionally, they were basically analogous to C pointers though (and,
> unlike C#, there was no concept of "unsafe" blocks).
>
>
> Doesn't really use any of the Java class library though, rather more had
> imported / wrapped parts of the normal C library (like "stdio" and
> similar).
>
> Well, say, one could have a file API, but it would take a form more like:
> File fd;
> long sz;
> byte[] buf;
> fd=File.fopen(name, mode);
> sz=fd.fseek(0, 2);
> buf=new byte[sz];
> fd.fseek(0, 0);
> fd.fread(buf, sz);
> fd.fclose();
> return buf;
> ...
>
> Though, code thus far had typically used raw imported stdio functions
> (without a class wrapper).
>
> But, in any case, would probably just have 'File' for all the normal
> file IO tasks, maybe 'Dir' for directory tasks (opendir/closedir/
> readdir), etc.
>
>
>
> My most advanced project to use a variant of this language was parts of
> my "BGBTech2" 3D engine; where it was used for things like game logic,
> physics, and NPC/mob behavior, etc. Serving a similar sort of role to
> "QuakeC" in Quake.
>
> But, this project faded out when I started doing my ISA projects, and C
> has had a lot more staying power at this.
>
> Well, and I am not particularly compelled to write non-trivial parts of
> the TestKern OS in a Java-like language (vs just gluing whatever I want
> onto C).
>
> Though, TestKern does have a few small test parts written in BS2.
>
>
> Note that (unlike Java), BS2 doesn't use JNI, rather it uses the
> 'native' keyword in a way more like that of P/Invoke in C#.
>
> Or, say:
> native int foo(int x); //just call 'foo' in C land.
>
> Also, "native" is also used for functions intended to be exported to C
> land (if the function has both native and a body, it is understood as an
> export).
>
> Also, like C, it can use the C preprocessor and similar...
>
>
> Just not a strong reason to use it, when pretty much anything I care
> about is C; well, and not really a good way to use it for native
> development (though using XG3 as a VM had been partly explored for the
> BGBTech3 engine; but in this case, it is still a case of C vs BS2).
>
> And, ironically, both this form of C and BS2 would still be subject to
> similar drawbacks as why BGBCC lost as a VM to the original BGBScript
> VM. Though, I don't have a direct equivalent of the original VM ATM, and
> wouldn't want to revive the original as the VM had become too large and
> complicated (and was heavyweight with fairly high memory usage, *).
>
>
> *: Though, in terms of code footprint, was in a similar area to V8 or
> SpiderMonkey. Ironically ending up in a similar sort of space:
> A JS-like language is compiled to a sort of stack based bytecode, which
> is then converted internally to 3AC and then JIT compiled to native code
> (with type inference and similar, so the 3AC stage only ever sees static
> types).
>
> But, slightly better to *not* compile a big chunk of code every time the
> program starts up.
>
> Ironically, as a VM emulating a CPU ISA being a much lighter weight
> option in comparison to throwing a compiler at the problem.
>
> But don't necessarily want to go around in circles. I have now a newer
> interpreter for a similar language, but am trying to keep it more
> minimal (dynamically typed plain interpreter only).
>
>
> Or, type inference and JIT aren't really worth it...
>
>
>
>
> Well, and also the hassle that the interfacing between the VM and the
> outside world when using an XG3 interpreter as a VM, is via an interface
> similar to COM objects, which is kind of a pain.
>
> Note that the VM and host would share the same VAS in this case, though
> the VM can uses "windows" to control access to main memory (so, would
> only have write access to its own working memory and to areas of memory
> shared with it).
>
>
>
>
>>> OTOH:
>>> Java's handling of packages and "one class per file" were needless
>>> pain IMO.
>>
>> I’ve done multiple top-level class definitions per file. I think
>> you’re only allowed one “public” top-level class definition, though.
>>
>
> I prefer it more when you can stick however much stuff you want in a
> file, but "one class" then becomes more an aesthetic thing.
>
> Also I prefer to still be able to have plain functions as well, rather
> than trying to shoehorn everything into class methods.
>
>
>> One thing I soon discovered was that there was no need to create
>> endless hierarchies of subdirectories to reflect the package namespace
>> hierarchy. You could group your source files more rationally than that,
>> and the project would still build just fine. ;)
>
> OK.
>
>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-03 16:59 -0500 |
| Subject | Re: endian history |
| Message-ID | <119rtt4$3d28c$1@dont-email.me> |
| In reply to | #118428 |
On 10/3/2026 9:25 AM, Robert Finch wrote:
> On 2026-10-03 1:54 a.m., BGB wrote:
>> On 10/2/2026 9:43 PM, Lawrence D’Oliveiro wrote:
>>> On Fri, 2 Oct 2026 16:46:12 -0500, BGB wrote:
>>>
>>>> Ironically, despite multi-core CPUs, I infrequently use
>>>> multi-threading, as I have usually found it preferable to try to
>>>> make the single-threaded code "fast enough" rather than deal with
>>>> the hassles of multithreading.
>>>
>>> This is very common. It’s why coroutines have made a comeback, in the
>>> form of async/await constructs (pioneered by Microsoft, to give them
>>> credit). When the bottleneck is not the CPU, multithreading buys you
>>> little or nothing apart from complexity.
>>>
>>
>> There are relatively few things that are meaningfully CPU bound at
>> present.
>>
>>
>> There is slow / inefficient coding, but the better fix is usually to
>> optimize the code, not to use threads.
>>
>> There are some tasks that could be made faster with threads, like
>> running genetic algorithms or training neural nets, but I prefer not
>> to bog down my PC in the name of faster NN training (so, this sort of
>> thing more often ends up as a long-running "slow-burn").
>>
>>
>> Though, I think part of the issue sometimes is that many people write
>> code that is sometimes horribly inefficient and then blame the
>> hardware for not being faster, rather than their code for being
>> inefficient or their approach for being wrong.
>>
>> Well, and the recent rise of "vibe coding" doesn't really help. But,
>> now you have "programmers" who don't even know how the program is
>> supposed to work, just yelling at their AI agents to fix the bugs.
>>
>>
>> Well, and then crying on social media about how they burnt through
>> their token budget for that month and they now need $k to get more
>> tokens (I guess the sentiment is something like the base plans give a
>> certain token budget per-month, but then to exceed this requires
>> paying a fair bit more).
>>
>> Ironically, I don't really know.
>>
>> In the stuff I interact with, haven't really gone beyond free tier;
>> nor seen much reason to pay. Sometimes feedback on things is nice, but
>> otherwise I can write my own code for free...
>>
>>
>>
>>>> Do agree with Java in a few areas though: Making all signed integer
>>>> math modulo and with consistent rules made sense; The
>>>> class/interface system and general approach to exceptions (*1) made
>>>> sense (and a slight improvement over the C++ approach here).
>>>
>>> Like a lot of things in C++, the multiple-inheritance system was prone
>>> to (unpleasantly) surprising behaviour. So it’s no surprise the Java
>>> folks saw fit to try to compromise, inventing the “interface” system
>>> as their approach to “multiple inheritance lite”, a.k.a. “every
>>> superclass except one must be an abstract base class”, to try to keep
>>> things under control.
>>>
>>> But then the Dylan folks invented C3 linearization, which turned out
>>> to be quite a reasonable way to implement multiple inheritance with
>>> minimum surprises. So this was adopted for the class mechanism in
>>> Python, for example
>>> <https://python-history.blogspot.com/2010/06/method-resolution-
>>> order.html>.
>>> And so Python gets to do clever stuff like use multiple inheritance to
>>> implement its enum types.
>>>
>>
>> But, isn't really compatible with the "just append stuff onto the end
>> of the parent class".
>>
>> The Java model can be implemented in terms of this property:
>> Every child class can have its members glued onto the end of the parent;
>> Or, new methods glued onto the end;
>> Interfaces either add nothing, or just have their contents glued on
>> implicitly.
>>
>>
>> The C++ model works in terms of append, but diamond inheritance
>> creates a mess here.
>>
>> Meanwhile, C3 would create another problem:
>> The in memory layout of a subclass will not necessarily match that of
>> the parent class in the MI case.
>>
>>
>>
>> In one of my languages (BS2) I had instead used an approach I called
>> "delegation scoping", which among other things, allowed faking C++
>> style multiple and virtual inheritance on top of a SI model.
>>
>> But, this existed more as a scoping trick (and the basic form of the
>> mechanism came from a language known as Self, which was a Smalltalk
>> derivative).
>>
>> Arguably, this model had also influenced JavaScript, but the version
>> in JS was far more limited.
>>
>> Though, the model used in BS2 was more limited than that used in BS,
>> in that BS effectively treated the scope as dynamically mutable,
>> whereas in BS2 it was static (would typically only follow paths that
>> exist at compile time except in the case of "dynamic classes").
>>
>> So, say for, "obj.x":
>> Will be a normal member load if this exists as part of the class
>> hierarchy;
>> Will check delegation paths if no direct path exists and the
>> corresponding (actual) member is not NULL (else it will return NULL or
>> 0 or similar);
>> Will check the dynamic part if one of the classes were dynamic.
>>
>>
>>
>> Ironically, have ended up not using BS2 much in my current projects,
>> partly as it is still hard-pressed to compete 1:1 with C; and it also
>> has some design flaws of its own (like its handling of strings isn't
>> quite C compatible).
>>
>> It is possible I could decode to rework it to just use UTF-8 for its
>> strings (vs "either 1252 or UTF-16, depending on contents"), which
>> would at least make things less of a mess here.
>>
>>
>> Syntactically though, BS2 was very similar to Java 1.x, so:
>> public class Foo extents Bar implements IBaz {
>> public int foo() { ... }
>> ...
>> }
>>
>>
>> Just sort of like Java but with laxer rules, more quirks, and no
>> garbage collector.
>>
>> Well, and some differences:
>> int[128] arr; //array with 128 elements, like a C array, 1D only.
>> int[] arr=new int[128]; //new array, unbounded lifespan
>> int[] arr=new! int[128]; //new array, automatic lifespan
>>
>>
>> If something is allocated with plain 'new', you also need to 'delete'
>> it, else the memory leaks.
>>
>> Where "new!" doesn't need "delete", but the object will not outlive
>> the function that created it.
>
> I would be inclined to the "auto" keyword here, finding it harder to
> understand or recollect what the '!' does.>
Possibly, but can note in this language:
auto somevar = expr;
Would cause 'auto' to effectively be in a superposition of possible
types, which the compiler then collapses to a single type by figuring
out what 'expr' produces.
Functionally, very similar to what is seen in C++.
Likewise, only a single type was allowed at runtime in most cases.
This differs from "variant" which was dynamic at runtime.
There was some wonk in the language, where it did allow:
auto someAdder(auto x, auto y)
{ return x+y; }
Which would type-specialize the function at the point of use (as an
alternative to generics). Didn't really work for methods though (if used
for class members or similar, would instead decay to 'variant').
The later case could imply a need for generics, but a lazier option
being to just throw up ones hands and say "use variant instead" (the
actual performance overhead of variant not being *that* bad).
This was vaguely similar to the predecessor language:
function someAdder(x, y)
{ return x+y; }
Would either type-infer if possible, or fall back to dynamic types.
But, the predecessor had a system that ended up becoming much more
complicated (and the complexities of trying to propagate types between
different locations and across a dynamically mutable scope tree quickly
got ugly; and was part of the downfall of that VM).
But, yeah, the "new!" syntax had IIRC originated in the original BS as a
shorthand to indicate automatic scope, which was freed faster than
waiting for the main GC to find it.
Well, and at the time (in the early 2010s), the GC had ended up becoming
my nemesis. Hence part of the motivation to not use a GC in BS2.
>> There was also "new(zoneid) Type" which as intended to use zone
>> allocation, but use of the language mostly fizzled out before I got as
>> far as really making much use of zones with it. In the case of zones,
>> they are basically magic 16-bit integers, and deleting a zone also
>> auto- deletes any objects associated with that zone.
>
> Interesting idea. I can see where it may be useful in some
> circumstances. But rather than a zone have new refer to the heap the
> allocation is taking place on. The heap could have its own
> characteristics like garbage collection.
>
> int[] arr=new(auto) int[128]; // array allocated on the stack
> int[] arr=new(gcheap) int[128]; // array allocated in garbage collected
> heap
> int[] arr=new(glbheap) int[128]; // array allocated on a global heap
>
> If there is a heap type in the OS it could be made visible to the compiler.
>
> heap[] heaparr=new heap[10];
> int[] arr=new(heaparr[1]) int[20];>
The zoneid wasn't really in the same category as allocation type...
The syntax could maybe be reused, but this wasn't really the intent.
But, yeah, as noted there was no GC in this case, there was:
Automatic lifetime;
Existence within a zone;
Or, global heap.
Conceptually, it could take a form like, say:
//before allocating stuff
Zone worldzone = new Zone(); //
Zone roomzone = new Zone(worldzone);
Then, say:
Entity obj = new(roomzone) EntityProp("models/sofa.mdl");
Then, say:
delete worldzone; //autodelete anything in worldzone and roomzone.
//though, in this form would also nuke the zone itself.
worldzone.clear(); //also remove everything in the zones
//but leaves the zones themselves intact.
In this case, the Zone being something like:
//calls into C land for this part
native int tkmm_alloczoneid();
native int tk_mfreezone(int ztag, int zmask);
...
public final class Zone {
ushort zoneid;
Zone[] child;
int n_child;
public Zone()
{
zoneid = tkmm_alloczoneid(); //allocate a 16-bit zone number
}
public Zone(Zone parent)
{
zoneid = tkmm_alloczoneid(); //allocate a 16-bit zone number
parent.addChild(this);
}
public ~Zone()
{
clear();
}
public clear()
{
int i;
for(i=0; i<n_child; i++)
child[i].clear();
tk_mfreezone(zoneid, -1);
}
protected addChild(Zone zn)
{
if(!child)
child = new Zone[64];
child[n_child++] = zn;
}
}
But, as noted, this wasn't defined.
I guess, could formally add if needed.
Could maybe also add the child-zone handling to the C land memory
manager, TBD.
Note that a zoneid of 0 is not used, this means the global heap.
Every heap allocation potentially has a zoneid and type-tag ID, though
for normal C allocations these were not used (likewise, the C malloc
having the high 16 bits of the pointer clear).
For BS2, it instead used type-tagged pointers by default.
Where, deleting or clearing the zone would also remove the prop created
within the zone.
There was a potential risk of leaving dangling pointers.
Doom had a mechanism in Z_Malloc to allow automatically nullifying a
pointer to a Z_Malloc'ed object when the zone was cleared. This
currently doesn't exist in my memory manager, and is unclear how it
could be implemented without significant complexity and overhead.
Like, to avoid dangling pointers would mean either needing to track
object references on assignment (expensive), or walk the heap (like in
an actual GC) to find the references to nullify. In this case, one
doesn't want to add the expensive parts of having a GC if trying to
avoid having a GC.
In an ideal world, holding a reference to an object that is removed or
goes out of scope should ideally have this reference automatically
become 'null' though.
A traditionally GC'ed system wouldn't have this issue, but alas.
But, yeah, it was an interesting project at the time, but afterwards
kinda seemed like a dead-end. It had seen attention now and then partly
because it exists in BGBCC and shares the same compiler infrastructure
as my C compiler.
Could invest more resources into it, if it were likely to be useful.
Its biggest annoyance in the past was its troublesome handling of
strings, but could fix this (by formally moving it over to UTF-8 as its
canonical string representation, rather than it trying to pretend the
world is using UTF-16).
<snip>
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-10-03 15:04 -0400 |
| Subject | Re: endian history |
| Message-ID | <uej2cltbv67vc7aqh9pp9c84inmmb8cvk1@4ax.com> |
| In reply to | #118411 |
On Sat, 3 Oct 2026 02:43:27 -0000 (UTC), Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >On Fri, 2 Oct 2026 16:46:12 -0500, BGB wrote: > >> Ironically, despite multi-core CPUs, I infrequently use >> multi-threading, as I have usually found it preferable to try to >> make the single-threaded code "fast enough" rather than deal with >> the hassles of multithreading. > >This is very common. It’s why coroutines have made a comeback, in the >form of async/await constructs (pioneered by Microsoft, to give them >credit). When the bottleneck is not the CPU, multithreading buys you >little or nothing apart from complexity. Historically, multithreading (multiprogramming in general) was created to cover I/O latency, and it bought the ability to do something else instead of just waiting. Even if all you can do is set up the next I/O, it can improve the run time overall. The problem is that too many programmers are better at figuring out what /could/ be done in parallel than what /should/ be done in parallel. Too many threads used inappropriately.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-02 21:53 +0000 |
| Subject | Re: endian history |
| Message-ID | <119p946$2g4hd$3@dont-email.me> |
| In reply to | #118393 |
On Fri, 02 Oct 2026 14:25:27 +0000, aph wrote:
> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Thu, 01 Oct 2026 10:44:32 +0000, aph wrote:
>>
>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>> But now you see why other programming languages keep the unsigned
>>>> integers. It just saves a certain amount of irritation and
>>>> occasional outright pain.
>>>
>>> Some languages do, some don't.
>>
>> Apart from Java, who else was that stupid?
>
> Python, Javascript, PHP, ...
Python 3.14.7 (main, Sep 13 2026, 08:30:29) [GCC 16.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> sum(1 << i for i in range(256))
115792089237316195423570985008687907853269984665640564039457584007913129639935
Still unsigned ...
>> ... yet the Java language manual (just the core language, not even
>> any of the standard classes, like those in java.lang) is already
>> getting close to 900 pages, not far short of the complexity of C++
>> already. Even the latest C-language spec, including standard
>> library, is not much more than half that.
>
> And adding more numeric types would have made it more complicated,
> obvs.
It’s already getting close to the complexity of C++. Wasn’t it
supposed to be a simpler language than C++, in the early days? Yet it
doesn’t seem to be saving much any more, by leaving out things like
unsigned ints, typedefs, multiple inheritance ... you know, basic
quality-of-life programming conveniences.
> The idea of Java was to have a high-level portable object-oriented
> language with classes, interfaces, exceptions, and threads. Every
> programming language is a compromise of some kind.
Some achieve it better than others. I would class Java among the ones
a bit further from the optimum these days.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-01 07:34 +0000 |
| Subject | Re: endian history |
| Message-ID | <2026Oct1.093411@mips.complang.tuwien.ac.at> |
| In reply to | #118334 |
aph@littlepinkcloud.invalid writes: >With wrapping signed arithmetic, all of the semantics of unsigned >arithmetic is the same, except for right shift and division >operations. The most common operations in my experience where there is a difference between signed and unsigned are different are unequality comparisons. Apparently the Java designers did not think that comparing for unsigned <, >, <=, >= is something the Java programmers would miss, and they probably are right. - 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 07:00 -0700 |
| Subject | Re: endian history |
| Message-ID | <86ld8hplkd.fsf@linuxsc.com> |
| In reply to | #118334 |
aph@littlepinkcloud.invalid writes: > Lawrence D?Oliveiro <ldo@nz.invalid> wrote: > >> Now, can anybody solve the mystery of why the Java language designers >> thought it would be a good idea to leave out unsigned integers? > > It's unnecessary, and the designer(s) wanted to get away from the zoo of > C's integer types. > > With wrapping signed arithmetic, all of the semantics of unsigned > arithmetic is the same, except for right shift and division > operations. Also left shift and relational comparisons.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-01 15:20 +0000 |
| Subject | Re: endian history |
| Message-ID | <2026Oct1.172040@mips.complang.tuwien.ac.at> |
| In reply to | #118351 |
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 -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 09:15 -0700 |
| Subject | Re: endian history |
| Message-ID | <864if5pfby.fsf@linuxsc.com> |
| In reply to | #118354 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-01 19:23 +0300 |
| Subject | Re: endian history |
| Message-ID | <20261001192324.00004a9b@yahoo.com> |
| In reply to | #118356 |
On Thu, 01 Oct 2026 09:15:29 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > 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. I would think that it is true on all twoc architectures that don't trap on signed integer overflow. Also it is a defenition guaranteed on all supported targets by gcc.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-02 21:31 -0700 |
| Subject | Re: endian history |
| Message-ID | <86bj9bo15t.fsf@linuxsc.com> |
| In reply to | #118359 |
Michael S <already5chosen@yahoo.com> writes: > On Thu, 01 Oct 2026 09:15:29 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> 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. > > I would think that it is true on all twoc architectures that don't > trap on signed integer overflow. Did you embark on any research to reach this characterization, or is it just speculation? > Also it is a defenition guaranteed on all supported targets by gcc. I don't know what that has to do with the question here, which is more about machine architectures and/or Java, and at first blush has nothing to do with gcc.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-03 10:25 +0000 |
| Subject | Re: endian history |
| Message-ID | <2026Oct3.122516@mips.complang.tuwien.ac.at> |
| In reply to | #118414 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Michael S <already5chosen@yahoo.com> writes: > >> On Thu, 01 Oct 2026 09:15:29 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> [Someone else:] >>>>>> With wrapping signed arithmetic, all of the semantics of >>>>>> unsigned arithmetic is the same, except for right shift and >>>>>> division operations. >>>>> >>>>> Also left shift Did you embark on any research to reach this characterization, or is it just speculation? Given that you did not name a single architecture to support your claim, not even when I asked for it, it is obvious that your claim has no basis in reality. >>>> 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. >> >> I would think that it is true on all twoc architectures that don't >> trap on signed integer overflow. > >Did you embark on any research to reach this characterization, or >is it just speculation? In my case it's based on knowing a number of architectures with 2s-complement representation of signed numbers, and none of them have separate shift-left instructions for signed and unsigned instructions, including AMD64 which has two mnemonics for the same instruction. Even if we ignore the "wrapping" precondition and look at MIPS and Alpha which have, in addition to a wrapping multiply instruction (multu/mul) which works for both signed and unsigned numbers, a trapping multiply instruction (mult/mulv) that traps on signed overflow, we find that they only have a non-trapping (aka "wrapping") shift-left instruction (sll), despite Alpha being the successor of VAX with its potentially trapping shift instruction. VAX itself has only one shift instruction, which serves as signed shift right if it shifts right, and when you use a shift count that shifts left, and do not enable trapping, produces the same result as the shift left instructions with the same operand size of other architectures, whether they are called arithmetic or logical (or, in case of AMD64, both). The only case where there could be a difference would be if the shift left was widening (just as we have different widening multiplications for signed and unsigned, and on some architectures even for combinations of signed and unsigned), but I am not aware of a widening shift instruction in any architecture. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 19 of 30 — ← Prev page 1 … 17 18 [19] 20 21 … 30 Next page →
Back to top | Article view | comp.arch
csiph-web