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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-04 19:35 +0200 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <20260104193513.0000637c@yahoo.com> |
| In reply to | #114606 |
On Sun, 4 Jan 2026 16:45:10 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Michael S <already5chosen@yahoo.com> schrieb: > > On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >> > >> And two decimal flavors, as well, with binary and densely packed > >> decimal encoding of the significand... it's a bit of a mess. > >> > > > > Since both formats have exactly identical semantics, in theory the > > mess is not worse (and not better) than two bytes orders of IEEE > > binary FP. > > Almost. > > IIRC, there is no restriction on the binary mantissa, so its > range is slightly larger for the same number of bits > (1000/1024)**(n/3). It's true that there is no restriction, but it does not influence semantics. In binary encoding, when the value of significand exceeds 10**(3*J+1)-1 then it is non-canonical representation of zero. It is very similar to how declets in DPD allowed to have all 1024 bit patterns, each pattern has defined numeric value in range [0:999], but 1000 patterns are canonical, i.e.allowed both as inputs and as outputs of arithmetic operations and remaining 24 patterns are non-canonical - accepted as inputs, but never produced as outputs.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-06 12:35 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jis1o$3nkoe$1@dont-email.me> |
| In reply to | #114606 |
Thomas Koenig wrote: > Michael S <already5chosen@yahoo.com> schrieb: >> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) >> Thomas Koenig <tkoenig@netcologne.de> wrote: >> >>> >>> And two decimal flavors, as well, with binary and densely packed >>> decimal encoding of the significand... it's a bit of a mess. >>> >> >> Since both formats have exactly identical semantics, in theory the mess >> is not worse (and not better) than two bytes orders of IEEE binary FP. > > Almost. > > IIRC, there is no restriction on the binary mantissa, so its > range is slightly larger for the same number of bits > (1000/1024)**(n/3). > Sorry, that's wrong: Just like the 24 "spare" DPD patterns are illegal, any mantissa corresponding to a number greater than the maximum allowed (1e34 afair) is also illegal, and there are rules for how to handle both cases (without checking, i seem to remember that they should be treated as zero?) Happy New Year everyone! Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-06 15:26 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260106152646.00007572@yahoo.com> |
| In reply to | #114637 |
On Tue, 6 Jan 2026 12:35:20 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > Thomas Koenig wrote: > > Michael S <already5chosen@yahoo.com> schrieb: > >> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > >> Thomas Koenig <tkoenig@netcologne.de> wrote: > >> > >>> > >>> And two decimal flavors, as well, with binary and densely packed > >>> decimal encoding of the significand... it's a bit of a mess. > >>> > >> > >> Since both formats have exactly identical semantics, in theory the > >> mess is not worse (and not better) than two bytes orders of IEEE > >> binary FP. > > > > Almost. > > > > IIRC, there is no restriction on the binary mantissa, so its > > range is slightly larger for the same number of bits > > (1000/1024)**(n/3). > > > Sorry, that's wrong: > > Just like the 24 "spare" DPD patterns are illegal, Non-canonical, which is not the same as illegal Silently accepted as input operands but never produced as result. > any mantissa > corresponding to a number greater than the maximum allowed (1e34 > afair) is also illegal, and there are rules for how to handle both > cases (without checking, i seem to remember that they should be > treated as zero?) > BID significand extension > max is indeed treated as zeros. Non-canonical DPD declets have non-zero values. They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, and i are in range [0:1]. > Happy New Year everyone! > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-06 17:06 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jjbus$3uhak$1@dont-email.me> |
| In reply to | #114639 |
Michael S wrote: > On Tue, 6 Jan 2026 12:35:20 +0100 > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > >> Thomas Koenig wrote: >>> Michael S <already5chosen@yahoo.com> schrieb: >>>> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: >>>> >>>>> >>>>> And two decimal flavors, as well, with binary and densely packed >>>>> decimal encoding of the significand... it's a bit of a mess. >>>>> >>>> >>>> Since both formats have exactly identical semantics, in theory the >>>> mess is not worse (and not better) than two bytes orders of IEEE >>>> binary FP. >>> >>> Almost. >>> >>> IIRC, there is no restriction on the binary mantissa, so its >>> range is slightly larger for the same number of bits >>> (1000/1024)**(n/3). >>> >> Sorry, that's wrong: >> >> Just like the 24 "spare" DPD patterns are illegal, > > Non-canonical, which is not the same as illegal > Silently accepted as input operands but never produced as result. > >> any mantissa >> corresponding to a number greater than the maximum allowed (1e34 >> afair) is also illegal, and there are rules for how to handle both >> cases (without checking, i seem to remember that they should be >> treated as zero?) >> > > BID significand extension > max is indeed treated as zeros. > Non-canonical DPD declets have non-zero values. > They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, and i are > in range [0:1]. OK, that is probably because allowing them on input is significantly faster/cheaper than having to detect and modify/trap/erase. That said, out of range mantissas could also have been accepted, except they would not have had a valid conversion to either DPD or ascii. 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-06 17:59 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1767722373-5857@newsgrouper.org> |
| In reply to | #114640 |
Terje Mathisen <terje.mathisen@tmsw.no> posted: > Michael S wrote: > > On Tue, 6 Jan 2026 12:35:20 +0100 > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > >> Thomas Koenig wrote: > >>> Michael S <already5chosen@yahoo.com> schrieb: > >>>> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: > >>>> > >>>>> > >>>>> And two decimal flavors, as well, with binary and densely packed > >>>>> decimal encoding of the significand... it's a bit of a mess. > >>>>> > >>>> > >>>> Since both formats have exactly identical semantics, in theory the > >>>> mess is not worse (and not better) than two bytes orders of IEEE > >>>> binary FP. > >>> > >>> Almost. > >>> > >>> IIRC, there is no restriction on the binary mantissa, so its > >>> range is slightly larger for the same number of bits > >>> (1000/1024)**(n/3). > >>> > >> Sorry, that's wrong: > >> > >> Just like the 24 "spare" DPD patterns are illegal, > > > > Non-canonical, which is not the same as illegal > > Silently accepted as input operands but never produced as result. > > > >> any mantissa > >> corresponding to a number greater than the maximum allowed (1e34 > >> afair) is also illegal, and there are rules for how to handle both > >> cases (without checking, i seem to remember that they should be > >> treated as zero?) > >> > > > > BID significand extension > max is indeed treated as zeros. > > Non-canonical DPD declets have non-zero values. > > They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, and i are > > in range [0:1]. > > OK, that is probably because allowing them on input is significantly > faster/cheaper than having to detect and modify/trap/erase. With the calculation latencies of IBM Z-series, modify/trap/erase is of no problem. > That said, out of range mantissas could also have been accepted, except > they would not have had a valid conversion to either DPD or ascii. > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-06 20:15 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260106201515.000054dc@yahoo.com> |
| In reply to | #114644 |
On Tue, 06 Jan 2026 17:59:33 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > Terje Mathisen <terje.mathisen@tmsw.no> posted: > > > Michael S wrote: > > > On Tue, 6 Jan 2026 12:35:20 +0100 > > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > > > >> Thomas Koenig wrote: > > >>> Michael S <already5chosen@yahoo.com> schrieb: > > >>>> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: > > >>>> > > >>>>> > > >>>>> And two decimal flavors, as well, with binary and densely > > >>>>> packed decimal encoding of the significand... it's a bit of a > > >>>>> mess. > > >>>> > > >>>> Since both formats have exactly identical semantics, in theory > > >>>> the mess is not worse (and not better) than two bytes orders > > >>>> of IEEE binary FP. > > >>> > > >>> Almost. > > >>> > > >>> IIRC, there is no restriction on the binary mantissa, so its > > >>> range is slightly larger for the same number of bits > > >>> (1000/1024)**(n/3). > > >>> > > >> Sorry, that's wrong: > > >> > > >> Just like the 24 "spare" DPD patterns are illegal, > > > > > > Non-canonical, which is not the same as illegal > > > Silently accepted as input operands but never produced as result. > > > > > >> any mantissa > > >> corresponding to a number greater than the maximum allowed (1e34 > > >> afair) is also illegal, and there are rules for how to handle > > >> both cases (without checking, i seem to remember that they > > >> should be treated as zero?) > > >> > > > > > > BID significand extension > max is indeed treated as zeros. > > > Non-canonical DPD declets have non-zero values. > > > They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, and i > > > are in range [0:1]. > > > > OK, that is probably because allowing them on input is > > significantly faster/cheaper than having to detect and > > modify/trap/erase. > > With the calculation latencies of IBM Z-series, modify/trap/erase is > of no problem. > How do you know calculation latencies of IBM Z-series? Did they made an information public? > > That said, out of range mantissas could also have been accepted, > > except they would not have had a valid conversion to either DPD or > > ascii. > > > > Terje > >
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-06 19:35 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <1767728134-5857@newsgrouper.org> |
| In reply to | #114647 |
Michael S <already5chosen@yahoo.com> posted: > On Tue, 06 Jan 2026 17:59:33 GMT > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > Terje Mathisen <terje.mathisen@tmsw.no> posted: > > > > > Michael S wrote: > > > > On Tue, 6 Jan 2026 12:35:20 +0100 > > > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > > > > > >> Thomas Koenig wrote: > > > >>> Michael S <already5chosen@yahoo.com> schrieb: > > > >>>> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > > >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >>>> > > > >>>>> > > > >>>>> And two decimal flavors, as well, with binary and densely > > > >>>>> packed decimal encoding of the significand... it's a bit of a > > > >>>>> mess. > > > >>>> > > > >>>> Since both formats have exactly identical semantics, in theory > > > >>>> the mess is not worse (and not better) than two bytes orders > > > >>>> of IEEE binary FP. > > > >>> > > > >>> Almost. > > > >>> > > > >>> IIRC, there is no restriction on the binary mantissa, so its > > > >>> range is slightly larger for the same number of bits > > > >>> (1000/1024)**(n/3). > > > >>> > > > >> Sorry, that's wrong: > > > >> > > > >> Just like the 24 "spare" DPD patterns are illegal, > > > > > > > > Non-canonical, which is not the same as illegal > > > > Silently accepted as input operands but never produced as result. > > > > > > > >> any mantissa > > > >> corresponding to a number greater than the maximum allowed (1e34 > > > >> afair) is also illegal, and there are rules for how to handle > > > >> both cases (without checking, i seem to remember that they > > > >> should be treated as zero?) > > > >> > > > > > > > > BID significand extension > max is indeed treated as zeros. > > > > Non-canonical DPD declets have non-zero values. > > > > They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, and i > > > > are in range [0:1]. > > > > > > OK, that is probably because allowing them on input is > > > significantly faster/cheaper than having to detect and > > > modify/trap/erase. > > > > With the calculation latencies of IBM Z-series, modify/trap/erase is > > of no problem. > > > > How do you know calculation latencies of IBM Z-series? > Did they made an information public? 9-15 months ago there was a presentation of their latest mainframe showing the pipeline lengths. Decode was on the order of 20 cycles, down from the top left; execute was horizontal across the middle; Retire was on the order of 12 cycles, down from the top right; > > > That said, out of range mantissas could also have been accepted, > > > except they would not have had a valid conversion to either DPD or > > > ascii. > > > > > > Terje > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-06 23:09 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260106230933.0000366b@yahoo.com> |
| In reply to | #114651 |
On Tue, 06 Jan 2026 19:35:34 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > Michael S <already5chosen@yahoo.com> posted: > > > On Tue, 06 Jan 2026 17:59:33 GMT > > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > > > Terje Mathisen <terje.mathisen@tmsw.no> posted: > > > > > > > Michael S wrote: > > > > > On Tue, 6 Jan 2026 12:35:20 +0100 > > > > > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > > > > > > > > > >> Thomas Koenig wrote: > > > > >>> Michael S <already5chosen@yahoo.com> schrieb: > > > > >>>> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > > > >>>> Thomas Koenig <tkoenig@netcologne.de> wrote: > > > > >>>> > > > > >>>>> > > > > >>>>> And two decimal flavors, as well, with binary and densely > > > > >>>>> packed decimal encoding of the significand... it's a bit > > > > >>>>> of a mess. > > > > >>>> > > > > >>>> Since both formats have exactly identical semantics, in > > > > >>>> theory the mess is not worse (and not better) than two > > > > >>>> bytes orders of IEEE binary FP. > > > > >>> > > > > >>> Almost. > > > > >>> > > > > >>> IIRC, there is no restriction on the binary mantissa, so its > > > > >>> range is slightly larger for the same number of bits > > > > >>> (1000/1024)**(n/3). > > > > >>> > > > > >> Sorry, that's wrong: > > > > >> > > > > >> Just like the 24 "spare" DPD patterns are illegal, > > > > > > > > > > Non-canonical, which is not the same as illegal > > > > > Silently accepted as input operands but never produced as > > > > > result. > > > > >> any mantissa > > > > >> corresponding to a number greater than the maximum allowed > > > > >> (1e34 afair) is also illegal, and there are rules for how to > > > > >> handle both cases (without checking, i seem to remember that > > > > >> they should be treated as zero?) > > > > >> > > > > > > > > > > BID significand extension > max is indeed treated as zeros. > > > > > Non-canonical DPD declets have non-zero values. > > > > > They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, > > > > > and i are in range [0:1]. > > > > > > > > OK, that is probably because allowing them on input is > > > > significantly faster/cheaper than having to detect and > > > > modify/trap/erase. > > > > > > With the calculation latencies of IBM Z-series, modify/trap/erase > > > is of no problem. > > > > > > > How do you know calculation latencies of IBM Z-series? > > Did they made an information public? > > 9-15 months ago there was a presentation of their latest mainframe > showing the pipeline lengths. > > Decode was on the order of 20 cycles, down from the top left; > execute was horizontal across the middle; > Retire was on the order of 12 cycles, down from the top right; > Back 20 years ago Intel used to have pipelines of comparable depth (IIRC, ~35 cycles in the 3rd and 4th generations of Pentium 4). But despite that, latency of simple ALU ops was 1 clock. Latency of L1D hit was 4 clocks, long for 2005, but standard today. Latencies of FMUL and FADD were 7 and 5 clocks, respectively - long, but not extraordinary. IBM's own POWER6 18 years ago had integer pipeline close to 30 stages and FP pipeline of around 35 stages. However FP MUL/ADD/FMA latency was 6 or 7 clocks. I would expect similar or shorter latency figures for BFP on modern IBM z. Likely shorter, because today they have far more silicon to through on various bypasses. Now, in case of DFP I don't want to guess, because I have no base for guessing.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-06 17:56 +0000 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <1767722183-5857@newsgrouper.org> |
| In reply to | #114602 |
Michael S <already5chosen@yahoo.com> posted: > On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > > > And two decimal flavors, as well, with binary and densely packed > > decimal encoding of the significand... it's a bit of a mess. > > > > Since both formats have exactly identical semantics, in theory the mess > is not worse (and not better) than two bytes orders of IEEE binary FP. Division by 10 is way faster in DPD than in Binary. > I see much bigger problem [than BID vs DPD] in the fact that IEEE > standard does not specify few very important things about global states > and interoperability of BFP and DFP in the same process. Like whether > BFP and DFP have common rounding mode or each one has mode of its own. > The same question about for exception flags and exception masks. > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-06 20:12 +0200 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <20260106201248.00007c6b@yahoo.com> |
| In reply to | #114642 |
On Tue, 06 Jan 2026 17:56:23 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > Michael S <already5chosen@yahoo.com> posted: > > > On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > > > > > > And two decimal flavors, as well, with binary and densely packed > > > decimal encoding of the significand... it's a bit of a mess. > > > > > > > Since both formats have exactly identical semantics, in theory the > > mess is not worse (and not better) than two bytes orders of IEEE > > binary FP. > > Division by 10 is way faster in DPD than in Binary. > Do you consider speed to be part of semantics? Just wondering... > > I see much bigger problem [than BID vs DPD] in the fact that IEEE > > standard does not specify few very important things about global > > states and interoperability of BFP and DFP in the same process. > > Like whether BFP and DFP have common rounding mode or each one has > > mode of its own. The same question about for exception flags and > > exception masks. > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-01-06 19:29 +0000 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <1767727780-5857@newsgrouper.org> |
| In reply to | #114645 |
Michael S <already5chosen@yahoo.com> posted: > On Tue, 06 Jan 2026 17:56:23 GMT > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > Michael S <already5chosen@yahoo.com> posted: > > > > > On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > > > > > > > > > And two decimal flavors, as well, with binary and densely packed > > > > decimal encoding of the significand... it's a bit of a mess. > > > > > > > > > > Since both formats have exactly identical semantics, in theory the > > > mess is not worse (and not better) than two bytes orders of IEEE > > > binary FP. > > > > Division by 10 is way faster in DPD than in Binary. > > > > Do you consider speed to be part of semantics? > Just wondering... More like justification for the facility itself. But also note: DPD can be converted to ASCII all data in parallel without any division going on. Binary does not have that property. > > > I see much bigger problem [than BID vs DPD] in the fact that IEEE > > > standard does not specify few very important things about global > > > states and interoperability of BFP and DFP in the same process. > > > Like whether BFP and DFP have common rounding mode or each one has > > > mode of its own. The same question about for exception flags and > > > exception masks. > > > > > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-07 15:06 +0200 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <20260107150627.0000604e@yahoo.com> |
| In reply to | #114650 |
On Tue, 06 Jan 2026 19:29:40 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > Michael S <already5chosen@yahoo.com> posted: > > > On Tue, 06 Jan 2026 17:56:23 GMT > > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > > > Michael S <already5chosen@yahoo.com> posted: > > > > > > > On Sun, 4 Jan 2026 00:21:31 -0000 (UTC) > > > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > > > > > > > > > > > > And two decimal flavors, as well, with binary and densely > > > > > packed decimal encoding of the significand... it's a bit of a > > > > > mess. > > > > > > > > Since both formats have exactly identical semantics, in theory > > > > the mess is not worse (and not better) than two bytes orders of > > > > IEEE binary FP. > > > > > > Division by 10 is way faster in DPD than in Binary. > > > > > > > Do you consider speed to be part of semantics? > > Just wondering... > > More like justification for the facility itself. > > But also note: DPD can be converted to ASCII all data in parallel > without any division going on. Binary does not have that property. > I took a look at how IBM exploits this property. I don't have up to date zArch manual. It's probably easily available, but right now I have no time or desire to search. So I looked at POWER, which tends to copy DFP stuff from zArch with one generation time gap. POWER ISA v.3.0 (2015) has following relevant instructions: ddedpd - DFP Decode DPD to BCD For Decimal128 it has two forms - convert 32 rightmost digits of significand (unsigned) - convert 31 rightmost digits of significand (signed) With IBM I am never sure what they call 'rightmost' :( If you wonder about couple of remaining digits, IBM has following helper instruction: dscli - DFP shift significand left immediate dscri - DFP shift significand right immediate Once again, since it's IBM, I am not sure about directions. dxex - DFD extract biased exponent. Exponent is extracted in binary form, not in BCD They also have instructions that workd in the opposite direction denbcd - DFP encode BCD to DPD It converts signed 31-digit or unsigned 32-digit BCD-encoded integer to DPD with exponent=0 diex - DFD insert biased exponent. Here too exponent is in binary form, not in BCD. So, POWER hardware helps a lot converting DPD to BCD, but leaves to software the last step of unpacking 4-bit BCD to 8-bit ASCII. Or, may be, they have instruction for that as well, but it's not in DFP related part of the book, so I missed it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-07 15:24 +0000 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <WUu7R.1062260$u2q8.180326@fx11.iad> |
| In reply to | #114662 |
Michael S <already5chosen@yahoo.com> writes: >On Tue, 06 Jan 2026 19:29:40 GMT >MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >So, POWER hardware helps a lot converting DPD to BCD, but leaves to >software the last step of unpacking 4-bit BCD to 8-bit ASCII. That's a fairly simple operation, just adding the proper zone digit (3 for ASCII, F for EBCDIC) to the 8-bit byte. The B3500 (1965) did that in hardware; I would find it strange if the Power CPU didn't. >Or, may be, they have instruction for that as well, but it's not in DFP >related part of the book, so I missed it. It was just a flavor of the move instruction in the B3500.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-07 18:06 +0200 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <20260107180639.00004838@yahoo.com> |
| In reply to | #114664 |
On Wed, 07 Jan 2026 15:24:38 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Tue, 06 Jan 2026 19:29:40 GMT > >MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > > >So, POWER hardware helps a lot converting DPD to BCD, but leaves to > >software the last step of unpacking 4-bit BCD to 8-bit ASCII. > > That's a fairly simple operation, just adding the proper zone > digit (3 for ASCII, F for EBCDIC) to the 8-bit byte. > The hard part is having bits in right places within wide word. I.e. you have 64 bits like that: '0123456789abcdef'. You want to convert it to pair of 64-bit numbers: '0001020304050607', '08090a0b0c0d0e0f' Without HW help it is not fast. Likely not faster than running respective DPD declets through look-up table where you, at least, get 3 ASCII digits per look-up. On modern wide core, likely only marginally faster than converting BYD mantissa. > The B3500 (1965) did that in hardware; > I would find it strange if the Power CPU didn't. > > >Or, may be, they have instruction for that as well, but it's not in > >DFP related part of the book, so I missed it. > > It was just a flavor of the move instruction in the B3500. I am not sure that we are talking about the same thing.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-07 16:41 +0000 |
| Subject | Re: floating point history, word order and byte order (was: Linus Torvalds ...) |
| Message-ID | <W0w7R.176260$WOOa.63446@fx41.iad> |
| In reply to | #114666 |
Michael S <already5chosen@yahoo.com> writes:
>On Wed, 07 Jan 2026 15:24:38 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> >On Tue, 06 Jan 2026 19:29:40 GMT
>> >MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>> >
>>
>> >So, POWER hardware helps a lot converting DPD to BCD, but leaves to
>> >software the last step of unpacking 4-bit BCD to 8-bit ASCII.
>>
>> That's a fairly simple operation, just adding the proper zone
>> digit (3 for ASCII, F for EBCDIC) to the 8-bit byte.
>>
>
>The hard part is having bits in right places within wide word.
>I.e. you have 64 bits like that:
>'0123456789abcdef'. You want to convert it to pair of 64-bit numbers:
>'0001020304050607', '08090a0b0c0d0e0f'
The ASCII[*] would be '3031323334353637', '3839414243444546'. That's
a move from the BCD '0123456789abcdef' to the corresponding ASCII
bytes.
[*] Printable version of the BCD input number.
The B3500 addressed to the digit, so it was a simple move to add
the zone digit when converting to ASCII (or EBCDIC depending on
a processor flag). Although 'undigits' (bit patterns 0b1010
through 0b1111) were not legal in BCD numbers on the B3500
and adding a zone digit to them didn't make them printable.
e.g.
INPUT DATA 8 UN 0123456789 // Unsigned Numeric 8 nibble field
OUTPUT DATA 8 UA // Unsigned Alphanumeric 8 byte field
MVN INPUT(UN), OUTPUT(UA) // yields 'f0f1f2f3f4f5f6f7f8f9' (EBCDIC)
If the output field was larger than the input field, leading
blanks would be added before the number when using MVN. MVA
would blank pad the output field after the number when the
output field was larger.
>Without HW help it is not fast. Likely not faster than running
>respective DPD declets through look-up table where you, at least, get 3
>ASCII digits per look-up. On modern wide core, likely only marginally
>faster than converting BYD mantissa.
>
>> The B3500 (1965) did that in hardware;
>> I would find it strange if the Power CPU didn't.
>>
>> >Or, may be, they have instruction for that as well, but it's not in
>> >DFP related part of the book, so I missed it.
>>
>> It was just a flavor of the move instruction in the B3500.
>
>I am not sure that we are talking about the same thing.
Probably not, since the ASCII zero character is encoded as 0x30
instead of the 0x00 you show in the example above.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-01-07 17:32 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jm5av$1llu6$2@paganini.bofh.team> |
| In reply to | #114667 |
Scott Lurndal <scott@slp53.sl.home> wrote:
> Michael S <already5chosen@yahoo.com> writes:
>>On Wed, 07 Jan 2026 15:24:38 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>> >On Tue, 06 Jan 2026 19:29:40 GMT
>>> >MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>>> >
>>>
>>> >So, POWER hardware helps a lot converting DPD to BCD, but leaves to
>>> >software the last step of unpacking 4-bit BCD to 8-bit ASCII.
>>>
>>> That's a fairly simple operation, just adding the proper zone
>>> digit (3 for ASCII, F for EBCDIC) to the 8-bit byte.
>>>
>>
>>The hard part is having bits in right places within wide word.
>>I.e. you have 64 bits like that:
>>'0123456789abcdef'. You want to convert it to pair of 64-bit numbers:
>>'0001020304050607', '08090a0b0c0d0e0f'
>
> The ASCII[*] would be '3031323334353637', '3839414243444546'. That's
> a move from the BCD '0123456789abcdef' to the corresponding ASCII
> bytes.
>
> [*] Printable version of the BCD input number.
>
> The B3500 addressed to the digit, so it was a simple move to add
> the zone digit when converting to ASCII (or EBCDIC depending on
> a processor flag). Although 'undigits' (bit patterns 0b1010
> through 0b1111) were not legal in BCD numbers on the B3500
> and adding a zone digit to them didn't make them printable.
>
> e.g.
>
> INPUT DATA 8 UN 0123456789 // Unsigned Numeric 8 nibble field
> OUTPUT DATA 8 UA // Unsigned Alphanumeric 8 byte field
>
> MVN INPUT(UN), OUTPUT(UA) // yields 'f0f1f2f3f4f5f6f7f8f9' (EBCDIC)
>
> If the output field was larger than the input field, leading
> blanks would be added before the number when using MVN. MVA
> would blank pad the output field after the number when the
> output field was larger.
>
>>Without HW help it is not fast. Likely not faster than running
>>respective DPD declets through look-up table where you, at least, get 3
>>ASCII digits per look-up. On modern wide core, likely only marginally
>>faster than converting BYD mantissa.
>>
>>> The B3500 (1965) did that in hardware;
>>> I would find it strange if the Power CPU didn't.
>>>
>>> >Or, may be, they have instruction for that as well, but it's not in
>>> >DFP related part of the book, so I missed it.
>>>
>>> It was just a flavor of the move instruction in the B3500.
>>
>>I am not sure that we are talking about the same thing.
>
> Probably not, since the ASCII zero character is encoded as 0x30
> instead of the 0x00 you show in the example above.
IIUC Michael was asking for the following transformation of
on the strings of hex digits:
0123456789abcdef
into
000102030405060708090a0b0c0d0e0f
given (fast) such transformation it is very easy to add proper
zone bits on modern hardware. One possible approach to transform
above would be to do byte type unpacking operation (that is
version of the above working on bytes) and then use masking and
shifting to more upper bits of each byte to the right place.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-07 19:14 +0000 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <4gy7R.1472900$79B9.1228669@fx14.iad> |
| In reply to | #114668 |
antispam@fricas.org (Waldek Hebisch) writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> Michael S <already5chosen@yahoo.com> writes: >>>On Wed, 07 Jan 2026 15:24:38 GMT >>>scott@slp53.sl.home (Scott Lurndal) wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >On Tue, 06 Jan 2026 19:29:40 GMT >>>> >MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >>>> > >>>> >>>> >So, POWER hardware helps a lot converting DPD to BCD, but leaves to >>>> >software the last step of unpacking 4-bit BCD to 8-bit ASCII. >>>> >>>> That's a fairly simple operation, just adding the proper zone >>>> digit (3 for ASCII, F for EBCDIC) to the 8-bit byte. >>>> >>> >>>The hard part is having bits in right places within wide word. >>>I.e. you have 64 bits like that: >>>'0123456789abcdef'. You want to convert it to pair of 64-bit numbers: >>>'0001020304050607', '08090a0b0c0d0e0f' >> >> The ASCII[*] would be '3031323334353637', '3839414243444546'. That's >> a move from the BCD '0123456789abcdef' to the corresponding ASCII >> bytes. >> >> [*] Printable version of the BCD input number. >> >> The B3500 addressed to the digit, so it was a simple move to add >> the zone digit when converting to ASCII (or EBCDIC depending on >> a processor flag). Although 'undigits' (bit patterns 0b1010 >> through 0b1111) were not legal in BCD numbers on the B3500 >> and adding a zone digit to them didn't make them printable. >> >> e.g. >> >> INPUT DATA 8 UN 0123456789 // Unsigned Numeric 8 nibble field >> OUTPUT DATA 8 UA // Unsigned Alphanumeric 8 byte field >> >> MVN INPUT(UN), OUTPUT(UA) // yields 'f0f1f2f3f4f5f6f7f8f9' (EBCDIC) >> >> If the output field was larger than the input field, leading >> blanks would be added before the number when using MVN. MVA >> would blank pad the output field after the number when the >> output field was larger. >> >>>Without HW help it is not fast. Likely not faster than running >>>respective DPD declets through look-up table where you, at least, get 3 >>>ASCII digits per look-up. On modern wide core, likely only marginally >>>faster than converting BYD mantissa. >>> >>>> The B3500 (1965) did that in hardware; >>>> I would find it strange if the Power CPU didn't. >>>> >>>> >Or, may be, they have instruction for that as well, but it's not in >>>> >DFP related part of the book, so I missed it. >>>> >>>> It was just a flavor of the move instruction in the B3500. >>> >>>I am not sure that we are talking about the same thing. >> >> Probably not, since the ASCII zero character is encoded as 0x30 >> instead of the 0x00 you show in the example above. > > >IIUC Michael was asking for the following transformation of >on the strings of hex digits: > >0123456789abcdef > >into > >000102030405060708090a0b0c0d0e0f > >given (fast) such transformation it is very easy to add proper >zone bits on modern hardware. One possible approach to transform >above would be to do byte type unpacking operation (that is >version of the above working on bytes) and then use masking and >shifting to more upper bits of each byte to the right place. Since you know that the zone digit after transformation will always be zero, an arithmetic "OR" of the ASCII/EBCDIC value for '0' (0x30/0xf0) over each byte should be sufficient. e.g. 000102030405060708090a0b0c0d0e0f | 30303030303030303030303030303030
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-08 12:50 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jo5m8$1eqni$1@dont-email.me> |
| In reply to | #114668 |
Waldek Hebisch wrote: > Scott Lurndal <scott@slp53.sl.home> wrote: >> Michael S <already5chosen@yahoo.com> writes: >>> On Wed, 07 Jan 2026 15:24:38 GMT >>> scott@slp53.sl.home (Scott Lurndal) wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>>> On Tue, 06 Jan 2026 19:29:40 GMT >>>>> MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >>>>> >>>> >>>>> So, POWER hardware helps a lot converting DPD to BCD, but leaves to >>>>> software the last step of unpacking 4-bit BCD to 8-bit ASCII. >>>> >>>> That's a fairly simple operation, just adding the proper zone >>>> digit (3 for ASCII, F for EBCDIC) to the 8-bit byte. >>>> >>> >>> The hard part is having bits in right places within wide word. >>> I.e. you have 64 bits like that: >>> '0123456789abcdef'. You want to convert it to pair of 64-bit numbers: >>> '0001020304050607', '08090a0b0c0d0e0f' >> >> The ASCII[*] would be '3031323334353637', '3839414243444546'. That's >> a move from the BCD '0123456789abcdef' to the corresponding ASCII >> bytes. >> >> [*] Printable version of the BCD input number. >> >> The B3500 addressed to the digit, so it was a simple move to add >> the zone digit when converting to ASCII (or EBCDIC depending on >> a processor flag). Although 'undigits' (bit patterns 0b1010 >> through 0b1111) were not legal in BCD numbers on the B3500 >> and adding a zone digit to them didn't make them printable. >> >> e.g. >> >> INPUT DATA 8 UN 0123456789 // Unsigned Numeric 8 nibble field >> OUTPUT DATA 8 UA // Unsigned Alphanumeric 8 byte field >> >> MVN INPUT(UN), OUTPUT(UA) // yields 'f0f1f2f3f4f5f6f7f8f9' (EBCDIC) >> >> If the output field was larger than the input field, leading >> blanks would be added before the number when using MVN. MVA >> would blank pad the output field after the number when the >> output field was larger. >> >>> Without HW help it is not fast. Likely not faster than running >>> respective DPD declets through look-up table where you, at least, get 3 >>> ASCII digits per look-up. On modern wide core, likely only marginally >>> faster than converting BYD mantissa. >>> >>>> The B3500 (1965) did that in hardware; >>>> I would find it strange if the Power CPU didn't. >>>> >>>>> Or, may be, they have instruction for that as well, but it's not in >>>>> DFP related part of the book, so I missed it. >>>> >>>> It was just a flavor of the move instruction in the B3500. >>> >>> I am not sure that we are talking about the same thing. >> >> Probably not, since the ASCII zero character is encoded as 0x30 >> instead of the 0x00 you show in the example above. > > > IIUC Michael was asking for the following transformation of > on the strings of hex digits: > > 0123456789abcdef > > into > > 000102030405060708090a0b0c0d0e0f > > given (fast) such transformation it is very easy to add proper > zone bits on modern hardware. One possible approach to transform > above would be to do byte type unpacking operation (that is > version of the above working on bytes) and then use masking and > shifting to more upper bits of each byte to the right place. > Intel (and then AMD) added PDEP (and the corresponding PEXT) opcode sometime within the last 20 years (probably less than 10?), it is perfect for this operation: ;; rsi has 8 nybbles to unpack into 16 bytes (rdx:rax) mov rbx, 0x0f0f0f0f0f0f0f0f pdep rax,rbx,rsi shr rsi,32 pdep rdx,rbx,rsi This is sub-5 cycles of latency. It is also doable with much older CPUs using the permute/byte shuffle operation, with a bit more or less latency depdning upon where the source and destination data resides (SIMD vs regular integer reg). Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-08 15:41 +0200 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <20260108154117.000012f8@yahoo.com> |
| In reply to | #114694 |
On Thu, 8 Jan 2026 12:50:32 +0100 Terje Mathisen <terje.mathisen@tmsw.no> wrote: > Waldek Hebisch wrote: > > Scott Lurndal <scott@slp53.sl.home> wrote: > >> Michael S <already5chosen@yahoo.com> writes: > >>> On Wed, 07 Jan 2026 15:24:38 GMT > >>> scott@slp53.sl.home (Scott Lurndal) wrote: > >>> > >>>> Michael S <already5chosen@yahoo.com> writes: > >>>>> On Tue, 06 Jan 2026 19:29:40 GMT > >>>>> MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >>>>> > >>>> > >>>>> So, POWER hardware helps a lot converting DPD to BCD, but > >>>>> leaves to software the last step of unpacking 4-bit BCD to > >>>>> 8-bit ASCII. > >>>> > >>>> That's a fairly simple operation, just adding the proper zone > >>>> digit (3 for ASCII, F for EBCDIC) to the 8-bit byte. > >>>> > >>> > >>> The hard part is having bits in right places within wide word. > >>> I.e. you have 64 bits like that: > >>> '0123456789abcdef'. You want to convert it to pair of 64-bit > >>> numbers: '0001020304050607', '08090a0b0c0d0e0f' > >> > >> The ASCII[*] would be '3031323334353637', '3839414243444546'. > >> That's a move from the BCD '0123456789abcdef' to the corresponding > >> ASCII bytes. > >> > >> [*] Printable version of the BCD input number. > >> > >> The B3500 addressed to the digit, so it was a simple move to add > >> the zone digit when converting to ASCII (or EBCDIC depending on > >> a processor flag). Although 'undigits' (bit patterns 0b1010 > >> through 0b1111) were not legal in BCD numbers on the B3500 > >> and adding a zone digit to them didn't make them printable. > >> > >> e.g. > >> > >> INPUT DATA 8 UN 0123456789 // Unsigned Numeric 8 > >> nibble field OUTPUT DATA 8 UA // Unsigned > >> Alphanumeric 8 byte field > >> > >> MVN INPUT(UN), OUTPUT(UA) // yields > >> 'f0f1f2f3f4f5f6f7f8f9' (EBCDIC) > >> > >> If the output field was larger than the input field, leading > >> blanks would be added before the number when using MVN. MVA > >> would blank pad the output field after the number when the > >> output field was larger. > >> > >>> Without HW help it is not fast. Likely not faster than running > >>> respective DPD declets through look-up table where you, at least, > >>> get 3 ASCII digits per look-up. On modern wide core, likely only > >>> marginally faster than converting BYD mantissa. > >>> > >>>> The B3500 (1965) did that in hardware; > >>>> I would find it strange if the Power CPU didn't. > >>>> > >>>>> Or, may be, they have instruction for that as well, but it's > >>>>> not in DFP related part of the book, so I missed it. > >>>> > >>>> It was just a flavor of the move instruction in the B3500. > >>> > >>> I am not sure that we are talking about the same thing. > >> > >> Probably not, since the ASCII zero character is encoded as 0x30 > >> instead of the 0x00 you show in the example above. > > > > > > IIUC Michael was asking for the following transformation of > > on the strings of hex digits: > > > > 0123456789abcdef > > > > into > > > > 000102030405060708090a0b0c0d0e0f > > > > given (fast) such transformation it is very easy to add proper > > zone bits on modern hardware. One possible approach to transform > > above would be to do byte type unpacking operation (that is > > version of the above working on bytes) and then use masking and > > shifting to more upper bits of each byte to the right place. > > > > Intel (and then AMD) added PDEP (and the corresponding PEXT) opcode > sometime within the last 20 years (probably less than 10?), it is > perfect for this operation: > Haswell. Officially launched in June 4, 2013. So 12.5 years ago. Time runs. > ;; rsi has 8 nybbles to unpack into 16 bytes (rdx:rax) > mov rbx, 0x0f0f0f0f0f0f0f0f > pdep rax,rbx,rsi > shr rsi,32 > pdep rdx,rbx,rsi > > This is sub-5 cycles of latency. That's nice. I'm not sure if POWER has similar instruction. > > It is also doable with much older CPUs using the permute/byte shuffle > operation, with a bit more or less latency depdning upon where the > source and destination data resides (SIMD vs regular integer reg). > > Terje > > I don't understand that part. Do you suggest that there are better swizzle instruction than unpack, mentioned by Waldek Hebisch? So far, I don't see so. Unpack looks to me the most suitable.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-01-08 21:25 +0100 |
| Subject | Re: floating point history, word order and byte order |
| Message-ID | <10jp3sl$1ql05$1@dont-email.me> |
| In reply to | #114699 |
Michael S wrote: > On Thu, 8 Jan 2026 12:50:32 +0100 > Terje Mathisen <terje.mathisen@tmsw.no> wrote: > >> Waldek Hebisch wrote: >>> Scott Lurndal <scott@slp53.sl.home> wrote: >>>> Michael S <already5chosen@yahoo.com> writes: >>>>> On Wed, 07 Jan 2026 15:24:38 GMT >>>>> scott@slp53.sl.home (Scott Lurndal) wrote: >>>>> >>>>>> Michael S <already5chosen@yahoo.com> writes: >>>>>>> On Tue, 06 Jan 2026 19:29:40 GMT >>>>>>> MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >>>>>>> >>>>>> >>>>>>> So, POWER hardware helps a lot converting DPD to BCD, but >>>>>>> leaves to software the last step of unpacking 4-bit BCD to >>>>>>> 8-bit ASCII. >>>>>> >>>>>> That's a fairly simple operation, just adding the proper zone >>>>>> digit (3 for ASCII, F for EBCDIC) to the 8-bit byte. >>>>>> >>>>> >>>>> The hard part is having bits in right places within wide word. >>>>> I.e. you have 64 bits like that: >>>>> '0123456789abcdef'. You want to convert it to pair of 64-bit >>>>> numbers: '0001020304050607', '08090a0b0c0d0e0f' >>>> >>>> The ASCII[*] would be '3031323334353637', '3839414243444546'. >>>> That's a move from the BCD '0123456789abcdef' to the corresponding >>>> ASCII bytes. >>>> >>>> [*] Printable version of the BCD input number. >>>> >>>> The B3500 addressed to the digit, so it was a simple move to add >>>> the zone digit when converting to ASCII (or EBCDIC depending on >>>> a processor flag). Although 'undigits' (bit patterns 0b1010 >>>> through 0b1111) were not legal in BCD numbers on the B3500 >>>> and adding a zone digit to them didn't make them printable. >>>> >>>> e.g. >>>> >>>> INPUT DATA 8 UN 0123456789 // Unsigned Numeric 8 >>>> nibble field OUTPUT DATA 8 UA // Unsigned >>>> Alphanumeric 8 byte field >>>> >>>> MVN INPUT(UN), OUTPUT(UA) // yields >>>> 'f0f1f2f3f4f5f6f7f8f9' (EBCDIC) >>>> >>>> If the output field was larger than the input field, leading >>>> blanks would be added before the number when using MVN. MVA >>>> would blank pad the output field after the number when the >>>> output field was larger. >>>> >>>>> Without HW help it is not fast. Likely not faster than running >>>>> respective DPD declets through look-up table where you, at least, >>>>> get 3 ASCII digits per look-up. On modern wide core, likely only >>>>> marginally faster than converting BYD mantissa. >>>>> >>>>>> The B3500 (1965) did that in hardware; >>>>>> I would find it strange if the Power CPU didn't. >>>>>> >>>>>>> Or, may be, they have instruction for that as well, but it's >>>>>>> not in DFP related part of the book, so I missed it. >>>>>> >>>>>> It was just a flavor of the move instruction in the B3500. >>>>> >>>>> I am not sure that we are talking about the same thing. >>>> >>>> Probably not, since the ASCII zero character is encoded as 0x30 >>>> instead of the 0x00 you show in the example above. >>> >>> >>> IIUC Michael was asking for the following transformation of >>> on the strings of hex digits: >>> >>> 0123456789abcdef >>> >>> into >>> >>> 000102030405060708090a0b0c0d0e0f >>> >>> given (fast) such transformation it is very easy to add proper >>> zone bits on modern hardware. One possible approach to transform >>> above would be to do byte type unpacking operation (that is >>> version of the above working on bytes) and then use masking and >>> shifting to more upper bits of each byte to the right place. >>> >> >> Intel (and then AMD) added PDEP (and the corresponding PEXT) opcode >> sometime within the last 20 years (probably less than 10?), it is >> perfect for this operation: >> > > Haswell. Officially launched in June 4, 2013. So 12.5 years ago. > Time runs. > >> ;; rsi has 8 nybbles to unpack into 16 bytes (rdx:rax) >> mov rbx, 0x0f0f0f0f0f0f0f0f >> pdep rax,rbx,rsi >> shr rsi,32 >> pdep rdx,rbx,rsi >> >> This is sub-5 cycles of latency. > > That's nice. > I'm not sure if POWER has similar instruction. > >> >> It is also doable with much older CPUs using the permute/byte shuffle >> operation, with a bit more or less latency depdning upon where the >> source and destination data resides (SIMD vs regular integer reg). >> >> Terje >> >> > > I don't understand that part. Do you suggest that there are better > swizzle instruction than unpack, mentioned by Waldek Hebisch? > So far, I don't see so. Unpack looks to me the most suitable. There are at least three ways to do it: a) PDEP in 64-bit regs b) PSHUFB and nybble masks using SSE/AVX regs c) PUNPACKLBW which expands bytes to words. Do it twice with a bytewise SHR 4 to select the upper nybbles and a mask to keep the lower nybbles of the first part. Did you intend to use (c) or is there yet another method? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.arch
csiph-web