Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #55820 > unrolled thread
| Started by | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| First post | 2026-07-11 17:11 +0200 |
| Last post | 2026-07-27 06:57 +0200 |
| Articles | 20 on this page of 339 — 28 participants |
Back to article view | Back to de.alt.folklore.computer
[aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-11 17:11 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marco Moock <mm@dorfdsl.de> - 2026-07-11 17:32 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Ralph Aichinger <ra@h5.or.at> - 2026-07-11 17:07 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-11 22:54 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-12 14:46 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marco Moock <mm@dorfdsl.de> - 2026-07-14 06:17 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-14 10:14 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-14 18:52 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marco Moock <mm@dorfdsl.de> - 2026-07-14 20:48 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Christian Weisgerber <naddy@mips.inka.de> - 2026-07-14 19:51 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-15 08:19 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-15 06:43 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-15 12:08 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-15 13:42 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-15 22:05 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-16 18:23 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-17 12:12 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-17 17:00 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-17 15:43 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-17 18:54 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-17 18:57 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-18 08:43 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-18 11:02 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-18 16:16 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-18 15:11 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-19 14:29 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-19 16:56 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-19 19:07 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-19 20:12 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-21 16:41 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-21 17:41 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-21 19:27 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-21 16:39 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Sebastian Barthel <naitsabes@freenet.de> - 2026-07-21 20:39 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2026-07-21 21:20 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-22 12:15 +0200
Feenstaub gegen echte Geldstücke auch für Minderjährige? (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-22 19:06 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-25 19:15 +0200
Free-to-play (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-26 08:16 +0200
Not free to spend (was: Free-to-play) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-26 12:01 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-26 10:18 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-26 22:05 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 07:37 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-27 09:27 +0200
Re: Not free to spend Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:21 +0000
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-27 06:21 +0000
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-26 17:42 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 10:43 +0200
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 18:00 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 18:54 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 20:17 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-07-27 20:52 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 23:04 +0200
Re: BNPL (was: Not free to spend) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 22:42 +0200
Re: BNPL (was: Not free to spend) Thomas Koenig <tkoenig@netcologne.de> - 2026-07-28 05:12 +0000
Re: BNPL (was: Not free to spend) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-28 08:55 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-28 17:38 +0200
Re: BNPL (was: Not free to spend) Michael Noe <michaelnoeusenet@mac.com> - 2026-07-28 07:07 +0000
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-27 21:35 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-28 23:35 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-29 02:00 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-29 13:25 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-30 16:29 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-07-30 21:59 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 09:23 +0200
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-29 18:21 +0200
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-30 13:27 +0200
Überschuldung von jungen Leute auch durch BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-30 14:57 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:21 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Kay Martinen <usenet@martinen.de> - 2026-07-31 12:32 +0200
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 13:59 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 12:10 +0000
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 16:21 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:35 +0200
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 17:24 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 15:33 +0000
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 18:54 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:26 +0200
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 17:59 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 16:06 +0000
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 19:03 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-08-03 10:09 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-30 17:13 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-30 17:25 +0200
Re: BNPL Guido Grohmann <guido.grohmann@gmx.de> - 2026-07-30 22:51 +0200
Re: BNPL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-01 07:00 +0200
Re: BNPL Thomas Koenig <tkoenig@netcologne.de> - 2026-08-04 16:48 +0000
Seltsame Namensableitungen (was: BNPL) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-04 20:33 +0200
Re: Seltsame Namensableitungen (was: BNPL) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-04 19:21 +0000
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-04 21:39 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-05 11:08 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-05 12:03 +0200
Re: Seltsame Namensableitungen Arno Welzel <usenet@arnowelzel.de> - 2026-08-05 20:25 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 01:59 +0200
Re: Seltsame Namensableitungen Arno Welzel <usenet@arnowelzel.de> - 2026-08-07 16:18 +0200
Re: Seltsame Namensableitungen Arno Welzel <usenet@arnowelzel.de> - 2026-08-07 16:19 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-05 16:29 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-05 16:29 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-05 18:15 +0000
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-05 20:44 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-06 06:17 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:23 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 02:10 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-06 21:35 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-08 09:04 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-08 12:55 +0200
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-08 15:11 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-08 20:30 +0000
Zeichenkodierungen (was: Seltsame Namensableitungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 11:57 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 14:24 +0000
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 18:09 +0200
Re: Zeichenkodierungen Kay Martinen <usenet@martinen.de> - 2026-08-09 22:27 +0200
Re: Zeichenkodierungen Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-10 18:50 +0200
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 19:36 +0200
Re: Zeichenkodierungen Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-11 07:57 +0000
Re: Zeichenkodierungen Christian Weisgerber <naddy@mips.inka.de> - 2026-08-10 18:59 +0000
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 23:46 +0000
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:01 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 08:25 +0200
Apple ][ (was: Zeichenkodierungen) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 09:36 +0200
Re: Apple ][ (was: Zeichenkodierungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 12:19 +0000
Re: Apple ][ michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 15:11 +0200
Re: Apple ][ (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 20:35 +0200
Re: Apple ][ michaelnoeusenet@mac.com (Michael Noe) - 2026-08-11 08:08 +0200
Re: Apple ][ Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-11 08:06 +0000
Re: Apple ][ "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-11 10:24 +0200
Re: Apple ][ Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-11 08:26 +0000
Re: Apple ][ "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-11 10:33 +0200
Re: Apple ][ Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-11 08:36 +0000
Re: Apple ][ "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-11 17:45 +0200
Re: Apple ][ Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-11 19:27 +0200
Re: Apple ][ "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-11 22:00 +0200
Re: Apple ][ Christian Corti <use@reply.to> - 2026-08-12 08:24 +0200
Re: Apple ][ "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-12 13:33 +0200
Re: Apple ][ Sebastian Barthel <naitsabes@freenet.de> - 2026-08-12 17:02 +0000
Re: Apple ][ Arno Welzel <usenet@arnowelzel.de> - 2026-08-11 16:02 +0200
Re: Apple ][ Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-11 16:22 +0200
Re: Apple ][ "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-11 17:19 +0200
Re: Apple ][ Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-12 06:26 +0000
Re: Apple ][ Arno Welzel <usenet@arnowelzel.de> - 2026-08-12 20:47 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 11:52 +0000
Re: Zeichenkodierungen Christian Corti <use@reply.to> - 2026-08-10 17:07 +0200
Re: Zeichenkodierungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 16:58 +0000
Re: Zeichenkodierungen Christian Corti <use@reply.to> - 2026-08-11 10:19 +0200
Wortgrößen (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 20:15 +0200
Re: Wortgrößen (was: Zeichenkodierungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-12 01:56 +0000
Re: Wortgrößen Christian Corti <use@reply.to> - 2026-08-12 08:34 +0200
Re: Wortgrößen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-12 16:22 +0000
Re: Wortgrößen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-12 13:19 +0200
Re: Wortgrößen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-12 16:38 +0000
Re: Wortgrößen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-12 22:59 +0200
Re: Wortgrößen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-13 14:27 +0000
Re: Wortgrößen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-13 19:54 +0200
Re: Wortgrößen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-13 20:19 +0000
Re: Wortgrößen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-13 18:36 +0000
Re: Wortgrößen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-13 20:11 +0000
Re: Wortgrößen Christian Weisgerber <naddy@mips.inka.de> - 2026-08-13 22:08 +0000
Re: Wortgrößen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-14 06:06 +0000
Re: Wortgrößen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-14 02:42 +0200
Re: Wortgrößen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-14 06:13 +0000
Re: Wortgrößen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-13 06:11 +0000
Re: Wortgrößen (was: Zeichenkodierungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-12 19:51 +0000
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-11 08:08 +0200
Re: Zeichenkodierungen Ralph Aichinger <ra@h5.or.at> - 2026-08-11 07:40 +0000
Re: Zeichenkodierungen Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-11 08:08 +0000
Re: Zeichenkodierungen Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-11 16:23 +0200
Re: Zeichenkodierungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-11 17:53 +0200
Re: Zeichenkodierungen Christian Weisgerber <naddy@mips.inka.de> - 2026-08-11 16:35 +0000
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-11 21:29 +0200
Re: Zeichenkodierungen Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-12 06:29 +0000
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-12 17:20 +0200
Re: Zeichenkodierungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-12 09:44 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-09 17:22 +0000
36 Bit (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 21:02 +0200
Re: 36 Bit (was: Zeichenkodierungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-10 05:53 +0000
Re: 36 Bit (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 19:15 +0200
Re: 36 Bit (was: Zeichenkodierungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-11 07:01 +0000
Re: 36 Bit Ralph Aichinger <ra@h5.or.at> - 2026-08-11 07:43 +0000
Re: 36 Bit Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-11 10:16 +0200
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-11 11:45 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 10:18 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 13:00 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 18:03 +0200
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 20:23 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 21:56 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-11 10:13 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-11 10:22 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-12 10:20 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-12 17:05 +0000
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-12 21:08 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-13 15:25 +0000
Re: Seltsame Namensableitungen Christian Corti <use@reply.to> - 2026-08-09 20:45 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 22:38 +0200
Re: Seltsame Namensableitungen Christian Corti <use@reply.to> - 2026-08-10 11:18 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-06 21:26 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-08 00:14 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-08 09:05 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-08 15:23 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-08 20:34 +0000
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 12:16 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 12:45 +0200
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 13:51 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 17:34 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 12:31 +0200
Re: Seltsame Namensableitungen tom nossen <news@nossen.org> - 2026-08-09 16:07 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 17:43 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 17:15 +0000
Tastaturen (Re: Seltsame Namensableitungen) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 20:43 +0200
Re: Tastaturen (Re: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 20:53 +0000
Re: Tastaturen (Re: Seltsame Namensableitungen) Kay Martinen <usenet@martinen.de> - 2026-08-10 00:51 +0200
Re: Tastaturen (Re: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 00:04 +0000
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:45 +0200
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:04 +0200
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:37 +0200
Tastaturen (was: Seltsame Namensableitungen) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 09:37 +0200
Re: Tastaturen (was: Seltsame Namensableitungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-09 08:45 +0000
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 12:12 +0200
Re: Tastaturen (was: Seltsame Namensableitungen) Christian Weisgerber <naddy@mips.inka.de> - 2026-08-09 10:40 +0000
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 19:43 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 10:29 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-10 20:15 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-11 10:20 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-11 10:23 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-08 07:13 +0000
Re: Seltsame Namensableitungen Andreas Eder <a_eder_muc@web.de> - 2026-08-08 15:45 +0200
Re: Seltsame Namensableitungen (was: BNPL) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-04 21:45 +0200
Re: BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-08-04 22:38 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-08-10 01:03 +0200
Re: BNPL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 10:31 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-30 16:04 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-30 22:11 +0200
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-31 09:08 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 08:39 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-31 11:45 +0200
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-31 14:59 +0200
OS or !OS (was: Not free to spend) Kay Martinen <usenet@martinen.de> - 2026-08-01 14:17 +0200
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:14 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-31 11:48 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 10:21 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-08-01 14:30 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-01 15:26 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-08-02 22:08 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-03 14:36 +0200
Re: BNPL Ralph Aichinger <ra@h5.or.at> - 2026-08-03 13:04 +0000
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-03 15:38 +0200
Re: BNPL Ralph Aichinger <ra@h5.or.at> - 2026-08-03 13:50 +0000
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-03 17:47 +0200
Re: BNPL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-03 17:58 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-04 14:14 +0200
Re: BNPL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-04 19:07 +0200
Re: BNPL Ignatios Souvatzis <u502sou@bnhb484.de> - 2026-08-06 09:45 +0000
Re: BNPL Ignatios Souvatzis <u502sou@bnhb484.de> - 2026-08-07 09:38 +0000
Re: Not free to spend Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-31 15:12 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 13:24 +0000
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:38 +0200
Re: Not free to spend Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-31 16:26 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 16:21 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:42 +0200
Re: Not free to spend Christian Corti <use@reply.to> - 2026-07-30 13:07 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-30 22:03 +0200
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:12 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 08:44 +0000
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:55 +0200
Re: Not free to spend Thomas Koenig <tkoenig@netcologne.de> - 2026-08-04 16:49 +0000
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-05 11:35 +0000
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:30 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:27 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-08-11 18:49 +0200
Re: Not free to spend Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-11 19:29 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-08-12 10:53 +0200
Re: Not free to spend Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-12 11:06 +0200
Re: Not free to spend Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-08-12 14:50 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-08-12 22:26 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-12 06:32 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-27 20:06 +0200
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 20:47 +0200
Re: Not free to spend "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2026-07-28 07:31 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-28 23:39 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 07:49 +0200
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-27 11:57 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 14:54 +0200
Re: Not free to spend Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:26 +0000
Re: Not free to spend Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:38 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-27 20:53 +0200
Re: Not free to spend Thomas Koenig <tkoenig@netcologne.de> - 2026-07-28 05:11 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Frank Wißmann <frank_wissmann@web.de> - 2026-07-14 20:09 +0200
VzEkC (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-26 23:17 +0200
Re: VzEkC (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:18 +0000
Re: VzEkC (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 18:50 +0200
Znesur (was: Re: VzEkC) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-27 21:42 +0200
Re: Zensur (was: Re: VzEkC) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 22:43 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-28 08:59 +0200
Re: Zensur Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-28 15:54 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-28 16:34 +0200
Re: Zensur Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-29 02:00 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-29 08:50 +0200
Re: Zensur Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-07-29 07:13 +0000
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-29 12:41 +0200
Re: Zensur Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-30 00:21 +0200
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-30 01:38 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:32 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-31 15:09 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-31 15:37 +0200
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-08-02 19:33 +0200
Re: Zensur "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-02 20:11 +0200
Re: Zensur Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-03 08:35 +0000
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-08-04 00:45 +0200
Re: Zensur Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:49 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-08-06 15:48 +0200
Re: Zensur Michael Kraemer <m.kraemer@gsi.de> - 2026-08-11 14:00 +0200
Re: Zensur Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:45 +0200
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-28 17:00 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-28 21:05 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-28 21:26 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-29 08:50 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-28 21:24 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-29 08:53 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:29 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-31 14:58 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:18 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-31 17:32 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-08-03 10:17 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-03 12:53 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-03 16:24 +0200
Re: VzEkC Kay Martinen <usenet@martinen.de> - 2026-07-30 22:31 +0200
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:24 +0200
Re: VzEkC Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 08:47 +0000
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:56 +0200
Re: VzEkC Kay Martinen <usenet@martinen.de> - 2026-07-31 12:50 +0200
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 14:05 +0200
Re: VzEkC R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-28 17:00 +0200
Re: VzEkC Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2026-07-30 23:21 +0000
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:42 +0200
Re: VzEkC Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2026-07-31 11:46 +0000
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:23 +0200
Re: VzEkC Kay Martinen <usenet@martinen.de> - 2026-08-04 01:31 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-26 02:37 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-26 23:17 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 06:57 +0200
Page 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-10 11:52 +0000 |
| Subject | Re: Zeichenkodierungen (was: Seltsame Namensableitungen) |
| Message-ID | <115ce1f$7jdt$1@solani.org> |
| In reply to | #56123 |
Am Mon, 10 Aug 2026 08:25:57 +0200 schrieb der Meister Peter J. Holzer folgendes: > On 2026-08-10 01:46, Sebastian Barthel <naitsabes@freenet.de> wrote: >> Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J. Holzer >> folgendes: >> >>> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>> Am Sun, 09 Aug 2026 11:57:24 +0200 schrieb der Meister Peter J. >>>> Holzer folgendes: >>>> >>>>> On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>>>> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J. >>>>>> Holzer folgendes: >>>>>>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook >>>>>>> aufgeschlagen, der eine 12-Bit-Kodierung von Zeichen einführen >>>>>>> wollte. >>> [...] >>>>> Aber anyway: Computer mit einer Wortlänge, die ein Vielfaches von 12 >>>>> beträgt, sind ähnlich veraltet wie Lochkarten (aber hier natürlich >>>>> on-topic, aber in der Python-Gruppe nicht). >>>> >>>> Och - da wäre ich vorsichtig. Evtl wird das je demnächst mal >>>> wiederentdeckt. >>> >>> Unwahrscheinlich. >> >> Mag sein ... :) >> >>>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der >>>> Textcodierung. >>> >>> Welche denn? >>> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt >>> es dann sicher eine andere Anwendung, für die 13 Bit besser wären. >> >> Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein paar >> schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, ..., 32 >> Bit auch hinbekommt ist ja wieder was anderes. Aber 8 Bit ist oft eher >> zu wenig. > > Dann nimmst Du halt 16 Bit. Dass 8 Bit die kleinste adressierbare > Einheit ist, heißt ja nicht, dass man auf 8-Bit-Zahlen beschränkt ist. > Aktuelle Prozessoren können typischerweise mit 8-, 16-. 32- und 64-Bit- > Zahlen umgehen. Trotzdem sollten auch die immer noch am schnellsten mit ihrem originären Wortformat unterwegs sein. Daß es wahrscheinlich eher unwahrscheinlich ist, daß jemand CPUs mit 15 Bit (oder 13 oder 11) baut, ist mir ja schon auch klar. Wobei es evtl schon interessant wäre, zu sehen, was damit dann passiert. > Gut, wenn Du nur 12 Bit bräuchtest und 16 Bit nehmen musst, > verschwendest Du 4 Bits. Aber wenn Du 13 Bit bräuchtest, müsstest Du bei > Deinem 12-Bit-Prozessor auf 24 Bit gehen und würdest 11 Bit > verschwenden. Für die Speicher-Ökonomie wäre eine möglichst kleine > Einheit sinnvoll, nicht eine möglichst große. Nicht umsonst können > manche GPUs mittlerweile mit 4-Bit-Floating-Point-Zahlen(!) umgehen. Spannend. Das ist dann besonders interessant, wenn man die beliebig zusammenstellen kann. Das gab es ja prinzipiell irgendwie schon bei dem 4004 (?)(für int) und im Z80 ist das ja sogar by design so gemacht worden (daß man 8Bit aus 2x 4Bit zusammengebaut hat; da allerdings eher aus Lizenz/ Patentschutzgründen). Ist natürlich witzig, wenn man die Breite solch einer fp Zahl dann der Grafikkkarte einfach beliebig vorgeben kann und die sucht sich die passende Menge an Recheneinheiten zusammen. Keine Ahnung, ob das so gemeint war, aber so würde ich das verstehen. (Meine Grafikkarte ist nicht sooo neu ... . :) Sie hat aber wohl immerhin schon Streamprozessoren (müßte ich aber auch nachsehen, ob das wirklich stimmt). Müßte eher mal neue Wärmeleitpaste bekommen ... mark2mind ... grad jetzt, wo es so heiß ist.) >> Beispiele wären etwa übliche Bildschirmauflösungen. Relativiert sich >> auch gerade (8K), aber bisher - und wahrscheinlich noch eine ganze Zeit >> lang - wären <= 4096 Pixel dann ein Wort. > > Und davor noch deutlich länger <= 2048, da hätte man nach Deiner Logik > 11-Bit-CPUs haben müssen. Aber auch da hat es Multi-Monitor-Setups > gegeben und für Koordinatenberechnungen wollte man sowieso noch Reserve > haben. Eine Wortgröße, die genau die Breite eines physischen Displays > aufnehmen kann, macht vermutlich nicht mal für eine Graphikkarte Sinn, > geschweige denn für ein Computersystem als Ganzes. > >> Wo es auch schön paßt, sind Farbwerte für einen Farbkanal. Da sind die >> Anzeigen üblicherweise intern 10Bit je Kanal (etwa in Monitoren). > > Und RGB hat dann schön in 32 Bit Platz. Deshalb sind es ja vmtl 10Bit geworden - nur eben andersherum entstanden: nicht von den Daten ausgehend, sondern, weil es zu einem Zeitpunkt dann diese sehr günstigen 32 Bit CPUs gab (ARM, MIPS, PowerPC), konnte man plötzlich sehr schön Farbwerte über 10Bit LUT umrechnen lassen. Wären das 36 Bit CPUs gewesen, hätten die Monitore etc. intern heute evtl eher 12Bit Farbkanäle. Die Argumentation von oben mit dem "12Bit ist besser" war ja aber ausgehend von den Werten, die man üblicherweise so hat - und da kommt man m.E. für viele Dinge (und gerade im Grafikbereich, aber auch bei Textcodierungen) sehr schnell an die Stelle, wo 8Bit sehr eng sind (siehe ASCII) und 16Bit eigentlich fast ein bißchen viel. Ich habe ja auch nur versucht einen Grund für die angefragten 12Bit zu finden - und kann das schon irgendwie nachvollziehen, daß das ein guter Kompromiß für viele Anwendungen sein könnte. Wenn man es evtl irgendwann selbst auch für int in der Breite zusammenbauen / vorgeben kann, sind die 12Bit ja auch wieder mit dabei, da ja auch bei int die Basis möglicherweise 4Bit sein wird. Dann wird man sehen, ob es benutzt wird. (4Bit ist auch so eine eine interessante Größe, weil sie schön die dezimale 10 abbildet. Das scheint aber wirklich niemanden mehr zu interessieren, weil man sich an Binärzahlen dermaßen gewöhnt hat. Der 6502 hat noch den Dezimalmodus (den wohl kaum jemand je benutzt hat).) Als noch ein weiteres Beispiel, was mir gestern noch einfiel, wären Streckenpunkt in einer Karte (Garmin, Automap etc.). Da kommt man mit 10 Punkten höchst selten aus, 256 bekommt man auch schnell, aber 4096 ist eine angenehme Größenordnung. Und uach die Koordinatenwerte selbst sollte man da schön reinbekommen (Länge,Breite je einzeln). Oder Schafherden ... . Oder bei ADC Werten (Sampling (wenn es nicht gerade Musik sein soll)). Aber so ein Teil, daß Drehbewegungen mißt (Vollkreis), macht dann 2048 echte Meßwerte, was sowas wie 2 Zehntel Winkelgrad Auflösung macht. Das ist so schlecht nicht und paßt für ganz viele Sachen im Alltag gut genug. Ähnlich bei Schiebereglern. Zusammenfassend: Um die Welt in "für Menschen gut verstänliche" Größeneinheiten zu teilen, ist 12 Bit nicht der schlechteste Wert. Was der Anfragende (Python Gruppe) damit an Zeichen eigentlich alles codieren wollte, wird er wohl aber nur selbst wissen. VG, SBn
[toc] | [prev] | [next] | [standalone]
| From | Christian Corti <use@reply.to> |
|---|---|
| Date | 2026-08-10 17:07 +0200 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <536pkm-aqu.ln1@news.informatik.uni-stuttgart.de> |
| In reply to | #56131 |
Sebastian Barthel <naitsabes@freenet.de> wrote: > Daß es wahrscheinlich eher unwahrscheinlich ist, daß jemand CPUs mit 15 > Bit (oder 13 oder 11) baut, ist mir ja schon auch klar. Wobei es evtl > schon interessant wäre, zu sehen, was damit dann passiert. Zählen 19 Bits auch? Dietz MINCAL 4 und 523. Christian
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-10 16:58 +0000 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <115cvvu$83ac$1@solani.org> |
| In reply to | #56135 |
Am Mon, 10 Aug 2026 17:07:49 +0200 schrieb der Meister Christian Corti folgendes: > Sebastian Barthel <naitsabes@freenet.de> wrote: >> Daß es wahrscheinlich eher unwahrscheinlich ist, daß jemand CPUs mit 15 >> Bit (oder 13 oder 11) baut, ist mir ja schon auch klar. Wobei es evtl >> schon interessant wäre, zu sehen, was damit dann passiert. > > Zählen 19 Bits auch? Dietz MINCAL 4 und 523. Ja klar ... . Interssant, daß es sowas mit ungeraden Zahlen wirklich gab. Danke. ( ... und schon wieder was zum Raussuchen ... und Nachlesen)
[toc] | [prev] | [next] | [standalone]
| From | Christian Corti <use@reply.to> |
|---|---|
| Date | 2026-08-11 10:19 +0200 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <1h2rkm-3ba.ln1@news.informatik.uni-stuttgart.de> |
| In reply to | #56138 |
Sebastian Barthel <naitsabes@freenet.de> wrote: > Am Mon, 10 Aug 2026 17:07:49 +0200 schrieb der Meister Christian Corti > > Zählen 19 Bits auch? Dietz MINCAL 4 und 523. > Ja klar ... . > Interssant, daß es sowas mit ungeraden Zahlen wirklich gab. Der Grund war für die Entwickler ganz einfach: mit 19 Bits kann man wunderbar viereinhalb Dezimalstellen darstellen, plus Vorzeichen, also den Bereich bis +/-39999 Das spielt bei der Meßwerterfassung bzw. -auswertung eine Rolle. Ursprünglich waren mehr Bits geplant, aber der Speicher wäre unverhältnismäßig teuer geworden. Christian
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-10 20:15 +0200 |
| Subject | Wortgrößen (was: Zeichenkodierungen) |
| Message-ID | <slrn117k5a6.1eelu.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56131 |
On 2026-08-10 13:52, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Mon, 10 Aug 2026 08:25:57 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>> On 2026-08-10 01:46, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J. Holzer
>>> folgendes:
>>>> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der
>>>>> Textcodierung.
>>>>
>>>> Welche denn?
>>>> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt
>>>> es dann sicher eine andere Anwendung, für die 13 Bit besser wären.
>>>
>>> Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein paar
>>> schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, ..., 32
>>> Bit auch hinbekommt ist ja wieder was anderes. Aber 8 Bit ist oft eher
>>> zu wenig.
>>
>> Dann nimmst Du halt 16 Bit. Dass 8 Bit die kleinste adressierbare
>> Einheit ist, heißt ja nicht, dass man auf 8-Bit-Zahlen beschränkt ist.
>> Aktuelle Prozessoren können typischerweise mit 8-, 16-. 32- und 64-Bit-
>> Zahlen umgehen.
>
> Trotzdem sollten auch die immer noch am schnellsten mit ihrem originären
> Wortformat unterwegs sein.
Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter
dient nur dazu, Speicher zu sparen.
(Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne mal
512 Bit, und die kleineren Einheiten dienen auch der Parallelisierung.)
>> Für die Speicher-Ökonomie wäre eine möglichst kleine Einheit
>> sinnvoll, nicht eine möglichst große. Nicht umsonst können manche
>> GPUs mittlerweile mit 4-Bit-Floating-Point-Zahlen(!) umgehen.
>
> Spannend.
>
> Das ist dann besonders interessant, wenn man die beliebig zusammenstellen
> kann.
Ich weiß nicht, was Du unter "beliebig zusammenstellen" verstehst, aber die
Antwort lautet fast sicher "Nein". GPUs verwendet man, wenn oft die
gleiche Operation durchführen will, und das möglichst parallel. Also
z.B. riesige Matrizen miteinander multiplizieren. Da muss natürlich
jedes Element der Matrix den gleichen Typ haben. Aber natürlich kann man
zwei Matrizen mit FP4 multiplizieren und das Ergebis dann zu einer
Matrix mit FP16 addieren (eventuell muss man dazischen umwandeln).
> Ist natürlich witzig, wenn man die Breite solch einer fp Zahl dann der
> Grafikkkarte einfach beliebig vorgeben kann und die sucht sich die
> passende Menge an Recheneinheiten zusammen.
Was auch immer das bedeuten soll. Du hast Instruktionen für 4-bit-,
8-bit-, 16-bit, 32-bit- und vielleicht 64-bit-Operationen, genauso wie
eine CPU Instruktionen für 8-bit-, 16-bit-, 32-bit- und
64-bit-Operationen hat. Ich sehe da jetzt überhaupt nicht überraschendes
darin, außer dass hier die Entwicklung zu immer kleineren Operanden
gegangen ist, während bei CPUs der Trend zu immer größeren ging.
>> Und RGB hat dann schön in 32 Bit Platz.
>
> Deshalb sind es ja vmtl 10Bit geworden
Richtig. Die Entwicklung orientiert sich oft an den gegebenen
Möglichkeiten. Siehe auch den 36/32-Bit Subthread nebenan.
> (4Bit ist auch so eine eine interessante Größe, weil sie schön die
> dezimale 10 abbildet. Das scheint aber wirklich niemanden mehr zu
> interessieren, weil man sich an Binärzahlen dermaßen gewöhnt hat. Der
> 6502 hat noch den Dezimalmodus (den wohl kaum jemand je benutzt hat).)
Es gibt ein dezimales Floating-Point-Format im IEEE-754-Standard. Das
basiert aber nicht auf BCD, sondern jeweils 10 Bit stellen Werte von 0
bis 999 dar.
> Als noch ein weiteres Beispiel, was mir gestern noch einfiel, wären
> Streckenpunkt in einer Karte (Garmin, Automap etc.). Da kommt man mit 10
> Punkten höchst selten aus, 256 bekommt man auch schnell, aber 4096 ist
> eine angenehme Größenordnung. Und uach die Koordinatenwerte selbst sollte
> man da schön reinbekommen (Länge,Breite je einzeln).
Bei Länge und Breite kämst Du mit 12 Bit aber nicht weit. Bei 40000 km
Erdumfang hättest Du da nur eine Auflösung von 10 km ...
Und wie Du die Anzahl der Punkte in der Liste kodierst, ist sowas von
egal ...
hjp
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-12 01:56 +0000 |
| Subject | Re: Wortgrößen (was: Zeichenkodierungen) |
| Message-ID | <115gjrp$amvr$1@solani.org> |
| In reply to | #56141 |
Am Mon, 10 Aug 2026 20:15:34 +0200 schrieb der Meister Peter J. Holzer folgendes: > On 2026-08-10 13:52, Sebastian Barthel <naitsabes@freenet.de> wrote: >> Am Mon, 10 Aug 2026 08:25:57 +0200 schrieb der Meister Peter J. Holzer >> folgendes: >>> On 2026-08-10 01:46, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>> Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J. >>>> Holzer folgendes: >>>>> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>>>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der >>>>>> Textcodierung. >>>>> >>>>> Welche denn? >>>>> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt >>>>> es dann sicher eine andere Anwendung, für die 13 Bit besser wären. >>>> >>>> Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein paar >>>> schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, ..., 32 >>>> Bit auch hinbekommt ist ja wieder was anderes. Aber 8 Bit ist oft >>>> eher zu wenig. >>> >>> Dann nimmst Du halt 16 Bit. Dass 8 Bit die kleinste adressierbare >>> Einheit ist, heißt ja nicht, dass man auf 8-Bit-Zahlen beschränkt ist. >>> Aktuelle Prozessoren können typischerweise mit 8-, 16-. 32- und >>> 64-Bit- >>> Zahlen umgehen. >> >> Trotzdem sollten auch die immer noch am schnellsten mit ihrem >> originären Wortformat unterwegs sein. > > Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter > dient nur dazu, Speicher zu sparen. > (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne mal > 512 Bit, und die kleineren Einheiten dienen auch der Parallelisierung.) Und genau das wird dann halt wieder langsamer, als es sein könnte, wenn die Zahlen "gut" passen würden. (Ich versteh ja sowieso nicht so wirklich, was man eigentlich mit 64Bit integer macht.) >>> Für die Speicher-Ökonomie wäre eine möglichst kleine Einheit sinnvoll, >>> nicht eine möglichst große. Nicht umsonst können manche GPUs >>> mittlerweile mit 4-Bit-Floating-Point-Zahlen(!) umgehen. >> Das ist dann besonders interessant, wenn man die beliebig >> zusammenstellen kann. > > Ich weiß nicht, was Du unter "beliebig zusammenstellen" verstehst, aber > die Antwort lautet fast sicher "Nein". GPUs verwendet man, wenn oft die > gleiche Operation durchführen will, und das möglichst parallel. Also > z.B. riesige Matrizen miteinander multiplizieren. ... kann man > zwei Matrizen mit FP4 multiplizieren und das Ergebis dann zu einer > Matrix mit FP16 addieren (eventuell muss man dazischen umwandeln). >> Ist natürlich witzig, wenn man die Breite solch einer fp Zahl dann der >> Grafikkkarte einfach beliebig vorgeben kann und die sucht sich die >> passende Menge an Recheneinheiten zusammen. > > Was auch immer das bedeuten soll. Du hast Instruktionen für 4-bit-, > 8-bit-, 16-bit, 32-bit- und vielleicht 64-bit-Operationen, genauso wie > eine CPU Instruktionen für 8-bit-, 16-bit-, 32-bit- und > 64-bit-Operationen hat. War ein wenig hergeholt ... die Idee war, daß man einer CPU / FPU / GPU, die komplett nur 4bit Basiseinheiten hat, den Typ ansagen kann und sie sich dann ein kleines Cluster an solchen Basiseinheiten so zusammenstellt, daß die (Typ)Anfrage bedient wird. Also: Man hat einen 24Bit Typ und schickt diese Info mit. Die CPU/GPU sucht sich 6 mal freie 4Bit Eineheiten und kümmert sich im das Weiterreichen des CarryFlags. Dann wird gerechnet. Das gesammelte Ergebnis gibt es zurück auf den Bus. > 64-bit-Operationen hat. Ich sehe da jetzt überhaupt nicht überraschendes > darin, außer dass hier die Entwicklung zu immer kleineren Operanden > gegangen ist, während bei CPUs der Trend zu immer größeren ging. Ja, das ist eine interessante Beobachtung. >> (4Bit ist auch so eine eine interessante Größe, weil sie schön die >> dezimale 10 abbildet. ... 6502 hat noch den Dezimalmodus ... > > Es gibt ein dezimales Floating-Point-Format im IEEE-754-Standard. Das > basiert aber nicht auf BCD, sondern jeweils 10 Bit stellen Werte von 0 > bis 999 dar. Klingt auch ganz brauchbar. >> Als noch ein weiteres Beispiel, was mir gestern noch einfiel, wären >> Streckenpunkt in einer Karte (Garmin, Automap etc.). Da kommt man mit >> 10 Punkten höchst selten aus, 256 bekommt man auch schnell, aber 4096 >> ist eine angenehme Größenordnung. Und uach die Koordinatenwerte selbst >> sollte man da schön reinbekommen (Länge,Breite je einzeln). > > Bei Länge und Breite kämst Du mit 12 Bit aber nicht weit. Bei 40000 km > Erdumfang hättest Du da nur eine Auflösung von 10 km ... Exakt. Und wenn man zwei Zahlen nimmt, hat man ein 10 x 10 km Rechteck (eigentlich natürlich ca. 1/10tel Grad), daß man dann in 4096tel einteilt. Das gibt eine ausgesprochen schöne Größe von 2.5m für einen "Pixel". Würde mir auf dem Garmin absolut ausreichen. Zum Wandern, Radfahren absolut gut. Dürfte sowas wie eine 1:10000 Karte ergeben. > Und wie Du die Anzahl der Punkte in der Liste kodierst, ist sowas von > egal ... Mag sein. Es ging auch mehr um den Bereich und die Größe, die er für übliche Anwendungen hat/braucht (Schafe zählen etc.). Am Ende ist es natürlich schon auch gut, wenn das bißchen Puffer nach oben hat und letztlich wird es sowieso diktiert von den Leuten, die die Chips bauen und daher müßig. Wenn die halt 64Bit vorgeben, dann ist das halt mal so. Pragmatisch gibt es da dann gar nichts zu diskutieren - ich find das ja aber trotzdem spannend an der Stelle. Es könnte ja auch ganz anders sein.
[toc] | [prev] | [next] | [standalone]
| From | Christian Corti <use@reply.to> |
|---|---|
| Date | 2026-08-12 08:34 +0200 |
| Subject | Re: Wortgrößen |
| Message-ID | <4ogtkm-kfn.ln1@news.informatik.uni-stuttgart.de> |
| In reply to | #56180 |
Sebastian Barthel <naitsabes@freenet.de> wrote: > War ein wenig hergeholt ... die Idee war, daß man einer CPU / FPU / GPU, > die komplett nur 4bit Basiseinheiten hat, den Typ ansagen kann und sie > sich dann ein kleines Cluster an solchen Basiseinheiten so > zusammenstellt, daß die (Typ)Anfrage bedient wird. Also: Man hat einen Schau dir den Dietz 621 an. Das ist ein 8-Bit Rechner mit variabler Wortlänge. Du kannst den Instruktionen mittels vorausgehendem DO-Befehl sagen, aus wievielen 8-Bit-Einheiten der Operand besteht, und zwar fast beliebig (bis zu 256 Bytes pro Wort). Alles alter Kaffee ;-) Christian
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-12 16:22 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115i6js$bocc$1@solani.org> |
| In reply to | #56185 |
Am Wed, 12 Aug 2026 08:34:12 +0200 schrieb der Meister Christian Corti folgendes: > Sebastian Barthel <naitsabes@freenet.de> wrote: >> War ein wenig hergeholt ... die Idee war, daß man einer CPU / FPU / >> GPU, >> die komplett nur 4bit Basiseinheiten hat, den Typ ansagen kann und sie >> sich dann ein kleines Cluster an solchen Basiseinheiten so >> zusammenstellt, daß die (Typ)Anfrage bedient wird. Also: Man hat einen > > Schau dir den Dietz 621 an. Das ist ein 8-Bit Rechner mit variabler > Wortlänge. Du kannst den Instruktionen mittels vorausgehendem DO-Befehl > sagen, aus wievielen 8-Bit-Einheiten der Operand besteht, und zwar fast > beliebig (bis zu 256 Bytes pro Wort). OK, ist notiert.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-12 13:19 +0200 |
| Subject | Re: Wortgrößen |
| Message-ID | <slrn117olm3.3hn7m.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56180 |
On 2026-08-12 03:56, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Mon, 10 Aug 2026 20:15:34 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>
>> On 2026-08-10 13:52, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Am Mon, 10 Aug 2026 08:25:57 +0200 schrieb der Meister Peter J. Holzer
>>> folgendes:
>>>> On 2026-08-10 01:46, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>>> Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J.
>>>>> Holzer folgendes:
>>>>>> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>>>>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der
>>>>>>> Textcodierung.
>>>>>>
>>>>>> Welche denn?
>>>>>> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt
>>>>>> es dann sicher eine andere Anwendung, für die 13 Bit besser wären.
>>>>>
>>>>> Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein paar
>>>>> schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, ..., 32
>>>>> Bit auch hinbekommt ist ja wieder was anderes. Aber 8 Bit ist oft
>>>>> eher zu wenig.
>>>>
>>>> Dann nimmst Du halt 16 Bit. Dass 8 Bit die kleinste adressierbare
>>>> Einheit ist, heißt ja nicht, dass man auf 8-Bit-Zahlen beschränkt ist.
>>>> Aktuelle Prozessoren können typischerweise mit 8-, 16-. 32- und
>>>> 64-Bit-
>>>> Zahlen umgehen.
>>>
>>> Trotzdem sollten auch die immer noch am schnellsten mit ihrem
>>> originären Wortformat unterwegs sein.
>>
>> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter
>> dient nur dazu, Speicher zu sparen.
>> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne mal
>> 512 Bit, und die kleineren Einheiten dienen auch der Parallelisierung.)
>
> Und genau das wird dann halt wieder langsamer, als es sein könnte, wenn
> die Zahlen "gut" passen würden.
Weniger als ein Taktzyklus ist schwierig. Vielleicht könnte man einen
12-Bit-Prozessor etwas schneller takten als einen 64-Bit-Prozessor, aber
das würde durch die höhere Anzahl Instruktionen mehr als wettgemacht.
Und zwischen einem 48-Bit-Prozessor und einem 64-Bit-Prozessor ist da
wohl kaum ein Unterschied.
> (Ich versteh ja sowieso nicht so wirklich, was man eigentlich mit 64Bit
> integer macht.)
Alles, wofür 32 Bit nicht reichen. 4 Milliarden ist jetzt nicht so viel,
da kommt man bald drüber. Jetzt wirst Du natürlich sagen, das 48 Bit
doch sicher reichen müssten, aber ein Petabyte sind 2^50 Byte, und in
der Gegend ist man teilweise schon. Von Kryptographie und anderen
Anwendungen, wo man mit wirklich großen Zahlen rechnet, mal ganz
abgesehen.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-12 16:38 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115i7hv$bocc$2@solani.org> |
| In reply to | #56190 |
Am Wed, 12 Aug 2026 13:19:31 +0200 schrieb der Meister Peter J. Holzer folgendes: > On 2026-08-12 03:56, Sebastian Barthel <naitsabes@freenet.de> wrote: >> Am Mon, 10 Aug 2026 20:15:34 +0200 schrieb der Meister Peter J. Holzer >> folgendes: >> >>> On 2026-08-10 13:52, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>> Am Mon, 10 Aug 2026 08:25:57 +0200 schrieb der Meister Peter J. >>>> Holzer folgendes: >>>>> On 2026-08-10 01:46, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>>>> Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J. >>>>>> Holzer folgendes: >>>>>>> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> >>>>>>> wrote: >>>>>>>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der >>>>>>>> Textcodierung. >>>>>>> >>>>>>> Welche denn? >>>>>>> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür >>>>>>> gibt es dann sicher eine andere Anwendung, für die 13 Bit besser >>>>>>> wären. >>>>>> >>>>>> Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein >>>>>> paar schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, >>>>>> ..., 32 Bit auch hinbekommt ist ja wieder was anderes. Aber 8 Bit >>>>>> ist oft eher zu wenig. >>>>> >>>>> Dann nimmst Du halt 16 Bit. Dass 8 Bit die kleinste adressierbare >>>>> Einheit ist, heißt ja nicht, dass man auf 8-Bit-Zahlen beschränkt >>>>> ist. >>>>> Aktuelle Prozessoren können typischerweise mit 8-, 16-. 32- und >>>>> 64-Bit- >>>>> Zahlen umgehen. >>>> >>>> Trotzdem sollten auch die immer noch am schnellsten mit ihrem >>>> originären Wortformat unterwegs sein. >>> >>> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter >>> dient nur dazu, Speicher zu sparen. >>> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne >>> mal 512 Bit, und die kleineren Einheiten dienen auch der >>> Parallelisierung.) >> >> Und genau das wird dann halt wieder langsamer, als es sein könnte, wenn >> die Zahlen "gut" passen würden. > > Weniger als ein Taktzyklus ist schwierig. Vielleicht könnte man einen > 12-Bit-Prozessor etwas schneller takten als einen 64-Bit-Prozessor, aber > das würde durch die höhere Anzahl Instruktionen mehr als wettgemacht. > Und zwischen einem 48-Bit-Prozessor und einem 64-Bit-Prozessor ist da > wohl kaum ein Unterschied. Ich würde ja gern mal einen kleinen 8Bit Core auf 5 GHz sehen ... wird aber eher nicht passieren, daß das jemand baut. 6502 / Z80 auf SPEED sozusagen. Warum man 12 Bit schneller takten können soll als 64 Bit, erschließt sich mir nicht wirklich. >> (Ich versteh ja sowieso nicht so wirklich, was man eigentlich mit 64Bit >> integer macht.) > > Alles, wofür 32 Bit nicht reichen. 4 Milliarden ist jetzt nicht so viel, > da kommt man bald drüber. Jetzt wirst Du natürlich sagen, das 48 Bit > doch sicher reichen müssten, aber ein Petabyte sind 2^50 Byte, und in > der Gegend ist man teilweise schon. Das sind aber halt so "computer-interne" Sachen. Da wird die große Zahl halt gebraucht, weil man gern die Adressen am Stück benennen können will. Wahrscheinlich hast Du recht, daß ich 48 Bit generell für "überreichlich" halten würde. Aber eben für normale integer Werte (Schafe zählen, Briefmarkensammlung verwalten, Ampel steuern etc). Daß es davon abgesehen durchaus nützlich sein kann, 48 Bit oder auch 64Bit oder sogar noch mehr zu haben, ist unbenommen. 48Bit wäre etwa für Grafik großartig - wegen 4x 12. Und ja, man selbst sieht auch den ersten Blick eigentlich keinen Unterschied zwischen 16 Millionen und "noch mehr" Farben, aber ich habe das mal in einer GamingFirma von einer Grafikerin gezeigt bekommen, wo es da schon durchaus Sinn machen kann, besseres "Gerät" zu benutzen. > der Gegend ist man teilweise schon. Von Kryptographie und anderen > Anwendungen, wo man mit wirklich großen Zahlen rechnet, mal ganz > abgesehen. Klar. Daß es schon schön - und nützlich - sein kann, wenn man große Zahlen darstellen kann, ist ja richtig. VG, SBn
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-12 22:59 +0200 |
| Subject | Re: Wortgrößen |
| Message-ID | <slrn117pnmd.15al.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56197 |
On 2026-08-12 18:38, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Wed, 12 Aug 2026 13:19:31 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>> On 2026-08-12 03:56, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Und genau das wird dann halt wieder langsamer, als es sein könnte, wenn
>>> die Zahlen "gut" passen würden.
>>
>> Weniger als ein Taktzyklus ist schwierig. Vielleicht könnte man einen
>> 12-Bit-Prozessor etwas schneller takten als einen 64-Bit-Prozessor, aber
>> das würde durch die höhere Anzahl Instruktionen mehr als wettgemacht.
[...]
> Warum man 12 Bit schneller takten können soll als 64 Bit, erschließt sich
> mir nicht wirklich.
Warum glaubst Du dann, dass ein 64-Bit-Prozessor langsamer sein sollte
als ein ein 12-Bit-Prozessor? Glaubst Du wirklich, dass man für ein
n-Bit-Addition n Taktzyklen braucht? Ich glaube, Du hast mindestens 50
Jahre Prozessorentwicklung verschlafen.
hjp
>
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-13 14:27 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115kk8r$dfqp$1@solani.org> |
| In reply to | #56204 |
Am Wed, 12 Aug 2026 22:59:57 +0200 schrieb der Meister Peter J. Holzer folgendes: > On 2026-08-12 18:38, Sebastian Barthel <naitsabes@freenet.de> wrote: >> Am Wed, 12 Aug 2026 13:19:31 +0200 schrieb der Meister Peter J. Holzer >> folgendes: >>> On 2026-08-12 03:56, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>> Und genau das wird dann halt wieder langsamer, als es sein könnte, >>>> wenn die Zahlen "gut" passen würden. >>> >>> Weniger als ein Taktzyklus ist schwierig. Vielleicht könnte man einen >>> 12-Bit-Prozessor etwas schneller takten als einen 64-Bit-Prozessor, >>> aber das würde durch die höhere Anzahl Instruktionen mehr als >>> wettgemacht. > [...] >> Warum man 12 Bit schneller takten können soll als 64 Bit, erschließt >> sich mir nicht wirklich. > > Warum glaubst Du dann, dass ein 64-Bit-Prozessor langsamer sein sollte > als ein ein 12-Bit-Prozessor? Glaubst Du wirklich, dass man für ein > n-Bit-Addition n Taktzyklen braucht? Ich glaube, Du hast mindestens 50 > Jahre Prozessorentwicklung verschlafen. Es ging um das da > Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter > dient nur dazu, Speicher zu sparen. > (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne mal > 512 Bit, und die kleineren Einheiten dienen auch der Parallelisierung.) Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich Byteweise das da wieder herausholen will, dann wird das langsamer (man muß dann shiften oder logisch verknüpfen oder was auch immer tun, aber in meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die Programmiersprache den evtl versteckt)). Das hat auch nichts mit dem Takt zu tun.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-13 19:54 +0200 |
| Subject | Re: Wortgrößen |
| Message-ID | <slrn117s17i.vmm1.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56206 |
On 2026-08-13 16:27, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Wed, 12 Aug 2026 22:59:57 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>
>> On 2026-08-12 18:38, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Am Wed, 12 Aug 2026 13:19:31 +0200 schrieb der Meister Peter J. Holzer
>>> folgendes:
>>>> On 2026-08-12 03:56, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>>> Und genau das wird dann halt wieder langsamer, als es sein könnte,
>>>>> wenn die Zahlen "gut" passen würden.
>>>>
>>>> Weniger als ein Taktzyklus ist schwierig. Vielleicht könnte man einen
>>>> 12-Bit-Prozessor etwas schneller takten als einen 64-Bit-Prozessor,
>>>> aber das würde durch die höhere Anzahl Instruktionen mehr als
>>>> wettgemacht.
>> [...]
>>> Warum man 12 Bit schneller takten können soll als 64 Bit, erschließt
>>> sich mir nicht wirklich.
>>
>> Warum glaubst Du dann, dass ein 64-Bit-Prozessor langsamer sein sollte
>> als ein ein 12-Bit-Prozessor? Glaubst Du wirklich, dass man für ein
>> n-Bit-Addition n Taktzyklen braucht? Ich glaube, Du hast mindestens 50
>> Jahre Prozessorentwicklung verschlafen.
>
> Es ging um das da
>
>> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter
>> dient nur dazu, Speicher zu sparen.
>> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne mal
>> 512 Bit, und die kleineren Einheiten dienen auch der Parallelisierung.)
>
> Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich
> Byteweise das da wieder herausholen will, dann wird das langsamer (man muß
> dann shiften oder logisch verknüpfen oder was auch immer tun, aber in
> meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die
> Programmiersprache den evtl versteckt)).
Prozessoren haben Instruktionen, um einzelne Bytes (und andere kleinere
Einheiten) im RAM zugreifen zu können[1]. Ja, das läuft unter Umständen
darauf hinaus, dass der Prozessor das, was er aus dem Cache liest, noch
shiften, maskieren und eventuell sign-extenden muss und das kostet ein
paar Gate-Delays (siehe Thomas Koenigs Posting), aber das sind sehr
einfache Operationen, das geht sich locker innerhalb eines Taktzyklus
aus. Ein Load von einem Byte ist nicht langsamer als eines von einem
ganzen Wort - allerdings auch nicht schneller.
> Das hat auch nichts mit dem Takt zu tun.
Indirekt schon, weil - wie Thomas ausgeführt hat, ein Taktzyklus lang
genug für die komplizierteste Instruktion, die in einem Takt ausgeführt
werden soll, sein muss. Macht man weniger in einem Takt, kann man
schneller takten. Aber das Grenzen.
hjp
[1] Ausnahme war der DEC Alpha (zumindest die ersten Modelle). Der hatte
tatsächlich nur Load- und Store-Instruktionen für 32 und 64 Bit.
Wollte man ein Byte oder 16-Bit-Wort laden, musste man die
notwendigen Shift- und And-Operationen explizit machen.
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-13 20:19 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115l8sr$dss4$2@solani.org> |
| In reply to | #56208 |
Am Thu, 13 Aug 2026 19:54:58 +0200 schrieb der Meister Peter J. Holzer folgendes: > On 2026-08-13 16:27, Sebastian Barthel <naitsabes@freenet.de> wrote: >> Am Wed, 12 Aug 2026 22:59:57 +0200 schrieb der Meister Peter J. Holzer >> folgendes: >> >>> On 2026-08-12 18:38, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>> Am Wed, 12 Aug 2026 13:19:31 +0200 schrieb der Meister Peter J. >>>> Holzer folgendes: >>>>> On 2026-08-12 03:56, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>>>> Und genau das wird dann halt wieder langsamer, als es sein könnte, >>>>>> wenn die Zahlen "gut" passen würden. >>>>> >>>>> Weniger als ein Taktzyklus ist schwierig. Vielleicht könnte man >>>>> einen 12-Bit-Prozessor etwas schneller takten als einen >>>>> 64-Bit-Prozessor, aber das würde durch die höhere Anzahl >>>>> Instruktionen mehr als wettgemacht. >>> [...] >>>> Warum man 12 Bit schneller takten können soll als 64 Bit, erschließt >>>> sich mir nicht wirklich. >>> >>> Warum glaubst Du dann, dass ein 64-Bit-Prozessor langsamer sein sollte >>> als ein ein 12-Bit-Prozessor? Glaubst Du wirklich, dass man für ein >>> n-Bit-Addition n Taktzyklen braucht? Ich glaube, Du hast mindestens 50 >>> Jahre Prozessorentwicklung verschlafen. >> >> Es ging um das da >> >>> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter >>> dient nur dazu, Speicher zu sparen. >>> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne >>> mal 512 Bit, und die kleineren Einheiten dienen auch der >>> Parallelisierung.) >> >> Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich >> Byteweise das da wieder herausholen will, dann wird das langsamer (man >> muß dann shiften oder logisch verknüpfen oder was auch immer tun, aber >> in meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die >> Programmiersprache den evtl versteckt)). > > Prozessoren haben Instruktionen, um einzelne Bytes (und andere kleinere > Einheiten) im RAM zugreifen zu können[1]. Ja, das läuft unter Umständen > darauf hinaus, dass der Prozessor das, was er aus dem Cache liest, noch > shiften, maskieren und eventuell sign-extenden muss und das kostet ein > paar Gate-Delays (siehe Thomas Koenigs Posting), aber das sind sehr > einfache Operationen, das geht sich locker innerhalb eines Taktzyklus > aus. Ein Load von einem Byte ist nicht langsamer als eines von einem > ganzen Wort - allerdings auch nicht schneller. Gut. Mit der Erklärung "nebenan" war das, glaub ich, verständlich. >> Das hat auch nichts mit dem Takt zu tun. > > Indirekt schon, weil - wie Thomas ausgeführt hat, ein Taktzyklus lang > genug für die komplizierteste Instruktion, die in einem Takt ausgeführt > werden soll, sein muss. Macht man weniger in einem Takt, kann man > schneller takten. Aber das Grenzen. Der langsamte bestimmt den Maximalspeed, sozusagen. > [1] Ausnahme war der DEC Alpha (zumindest die ersten Modelle). Der hatte > tatsächlich nur Load- und Store-Instruktionen für 32 und 64 Bit. > Wollte man ein Byte oder 16-Bit-Wort laden, musste man die > notwendigen Shift- und And-Operationen explizit machen. Das war anscheinend ein schöner Chip. Habe ein paar DEC Zeitschriften aus der Zeit - die waren da wohl schon ganz stolz auf ihre Gerätereihe, die sie damit gebaut hatten. Alpha Server 2100 und sowas in der Art bis hin zu den ganz großen Schränken. Ich finden das ja eigentlich charmant, daß man sagt, man hat einen xy Architektur und kann eben nur xy laden/speichern. Das hat was sehr "ästhetisches". Mit den beschriebenen Infos oben zu dem heutigen Prozedere, macht das natürlich dann wahrscheinlich schon Sinn, die Option auf andere Größen (wieder) zu eröffnen. VG, SBn
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-08-13 18:36 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115l2s4$1tfu0$1@dont-email.me> |
| In reply to | #56206 |
Sebastian Barthel <naitsabes@freenet.de> schrieb: > Am Wed, 12 Aug 2026 22:59:57 +0200 schrieb der Meister Peter J. Holzer > folgendes: >> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter >> dient nur dazu, Speicher zu sparen. >> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne mal >> 512 Bit, und die kleineren Einheiten dienen auch der Parallelisierung.) > > Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich > Byteweise das da wieder herausholen will, dann wird das langsamer (man muß > dann shiften oder logisch verknüpfen oder was auch immer tun, aber in > meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die > Programmiersprache den evtl versteckt)). > > Das hat auch nichts mit dem Takt zu tun. Moderne Architekturen (ausser den ganz primitiven) verwenden Caches, der den Speicher in "cache lines" unterteilt, im Moment häufig 64 Bytes = 512 Bits. Ein Lesevorgang holt sich also die Cache Line und extrahiert daraus die gewünschten Daten der richtigen Größe. Dafür braucht man also schon Shifter. Wenn die Architektur auch mit Daten klarkommt, die über eine Cache Line hinausgehen, dann müssen dafür zwei geholt und die Daten zusammengesetzt werden. Die /360 konnte das nicht, die frühen RISC-Architekturen auch nicht; x86 konnte es schon immer, und bei RISC und /370 kam es dazu. Ein Schreibvorgang ist potentiell noch komplizierter: Eine (oder zwei) Cache Lines werden geholt, die Daten überschrieben, und dann wieder zurückgeschrieben. Da heute immer (außer für AVX-512) die Cache Lines größer sind als die Register, ist die Logik sowieso nötig, aber man braucht halt mehr Ebenen im Shifter. Bei der Alpha wollten sie das damals sparen, indem sie am Anfang nur load/store von 32- und 64-bit-Werten unterstützt hatten. Hat sich als Fehler herausgestellt und wurde später geändert. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-13 20:11 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115l8d0$dss4$1@solani.org> |
| In reply to | #56209 |
Am Thu, 13 Aug 2026 18:36:52 +0000 schrieb der Meister Thomas Koenig folgendes: > Sebastian Barthel <naitsabes@freenet.de> schrieb: >> Am Wed, 12 Aug 2026 22:59:57 +0200 schrieb der Meister Peter J. Holzer >> folgendes: > >>> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter >>> dient nur dazu, Speicher zu sparen. >>> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne >>> mal 512 Bit, und die kleineren Einheiten dienen auch der >>> Parallelisierung.) >> >> Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich >> Byteweise das da wieder herausholen will, dann wird das langsamer (man >> muß dann shiften oder logisch verknüpfen oder was auch immer tun, aber >> in meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die >> Programmiersprache den evtl versteckt)). >> >> Das hat auch nichts mit dem Takt zu tun. > > Moderne Architekturen (ausser den ganz primitiven) verwenden Caches, der > den Speicher in "cache lines" unterteilt, im Moment häufig 64 Bytes = > 512 Bits. > > Ein Lesevorgang holt sich also die Cache Line und extrahiert daraus die > gewünschten Daten der richtigen Größe. Dafür braucht man also schon > Shifter. Wenn die Architektur auch mit Daten klarkommt, die über eine > Cache Line hinausgehen, dann müssen dafür zwei geholt und die Daten > zusammengesetzt werden. Die /360 konnte das nicht, die frühen > RISC-Architekturen auch nicht; x86 konnte es schon immer, und bei RISC > und /370 kam es dazu. OK. Die Argumentation ist also ungefähr so: Es WIRD sowieso IMMER geshiftet bevor ein Wert das Register erreicht, weshalb es dann auch völlig egal ist wie groß die Zahl ist, solange sie ins Register paßt. Richtig ? > Ein Schreibvorgang ist potentiell noch komplizierter: Eine (oder zwei) > Cache Lines werden geholt, die Daten überschrieben, und dann wieder > zurückgeschrieben. > Da heute immer (außer für AVX-512) die Cache Lines größer sind als die > Register, ist die Logik sowieso nötig, aber man braucht halt mehr Ebenen > im Shifter. Bei der Alpha wollten sie das damals sparen, indem sie am > Anfang nur load/store von 32- und 64-bit-Werten unterstützt hatten. Hat > sich als Fehler herausgestellt und wurde später geändert. Der (originale) ARM macht das ja irgendwie auch so - der speichert m.W. nur 32Bit Werte und die immer auf 4 Byte Positionen "aligned". Es gibt zwar auch die Möglichkeit auf Bytes zuzugreifen, aber das wird "teuer", weshalb es völlig unüblich war. VG, SBn
[toc] | [prev] | [next] | [standalone]
| From | Christian Weisgerber <naddy@mips.inka.de> |
|---|---|
| Date | 2026-08-13 22:08 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <slrn117sg3m.1fak.naddy@lorvorc.mips.inka.de> |
| In reply to | #56210 |
On 2026-08-13, Sebastian Barthel <naitsabes@freenet.de> wrote: > Der (originale) ARM macht das ja irgendwie auch so - der speichert m.W. > nur 32Bit Werte und die immer auf 4 Byte Positionen "aligned". Es gibt > zwar auch die Möglichkeit auf Bytes zuzugreifen, aber das wird "teuer", > weshalb es völlig unüblich war. ARM hatte schon immer¹ LDRB/STRB um ein einzelnes Bytes zu lesen/ schreiben. Die waren auch nicht "teuer". ¹) ARM2, Acorn Archimedes. -- Christian "naddy" Weisgerber naddy@mips.inka.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-08-14 06:06 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115mb9s$28svi$1@dont-email.me> |
| In reply to | #56210 |
Sebastian Barthel <naitsabes@freenet.de> schrieb: > Am Thu, 13 Aug 2026 18:36:52 +0000 schrieb der Meister Thomas Koenig > folgendes: > >> Sebastian Barthel <naitsabes@freenet.de> schrieb: >>> Am Wed, 12 Aug 2026 22:59:57 +0200 schrieb der Meister Peter J. Holzer >>> folgendes: >> >>>> Das originäre Wortformat bei aktuellen CPUs ist 64-Bit. Alles darunter >>>> dient nur dazu, Speicher zu sparen. >>>> (Außer, wenn man SIMD-Instruktionen dazurechnet. Dann sind es gerne >>>> mal 512 Bit, und die kleineren Einheiten dienen auch der >>>> Parallelisierung.) >>> >>> Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich >>> Byteweise das da wieder herausholen will, dann wird das langsamer (man >>> muß dann shiften oder logisch verknüpfen oder was auch immer tun, aber >>> in meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die >>> Programmiersprache den evtl versteckt)). >>> >>> Das hat auch nichts mit dem Takt zu tun. >> >> Moderne Architekturen (ausser den ganz primitiven) verwenden Caches, der >> den Speicher in "cache lines" unterteilt, im Moment häufig 64 Bytes = >> 512 Bits. >> >> Ein Lesevorgang holt sich also die Cache Line und extrahiert daraus die >> gewünschten Daten der richtigen Größe. Dafür braucht man also schon >> Shifter. Wenn die Architektur auch mit Daten klarkommt, die über eine >> Cache Line hinausgehen, dann müssen dafür zwei geholt und die Daten >> zusammengesetzt werden. Die /360 konnte das nicht, die frühen >> RISC-Architekturen auch nicht; x86 konnte es schon immer, und bei RISC >> und /370 kam es dazu. > > OK. Die Argumentation ist also ungefähr so: Es WIRD sowieso IMMER > geshiftet bevor ein Wert das Register erreicht, weshalb es dann auch > völlig egal ist wie groß die Zahl ist, solange sie ins Register paßt. > > Richtig ? Nicht völlig egal, es gibt einen zusätzlichen Aufwand. Pro Bit braucht der Shifter eine zusäztliche Ebne. Deshalb haben wir keine Bit-addressierbaren Architekturen (wofür 64-Bit Addressen durchaus ausreichen würden, zumindest für die allermeisten Aufgaben). 8-Bit-Adressierbarkeit ist von der gegenwärtigen Software so häufig gefordert, dass es sich lohnt. Bei der ursprünglichen Alpha wollten sie sich das einsparen. Kann man bei https://shiftleft.com/mirrors/www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art1.pdf nachlesen. Ich habe die mal im Rückblick (und mit meiner persönlichen Perspektive :-) eingeordnet. # Thus, the Alpha AXP architecture has no condition codes, Gute Idee. # no global exception enables, Eher schlecht. # no multiplier-quotient or string registers, Gute Idee. Mehr als ein Register als Ziel macht Dinge kompliziert. Für Multiplikationen gibt es "multiply high", und ein "multiply" gefolgt von einem "multiply high" mit den gleichen Quellen kann man gut zusammenfassen, dann kostet das multiply high nur einen extra Zyklus. # no branch delay slots, Gute Idee. Branch Delay funktioniert für eine einzelne Pipeline, für superskalar ist es schlecht. # no suppressed instructions or skips, Die können m.E. für bestimmte Sachen gut sein, aber man braucht sie nicht unbedingt, vor allem mit guten branch predictors. # no precise arithmetic exceptions, Schlechte Idee, aber damit waren sie nicht allein. # and no single-byte writes to memory. Ganz schlechte Idee. # All of these features, found in some RISC architectures, have # the effect of hindering multiple instruction issue, or hindering # pipelining of multiple instances of the same instruction. Joo... einfach für den Hardware-Designer, schlecht für den Progrmmierer :-) Und dann noch das Memory-Modell, was berühmt ist, aber nicht aus den richtigen Gründen. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2026-08-14 02:42 +0200 |
| Subject | Re: Wortgrößen |
| Message-ID | <ne76jfFgkq3U1@mid.individual.net> |
| In reply to | #56206 |
Am 13.08.26 um 16:27 schrieb Sebastian Barthel: > Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich > Byteweise das da wieder herausholen will, dann wird das langsamer (man muß > dann shiften oder logisch verknüpfen oder was auch immer tun, aber in > meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die > Programmiersprache den evtl versteckt)). > > Das hat auch nichts mit dem Takt zu tun. shiften kann mit Multiplexer/Demultiplexer erledigt werden, so das kaum Taktzeiten verlorengehen. Früher erwog ich mal, ALUs mit ERPROMs zu machen. Wenn das mit pipeline und Parallelverarbeitung verknüpft wird... -- <https://www.hermann-riemann.de> bzw.: <https://www.hermann-riemann.eu/de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-08-14 06:13 +0000 |
| Subject | Re: Wortgrößen |
| Message-ID | <115mblf$28svi$2@dont-email.me> |
| In reply to | #56213 |
Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb: > Am 13.08.26 um 16:27 schrieb Sebastian Barthel: > >> Wenn man mit dem Modus wirklich Speicher sparen will und z.B. wirklich >> Byteweise das da wieder herausholen will, dann wird das langsamer (man muß >> dann shiften oder logisch verknüpfen oder was auch immer tun, aber in >> meinem Verständnis erfordert es immer Zusatzaufwand (auch wenn die >> Programmiersprache den evtl versteckt)). >> >> Das hat auch nichts mit dem Takt zu tun. > > shiften kann mit Multiplexer/Demultiplexer erledigt werden, > so das kaum Taktzeiten verlorengehen. > > Früher erwog ich mal, ALUs mit ERPROMs zu machen. DEC hat das z.T. gemacht, zum Beispiel waren die 4*4 - Multiplizierer auf der VAX 11-780 ROMS. > Wenn das mit pipeline und Parallelverarbeitung verknüpft wird... Klar. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
Page 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web