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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | kegs@provalid.com (Kent Dickey) |
|---|---|
| Date | 2025-10-06 15:49 +0000 |
| Subject | Re: SASOS and virtually tagged caches (was: Linus Torvalds on bad architectural features) |
| Message-ID | <10c0odm$d37h$1@dont-email.me> |
| In reply to | #113624 |
In article <10brpft$23go$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote: >It appears that Kent Dickey <kegs@provalid.com> said: >>>AFAIK, the main problem with SASOS is "backward compatibility", most >>>importantly with `fork`. ... > >>First process is ASID=1. It forks, and the child is ASID=2. It is a >>completely new address space. ... Sorry, bad terminology. I just means all addresses under ASID=2 are invalid. In my example, all processes can peek inside any other process's address space, by just forming the 64-bit virtual address. The ASID thing is just a convention, so I wouldn't have to type 16 digit hex numbers over and over. [snip] >The last widely used single address space systems I can think of were OS/VS1 >and OS/VS2 SVS, each of which provided a single full sized address space in >which they essentially ran their real memory predecessors MFT and MVT. As >Lynn has often told us, operating system bloat forced them quickly to go >to MVS, an address space per process. HP-UX on PA-RISC from 1986-2004 or so was effectively a SAS computer. In 32-bit CPUs, the virtual address space was 48 bits, and normal user code could form any 48-bit address, and this was used for shared libraries and shared code (processes running the same executable shared the same virtual address space for the executable). In 64-bit mode, it works mostly as I described. There were 32-bit Space registers which were OR'ed into the upper bits of the 64-bit virtual address, to give the global 64-bit system address. It was an OS convention to limit the Space values to the upper 16 bits or so, and it could change it to whatever it wanted. >I suppose there could still be single address space realtime or >embedded systems where all the programs to be run are known when the >system is built. > > > >-- >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 Kent
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-10-03 15:41 +0000 |
| Message-ID | <1759506094-5857@newsgrouper.org> |
| In reply to | #113595 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > Apparently someone wants to create a big-endian RISC-V, and someone > proposed adding support to that to Linux. This has evoked the > following design guideline for designing bad architectures from Linus > Torvalds (extracted from > <https://lwn.net/ml/all/CAHk-=wji-hEV1U1x92TLsrPbpSPqDD7Cgv2YwzeL-mMbM7iaRA@mail.gmail.com/>): > > |If somebody really wants to create bad hardware in this day and age, > |please do make it big-endian, and also add the following very > |traditional features for sh*t-for-brains hardware: > | > | - virtually tagged caches > | > | You can't really claim to be worst-of-the-worst without virtually > |tagged caches. > | > | Tears of joy as you debug cache alias issues and of flushing caches > |on context switches. Avoided. > | - only do aligned memory accesses > | > | Bonus point for not even faulting, and just loading and storing > |garbage instead. Avoided. > | - expose your pipeline details in the ISA > | > | Delayed branch slots or explicit instruction grouping is a great > |way to show that you eat crayons for breakfast before you start > |designing your hardware platform Avoided > | - extended memory windows > | > | It was good enough for 8-bit machines in order to address more > |memory, and became a HIGHMEM.SYS staple in the DOS world, and then got > |taken up by both x86 and arm in their 32-bit days as HIGHMEM support. Avoided > | It has decades of history, and an architecture cannot be called > |truly awful if it doesn't support some kind of HIGHMEM crap. > | > | - register windows. It's like extended memory, but for your registers! > | > | Please make sure to also have hardware support for filling and > |spilling them, but make it limited enough that system software has to > |deal with faults at critical times. Nesting exceptions is joyful! > | > | Bonus points if they are rotating and overflowing them silently > |just corrupts data. Keep those users on their toes! Avoided > | - in fact, require software fallbacks for pretty much anything unusual. > | > | TLB fills? They might only happen every ten or twenty instructions, > |so make them fault to some software implementation to really show your > |mad hardware skillz. Avoided--and mine are even coherent so you don't even have to shoot them down. > | denormals or any other FP precision issues? No, no, don't waste > |hardware on getting it right, software people *LOVE* to clean up after > |you. > | > | Remember: your mom picked up your dirty laundry from your floor, > |and software people are like the super-moms of the world. Avoided. > | - make exceptions asynchronous. Avoided > | That's another great way to make sure people stay on their toes. > |Make sure machine check exceptions can happen in any context, so that > |you are guaranteed to have a dead machine any time anything goes > |wrong. > | > | But you should also take the non-maskability of NMI to heart, and > |make sure that software cannot possibly write code that is truly > |atomic. Because the NM is NMI is what makes it great! Avoided > | Floating point! Make sure that the special case you don't deal with > |in hardware are also delayed so that the software people have extra > |joy in trying to figure out just WTF happened. See the previous entry: > |they live for that stuff. Avoided > |I'm sure I've forgotten many other points. And I'm sure that hardware > |people will figure it out! > A clean sweep.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-10-03 16:19 -0500 |
| Message-ID | <10bpemo$23ml1$1@dont-email.me> |
| In reply to | #113600 |
On 10/3/2025 10:41 AM, MitchAlsup wrote:
>
> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>> Apparently someone wants to create a big-endian RISC-V, and someone
>> proposed adding support to that to Linux. This has evoked the
>> following design guideline for designing bad architectures from Linus
>> Torvalds (extracted from
>> <https://lwn.net/ml/all/CAHk-=wji-hEV1U1x92TLsrPbpSPqDD7Cgv2YwzeL-mMbM7iaRA@mail.gmail.com/>):
>>
>> |If somebody really wants to create bad hardware in this day and age,
>> |please do make it big-endian, and also add the following very
>> |traditional features for sh*t-for-brains hardware:
>> |
>> | - virtually tagged caches
>> |
>> | You can't really claim to be worst-of-the-worst without virtually
>> |tagged caches.
>> |
>> | Tears of joy as you debug cache alias issues and of flushing caches
>> |on context switches.
>
> Avoided.
>
>> | - only do aligned memory accesses
>> |
>> | Bonus point for not even faulting, and just loading and storing
>> |garbage instead.
>
> Avoided.
>
>> | - expose your pipeline details in the ISA
>> |
>> | Delayed branch slots or explicit instruction grouping is a great
>> |way to show that you eat crayons for breakfast before you start
>> |designing your hardware platform
>
> Avoided
>
>> | - extended memory windows
>> |
>> | It was good enough for 8-bit machines in order to address more
>> |memory, and became a HIGHMEM.SYS staple in the DOS world, and then got
>> |taken up by both x86 and arm in their 32-bit days as HIGHMEM support.
>
> Avoided
>
>> | It has decades of history, and an architecture cannot be called
>> |truly awful if it doesn't support some kind of HIGHMEM crap.
>> |
>> | - register windows. It's like extended memory, but for your registers!
>> |
>> | Please make sure to also have hardware support for filling and
>> |spilling them, but make it limited enough that system software has to
>> |deal with faults at critical times. Nesting exceptions is joyful!
>> |
>> | Bonus points if they are rotating and overflowing them silently
>> |just corrupts data. Keep those users on their toes!
>
> Avoided
>
>> | - in fact, require software fallbacks for pretty much anything unusual.
>> |
>> | TLB fills? They might only happen every ten or twenty instructions,
>> |so make them fault to some software implementation to really show your
>> |mad hardware skillz.
>
> Avoided--and mine are even coherent so you don't even have to shoot
> them down.
>
>> | denormals or any other FP precision issues? No, no, don't waste
>> |hardware on getting it right, software people *LOVE* to clean up after
>> |you.
>> |
>> | Remember: your mom picked up your dirty laundry from your floor,
>> |and software people are like the super-moms of the world.
>
> Avoided.
>
>> | - make exceptions asynchronous.
>
> Avoided
>
>> | That's another great way to make sure people stay on their toes.
>> |Make sure machine check exceptions can happen in any context, so that
>> |you are guaranteed to have a dead machine any time anything goes
>> |wrong.
>> |
>> | But you should also take the non-maskability of NMI to heart, and
>> |make sure that software cannot possibly write code that is truly
>> |atomic. Because the NM is NMI is what makes it great!
>
> Avoided
>
>> | Floating point! Make sure that the special case you don't deal with
>> |in hardware are also delayed so that the software people have extra
>> |joy in trying to figure out just WTF happened. See the previous entry:
>> |they live for that stuff.
>
> Avoided
>
>> |I'm sure I've forgotten many other points. And I'm sure that hardware
>> |people will figure it out!
>>
>
> A clean sweep.
The alternative position might be:
All jank is acceptable so long as it doesn't significantly impede
performance or negatively impact userland.
Or, maybe, actively embracing the "full jank route".
Possibly Torvalds wouldn't exactly approve though...
Well, except for aligned-only and big-endian, better reasons not to go
that way. Better IMO to just leave everything LE and then use byte-swap
instructions for the rare case one needs to access a big-endian variable.
Well, and then be annoyed that C lacks any standard way to specify the
endianess of variables or pointers; and the need to have compiler
builtins which map to to htonl/ntohl/htons/ntohs/... (with the usual
annoyance that one also needs a generic function fallback in the
background for the case where someone wants to take the function pointer
of one of these functions; sorta like with memcpy and similar).
If I were to try to go in a "jank reducing" direction, probably:
Use XG3 as a design base;
Comparably cleaner and more orthogonal than XG1 and XG2.
Eliminate Modal stuff;
Maybe drop the RISC-V conjoined-twin thing;
Hardware page walker and fully IEEE FPU?...
Probably also add cache coherence.
Mandate zero or sign extended registers as the default (like x86-64);
Put FPU status/control into its own register or similar (*1).
...
Though, unclear is if a "good" core by these definitions could be done
without a significant negative impact on FPGA resource budget.
*1: Sticking it into the HOBs of either GP or SP is ugly, and has an
unreasonable level of footgun potential. So, this is pretty high on my
"I probably need to change this before it ends up getting stuck this way
permanently" thing (in which case, would go back to SP[63:48] being
hard-wired to 0).
This is probably one of those "going to change once I come up with a
better option" situations.
Don't really want to define a new CR for this, but need a place to put
it that:
May be exposed to userland without creating problems;
May be saved/restored on context switches.
Actually, relocating it the HOBs of TBR could almost work here:
Already preserved on context switch;
Not directly visible to RISC-V or XG3 via normal registers;
TP is a shadow of TBR in TestKern, but TP is its own register here.
In this case, might change TP from "Read Only in userland" to "Fault on
attempt to modify low 48-bits in Userland".
Exposure to RISC-V land being the bigger problem, as compilers like GCC
are not going to be aware of "various registers may have weird crap
squirreled into the HOBs" type issues.
Granted, Link-Registers have weird stuff in the HOBs, but generally GCC
doesn't poke at the link register. But, then again, there is still the
"glibc violently explodes if I try to use it" issue, and I can't prove
this is not due to the wacky link registers or similar (would have to
more carefully examine it to make sure it isn't doing something weird
here). If it turns out that glibc messes with the link register, may
need to figure out a way to make RV mode work with bare-pointer link
registers.
...
[toc] | [prev] | [next] | [standalone]
| From | John Savard <quadibloc@invalid.invalid> |
|---|---|
| Date | 2025-10-09 13:57 +0000 |
| Message-ID | <10c8evi$2qv77$1@dont-email.me> |
| In reply to | #113595 |
On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl wrote: > Apparently someone wants to create a big-endian RISC-V, and someone > proposed adding support to that to Linux. I had previously seen Linus' specific response to that: support should not be added now, as that would be promoting fragmentation of RISC-V, but, of course, if it was implemented and widely used, of course it would have to be supported in Linux. John Savard
[toc] | [prev] | [next] | [standalone]
| From | John Savard <quadibloc@invalid.invalid> |
|---|---|
| Date | 2025-10-09 21:41 +0000 |
| Message-ID | <10c9a5e$3chr9$1@dont-email.me> |
| In reply to | #113595 |
On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl quoted: > |If somebody really wants to create bad hardware in this day and age, > |please do make it big-endian, and also add the following very > |traditional features for sh*t-for-brains hardware: I think that for a computer to be big-endian is a good thing. It makes it easier to understand core dumps, as numbers are stored just as they are written. But more importantly, it means that binary integers are ordered the same way as packed decimal integers, which are ordered the same way as integers in character text form. As for the _rest_ of the items, though, all of them are indeed bad things. But some are worse than others. > | - only do aligned memory accesses Nearly all memory access are, or could be, aligned. Performance is improved if they are. As long as there's some provision to handle unaligned data, such as a move characters instruction, data structures can be dealt with for things like communications formats. I'm not saying it isn't bad, just that it was excusable before we had as many transistors available as we do now. > | - expose your pipeline details in the ISA The original MIPS did this. This is bad indeed, as whatever you do in this direction won't be applicable to later iterations of the ISA as technology advances. Failing to support the entire IEEE 754 floating-point standard just needs to be documented. Expecting software to fake it being implemented is not reasonable: as long as denormals instead produce zero as the result, one just has an inferior floating-point format, not a computer that doesn't work. Once again, bad, but not all that terrible. But anything that means that programs could randomly fail because interrupts don't properly save or restore the entire machine state... *that* is catastrophically bad, and hardly compares to his other examples. John Savard
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-10-09 22:10 +0000 |
| Message-ID | <1760047810-5857@newsgrouper.org> |
| In reply to | #113680 |
John Savard <quadibloc@invalid.invalid> posted:
> On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl quoted:
> > |If somebody really wants to create bad hardware in this day and age,
> > |please do make it big-endian, and also add the following very
> > |traditional features for sh*t-for-brains hardware:
>
> I think that for a computer to be big-endian is a good thing.
>
> It makes it easier to understand core dumps, as numbers are stored just as
> they are written.
>
> But more importantly, it means that binary integers are ordered the same
> way as packed decimal integers, which are ordered the same way as integers
> in character text form.
Nada true:: packed decimal in LE is stored in the same order as binary.
Bytes at higher addresses are more significant.
> As for the _rest_ of the items, though, all of them are indeed bad things.
>
> But some are worse than others.
>
> > | - only do aligned memory accesses
>
> Nearly all memory access are, or could be, aligned. Performance is
> improved if they are. As long as there's some provision to handle
> unaligned data, such as a move characters instruction, data structures can
> be dealt with for things like communications formats.
> I'm not saying it isn't bad, just that it was excusable before we had as
> many transistors available as we do now.
I am (AM) a BE guy through and through--but even I can read the writing
on the wall. BE is dead and will remain an ever shrinking niche. Making
My 66000 architecture LE was <indeed> painful; but ultimately the correct
decision.
> > | - expose your pipeline details in the ISA
>
> The original MIPS did this. This is bad indeed, as whatever you do in this
> direction won't be applicable to later iterations of the ISA as technology
> advances.
We {the original RISC generation 1 architects} would have all dropped
delayed branches if we believed everyone else would do so. But we knew
they wouldn't, so we couldn't allow ourselves to loose 20% perf, so we
all jumped off the same cliff like lemmings. That was in the 1-wide
generation, by the 2-wide generation we knew it was bad-architecture,
by the 4-wide generation we would have all been better off without.
I do not think any of us would do that to our projects again. I advise
you not too either.
> Failing to support the entire IEEE 754 floating-point standard just needs
> to be documented. Expecting software to fake it being implemented is not
> reasonable: as long as denormals instead produce zero as the result, one
> just has an inferior floating-point format, not a computer that doesn't
> work. Once again, bad, but not all that terrible.
No, just no. There are enough transistors today to "do the right thing"
a) full 754-2019 support
b) misaligned memory
c) hardware table-walkers
d) HyperVisor support
e) an infinite number of interrupt tables
> But anything that means that programs could randomly fail because
> interrupts don't properly save or restore the entire machine state...
> *that* is catastrophically bad, and hardly compares to his other examples.
We now need to provide for situations where the Guest OS fails, or
where Host OS fails; and the system remains up and running while
only a few applications die off and guest OS or Host OS reboots
from checkpoints.
> John Savard
>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-09 22:21 +0000 |
| Message-ID | <szWFQ.39291$RrE7.17772@fx45.iad> |
| In reply to | #113680 |
John Savard <quadibloc@invalid.invalid> writes: >On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl quoted: >> |If somebody really wants to create bad hardware in this day and age, >> |please do make it big-endian, and also add the following very >> |traditional features for sh*t-for-brains hardware: > >I think that for a computer to be big-endian is a good thing. > >It makes it easier to understand core dumps, as numbers are stored just as >they are written. Any good dump analyzer will happily bswap the value before converting it into a printable form on a little-endian system, just to make it readable (when dumping in other than 8-bit units, of course). The only benefit in modern days for big-endian is that network protocols are in big-endian form. Not a big issue with modern LE CPUs, where byteswap is a single cycle instruction.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-10-10 08:30 +0000 |
| Message-ID | <2025Oct10.103003@mips.complang.tuwien.ac.at> |
| In reply to | #113683 |
scott@slp53.sl.home (Scott Lurndal) writes: >The only benefit in modern days for big-endian is that network >protocols are in big-endian form. Not a big issue with modern >LE CPUs, where byteswap is a single cycle instruction. Clever architects put the byte swap it in the load and store instructions, where the byte-swapping is just an addition to the handling of misaligned loads and stores, which itself is an addition to the handling of smaller-than-transfer-width accesses. PowerPC has such instructions. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-10 15:02 +0000 |
| Message-ID | <Zd9GQ.7802$Je0d.6574@fx03.iad> |
| In reply to | #113689 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >scott@slp53.sl.home (Scott Lurndal) writes: >>The only benefit in modern days for big-endian is that network >>protocols are in big-endian form. Not a big issue with modern >>LE CPUs, where byteswap is a single cycle instruction. > >Clever architects put the byte swap it in the load and store >instructions, where the byte-swapping is just an addition to the >handling of misaligned loads and stores, which itself is an addition >to the handling of smaller-than-transfer-width accesses. PowerPC has >such instructions. Even better, hardware network accelerators bypass the CPU entirely whan working with packets.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-10-11 07:18 +0000 |
| Message-ID | <2025Oct11.091816@mips.complang.tuwien.ac.at> |
| In reply to | #113680 |
John Savard <quadibloc@invalid.invalid> writes: >On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl quoted: >> |If somebody really wants to create bad hardware in this day and age, >> |please do make it big-endian, and also add the following very >> |traditional features for sh*t-for-brains hardware: > >I think that for a computer to be big-endian is a good thing. Whatever the technical merits of different byte orders may be (and the names "big-endian" and "little-endian" already indicate that far more discussion has been expended on the topic than these merits justify <https://en.wikipedia.org/wiki/Lilliput_and_Blefuscu#History_and_politics>), little-endian has won, and that's its major merit, and big-endian's major demerit. Any big-endian architecture will suffer from less software support, and conversely, if software wants to include support for this hardware, that results in extra development effort, i.e., extra cost (not for all software, but for some). And Linus Torvalds is not willing to expend this effort, not even if the initial patches for supporting such an architecture come for free, because the additional effort would be ongoing. IBM has recognized the sign of the times, and added full-blown little-endian support to Power (including unaligned accesses), and in their Linux efforts retracted their support for the big-endian Power and threw their weight behind little-endian Power. Standardization has lots of merits, and deviating from an established standard is a step one should not take lightly. >But more importantly, it means that binary integers are ordered the same >way as packed decimal integers, which are ordered the same way as integers >in character text form. Says who? In a course we were a group of five who had to write some program dealing with BCD numbers in 80286 assembly language. We divided the work up, with each one writing some routines. Evantually, on integration testing, we found that half of the group had interpreted the numbers to be represented in little-endian order (because the CPU was little-endian), and the other half had interpreted them to be represented in big-endian order (because that results in more readable memory dumps); and none of us thought that any of the others would implement the other byte order. So no, the byte order of BCD numbers is not obvious. >> | - only do aligned memory accesses > >Nearly all memory access are, or could be, aligned. Performance is >improved if they are. As long as there's some provision to handle >unaligned data, such as a move characters instruction, data structures can >be dealt with for things like communications formats. >I'm not saying it isn't bad, just that it was excusable before we had as >many transistors available as we do now. Again, the merit of supporting unaligned accesses in this day and age is that more software will run on your hardware, and the demerit of not doing it is that extra software effort is required for some software to support it, as you outline. >Failing to support the entire IEEE 754 floating-point standard just needs >to be documented. Expecting software to fake it being implemented is not >reasonable: as long as denormals instead produce zero as the result, one >just has an inferior floating-point format, not a computer that doesn't >work. Software that expects a-b == 0.0 to give the same result as a==b (as guaranteed by IEEE 754 40 years ago) won't work. What do you mean with "not a computer that does not work" if the computer does not run software with the intended results? I take pride in the portability of my software, but for things that have been settled in the mainstream (byte order, alignment, IEEE FP, among other things), there must be a very good reason to support deviants. E.g., RWX mappings have worked on every OS since the beginning of mmap(), and are necessary for JITs. Trying to mmap RWX fails on MacOS on Apple Silicon (it works on the same MacOS version on Intel hardware, and it works on the same Apple Silicon under Linux, so this is a voluntary removal of a capability by Apple). As a result, the development version of Gforth did not work on MacOS on Apple Silicon for several years. My plan for fixing that was to just disable the JIT compiler and fall back to the threaded code interpreter on that OS, but Bernd Paysan actually decided to jump through the hoops that Apple sets up for people writing JIT compilers. The result is a speedup by a factor 2-3 (times are run-times in seconds): sieve bubble matrix fib fft 0.108 0.107 0.071 0.119 0.057 threaded code on Mac Mini M1 MacOS 0.052 0.041 0.027 0.038 0.018 JIT compiler on Mac Mini M1 MacOS 0.029 0.034 0.015 0.044 0.015 JIT compiler on Core i5-1135G7 Linux For comparison, I also provided numbers for laptop hardware contemporary with the M1. - 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 | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-10-12 02:37 +0000 |
| Message-ID | <10cf49k$21aq$1@gal.iecc.com> |
| In reply to | #113694 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >John Savard <quadibloc@invalid.invalid> writes: >>On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl quoted: >>> |If somebody really wants to create bad hardware in this day and age, >>> |please do make it big-endian, and also add the following very >>> |traditional features for sh*t-for-brains hardware: >> >>I think that for a computer to be big-endian is a good thing. Garrrgghhhhhhhh, not this again. >Whatever the technical merits of different byte orders may be (and the >names "big-endian" and "little-endian" already indicate that far more >discussion has been expended on the topic than these merits justify ><https://en.wikipedia.org/wiki/Lilliput_and_Blefuscu#History_and_politics>), >little-endian has won, and that's its major merit, and big-endian's >major demerit. Yup. I really wish the arguments about which order is "more natural" would stop since they're just people's cultural preconceptions. I imagine that if my first language were Arabic or Hebrew, I would find left-to-right big-endian core dumps much less readable than the familiar looking right-to-left little-endian ones. But as you correctly said, the fight is over, little-endian has won, let's argue about something else. IEN 137 said everything worth saying about this topic 45 years ago. https://www.rfc-editor.org/ien/ien137.txt -- 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 | 2025-10-12 07:13 +0000 |
| Message-ID | <10cfkfl$1a6cp$1@dont-email.me> |
| In reply to | #113700 |
John Levine <johnl@taugh.com> schrieb: > But as you correctly said, the fight is over, little-endian has won, > let's argue about something else. There is something to be said for at least having a big-endian system around to test programs: If people mismatch types, there is a chance that it will blow up on a big-endian system and work silently on a little-endian system. This has a reverse side: Little-endian having effectively won, software often does not work on big-endian systems out of the box any more. I suspect this is why IBM effectively chose little-endian for POWER, but AIX is big-endian (and will remain so for the forseeable future). And of course, this is all due to an architecture which is arguably the most influential of all times (or at least has the highest ratio of influence to recognition level, but that by a _huge_ margin): The Datapoint 2200. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-10-12 09:51 +0000 |
| Message-ID | <2025Oct12.115138@mips.complang.tuwien.ac.at> |
| In reply to | #113703 |
Thomas Koenig <tkoenig@netcologne.de> writes: >There is something to be said for at least having a big-endian >system around to test programs: If people mismatch types, there >is a chance that it will blow up on a big-endian system and work >silently on a little-endian system. If the only thing wrong with the software is that it does not work on big-endian systems, and little-endian has won, is there really anything wrong with the software? >This has a reverse side: Little-endian having effectively won, >software often does not work on big-endian systems out of the box >any more. I suspect this is why IBM effectively chose little-endian >for POWER, but AIX is big-endian (and will remain so for the forseeable >future). If someone chooses to buy a big-endian system nowadays, they hopefully know about these problems. If they need a particular piece of software, they hopefully are able to sponsor porting it to the big-endian system. >And of course, this is all due to an architecture which is arguably >the most influential of all times (or at least has the highest >ratio of influence to recognition level, but that by a _huge_ margin): >The Datapoint 2200. Another widely-used architecture today inherited its byte order from the 6502. But the actual reason why little-endian has won is that all the big-endian architectures either have been cancelled (HPPA, MIPSeb, SPARC), switched to little-endian (Power on Linux), or are retreating to a niche (Power on AIX, S390x). - 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 | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-10-12 10:14 +0000 |
| Message-ID | <10cfv1g$1cvp5$1@dont-email.me> |
| In reply to | #113704 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>There is something to be said for at least having a big-endian >>system around to test programs: If people mismatch types, there >>is a chance that it will blow up on a big-endian system and work >>silently on a little-endian system. > > If the only thing wrong with the software is that it does not work on > big-endian systems, and little-endian has won, is there really > anything wrong with the software? A type mismatch? I think so. >>And of course, this is all due to an architecture which is arguably >>the most influential of all times (or at least has the highest >>ratio of influence to recognition level, but that by a _huge_ margin): >>The Datapoint 2200. > > Another widely-used architecture today inherited its byte order from > the 6502. Which one? -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-12 13:56 +0300 |
| Message-ID | <20251012135625.00005fe3@yahoo.com> |
| In reply to | #113705 |
On Sun, 12 Oct 2025 10:14:08 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > > Thomas Koenig <tkoenig@netcologne.de> writes: > >>There is something to be said for at least having a big-endian > >>system around to test programs: If people mismatch types, there > >>is a chance that it will blow up on a big-endian system and work > >>silently on a little-endian system. > > > > If the only thing wrong with the software is that it does not work > > on big-endian systems, and little-endian has won, is there really > > anything wrong with the software? > > A type mismatch? I think so. > > >>And of course, this is all due to an architecture which is arguably > >>the most influential of all times (or at least has the highest > >>ratio of influence to recognition level, but that by a _huge_ > >>margin): The Datapoint 2200. > > > > Another widely-used architecture today inherited its byte order from > > the 6502. > > Which one? Arm. It was designed as CPU for successor of 6502-based BBC Micro. But does 6502 really have "byte order" in hardware? Or just "soft" conventions of BBC BASIC interpreter?
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-10-12 11:38 +0000 |
| Message-ID | <10cg3vv$1e9b5$1@dont-email.me> |
| In reply to | #113706 |
Michael S <already5chosen@yahoo.com> schrieb: > On Sun, 12 Oct 2025 10:14:08 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> > Thomas Koenig <tkoenig@netcologne.de> writes: >> >>There is something to be said for at least having a big-endian >> >>system around to test programs: If people mismatch types, there >> >>is a chance that it will blow up on a big-endian system and work >> >>silently on a little-endian system. >> > >> > If the only thing wrong with the software is that it does not work >> > on big-endian systems, and little-endian has won, is there really >> > anything wrong with the software? >> >> A type mismatch? I think so. >> >> >>And of course, this is all due to an architecture which is arguably >> >>the most influential of all times (or at least has the highest >> >>ratio of influence to recognition level, but that by a _huge_ >> >>margin): The Datapoint 2200. >> > >> > Another widely-used architecture today inherited its byte order from >> > the 6502. >> >> Which one? > > Arm. That does not have many architectural features from the 6502 :-) >It was designed as CPU for successor of 6502-based BBC Micro. > > But does 6502 really have "byte order" in hardware? Or just "soft" > conventions of BBC BASIC interpreter? Yes, the 6502 is little-endian, which you can see in its instruction formats and the way the pointers in the zero page were stored. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-12 15:31 +0300 |
| Message-ID | <20251012153121.000003ba@yahoo.com> |
| In reply to | #113707 |
On Sun, 12 Oct 2025 11:38:39 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Michael S <already5chosen@yahoo.com> schrieb: > > On Sun, 12 Oct 2025 10:14:08 -0000 (UTC) > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > >> > Thomas Koenig <tkoenig@netcologne.de> writes: > >> >>There is something to be said for at least having a big-endian > >> >>system around to test programs: If people mismatch types, there > >> >>is a chance that it will blow up on a big-endian system and work > >> >>silently on a little-endian system. > >> > > >> > If the only thing wrong with the software is that it does not > >> > work on big-endian systems, and little-endian has won, is there > >> > really anything wrong with the software? > >> > >> A type mismatch? I think so. > >> > >> >>And of course, this is all due to an architecture which is > >> >>arguably the most influential of all times (or at least has the > >> >>highest ratio of influence to recognition level, but that by a > >> >>_huge_ margin): The Datapoint 2200. > >> > > >> > Another widely-used architecture today inherited its byte order > >> > from the 6502. > >> > >> Which one? > > > > Arm. > > That does not have many architectural features from the 6502 :-) It has the same byte order. CZVN flags are superficially similar, although there is an important difference - on ARM Z flag is not affected by non-arithmetic instructions. Also both processors appear to share a philosophy of design driven by practicality rather than by theoretical principles. They are what they are because that was a maximum that comfortably fit into available budgets of all sorts rather than because of "closing semantic gap" or conversly "reducing instruction set". > > >It was designed as CPU for successor of 6502-based BBC Micro. > > > > But does 6502 really have "byte order" in hardware? Or just "soft" > > conventions of BBC BASIC interpreter? > > Yes, the 6502 is little-endian, > which you can see in its instruction formats That does not count. Instruction encoding is orthogonal to the question of byte order during execution. I had seen various combinations. Including encodings that have no particular order, i.e. immediate field scattered in instruction word. Not that I remember which architecture it was. > and the way the pointers in the zero page were stored. > Yes, I see. Indirect addressing modes are clearly LE. In case of JMP instruction 16-bit LE pointer does not even have to be in zero page.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-10-12 13:36 +0000 |
| Message-ID | <2025Oct12.153651@mips.complang.tuwien.ac.at> |
| In reply to | #113708 |
Michael S <already5chosen@yahoo.com> writes: >On Sun, 12 Oct 2025 11:38:39 -0000 (UTC) >Thomas Koenig <tkoenig@netcologne.de> wrote: > >> Michael S <already5chosen@yahoo.com> schrieb: >> > Arm. >> >> That does not have many architectural features from the 6502 :-) > >It has the same byte order. Which is what is relevant for the question at hand. The intention of the ARM architects was to produce a CPU for their successor of the BBC Micro, and they certainly mentioned the prominent role of the 6502 as inspiration in their accounts; they obviously did not try to create a 32-bit 6502, but at least they did not change the byte order. >CZVN flags are superficially similar, although there is an important >difference - on ARM Z flag is not affected by non-arithmetic >instructions. What about the other flags? My impression was that ARM instruction sets always set NZCV together, which makes OoO implementation quite a bit cheaper. Looking in Zaks' 6502 book, I find that SBC sets NVZC, whereas CMP only sets NZC (and lots of other instructions only set NZ). I expect that this difference between SBC and CMP cost a transistor or two. I wonder why they did that. Only setting NZ on, e.g., INC/INX/INY probably also cost some transistors, but allowed to keep C in. e.g. a long-addition loop. >> Yes, the 6502 is little-endian, >> which you can see in its instruction formats > >That does not count. Instruction encoding is orthogonal to the question >of byte order during execution. I had seen various combinations. >Including encodings that have no particular order, i.e. immediate field >scattered in instruction word. Not that I remember which architecture it >was. In many (e.g., HPPA, RISC-V, funny constant encodings on ARM A64). However, on the 6502 it is significant, because the instructions are read byte-by-byte. They switched from the 6800's big-endian order to little-endian because the latter was cheaper and faster to implement especially in the instructions. For the data, they could have accessed two-byte data backwards and become big-endian (but with the address pointing to the LSB, and the MSB being at address-1) without much difficulty. The unusual address could be hidden by the assembler (i.e., if you write "lda (2),y", that would be encoded as $b1 $3. >Indirect addressing modes are clearly LE. >In case of JMP instruction 16-bit LE pointer does not even have to be in >zero page. JSR stores the return address in little-endian order and RTS loads the address to return to in little-endian order. - 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-12 20:13 +0300 |
| Message-ID | <20251012201357.00006da5@yahoo.com> |
| In reply to | #113710 |
On Sun, 12 Oct 2025 13:36:51 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Sun, 12 Oct 2025 11:38:39 -0000 (UTC) > >Thomas Koenig <tkoenig@netcologne.de> wrote: > > > >> Michael S <already5chosen@yahoo.com> schrieb: > >> > Arm. > >> > >> That does not have many architectural features from the 6502 :-) > > > >It has the same byte order. > > Which is what is relevant for the question at hand. The intention of > the ARM architects was to produce a CPU for their successor of the BBC > Micro, and they certainly mentioned the prominent role of the 6502 as > inspiration in their accounts; they obviously did not try to create a > 32-bit 6502, but at least they did not change the byte order. > > >CZVN flags are superficially similar, although there is an important > >difference - on ARM Z flag is not affected by non-arithmetic > >instructions. > > What about the other flags? Sorry, my mistake. On 6502 Z is not the only flag that is affected by non-arithmetic instructions. N is affected as well. Also, apart fron different flags-handling by INC/DEC, which is fully expected, there are differences in Logical, shift and evenin compare instruuctions. So, the two architectures are more far apart in flags handling then I thought. Convinient reference here: http://www.6502.org/users/obelisk/6502/instructions.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-10-12 17:47 +0000 |
| Message-ID | <2025Oct12.194741@mips.complang.tuwien.ac.at> |
| In reply to | #113717 |
Michael S <already5chosen@yahoo.com> writes: >On Sun, 12 Oct 2025 13:36:51 GMT >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >CZVN flags are superficially similar, although there is an important >> >difference - on ARM Z flag is not affected by non-arithmetic >> >instructions. >> >> What about the other flags? > >Sorry, my mistake. On 6502 Z is not the only flag that is affected by >non-arithmetic instructions. N is affected as well. >Also, apart fron different flags-handling by INC/DEC, which is >fully expected, there are differences in Logical, shift and evenin >compare instruuctions. >So, the two architectures are more far apart in flags handling then I >thought. But I don't think that the ARM architects considered that to be a problem. The instructions were different anyway, and they did not want to have an 8086-style 6502->ARM assembly-language translator, did they? Anyway, for an OoO implementation the important question is if ARM always updates all of NZCV at the same time, or if it is selective in the updates. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web