Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #113595 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2025-10-03 08:58 +0000 |
| Last post | 2025-12-28 21:34 +0000 |
| Articles | 20 on this page of 215 — 26 participants |
Back to article view | Back to comp.arch
Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-03 08:58 +0000
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-10-03 05:40 -0500
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-03 13:46 +0300
SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-10-03 11:26 -0400
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 15:42 +0000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-03 16:18 +0000
Re: SASOS and virtually tagged caches Stefan Monnier <monnier@iro.umontreal.ca> - 2025-10-03 15:44 -0400
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) George Neuner <gneuner2@comcast.net> - 2025-10-06 06:54 -0400
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-06 16:44 +0000
Re: SASOS and virtually tagged caches BGB <cr88192@gmail.com> - 2025-10-03 17:42 -0500
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-04 04:36 +0000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) John Levine <johnl@taugh.com> - 2025-10-04 18:36 +0000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-04 19:00 +0000
Re: SASOS and virtually tagged caches Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-04 12:31 -0700
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Michael S <already5chosen@yahoo.com> - 2025-10-05 01:05 +0300
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) John Levine <johnl@taugh.com> - 2025-10-04 22:44 +0000
Re: SASOS and virtually tagged caches BGB <cr88192@gmail.com> - 2025-10-04 17:57 -0500
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) Michael S <already5chosen@yahoo.com> - 2025-10-05 02:18 +0300
Re: SASOS and virtually tagged caches EricP <ThatWouldBeTelling@thevillage.com> - 2025-10-05 13:02 -0400
Re: SASOS and virtually tagged caches Lynn Wheeler <lynn@garlic.com> - 2025-10-04 14:17 -1000
Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) kegs@provalid.com (Kent Dickey) - 2025-10-06 15:49 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 15:41 +0000
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-10-03 16:19 -0500
Re: Linus Torvalds on bad architectural features John Savard <quadibloc@invalid.invalid> - 2025-10-09 13:57 +0000
Re: Linus Torvalds on bad architectural features John Savard <quadibloc@invalid.invalid> - 2025-10-09 21:41 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-09 22:10 +0000
Re: Linus Torvalds on bad architectural features scott@slp53.sl.home (Scott Lurndal) - 2025-10-09 22:21 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-10 08:30 +0000
Re: Linus Torvalds on bad architectural features scott@slp53.sl.home (Scott Lurndal) - 2025-10-10 15:02 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-11 07:18 +0000
Re: Linus Torvalds on bad architectural features John Levine <johnl@taugh.com> - 2025-10-12 02:37 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 07:13 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 09:51 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 10:14 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 13:56 +0300
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 11:38 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 15:31 +0300
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 13:36 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 20:13 +0300
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 17:47 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-12 19:31 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 13:31 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 15:10 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 15:48 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 16:25 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 17:25 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 20:03 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-12 21:07 +0000
Re: Linus Torvalds on bad architectural features Robert Swindells <rjs@fdy2.co.uk> - 2025-10-13 17:26 +0000
Re: Linus Torvalds on bad architectural features Michael S <already5chosen@yahoo.com> - 2025-10-12 19:56 +0300
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-10-12 17:02 +0000
Re: Linus Torvalds on bad architectural features John Levine <johnl@taugh.com> - 2025-10-12 21:07 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-12 16:11 +0000
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-10-12 13:04 -0500
Re: Linus Torvalds on bad architectural features Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-28 00:10 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-28 17:43 +0000
Re: Linus Torvalds on bad architectural features EricP <ThatWouldBeTelling@thevillage.com> - 2025-12-28 13:34 -0500
Re: Linus Torvalds on bad architectural features Stefan Monnier <monnier@iro.umontreal.ca> - 2025-12-28 13:55 -0500
Re: Linus Torvalds on bad architectural features BGB <cr88192@gmail.com> - 2025-12-28 16:09 -0600
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-12-28 23:00 +0000
Re: Linus Torvalds on bad architectural features anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-29 06:59 +0000
Re: Linus Torvalds on bad architectural features Thomas Koenig <tkoenig@netcologne.de> - 2025-12-29 08:17 +0000
word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-12-29 09:08 +0000
Re: word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-29 13:39 +0000
Re: word order and byte order (was: Linus Torvalds ...) John Levine <johnl@taugh.com> - 2025-12-31 02:54 +0000
Re: word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2025-12-31 09:43 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) John Levine <johnl@taugh.com> - 2026-01-01 17:46 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2026-01-04 00:21 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) John Levine <johnl@taugh.com> - 2026-01-04 04:12 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-04 08:06 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-04 12:20 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-04 18:01 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-04 15:20 -0800
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 09:08 +0000
Re: floating point history, word order and byte order jgd@cix.co.uk (John Dallman) - 2026-01-06 22:06 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-07 13:34 +0200
Re: floating point history, word order and byte order jgd@cix.co.uk (John Dallman) - 2026-01-07 13:16 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-07 17:55 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 17:39 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:58 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 20:05 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-07 23:47 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 22:10 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 00:59 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-07 14:23 -0600
Re: floating point history, word order and byte order Robert Finch <robfi680@gmail.com> - 2026-01-07 21:16 -0500
Re: floating point history, word order and byte order kegs@provalid.com (Kent Dickey) - 2026-01-28 13:25 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-28 15:26 -0600
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-28 23:03 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-28 17:43 -0600
Re: floating point history, word order and byte order Robert Finch <robfi680@gmail.com> - 2026-01-29 03:47 -0500
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-29 21:30 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-29 17:44 -0600
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:56 +0100
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-07 14:38 -0600
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 21:18 +0000
Re: floating point history, word order and byte order BGB <cr88192@gmail.com> - 2026-01-07 16:10 -0600
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 00:05 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 02:38 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-08 10:52 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 18:50 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 13:10 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 18:54 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 21:35 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-09 01:24 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-10 18:02 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-11 15:01 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:18 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-11 20:50 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 22:11 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 12:20 +0200
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-13 14:45 -0500
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-21 01:44 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-21 11:05 +0200
Re: floating point history, word order and byte order Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-14 20:49 -0800
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-21 22:33 +0100
Re: floating point history, word order and byte order Robert Finch <robfi680@gmail.com> - 2026-01-22 14:37 -0500
Re: floating point history, word order and byte order George Neuner <gneuner2@comcast.net> - 2026-01-22 15:12 -0500
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-22 22:57 +0200
Re: floating point history, word order and byte order George Neuner <gneuner2@comcast.net> - 2026-01-23 13:47 -0500
[OT] Usenet (was: floating point history ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-24 15:58 +0000
Re: [OT] Usenet (was: floating point history ...) David LaRue <huey.dll@tampabay.rr.com> - 2026-01-25 01:09 +0000
Re: [OT] Usenet (was: floating point history ...) George Neuner <gneuner2@comcast.net> - 2026-01-25 18:12 -0500
Re: [OT] Usenet (was: floating point history ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-26 21:38 +0000
Re: [OT] Usenet Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2026-01-27 12:19 +0200
Re: [OT] Usenet (was: floating point history ...) George Neuner <gneuner2@comcast.net> - 2026-01-27 06:33 -0500
Re: floating point history, word order and byte order jgd@cix.co.uk (John Dallman) - 2026-01-24 09:11 +0000
Re: floating point history, word order and byte order Brett <ggtgp@yahoo.com> - 2026-01-25 22:13 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 22:30 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 01:07 +0200
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 01:10 +0200
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-12 00:57 +0200
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 01:14 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-11 12:52 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:07 +0000
Re: floating point history, word order and byte order "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-11 12:40 -0800
Re: floating point history, word order and byte order "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-11 15:41 -0800
Re: floating point history, word order and byte order "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-11 15:40 -0800
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 13:05 +0100
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 00:33 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-11 14:31 +0200
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-10 23:21 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 00:03 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 11:21 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:08 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-11 08:38 -0800
Re: floating point history, word order and byte order John Levine <johnl@taugh.com> - 2026-01-11 19:03 +0000
Re: floating point history, word order and byte order Thomas Koenig <tkoenig@netcologne.de> - 2026-01-12 22:22 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-13 09:55 +0100
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-04 18:47 +0000
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-04 14:12 -0500
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-04 20:14 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-04 13:05 -0800
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 08:51 +0000
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-05 11:55 -0500
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-05 19:26 +0200
Re: floating point history, word order and byte order Stefan Monnier <monnier@iro.umontreal.ca> - 2026-01-05 14:33 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-06 17:26 +0000
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 17:40 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-07 17:57 +0000
Re: floating point history, word order and byte order Thomas Koenig <tkoenig@netcologne.de> - 2026-01-09 16:32 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-11 11:49 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-11 18:11 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-12 00:37 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-12 02:05 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-12 16:28 +0100
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 08:16 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 10:21 +0000
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 11:05 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-05 18:03 +0000
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 13:51 -0500
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 14:21 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-06 17:50 +0000
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 10:31 -0500
Re: floating point history, word order and byte order EricP <ThatWouldBeTelling@thevillage.com> - 2026-01-05 11:02 -0500
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-06 18:14 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-05 15:40 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-04 13:22 +0100
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-04 12:36 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Thomas Koenig <tkoenig@netcologne.de> - 2026-01-04 16:45 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-04 19:35 +0200
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-06 12:35 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-06 15:26 +0200
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-06 17:06 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 17:59 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-06 20:15 +0200
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 19:35 +0000
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-06 23:09 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 17:56 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-06 20:12 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-06 19:29 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-07 15:06 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 15:24 +0000
Re: floating point history, word order and byte order (was: Linus Torvalds ...) Michael S <already5chosen@yahoo.com> - 2026-01-07 18:06 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 16:41 +0000
Re: floating point history, word order and byte order antispam@fricas.org (Waldek Hebisch) - 2026-01-07 17:32 +0000
Re: floating point history, word order and byte order scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 19:14 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 12:50 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-08 15:41 +0200
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 21:25 +0100
Re: floating point history, word order and byte order Michael S <already5chosen@yahoo.com> - 2026-01-08 22:50 +0200
Re: floating point history, word order and byte order (was: Linus Torvalds ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 17:44 +0000
Re: floating point history, word order and byte order Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-01-07 10:22 -0800
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:47 +0100
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-07 18:38 +0100
Re: floating point history, word order and byte order anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-01-07 18:38 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 20:11 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-08 13:01 +0100
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-08 18:52 +0000
Re: floating point history, word order and byte order scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 19:19 +0000
Re: floating point history, word order and byte order MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-01-07 19:56 +0000
Re: floating point history, word order and byte order Terje Mathisen <terje.mathisen@tmsw.no> - 2026-01-04 13:17 +0100
Re: Linus Torvalds on bad architectural features Stefan Monnier <monnier@iro.umontreal.ca> - 2025-12-29 13:48 -0500
Re: Linus Torvalds on bad architectural features Bill Findlay <findlaybill@blueyonder.co.uk> - 2025-12-28 19:21 +0000
Re: Linus Torvalds on bad architectural features MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-12-28 21:34 +0000
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 14:31 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260111143154.00007152@yahoo.com> |
| In reply to | #114716 |
On Sun, 11 Jan 2026 00:33:22 -0000 (UTC) antispam@fricas.org (Waldek Hebisch) wrote: > Michael S <already5chosen@yahoo.com> wrote: > > On Tue, 6 Jan 2026 22:06 +0000 (GMT Standard Time) > > jgd@cix.co.uk (John Dallman) wrote: > > > >> In article <2026Jan5.100825@mips.complang.tuwien.ac.at>, > >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> > >> > Possibly. But the lack of takeup of the Intel library and of > >> > the gcc support shows that "build it and they will come" does > >> > not work out for DFP. > >> > >> The world has got very used to IEEE BFP, and has solutions that > >> work acceptably with it. Lots of organisations don't see anything > >> obvious for them in DFP. > >> > >> The thing I'd like to try out is fast quad-precision BFP. For the > >> field I work in, that would make some things much simpler. I did > >> try to interest AMD in the idea in the early days of x86-64, but > >> they didn't bite. > >> > >> John > > > > I already asked you couple of years ago how fast do want binary128 > > in order to consider it fast enough. > > IIRC, you either avoided the answer completely or gave totally > > unrealistic answer like "the same as binary64". > > May be, nobody bites because with non-answers or answers like that > > nobody thinks that you are serious? > > I would hope for half troughput and say 1-2 clocks more latency > for addition. That sounds doable, from power and thermal perspective, but does not sound sufficiently important for anybody to bother. Having addition at half throughput of binary64 instead of quarter would not sell you more chips. > For multiplication I would expect 1/4 troughput > and maybe twice latency than for binary64. > > As of today, there is double-double. IIRC double-double addition > needs 6 double additions, that is way too much. AFAICS > quantifying double-double mutiplication performance is more > tricky: there is relatively easy implementation using > 64-bit multiply-add (it takes adwantage of fact that multiply-add > can deliver low-order bits that only contibute to rounding in > normal FP multiply), but this implements normal multiply in > terms of multiply-add. Implementing multiply-add takes > more effort and impementing multiply only using multiply > tekes even more effort. > Are there compilers that are able to vectirize double-double? If not, any talk about throughput is pointless. > Anyway, to make sense hardware should be faster than double-double. > I disagree. Numeric properties of binary128 are better than double-double. And far easier to analyze, both deeply and applying rules of thumb. As far as I am concerned, the low performance limit for hardware implementation of binary128 is set not by double-double, but by competent implementation of binary128 with integer math, including competent ABI. Current soft binary128 in gcc is ~ factor of two away from that in add/mul/fma, larger factor in div, larger yet in sqrt. As to ABI incompetence in this case, it is hard to quantify. > > Anecdote. > > Few months ago I tried to design very long decimation filters with > > stop band attenuation of ~160 dB. > > Matlab's implementation of Parks–McClellan algorithm (a customize > > variation of Remez Exchange spiced with a small portion of black > > magic) was not up to the task. Gnu Octave implementation was > > somewhat worse yet. > > When I started to investigate the reasons I found out that there > > were actually two of them, both related to insufficient precision > > of the series of DP FP calculations. > > The first was Discreet Cosine Transform and underlying FFT engine > > for N around 32K. > > The second was solving system of linear equations for N around 1000 > > a a little more. > > In both cases precision of DP FP was perfectly sufficient both for > > inputs and for outputs. 32KBut errors accumulated in intermediate > > caused troubles. > > > > In both cases quad-precision FP was key to solution. > > > > For DCT (FFT) I went for full re-implementation at higher > > precision. > > Hmm, I did estimates for FFT and my result was that in classic > implementation each layers of butterflies essentially additively > contributes to L^2 error. So 32K point radix-2 FFT has 15 times > bigger L^2 error than single layer of batterflies, which has error > about 4 times machine epsilon. With radix-4 FFT error of single > batterfly is larger, but number of layers is halved and result > is similar. So, in terms of L^2 error 32K point FFT needs very > little extra precision, essentially 6 bits. My estimated was 7.5 bits. > But Remez works > in term of supremum norm and at 32K points that may need extra > 8 bits. So it if possible that 80-bit format would have enough > accuracy for your purpose. > Yes, 80-bit would suffice. But since it was not time-critical part, I had chose 128 bits. > I looked at FFT as one of possible ways to implement convolution > of integer sequences with exact result. Alas, double precision > computation is good only for about 20 bits for relatively short > seqences and less for longer ones. It seems that integer only > computation is much faster. Fast 128-bit floating point would > shift balance towards floating point, but probably not enough > to beat integer computations. > > > For Linear Solver, I left LU decomposition, which happens to be the > > heavy O(N**3) part in DP. Quad-precision was applied only during > > final solver stages - forward propagation, back propagation, > > calculation of residual error vector and repetition of forward and > > back propagation. All those parts are O(N**2). That modification > > was sufficient to improve precision of result almost to the best > > possible in DP FP format. And sufficient for good convergence of > > Parks–McClellan algorithm. > > Yes, as long as your system is reasonably well conditioned it is > easy to improve accuracy in a postprocessing step. OTOH system > may be so badly conditioned that solving in double precision leads > to catastrophic errors while solving in higher precision works > fine. > That is part of black magic that I mentioned above. Parks–McClellan algorithm works in acos(x) domain. It leads to better conditioned linear systems that when doing Remez taken from math books. At least it's true for sort of filters that are suitable for decimation. > > So, what is a point of my anecdote? > > The speed of quad-precision FP was never an obstacle, even when > > running on rather old hardware. And it's not like calculations here > > were not heavy. They were heavy all right, thank you very much. > > Using quad-precision only when necessary helped. > > But what helped more is not being hesitant. Doing things instead of > > worrying that they would be too slow. > > Well, I have arbitrary precision implementation of LLL algorithm. > It works, but it is about 100 times slower than using double precision > math. My point is that John should measure first. Only after measurements he has full rights to cry "Slow!". > The trouble is, in worst case double precision LLL in > dimension 53 may fail to converge. On tame data LLL is expected > to work in higher dimensions, but even on tame data at dimentsion > about 250 double precision LLL is expected to fail. In a sense > this is no-win situations, as needed number of bits grows linearly > with dimension (both worst case and tame case). One can try to > use double precision when it works. But it is frustrating > how much effort one needs to spend to get better speed using > FPU. And especially, there is contrast with integer math > where it is realatively easy to get higher precisions when > needed. But for integer math RISC-V tries to change this by not > providing carry bit. And, AFAICS SSE/AVX do not provide high > order bits of multiplication (no vectored MULHI instruction), so > multiprecision multiplies must go trough scalar multiplier. > Vectored MULHI exists in SSE/AVX, but it is intended for image processing and for low-end audio processing (16-bit input and output). So it does not help They have width-doubling multiplication that is closer to your need (look for PMULUDQ). It is still rather narrow (32x32=64). However on modern high-end Intel and AMD it provided 2x8 = 16 multiplications per clock, so at least potentially it has higher bandwidth than single 64x64=128bit multiplication in non-SIMD domain. It seems, the most serious problems for attempts to use AVX/AVX512 for very high precision integer math is absence of support for carry chains for items wider than 64 bits. However there are few interesting ideas of how to deal with that limitation by means of speculation and of replacement of data dependencies with control dependencies. The core idea is that carry caused by carry is extremely rare so can be profitably predicted as not happening. It's normally does not matter how slow is the fix when it happened nevertheless. For more concrete examples you can look at discussion of 3-way addition of 64Kbit integers that happened here few months ago.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-01-10 23:21 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jumu2$2khm0$3@paganini.bofh.team> |
| In reply to | #114654 |
John Dallman <jgd@cix.co.uk> wrote:
> In article <2026Jan5.100825@mips.complang.tuwien.ac.at>,
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Possibly. But the lack of takeup of the Intel library and of the
>> gcc support shows that "build it and they will come" does not work
>> out for DFP.
>
> The world has got very used to IEEE BFP, and has solutions that work
> acceptably with it. Lots of organisations don't see anything obvious for
> them in DFP.
AFAICS DFP exists as a standard only because IBM pushed it. I had
a short e-mail exchange with main DFP advocate at IBM. My point
was that purely software implementation of his decimal benchmark had
perfectly adequate performance. His answer was that he knows this,
but that was hand written code that normal users would not write.
Compilers for Cobol could generate such code, but apparently no
existing compilers supported it. He claimed that there
must be hardware support to make it widely available. He somewhat
ignored fact that even with hardware support there still needs
to be support in compilers. And that C++ templates allow
fast fixed point decimals as library feature. If there is no
such library (and I am not aware of one) it is due to low
demand and not due to difficulty.
Anyway, he and IBM succeded pushd the DFP standard, but adoption
is as I and other folks predicted.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-11 00:03 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1768089816-5857@newsgrouper.org> |
| In reply to | #114714 |
antispam@fricas.org (Waldek Hebisch) posted: > John Dallman <jgd@cix.co.uk> wrote: > > In article <2026Jan5.100825@mips.complang.tuwien.ac.at>, > > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > > >> Possibly. But the lack of takeup of the Intel library and of the > >> gcc support shows that "build it and they will come" does not work > >> out for DFP. > > > > The world has got very used to IEEE BFP, and has solutions that work > > acceptably with it. Lots of organisations don't see anything obvious for > > them in DFP. > > AFAICS DFP exists as a standard only because IBM pushed it. I had > a short e-mail exchange with main DFP advocate at IBM. Mike Cow<something>shaw ?? > My point > was that purely software implementation of his decimal benchmark had > perfectly adequate performance. His answer was that he knows this, > but that was hand written code that normal users would not write. > Compilers for Cobol could generate such code, but apparently no > existing compilers supported it. He claimed that there > must be hardware support to make it widely available. He somewhat > ignored fact that even with hardware support there still needs > to be support in compilers. And that C++ templates allow > fast fixed point decimals as library feature. If there is no > such library (and I am not aware of one) it is due to low > demand and not due to difficulty. > > Anyway, he and IBM succeded pushd the DFP standard, but adoption > is as I and other folks predicted. >
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-01-11 11:21 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10k013l$2s84p$1@paganini.bofh.team> |
| In reply to | #114715 |
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>
> antispam@fricas.org (Waldek Hebisch) posted:
>
>> John Dallman <jgd@cix.co.uk> wrote:
>> > In article <2026Jan5.100825@mips.complang.tuwien.ac.at>,
>> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> >
>> >> Possibly. But the lack of takeup of the Intel library and of the
>> >> gcc support shows that "build it and they will come" does not work
>> >> out for DFP.
>> >
>> > The world has got very used to IEEE BFP, and has solutions that work
>> > acceptably with it. Lots of organisations don't see anything obvious for
>> > them in DFP.
>>
>> AFAICS DFP exists as a standard only because IBM pushed it. I had
>> a short e-mail exchange with main DFP advocate at IBM.
>
> Mike Cow<something>shaw ??
Mike Cowlishaw, yes.
>> My point
>> was that purely software implementation of his decimal benchmark had
>> perfectly adequate performance. His answer was that he knows this,
>> but that was hand written code that normal users would not write.
>> Compilers for Cobol could generate such code, but apparently no
>> existing compilers supported it. He claimed that there
>> must be hardware support to make it widely available. He somewhat
>> ignored fact that even with hardware support there still needs
>> to be support in compilers. And that C++ templates allow
>> fast fixed point decimals as library feature. If there is no
>> such library (and I am not aware of one) it is due to low
>> demand and not due to difficulty.
>>
>> Anyway, he and IBM succeded pushd the DFP standard, but adoption
>> is as I and other folks predicted.
>>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-11 18:08 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1768154931-5857@newsgrouper.org> |
| In reply to | #114719 |
antispam@fricas.org (Waldek Hebisch) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > > antispam@fricas.org (Waldek Hebisch) posted: > > > >> John Dallman <jgd@cix.co.uk> wrote: > >> > In article <2026Jan5.100825@mips.complang.tuwien.ac.at>, > >> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> > > >> >> Possibly. But the lack of takeup of the Intel library and of the > >> >> gcc support shows that "build it and they will come" does not work > >> >> out for DFP. > >> > > >> > The world has got very used to IEEE BFP, and has solutions that work > >> > acceptably with it. Lots of organisations don't see anything obvious for > >> > them in DFP. > >> > >> AFAICS DFP exists as a standard only because IBM pushed it. I had > >> a short e-mail exchange with main DFP advocate at IBM. > > > > Mike Cow<something>shaw ?? > > Mike Cowlishaw, yes. Thanks: my memory had it as Cowlingshaw--which I knew was wrong. > > >> My point > >> was that purely software implementation of his decimal benchmark had > >> perfectly adequate performance. His answer was that he knows this, > >> but that was hand written code that normal users would not write. > >> Compilers for Cobol could generate such code, but apparently no > >> existing compilers supported it. He claimed that there > >> must be hardware support to make it widely available. He somewhat > >> ignored fact that even with hardware support there still needs > >> to be support in compilers. And that C++ templates allow > >> fast fixed point decimals as library feature. If there is no > >> such library (and I am not aware of one) it is due to low > >> demand and not due to difficulty. > >> > >> Anyway, he and IBM succeded pushd the DFP standard, but adoption > >> is as I and other folks predicted. > >> >
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-01-11 08:38 -0800 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10k0jmc$1k49$1@dont-email.me> |
| In reply to | #114714 |
On 1/10/2026 3:21 PM, Waldek Hebisch wrote: > John Dallman <jgd@cix.co.uk> wrote: >> In article <2026Jan5.100825@mips.complang.tuwien.ac.at>, >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >> >>> Possibly. But the lack of takeup of the Intel library and of the >>> gcc support shows that "build it and they will come" does not work >>> out for DFP. >> >> The world has got very used to IEEE BFP, and has solutions that work >> acceptably with it. Lots of organisations don't see anything obvious for >> them in DFP. > > AFAICS DFP exists as a standard only because IBM pushed it. While I have no personal knowledge of this, I don't doubt it. > I had > a short e-mail exchange with main DFP advocate at IBM. My point > was that purely software implementation of his decimal benchmark had > perfectly adequate performance. His answer was that he knows this, > but that was hand written code that normal users would not write. > Compilers for Cobol could generate such code, but apparently no > existing compilers supported it. He claimed that there > must be hardware support to make it widely available. He somewhat > ignored fact that even with hardware support there still needs > to be support in compilers. Or perhaps (again, no personal knowledge - just speculation) that supporting an additional data type in the IBM COBOL (and, for what its worth PL/1) compilers is easier if there was hardware support for it. > And that C++ templates allow > fast fixed point decimals as library feature. If there is no > such library (and I am not aware of one) it is due to low > demand and not due to difficulty. For the existing Z series base, I suspect anything related to C++ is not significant, i.e. about as important as DFP is to the typical C++ user. :-) > Anyway, he and IBM succeded pushd the DFP standard, but adoption > is as I and other folks predicted. Yes. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-01-11 19:03 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10k0s6k$m2$1@gal.iecc.com> |
| In reply to | #114724 |
According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>: >> existing compilers supported it. He claimed that there >> must be hardware support to make it widely available. He somewhat >> ignored fact that even with hardware support there still needs >> to be support in compilers. > >Or perhaps (again, no personal knowledge - just speculation) that >supporting an additional data type in the IBM COBOL (and, for what its >worth PL/1) compilers is easier if there was hardware support for it. Having written a few compilers, I can say that it is equally easy within epsilon to emit a DFADD instruction as the equivalent of CALL DFADD. I could believe it's politically easier, hey we'll look dumb if we announce this swell DFP feature and our own compilers don't use it. >> And that C++ templates allow >> fast fixed point decimals as library feature. If there is no >> such library (and I am not aware of one) it is due to low >> demand and not due to difficulty. > >For the existing Z series base, I suspect anything related to C++ is not >significant, i.e. about as important as DFP is to the typical C++ user. :-) Maybe. Remember that IBM has full support for linux on Z. There used to be a pricing hack (may still be) where you could buy a lower cost linux-only Z series processor which was just a regular processor with a microcode tweak to keep it from booting z/OS. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-01-12 22:22 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10k3s6d$2mi9q$2@dont-email.me> |
| In reply to | #114730 |
John Levine <johnl@taugh.com> schrieb: > According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>: >>> existing compilers supported it. He claimed that there >>> must be hardware support to make it widely available. He somewhat >>> ignored fact that even with hardware support there still needs >>> to be support in compilers. >> >>Or perhaps (again, no personal knowledge - just speculation) that >>supporting an additional data type in the IBM COBOL (and, for what its >>worth PL/1) compilers is easier if there was hardware support for it. > > Having written a few compilers, I can say that it is equally easy > within epsilon to emit a DFADD instruction as the equivalent of CALL > DFADD. I could believe it's politically easier, hey we'll look dumb if > we announce this swell DFP feature and our own compilers don't use it. Unfortunately, I do not have access to a machine with an IBM COBOL compiler. It would be interesting to see if it actually uses the decimal float arithmetic. But xlc has an option for that, -qdfp. [...] -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-13 09:55 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10k5195$30jtn$1@dont-email.me> |
| In reply to | #114730 |
John Levine wrote: > According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>: >>> existing compilers supported it. He claimed that there >>> must be hardware support to make it widely available. He somewhat >>> ignored fact that even with hardware support there still needs >>> to be support in compilers. >> >> Or perhaps (again, no personal knowledge - just speculation) that >> supporting an additional data type in the IBM COBOL (and, for what its >> worth PL/1) compilers is easier if there was hardware support for it. > > Having written a few compilers, I can say that it is equally easy > within epsilon to emit a DFADD instruction as the equivalent of CALL > DFADD. I could believe it's politically easier, hey we'll look dumb if > we announce this swell DFP feature and our own compilers don't use it. Back in the FDIV bug days, the workaround code I did most of the writing on simply replaced all FDIV opcodes with a CALL FDIVFIX, none of the compiler teams found that to be any problem at all. For most it was probably just a patch to the code output table? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-04 18:47 +0000 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <1767552440-5857@newsgrouper.org> |
| In reply to | #114600 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > John Levine <johnl@taugh.com> writes: > >Software implmentations of DFP would be slow, but if you know what you are > >doing you can get the correctly rounded declmal results using BFP which I > >would think would be faster. > > If you know what you are doing, you use fixed point for those > financial applications which DFP targets, because that's what finance > used in the old days, and what they laid down in their rules (and > still do; the Euro conversion (early 2000s) has to happen with 4 > decimal digits after the decimal point; which is noted as unusual, > apparently 2 or 3 digits are more common). And whenever I bring that > up, it is explained to me that DFP actually behaves like fixed point. > Which leads to the question why one would use DFP rather than fixed > point. So, would it not be easier and faster to simply make a densely-packed 128-bit Fixed-Point decimal function unit ?!? A rounding mode, and a number of digits below the decimal point, in a control register ???!!! 3-cycle ADD/SUB 6-cycle MUL ~30-cycle DIV > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-01-04 14:12 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <jwvms2tdwn8.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #114608 |
> So, would it not be easier and faster to simply make a densely-packed
> 128-bit Fixed-Point decimal function unit ?!? A rounding mode, and a
> number of digits below the decimal point, in a control register ???!!!
I'm not sure I understand your proposal correctly, but the number of
digits below the decimal point should not be a global setting because
several computations can commonly happen at the same time with different
number of digits below the decimal point.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-04 20:14 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1767557649-5857@newsgrouper.org> |
| In reply to | #114610 |
Stefan Monnier <monnier@iro.umontreal.ca> posted: > > So, would it not be easier and faster to simply make a densely-packed > > 128-bit Fixed-Point decimal function unit ?!? A rounding mode, and a > > number of digits below the decimal point, in a control register ???!!! > > I'm not sure I understand your proposal correctly, It is not so much of a question, as it is my mind rambling through the possibilities. Loosely based on IBM 360--except 2× or 4× as long and stored in densely packed decimal instead of 4-bit digits. No decision on whether data is stored in registers or processed via memory. > but the number of > digits below the decimal point should not be a global setting because > several computations can commonly happen at the same time with different > number of digits below the decimal point. OK, forgot that COBOL has each number defined with its own decimal location. Should each calculation have its own "rounding mode" or "what to do with bits that fall off below the defined Lower-end" ?? It just seems to me that once the "container" is big enough to deal with world GDP (of 2100) in the least valuable currency in the world, that making the decimal point "float" adds little value. > > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-01-04 13:05 -0800 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jekmi$2aob4$1@dont-email.me> |
| In reply to | #114611 |
On 1/4/2026 12:14 PM, MitchAlsup wrote: > > Stefan Monnier <monnier@iro.umontreal.ca> posted: > >>> So, would it not be easier and faster to simply make a densely-packed >>> 128-bit Fixed-Point decimal function unit ?!? A rounding mode, and a >>> number of digits below the decimal point, in a control register ???!!! >> >> I'm not sure I understand your proposal correctly, > > It is not so much of a question, as it is my mind rambling through the > possibilities. Loosely based on IBM 360--except 2× or 4× as long and > stored in densely packed decimal instead of 4-bit digits. No decision > on whether data is stored in registers or processed via memory. > >> but the number of >> digits below the decimal point should not be a global setting because >> several computations can commonly happen at the same time with different >> number of digits below the decimal point. > > OK, forgot that COBOL has each number defined with its own decimal > location. > > Should each calculation have its own "rounding mode" or "what to do > with bits that fall off below the defined Lower-end" ?? COBOL also allows specification of rounded or not on each calculation. I don't know about how it handles different rounding modes. > It just seems to me that once the "container" is big enough to deal > with world GDP (of 2100) in the least valuable currency in the world, > that making the decimal point "float" adds little value. It used to be that people cared about how much storage (both main memory and disk/tape, each data item took, but I think those days are mostly over. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-01-05 08:51 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <2026Jan5.095148@mips.complang.tuwien.ac.at> |
| In reply to | #114611 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: >Should each calculation have its own "rounding mode" or "what to do >with bits that fall off below the defined Lower-end" ?? Yes. If you look at Java's BigDecimal operations <https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html>, they all have versions without and width MathContext (which includes a target scale and a rounding mode), and sometimes additional variants (e.g., divide() has variants where you pass just the rounding mode, or the rounding mode and scale individually instead of through a MathContext). One feature of BigDecimal is arbitrary precision. As we have discussed, that's not necessary for financial calculations. >It just seems to me that once the "container" is big enough to deal >with world GDP (of 2100) in the least valuable currency in the world, >that making the decimal point "float" adds little value. I agree. It also adds little value otherwise, because the regulations specify fixed-point computations. - 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 | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-01-05 11:55 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <jwvv7hg9flg.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #114617 |
> If you look at Java's BigDecimal operations > <https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html>, > they all have versions without and width MathContext (which includes a > target scale and a rounding mode), and sometimes additional variants > (e.g., divide() has variants where you pass just the rounding mode, or > the rounding mode and scale individually instead of through a > MathContext). I wonder how that would compare in practice with a Rational type, where all arithmetic operations are exact (and thus don't need anything like a MathContext) and you simply provide a rounding function that takes two argument: a "target scale" (in the form of a target denominator) and a rounding mode. [ Extra points for implementing compiler optimizations that keep track of the denominators statically to try and do away with the denominators at run-time as much as possible. Maybe also figure out how to eliminate the use of bignums for the numerators. 🙂 ] - Stefan
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-05 19:26 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260105192605.00002394@yahoo.com> |
| In reply to | #114626 |
On Mon, 05 Jan 2026 11:55:21 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > If you look at Java's BigDecimal operations > > <https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html>, > > they all have versions without and width MathContext (which > > includes a target scale and a rounding mode), and sometimes > > additional variants (e.g., divide() has variants where you pass > > just the rounding mode, or the rounding mode and scale individually > > instead of through a MathContext). > > I wonder how that would compare in practice with a Rational type, > where all arithmetic operations are exact (and thus don't need > anything like a MathContext) and you simply provide a rounding > function that takes two argument: a "target scale" (in the form of a > target denominator) and a rounding mode. > > [ Extra points for implementing compiler optimizations that keep track > of the denominators statically to try and do away with the > denominators at run-time as much as possible. Maybe also figure out > how to eliminate the use of bignums for the numerators. 🙂 ] > > > - Stefan exp() would be a challenge.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-01-05 14:33 -0500 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <jwvpl7n3mx3.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #114627 |
Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I wonder how that would compare in practice with a Rational type, > where all arithmetic operations are exact (and thus don't need > anything like a MathContext) and you simply provide a rounding > function that takes two argument: a "target scale" (in the form of a > target denominator) and a rounding mode. [ Note: those two arguments together are basically the same thing as a MathContext. ] Michael S [2026-01-05 19:26:05] wrote: > exp() would be a challenge. [ I assume you mean the case where the exponent is non-integer. ] Not any more than for other approaches, AFAICT. Most likely it would convert to&from float. If you want to be thorough, you'd let it take a MathContext argument and use arbitrary precision floats to perform the computation if the precision of IEEE floats isn't sufficient. Anton Ertl [2026-01-05 17:40:15] wrote: > BigDecimal is almost like what you imagine, except that the > denominators are always powers of 10. Without MathContext addition, > subtraction, and multiplication are exact, and division is also exact > or produces an exception. Hmm... so they're rationals limited to denominators that are powers of 10? I guess it does save them from GCD-style computations to simplify the fractions. > Proper rational arithmetics (used in IIRC Prolog II) is also exact for > division (and has no rounding), It's also available in many other languages as part of the standard library. > but you can get really long numerators and denominators. The only case where the numerators would need to get larger than for BigDecimal if for division (when BigDecimal produces an exception), so I guess that would argue in favor of providing an additional division operation that takes something like a MathContext to avoid the computation of the exact result before doing the rounding (or signaling an exception). Stefan Monnier <monnier@iro.umontreal.ca> wrote: >[ Extra points for implementing compiler optimizations that keep track > of the denominators statically to try and do away with the > denominators at run-time as much as possible. Anton Ertl [2026-01-05 17:40:15] wrote: > For the kind of fixed point used for financial calculation rules, the > scale of every calculation is statically known (it comes out of the > rules), so a compiler for a programming language that has such fixed > point numbers as native type (Cobol, Ada, anything else?) does not > need to check every time whether rescaling is necessary (which > probably happens for Java's BigDecimal). Indeed, that's why I was suggesting it would be useful for the compiler to try and optimize away the management of the scales. If you can move it to types it's of course even better since it removes the need for the optimizer to figure out when and if the optimization can be applied. Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Maybe also figure out how to eliminate the use of bignums for > the numerators. Anton Ertl [2026-01-05 17:40:15] wrote: > I don't think that's possible if the language specifies > arbitrary-precision-arithmetics, because the program processes input > data that ios coming from data sources that can contain > arbitrarily-large numbers. I was assuming we're free to define the semantics of the Rational type, e.g. specifying a limit to the precision. > What is possible, and is done in various dynamically-typed languages > is to have the common case (a bignum that's actually small) unbox, and > use boxing only in those cases where the number exceeds the range of > unboxed numbers. Or that, indeed. [ Tho, I tend to use the word "boxing" in a different way, where I consider both cases "boxed" (i.e. made to fit in a fixed-size (typically 64bit) "box"), just that one of them involves placing the data in a separate memory location and putting the "pointer + tag" in the box, whereas the other puts the "small integer + tag" in that same box. ] - Stefan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-01-06 17:26 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <2026Jan6.182622@mips.complang.tuwien.ac.at> |
| In reply to | #114633 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: >Anton Ertl [2026-01-05 17:40:15] wrote: >> BigDecimal is almost like what you imagine, except that the >> denominators are always powers of 10. Without MathContext addition, >> subtraction, and multiplication are exact, and division is also exact >> or produces an exception. > >Hmm... so they're rationals limited to denominators that are powers >of 10? I guess it does save them from GCD-style computations to simplify >the fractions. Yes. >> but you can get really long numerators and denominators. > >The only case where the numerators would need to get larger than for >BigDecimal if for division (when BigDecimal produces an exception), so >I guess that would argue in favor of providing an additional division >operation that takes something like a MathContext to avoid the >computation of the exact result before doing the rounding (or signaling >an exception). If you have rationals as input numbers, addition and subtraction results in a denominator that has the sum of the number of bits in the operand denominator, and the numerator of the result can also get much larger than the numerators of the operands. Now what happens if you add up a lot of rational numbers. For multiplication in the worst case the numerators have the sum of the bits of ther operand numberators, and likewise for the denominators. If you only have integer inputs and don't have division, that's (big?) integers, not rational numbers. Concerning the idea of division inexact results, I don't think that those people who choose to use rational numbers will choose to use such a division operation in the usual case. If they were satisfied with inexact results, they would have chosen FP (or, for special requirements, something like BigDecimal). >Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Maybe also figure out how to eliminate the use of bignums for >> the numerators. > >Anton Ertl [2026-01-05 17:40:15] wrote: >> I don't think that's possible if the language specifies >> arbitrary-precision-arithmetics, because the program processes input >> data that ios coming from data sources that can contain >> arbitrarily-large numbers. > >I was assuming we're free to define the semantics of the Rational type, >e.g. specifying a limit to the precision. For a general rational type, I expect that it would overflow a fixed size often enough that that would not be practical. For something like BigDecimal and a use in a financial institutions, I think that a 128-bit mantissa (38 significant digits) is good enough for representing any amount of currency occuring in practice. >[ Tho, I tend to use the word "boxing" in a different way, where > I consider both cases "boxed" (i.e. made to fit in a fixed-size > (typically 64bit) "box"), just that one of them involves placing the > data in a separate memory location and putting the "pointer + tag" in > the box, whereas the other puts the "small integer + tag" in that > same box. ] https://en.wikipedia.org/wiki/Boxing_(computer_programming) describes the meaning in common use (that I use, too). - 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-01-05 17:40 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <2026Jan5.184015@mips.complang.tuwien.ac.at> |
| In reply to | #114626 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: >> If you look at Java's BigDecimal operations >> <https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html>, >> they all have versions without and width MathContext (which includes a >> target scale and a rounding mode), and sometimes additional variants >> (e.g., divide() has variants where you pass just the rounding mode, or >> the rounding mode and scale individually instead of through a >> MathContext). > >I wonder how that would compare in practice with a Rational type, where >all arithmetic operations are exact (and thus don't need anything like >a MathContext) and you simply provide a rounding function that takes >two argument: a "target scale" (in the form of a target denominator) and >a rounding mode. BigDecimal is almost like what you imagine, except that the denominators are always powers of 10. Without MathContext addition, subtraction, and multiplication are exact, and division is also exact or produces an exception. The MathContext consists of the target scale and the rounding mode. Proper rational arithmetics (used in IIRC Prolog II) is also exact for division (and has no rounding), but you can get really long numerators and denominators. >[ Extra points for implementing compiler optimizations that keep track > of the denominators statically to try and do away with the > denominators at run-time as much as possible. For the kind of fixed point used for financial calculation rules, the scale of every calculation is statically known (it comes out of the rules), so a compiler for a programming language that has such fixed point numbers as native type (Cobol, Ada, anything else?) does not need to check every time whether rescaling is necessary (which probably happens for Java's BigDecimal). > Maybe also figure out > how to eliminate the use of bignums for the numerators. I don't think that's possible if the language specifies arbitrary-precision-arithmetics, because the program processes input data that ios coming from data sources that can contain arbitrarily-large numbers. What is possible, and is done in various dynamically-typed languages is to have the common case (a bignum that's actually small) unbox, and use boxing only in those cases where the number exceeds the range of unboxed numbers. I have looked at the OpenJDK BigInteger implementation, and there the BigInteger is always boxed (as is everything else in Java that is an object). - 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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-01-07 17:57 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jm6qc$1llu6$3@paganini.bofh.team> |
| In reply to | #114626 |
Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> If you look at Java's BigDecimal operations
>> <https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html>,
>> they all have versions without and width MathContext (which includes a
>> target scale and a rounding mode), and sometimes additional variants
>> (e.g., divide() has variants where you pass just the rounding mode, or
>> the rounding mode and scale individually instead of through a
>> MathContext).
>
> I wonder how that would compare in practice with a Rational type, where
> all arithmetic operations are exact (and thus don't need anything like
> a MathContext) and you simply provide a rounding function that takes
> two argument: a "target scale" (in the form of a target denominator) and
> a rounding mode.
>
> [ Extra points for implementing compiler optimizations that keep track
> of the denominators statically to try and do away with the
> denominators at run-time as much as possible. Maybe also figure out
> how to eliminate the use of bignums for the numerators. 🙂 ]
I use every day a computer algebra system. One possiblity here
is to use arbitrary precision fractions. Observations:
- once there is more complex computation numerators and denominators
tend to be pretty big
- a lot of time is spent computing gcd, but if you try to save on
gcd-s and work with unsimplified fractions you may get trenendous
blowup (like million digit numbers in what should be reasonably
small computation).
- general, if one needs numeric approximation, then arbitrary
precision (software) floating point is much faster
BTW: sometimes people write rational type/class that uses fixed
size numerators and denominators. Such type is useless once
there is longer/less regular seqence of operations: simply
fixed size numbers overflow too easily.
BTW2: Usual trick with rational operations is to estimate size
of final result. If size of final result is known with reasonable
accuracy, than usually computation using a finite fields is much
faster and allows exact recovery of final result.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.arch
csiph-web