Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #47248 > unrolled thread
| Started by | "F. W." <me@home.invalid> |
|---|---|
| First post | 2025-01-22 09:30 +0100 |
| Last post | 2025-03-01 15:11 +0100 |
| Articles | 20 on this page of 182 — 25 participants |
Back to article view | Back to de.alt.folklore.computer
Acorn Archimedes "F. W." <me@home.invalid> - 2025-01-22 09:30 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-01-22 10:49 +0100
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-22 18:09 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-22 19:35 +0100
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-22 22:50 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-23 09:14 +0100
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-24 20:39 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-27 17:56 +0100
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-27 21:13 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-28 17:32 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-28 21:05 +0000
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-23 19:34 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-24 20:52 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-25 10:23 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-01-25 13:12 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-25 12:31 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-25 15:42 +0000
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-27 21:30 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-28 17:03 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-28 21:03 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-29 18:02 +0100
Re: Acorn Archimedes Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-01-29 19:13 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-29 21:00 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-30 18:21 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-30 20:59 +0000
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-01-31 06:27 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-01 07:39 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-01 09:27 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-01 09:35 +0000
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-02-01 11:16 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-01 12:03 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-02 09:35 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-02 10:22 +0000
Re: Acorn Archimedes Markus Elsken <markus.elsken@ewetel.net> - 2025-02-02 13:59 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-02-02 14:25 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-02 21:40 +0000
Re: Acorn Archimedes Clemens Schüller <cs.usenet@mailbox.org> - 2025-02-02 22:52 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-03 10:24 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-03 17:21 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-03 18:03 +0000
Re: Acorn Archimedes "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2025-02-04 12:01 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-04 11:37 +0000
Re: Acorn Archimedes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-02-04 12:55 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-04 12:26 +0000
Re: Acorn Archimedes Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-02-04 14:51 +0100
Re: Acorn Archimedes "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2025-02-04 21:55 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-05 07:06 +0000
Re: Acorn Archimedes Michael Kraemer <m.kraemer@gsi.de> - 2025-02-06 11:05 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-06 21:18 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-04 17:50 +0100
Re: Acorn Archimedes "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2025-02-04 22:31 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-04 22:06 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-05 17:02 +0100
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-31 11:19 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-01 08:43 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-02 09:22 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-02 09:59 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-02-03 17:29 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-02-03 17:04 +0000
Re: Acorn Archimedes Kay Martinen <usenet@martinen.de> - 2025-01-29 19:56 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-29 21:25 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-26 14:02 +0000
Re: Acorn Archimedes Markus Elsken <markus.elsken@ewetel.net> - 2025-01-25 15:12 +0100
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-25 15:18 +0000
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-25 16:22 +0000
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-26 09:18 +0100
Re: Acorn Archimedes mlelstv@serpens.de (Michael van Elst) - 2025-01-26 08:46 +0000
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-26 10:44 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-26 21:54 +0000
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-31 18:30 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-01 10:07 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-01 10:10 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-01 15:03 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-01 18:25 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-01 16:05 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-01 19:13 +0100
Re: Acorn Archimedes Markus Elsken <markus.elsken@ewetel.net> - 2025-02-02 14:01 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-03 18:41 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-01-24 17:32 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-01-22 20:11 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-22 19:33 +0000
Re: Acorn Archimedes Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-01-22 21:32 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-22 22:19 +0000
Re: Acorn Archimedes Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-01-23 13:17 +0100
Re: Acorn Archimedes Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2025-01-23 16:36 +0100
Re: Acorn Archimedes Arno Welzel <usenet@arnowelzel.de> - 2025-01-24 22:27 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-23 17:33 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-24 20:56 +0000
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-25 09:01 +0000
Re: Acorn Archimedes Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2025-01-23 16:40 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-23 17:25 +0000
Re: Acorn Archimedes Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2025-01-23 20:16 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-01-24 17:44 +0100
Re: Acorn Archimedes Stefan Reuther <stefan.news@arcor.de> - 2025-01-24 19:16 +0100
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-01-24 21:25 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-23 13:28 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-02-06 03:06 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-22 10:36 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-22 10:39 +0100
Re: Acorn Archimedes Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-01-22 17:04 +0100
Re: Acorn Archimedes Arno Welzel <usenet@arnowelzel.de> - 2025-01-22 19:39 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-22 20:29 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-27 18:43 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-02-06 03:17 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-22 22:28 +0000
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-24 08:23 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-24 07:47 +0100
Re: Acorn Archimedes Christian Corti <use@reply.to> - 2025-01-24 09:23 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-24 10:22 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-24 10:23 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-25 16:25 +0100
Re: Acorn Archimedes Andreas Eder <a_eder_muc@web.de> - 2025-01-24 16:12 +0100
Re: Acorn Archimedes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-01-24 17:48 +0100
Re: Acorn Archimedes Ulf_Kutzner <Ulf.Kutzner@web.de> - 2025-01-24 16:56 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-25 15:01 +0100
Re: Acorn Archimedes Andreas Eder <a_eder_muc@web.de> - 2025-01-25 17:14 +0100
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-01-25 22:16 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-26 08:03 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-26 15:43 +0100
Re: Acorn Archimedes Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-01-26 16:55 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-27 14:11 +0100
Re: Acorn Archimedes Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-01-27 18:26 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-27 19:04 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-24 07:50 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-02-06 03:21 +0000
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-09 06:55 +0100
Re: Acorn Archimedes Kay Martinen <usenet@martinen.de> - 2025-04-10 10:08 +0200
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-04-10 20:09 +0200
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-04-10 20:19 +0200
Re: Acorn Archimedes Frank Nitzschner <nospam@nitzschner.de> - 2025-04-12 17:43 +0200
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-01-24 08:06 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-25 16:20 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-01-26 15:54 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-02-06 03:41 +0000
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-15 15:40 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-15 16:36 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-16 07:05 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-22 17:06 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-02-23 05:27 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-03-06 20:16 +0000
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-07 18:13 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-03-07 19:08 +0000
Re: Acorn Archimedes Christian Weisgerber <naddy@mips.inka.de> - 2025-03-07 20:31 +0000
Re: Acorn Archimedes Thomas Koenig <tkoenig@netcologne.de> - 2025-03-08 07:36 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-02-24 18:51 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-01 11:24 +0100
Re: Acorn Archimedes Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2025-03-01 13:53 +0100
Re: Acorn Archimedes Joerg Walther <joerg.walther@magenta.de> - 2025-03-01 15:27 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-01 16:31 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-01 17:26 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-01 18:02 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-01 18:04 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-02 10:19 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-02 13:04 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-02 13:18 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-02 15:36 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-02 17:34 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-02 20:57 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-02 13:30 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-02 13:36 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-07 17:41 +0100
Re: Acorn Archimedes Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-03-02 19:10 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-04 20:05 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-04 20:13 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-02 10:14 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-02 13:27 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-02 15:59 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-15 16:27 +0100
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-16 11:01 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-02 17:49 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-03-04 00:38 +0000
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-04 21:30 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-03-05 20:26 +0000
Re: Acorn Archimedes olaf <olaf@criseis.ruhr.de> - 2025-03-06 08:40 +0100
Re: Acorn Archimedes Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-03-07 18:19 +0100
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-02 12:41 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-01 16:39 +0100
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-01 14:21 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-03-04 00:55 +0000
Re: Acorn Archimedes "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-03-04 21:45 +0100
Re: Acorn Archimedes Sebastian Barthel <naitsabes@freenet.de> - 2025-03-05 20:17 +0000
Re: Acorn Archimedes michaelnoeusenet@mac.com (Michael Noe) - 2025-03-01 15:11 +0100
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-01-29 18:02 +0100 |
| Message-ID | <vndqfn.1h0.1@stefan.msgid.phost.de> |
| In reply to | #47322 |
Am 28.01.2025 um 22:03 schrieb Thomas Koenig: > Stefan Reuther <stefan.news@arcor.de> schrieb: >> Am 27.01.2025 um 22:30 schrieb Thomas Koenig: >>> Beispiel: Die simple "add" - Instruktion hat folgende Varianten >>> (Rdst ist das Destination-Register, Rsrc1 das erste Source-Register, >>> Rsrc2 das zweite Source-Register, Imm5 eine 5-Bit-Zahl etc). >>> >>> add Rdst,#Imm32,Rsrc2 ; Rdst = Imm32 + Rsrc2, 8 byte >>> add Rdst,#Imm32,-Rsrc2 ; Rdst = Imm32 - Rsrc2, 8 byte >>> add Rdst,#-Imm5,Rsrc2 ! Rdst = -Imm5 + Rsrc2, 4 byte >>> add Rdst,#Imm5,Rsrc2 ! Rdst = Imm5 + Rsrc2, 4 byte >>> add Rdst,#Imm64,Rsrc2 ! Rdst = Imm64 + Rsrc2, 12 byte >>> add Rdst,#Imm64,-Rsrc2 ! Rdst = Imm64 - Rsrc2, 12 byte >> [...] >>> Es existiert auch ein Compiler und ein Assembler (letzterer >>> von mir). Im Vergleich zu RISC-V ist sehr interessant, wie vor >>> allem die Konstanten in der Instruktion zu Vereinfachungen und >>> kürzerem Code führen. >> >> Die Frage ist: vereinfacht für wen? Klar, für den >> Assembler-Programmierer, aber ist die Komplexität im Silizium das wert? > > Natürlich auch für Compiler. Dem Compiler ist das doch eigentlich ziemlich egal. Das ist ein Programm, das ist beliebig geduldig und kommt im Gegensatz zu dem Menschen mit vertauschten Vorzeichen oder Operanden nicht durcheinander. >> Variable Instruktionslänge wird ja gemeinhin als ein Nachteil von x86 >> angesehen. Insbesondere in Kombination mit misaligneten Daten führt das >> dann dazu, dass eine Instruktion beliebig viele Cache Misses oder gar >> Page Faults auslösen kann. > > Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes. > Immediates, die nicht in die 5-bit-Register passen, sind entweder > 32 oder 64 Bytes groß. [...] > Das ist in einem ziemlich ausgeklügelten Encoding reingepackt. > Um die Länge einer Instruktion zu dekodieren (also nachzuschauen, > wo die nächste Instruktion anfängt) werden 33 Gates benötigt, > maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet, > also vier Gate Delays. Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults auslösen kann, bleibt damit. > Das Problem bei x86 ist, dass die ISA immer wieder erweitert > wurde, so dass das Dekodieren wirklch schwierig wird und > Pipelines tiefer macht. Oder das Stack-Handling... IMHO > braucht Intel/AMD einen ganzen Zyklus, um die ganzen push- und > pop-Befehle zu einer Mikroinstruktion zusammenzfassen. Das > geht einfacher :-) Die ständig erweiterte ISA ist ein Problem. Aber push und pop sind in erster Linie auch nichts anderes als Store mit Prädekrement/ Postdekrement, was jeder RISC hat. Oder wo siehst du da ein Problem? Spaßig ist sowas wie "pop ss" (macht für die nächste Instruktion *alle* Interrupts zu inkl. NMI), aber das ist in amd64 hoffentlich kein Thema mehr... Stefan
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-01-29 19:13 +0100 |
| Message-ID | <vndpll$h81$1@news.bawue.net> |
| In reply to | #47324 |
On 1/29/25 18:02, Stefan Reuther wrote: > Spaßig ist sowas wie "pop ss" (macht für die nächste Instruktion *alle* > Interrupts zu inkl. NMI), aber das ist in amd64 hoffentlich kein Thema > mehr... Ein NMI den man abschalten kann ist aber irgendwie kein NMI mehr. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-29 21:00 +0000 |
| Message-ID | <vne4ts$2i301$1@dont-email.me> |
| In reply to | #47324 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 28.01.2025 um 22:03 schrieb Thomas Koenig:
>> Stefan Reuther <stefan.news@arcor.de> schrieb:
>>> Am 27.01.2025 um 22:30 schrieb Thomas Koenig:
>>>> Beispiel: Die simple "add" - Instruktion hat folgende Varianten
>>>> (Rdst ist das Destination-Register, Rsrc1 das erste Source-Register,
>>>> Rsrc2 das zweite Source-Register, Imm5 eine 5-Bit-Zahl etc).
>>>>
>>>> add Rdst,#Imm32,Rsrc2 ; Rdst = Imm32 + Rsrc2, 8 byte
>>>> add Rdst,#Imm32,-Rsrc2 ; Rdst = Imm32 - Rsrc2, 8 byte
>>>> add Rdst,#-Imm5,Rsrc2 ! Rdst = -Imm5 + Rsrc2, 4 byte
>>>> add Rdst,#Imm5,Rsrc2 ! Rdst = Imm5 + Rsrc2, 4 byte
>>>> add Rdst,#Imm64,Rsrc2 ! Rdst = Imm64 + Rsrc2, 12 byte
>>>> add Rdst,#Imm64,-Rsrc2 ! Rdst = Imm64 - Rsrc2, 12 byte
>>> [...]
>>>> Es existiert auch ein Compiler und ein Assembler (letzterer
>>>> von mir). Im Vergleich zu RISC-V ist sehr interessant, wie vor
>>>> allem die Konstanten in der Instruktion zu Vereinfachungen und
>>>> kürzerem Code führen.
>>>
>>> Die Frage ist: vereinfacht für wen? Klar, für den
>>> Assembler-Programmierer, aber ist die Komplexität im Silizium das wert?
>>
>> Natürlich auch für Compiler.
>
> Dem Compiler ist das doch eigentlich ziemlich egal. Das ist ein
> Programm, das ist beliebig geduldig und kommt im Gegensatz zu dem
> Menschen mit vertauschten Vorzeichen oder Operanden nicht durcheinander.
Klar, Compiler sind geduldig.
>
>>> Variable Instruktionslänge wird ja gemeinhin als ein Nachteil von x86
>>> angesehen. Insbesondere in Kombination mit misaligneten Daten führt das
>>> dann dazu, dass eine Instruktion beliebig viele Cache Misses oder gar
>>> Page Faults auslösen kann.
>>
>> Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes.
>> Immediates, die nicht in die 5-bit-Register passen, sind entweder
>> 32 oder 64 Bytes groß.
> [...]
>> Das ist in einem ziemlich ausgeklügelten Encoding reingepackt.
>> Um die Länge einer Instruktion zu dekodieren (also nachzuschauen,
>> wo die nächste Instruktion anfängt) werden 33 Gates benötigt,
>> maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet,
>> also vier Gate Delays.
>
> Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass
> eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults
> auslösen kann, bleibt damit.
Wir sind in dem Zeitalter angekommen, wo man für eine 64-bit-Architektur
eine minimale Cache-Line-Größe vorschreiben kann :-)
Mit 64 Bytes dache line kann eine Instrukion von maximal 20
Bytes dann höchstens einen Cache Miss auslösen. Und wer die
Mechanismen hat, um mit Daten, die nicht auf einer natürlichen
Grenze ausgerichtet sind, klarzukommen, sollte das auch für
Instruktionen hinbekommen :-)
>> Das Problem bei x86 ist, dass die ISA immer wieder erweitert
>> wurde, so dass das Dekodieren wirklch schwierig wird und
>> Pipelines tiefer macht. Oder das Stack-Handling... IMHO
>> braucht Intel/AMD einen ganzen Zyklus, um die ganzen push- und
>> pop-Befehle zu einer Mikroinstruktion zusammenzfassen. Das
>> geht einfacher :-)
>
> Die ständig erweiterte ISA ist ein Problem. Aber push und pop sind in
> erster Linie auch nichts anderes als Store mit Prädekrement/
> Postdekrement, was jeder RISC hat. Oder wo siehst du da ein Problem?
Wenn man das naiv macht, rennt man in Hazards bei Pipelines.
Nehmen wir mal
pushq %r14
pushq %r15
Das ist, ausgeschrieben,
leaq -8(%rsp),%rsp
movq %r14,(%rsp)
leaq -8(%rsp),%rsp
movq %r15,(%rsp)
Das ist ein read-after-write Hazard - ich kann das zweite subq erst
ausführen, wenn ich das Resultat des ersten habe, d.h. man müsste
da erst mal warten, bis der fertig ist. Das ist bei einer OoO -
Implementierung, bei der gleichzeitig viel Instruktionen parallel
laufen, sehr ärgerlich.
Lösung? Man könnte natürlich schreiben
movq %r14,8(%rsp)
movq %r15,16(%rsp)
leaq %rsp,16(%rsp)
Wie sieht das denn jetzt aus? Schaun mer mal:
foo:
pushq %r14
pushq %r15
bar:
leaq -8(%rsp),%rsp
subq $8, %rsp
movq %r14,(%rsp)
leaq -8(%rsp),%rsp
movq %r15,(%rsp)
baz:
movq %r14,-8(%rsp)
movq %r15,-16(%rsp)
leaq -16(%rsp),%rsp
(leaq, um die Renamer für die Flag-Register ein bisschen weniger
zu stressen).
wird disassembliert zu
0000000000000000 <foo>:
0: 41 56 push %r14
2: 41 57 push %r15
0000000000000004 <bar>:
4: 48 8d 64 24 f8 lea -0x8(%rsp),%rsp
9: 48 83 ec 08 sub $0x8,%rsp
d: 4c 89 34 24 mov %r14,(%rsp)
11: 48 8d 64 24 f8 lea -0x8(%rsp),%rsp
16: 4c 89 3c 24 mov %r15,(%rsp)
000000000000001a <baz>:
1a: 4c 89 74 24 f8 mov %r14,-0x8(%rsp)
1f: 4c 89 7c 24 f0 mov %r15,-0x10(%rsp)
24: 48 8d 64 24 f0 lea -0x10(%rsp),%rsp
(Ja, subq wäre ein Byte kürzer).
Vier oder 15 Bytes, das ist hier die Frage... aus Gründen der
Codegröße will natürlich jeder die Variante von foo.
Aber was nu? Damit das nicht zu dem Hazard führt, muss die
Sequenz von push - Instruktionen speziell behandelt werden, damit
die Micro-Ops intern die Variante von baz ausführen. Das ist
aber teuer und kostet (AFAIK) bei x86_64 einen vollen Zyklus beim
Dekodieren. Damit ist die Pipeline wieder tiefer, und das kostet
beim nächsten Branch Mispredict oder beim nächsten Interrupt.
Und Leistung frisst das auch.
Bei aarch64 wäre das ein add auf den Stackpointer und ein stp
(Store Pair), also acht Bytes, und einen ganzen Sack Komplikationen
weniger.
> Spaßig ist sowas wie "pop ss" (macht für die nächste Instruktion *alle*
> Interrupts zu inkl. NMI), aber das ist in amd64 hoffentlich kein Thema
> mehr...
*schauder*
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-01-30 18:21 +0100 |
| Message-ID | <vngfui.360.1@stefan.msgid.phost.de> |
| In reply to | #47327 |
Am 29.01.2025 um 22:00 schrieb Thomas Koenig: > Stefan Reuther <stefan.news@arcor.de> schrieb: >> Am 28.01.2025 um 22:03 schrieb Thomas Koenig: >>> Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes. >>> Immediates, die nicht in die 5-bit-Register passen, sind entweder >>> 32 oder 64 Bytes groß. >> [...] >>> Das ist in einem ziemlich ausgeklügelten Encoding reingepackt. >>> Um die Länge einer Instruktion zu dekodieren (also nachzuschauen, >>> wo die nächste Instruktion anfängt) werden 33 Gates benötigt, >>> maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet, >>> also vier Gate Delays. >> >> Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass >> eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults >> auslösen kann, bleibt damit. > > Wir sind in dem Zeitalter angekommen, wo man für eine 64-bit-Architektur > eine minimale Cache-Line-Größe vorschreiben kann :-) > > Mit 64 Bytes dache line kann eine Instrukion von maximal 20 > Bytes dann höchstens einen Cache Miss auslösen. ...und dazu noch TLB Misses und Page Faults, sowie die von dem in der Instruktion enthaltenen Speicherzugriff enthaltenen Datum. Das schlägt dann bis auf die Software durch, die dann aufpassen muss, jene Page/TLB-Einträge nicht zu löschen, um Fortschritt gewährleisten zu können. Kein unlösbares Problem, aber eben dennoch eine Entscheidung, die ich in der Form nicht treffen würde, wenn meine Mission "Einfachheit" lautet. >> Die ständig erweiterte ISA ist ein Problem. Aber push und pop sind in >> erster Linie auch nichts anderes als Store mit Prädekrement/ >> Postdekrement, was jeder RISC hat. Oder wo siehst du da ein Problem? > > Wenn man das naiv macht, rennt man in Hazards bei Pipelines. > > Nehmen wir mal > > pushq %r14 > pushq %r15 > > Das ist, ausgeschrieben, > > leaq -8(%rsp),%rsp > movq %r14,(%rsp) > leaq -8(%rsp),%rsp > movq %r15,(%rsp) > > Das ist ein read-after-write Hazard - ich kann das zweite subq erst > ausführen, wenn ich das Resultat des ersten habe, d.h. man müsste > da erst mal warten, bis der fertig ist. Das ist bei einer OoO - > Implementierung, bei der gleichzeitig viel Instruktionen parallel > laufen, sehr ärgerlich. Das Problem hat ARM bei 'push r0' aka 'str r0, [sp, #-4]!' ebenso. Und jede andere RISC-Architektur auch. Also kein Vorwurf, den man x86 oder amd64 machen könnte. > Bei aarch64 wäre das ein add auf den Stackpointer und ein stp > (Store Pair), also acht Bytes, und einen ganzen Sack Komplikationen > weniger. Würdest du das so machen, hättest du wieder den möglichen Hazard beim 'add', und das 'stp' löst dir nur den Spezialfall, dass du genau zwei Register hast, die m.W. auch noch benachbart sein müssen. Praktisch vermeiden Compiler offenbar heutzutage push/pop, sondern legen die Stackframes bereits mit entsprechend Platz an und nutzen dann entsprechend SP- oder FP-relative Adressierung, und zwar sowohl bei ARM, als auch bei amd64. >> Spaßig ist sowas wie "pop ss" (macht für die nächste Instruktion *alle* >> Interrupts zu inkl. NMI), aber das ist in amd64 hoffentlich kein Thema >> mehr... > > *schauder* Das ist halt nötig, damit es zuverlässig funktioniert, denn wenn der Interrupt zuschlägt, während du gerade die Hälfte der Stack-Adresse geladen hast, versaut dir das ganz schön den Tag. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-01-30 20:59 +0000 |
| Message-ID | <vngp78$34a0h$1@dont-email.me> |
| In reply to | #47329 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 29.01.2025 um 22:00 schrieb Thomas Koenig:
>> Stefan Reuther <stefan.news@arcor.de> schrieb:
>>> Am 28.01.2025 um 22:03 schrieb Thomas Koenig:
>>>> Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes.
>>>> Immediates, die nicht in die 5-bit-Register passen, sind entweder
>>>> 32 oder 64 Bytes groß.
>>> [...]
>>>> Das ist in einem ziemlich ausgeklügelten Encoding reingepackt.
>>>> Um die Länge einer Instruktion zu dekodieren (also nachzuschauen,
>>>> wo die nächste Instruktion anfängt) werden 33 Gates benötigt,
>>>> maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet,
>>>> also vier Gate Delays.
>>>
>>> Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass
>>> eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults
>>> auslösen kann, bleibt damit.
>>
>> Wir sind in dem Zeitalter angekommen, wo man für eine 64-bit-Architektur
>> eine minimale Cache-Line-Größe vorschreiben kann :-)
>>
>> Mit 64 Bytes dache line kann eine Instrukion von maximal 20
>> Bytes dann höchstens einen Cache Miss auslösen.
>
> ...und dazu noch TLB Misses und Page Faults, sowie die von dem in der
> Instruktion enthaltenen Speicherzugriff enthaltenen Datum.
Jep. Und ansonsten kommt das halt ein bissschen später, wenn die
nächste oder übernächste Instruktion ausgeführt wird.
> Das schlägt dann bis auf die Software durch, die dann aufpassen muss,
> jene Page/TLB-Einträge nicht zu löschen, um Fortschritt gewährleisten zu
> können.
Wenn mein Code insgesamt größer wird, habe ich mehr cache misses/
TLB misses.
Schauen wir uns doch mal den Assembler-Code an:
void foo (long int *a, long int b)
{
a[b+0xFEDCBA0987654321] = 0x1234567890ABCDEF;
}
ist in 64-bit RISC-V
foo:
li a5,-610844672
addi a5,a5,305
slli a5,a5,13
addi a5,a5,-619
slli a5,a5,14
addi a5,a5,801
li a3,593920
add a1,a1,a5
addi a3,a3,-1347
li a5,38178816
slli a3,a3,12
addi a5,a5,-1329
slli a1,a1,3
addi a3,a3,-529
slli a5,a5,35
add a0,a0,a1
add a5,a5,a3
sd a5,0(a0)
ret
19 Instruktionen, 76 Bytes, Wahrscheinlichkeit, dass eine cache line
überschritten wird, wenn man 64-Byte-Cachelienes hat: 100%.
Vergleich: My 66000
foo: ; @foo
; %bb.0: ; %entry
std #1311768467294899695,[r1,r2<<3,-655889144883832568]
ret
Zwei Instruktionen, 24 Bytes, Wahrscheinlichkeit, dass eine cache line
überschritten wird, wenn man 64-Byte cache lines hat und zufälliges
Alignment: 5/16.
Was ist besser?
(OK, das Beispiel ist gemein, das ist eine spezielle Schwäche
von RISC-V).
> Kein unlösbares Problem, aber eben dennoch eine Entscheidung,
> die ich in der Form nicht treffen würde, wenn meine Mission
> "Einfachheit" lautet.
Die Mission lautet eher "Hohe Performacnce", und wo Einfachheit da
hilft, ist das gut.
>
>>> Die ständig erweiterte ISA ist ein Problem. Aber push und pop sind in
>>> erster Linie auch nichts anderes als Store mit Prädekrement/
>>> Postdekrement, was jeder RISC hat. Oder wo siehst du da ein Problem?
>>
>> Wenn man das naiv macht, rennt man in Hazards bei Pipelines.
>>
>> Nehmen wir mal
>>
>> pushq %r14
>> pushq %r15
>>
>> Das ist, ausgeschrieben,
>>
>> leaq -8(%rsp),%rsp
>> movq %r14,(%rsp)
>> leaq -8(%rsp),%rsp
>> movq %r15,(%rsp)
>>
>> Das ist ein read-after-write Hazard - ich kann das zweite subq erst
>> ausführen, wenn ich das Resultat des ersten habe, d.h. man müsste
>> da erst mal warten, bis der fertig ist. Das ist bei einer OoO -
>> Implementierung, bei der gleichzeitig viel Instruktionen parallel
>> laufen, sehr ärgerlich.
>
> Das Problem hat ARM bei 'push r0' aka 'str r0, [sp, #-4]!' ebenso.
push ist eine Abkürzung für STMDB sp!, reglist .
Das ist eine einzige Instruktion, die eine Liste von Registern
abspeichert und danach den Stack Pointer updated. Im Gegensatz
zu x86 gibt es da keinen Hazard.
> Und
> jede andere RISC-Architektur auch. Also kein Vorwurf, den man x86 oder
> amd64 machen könnte.
"Jede andere" RISC-Architektur stimmt nicht. Die beiden kanonischen
RISC-Architekturne sind SPARC und MIPS und keine von beiden hat
so etwas. POWER hat load/store with update, das wird dann einfach
in zwei Mikroinstruktionen gecrackt.
Und was auf Mikroprozessoren der frühen Generationen als eine gute
Idee erschien, hat sich mittlerweile als Problem herausgestellt.
Bei aarch64 haben sie store multiple/load multiple verzichtet.
>
>> Bei aarch64 wäre das ein add auf den Stackpointer und ein stp
>> (Store Pair), also acht Bytes, und einen ganzen Sack Komplikationen
>> weniger.
>
> Würdest du das so machen, hättest du wieder den möglichen Hazard beim
> 'add', und das 'stp' löst dir nur den Spezialfall, dass du genau zwei
> Register hast, die m.W. auch noch benachbart sein müssen.
Das ist ja der Punkt - ich muss den Stackpointer nur einmal anpassen,
also kein Hazard.
Und die calling conventions nun mal so, dass nebeneinanderliegnde
Register entweder beim Caller oder beim Callee abgespeichert werdem
>
> Praktisch vermeiden Compiler offenbar heutzutage push/pop, sondern legen
> die Stackframes bereits mit entsprechend Platz an und nutzen dann
> entsprechend SP- oder FP-relative Adressierung, und zwar sowohl bei ARM,
> als auch bei amd64.
So offenbar ist das nicht.
Mal den Anfang einer semi-beliebigen Funktion aus libgfortran
disassembliert:
0000000000000000 <matmul_r4_avx>:
0: f3 0f 1e fa endbr64
4: 41 55 push %r13
6: 41 89 ca mov %ecx,%r10d
9: 4c 8d 6c 24 10 lea 0x10(%rsp),%r13
e: 48 83 e4 e0 and $0xffffffffffffffe0,%rsp
12: 41 ff 75 f8 push -0x8(%r13)
16: 55 push %rbp
17: 48 89 e5 mov %rsp,%rbp
1a: 41 57 push %r15
1c: 49 89 d7 mov %rdx,%r15
1f: 41 56 push %r14
21: 41 55 push %r13
23: 49 89 f5 mov %rsi,%r13
26: 41 54 push %r12
28: 49 89 fc mov %rdi,%r12
2b: 53 push %rbx
2c: 48 81 ec 48 04 00 00 sub $0x448,%rsp
Da sind jede Menge push-Befehle...
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-01-31 06:27 +0100 |
| Message-ID | <slrnvponpg.ojbu.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #47330 |
On 2025-01-30 20:59, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Stefan Reuther <stefan.news@arcor.de> schrieb:
>> Am 29.01.2025 um 22:00 schrieb Thomas Koenig:
>>> Stefan Reuther <stefan.news@arcor.de> schrieb:
>>>> Am 28.01.2025 um 22:03 schrieb Thomas Koenig:
>>>>> Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes.
>>>>> Immediates, die nicht in die 5-bit-Register passen, sind entweder
>>>>> 32 oder 64 Bytes groß.
>>>> [...]
>>>>> Das ist in einem ziemlich ausgeklügelten Encoding reingepackt.
>>>>> Um die Länge einer Instruktion zu dekodieren (also nachzuschauen,
>>>>> wo die nächste Instruktion anfängt) werden 33 Gates benötigt,
>>>>> maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet,
>>>>> also vier Gate Delays.
>>>>
>>>> Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass
>>>> eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults
>>>> auslösen kann, bleibt damit.
>>>
>>> Wir sind in dem Zeitalter angekommen, wo man für eine 64-bit-Architektur
>>> eine minimale Cache-Line-Größe vorschreiben kann :-)
>>>
>>> Mit 64 Bytes dache line kann eine Instrukion von maximal 20
>>> Bytes dann höchstens einen Cache Miss auslösen.
>>
>> ...und dazu noch TLB Misses und Page Faults, sowie die von dem in der
>> Instruktion enthaltenen Speicherzugriff enthaltenen Datum.
>
> Jep. Und ansonsten kommt das halt ein bissschen später, wenn die
> nächste oder übernächste Instruktion ausgeführt wird.
Es macht aber einen Unterschied, ob diese Misses während einer
Instruktion auftreten oder "zwischen" den Instruktionen.
Wenn jede Instruktion ein 32-Bit-Wort lang ist, kann ein Cache-Miss,
TLB-Miss, Page-Miss jeweils nur genau beim Laden dieses Worts auftreten.
Der wird behandelt und nach der Behandlung kann dieses Wort gelesen
werden.
Wenn eine Instruktion zwei oder mehr Worte lang ist, kann ein Cache Miss
bei einem beliebigen dieser Worte auftreten. Beim ersten Wort ist es
gleich wie oben: Der Miss wird behandelt, danach stehen alle Worte der
Instruktion zur Verfügung. Aber bei allen anderen kann es komplizierter
werden: Es besteht die Gefahr, dass man sich während der Behandlung des
Misses für dieses Wort den Cache-, TLB- oder Page-Eintrag für das erste
Wort rausschießt. Wenn der Handler dann zurückkehrt, kann bekommt der
Prozessor beim Versuch, das erste Wort der Instruktion zu lesen, einen
Miss, im Handler schießt er sich dann den zweiten wieder raus und so
weiter - d.h. die Instruktion kann nie geladen werden.
Wie Stefan geschrieben hat, ist das kein unlösbares Problem, ich würde
sogar annehmen, dass die Standard-Implementationen (ob in Hardware oder
Software) das bereits lösen, aber es ist etwas, das man bedenken muss.
Das Laden der Instruktionen dürfte da allerdings auch der einfachere
Fall sein. Gemeiner sind Memory-Zugriffe der Instruktion selbst. Die VAX
hatte bis zu 3 memory-indirekte Parameter. Das waren also bis zu 6
Speicherzugriffe pro Instruktion, die alle unaligned sein konnten, also
tatsächlich 12. Plus bis zu 2 für die Instruktion selbst,
Page-Fault-Handler mussten also sicherstellen, dass mindestens die
letzten 14 Pages nicht wieder rausgeswappt wurden, weil man sonst in
eine Endlosschleife von Page-Misses kommen konnte.
hp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-01 07:39 +0000 |
| Message-ID | <vnkj4e$7v6$1@dont-email.me> |
| In reply to | #47331 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2025-01-30 20:59, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Stefan Reuther <stefan.news@arcor.de> schrieb: >>> Am 29.01.2025 um 22:00 schrieb Thomas Koenig: >>>> Stefan Reuther <stefan.news@arcor.de> schrieb: >>>>> Am 28.01.2025 um 22:03 schrieb Thomas Koenig: >>>>>> Die Archektur hat alle Instruktionen als Vielfaches von vier Bytes. >>>>>> Immediates, die nicht in die 5-bit-Register passen, sind entweder >>>>>> 32 oder 64 Bytes groß. >>>>> [...] >>>>>> Das ist in einem ziemlich ausgeklügelten Encoding reingepackt. >>>>>> Um die Länge einer Instruktion zu dekodieren (also nachzuschauen, >>>>>> wo die nächste Instruktion anfängt) werden 33 Gates benötigt, >>>>>> maximal 3-Eingänge NOR oder NAND, in vier Ebenen verschaltet, >>>>>> also vier Gate Delays. >>>>> >>>>> Das ist durchaus weniger komplex als bei Intel, aber das Problem, dass >>>>> eine Instruktion dann viele Cache Misses, TLB Misses und Page Faults >>>>> auslösen kann, bleibt damit. >>>> >>>> Wir sind in dem Zeitalter angekommen, wo man für eine 64-bit-Architektur >>>> eine minimale Cache-Line-Größe vorschreiben kann :-) >>>> >>>> Mit 64 Bytes dache line kann eine Instrukion von maximal 20 >>>> Bytes dann höchstens einen Cache Miss auslösen. >>> >>> ...und dazu noch TLB Misses und Page Faults, sowie die von dem in der >>> Instruktion enthaltenen Speicherzugriff enthaltenen Datum. >> >> Jep. Und ansonsten kommt das halt ein bissschen später, wenn die >> nächste oder übernächste Instruktion ausgeführt wird. > > Es macht aber einen Unterschied, ob diese Misses während einer > Instruktion auftreten oder "zwischen" den Instruktionen. > > Wenn jede Instruktion ein 32-Bit-Wort lang ist, kann ein Cache-Miss, > TLB-Miss, Page-Miss jeweils nur genau beim Laden dieses Worts auftreten. > Der wird behandelt und nach der Behandlung kann dieses Wort gelesen > werden. > > Wenn eine Instruktion zwei oder mehr Worte lang ist, kann ein Cache Miss > bei einem beliebigen dieser Worte auftreten. Beim ersten Wort ist es > gleich wie oben: Der Miss wird behandelt, danach stehen alle Worte der > Instruktion zur Verfügung. Aber bei allen anderen kann es komplizierter > werden: Es besteht die Gefahr, dass man sich während der Behandlung des > Misses für dieses Wort den Cache-, TLB- oder Page-Eintrag für das erste > Wort rausschießt. Wenn der Handler dann zurückkehrt, kann bekommt der > Prozessor beim Versuch, das erste Wort der Instruktion zu lesen, einen > Miss, im Handler schießt er sich dann den zweiten wieder raus und so > weiter - d.h. die Instruktion kann nie geladen werden. > > Wie Stefan geschrieben hat, ist das kein unlösbares Problem, ich würde > sogar annehmen, dass die Standard-Implementationen (ob in Hardware oder > Software) das bereits lösen, aber es ist etwas, das man bedenken muss. Natürlich muss das bedacht werden. Eine sinnvolle Variante ein instruction buffer von hinreichender Größe. Die Logik des instruction buffer kümmert sich um page faults, cache misses und den ganzen Rest, und Instruktion werden erst ausgeführt, wenn sie komplett im Buffer sind. Eine ISA, die für sowas geeignet ist, kann z.B. in 32-bit-Teile unterteilt sein (Instruktionsgrößen von 32, 64, 96, 128 oder 160 Bits), wobei man in den ersten 32 Bit die Länge der Instruktion ermittelt. Dann kann man alle 32 bit in einem Instruction buffer einen Decoder einbauen, und jeder Decoder kann dann 1 bis 4 nachgeschaltete Decoder abschalten bzw. ihr Ergebnis verwerfen). Das ist jetzt nicht die reine RISC-Lehre, aber ermöglicht effiziente Implementierung von variabler Länge von Instruktoinen. Die ISA, die das am extremsten durchgezogen hat war die /360 - Instruktionen von 16, 32 und 48 bit, und in den ersten 16 Bit (genau genommen sogar in den ersten 2 Bit) war die Länge der Instruktion dekodiert. (OK, damals hatten die noch keinen Instruction Buffer im Sinn :-) > Das Laden der Instruktionen dürfte da allerdings auch der einfachere > Fall sein. Gemeiner sind Memory-Zugriffe der Instruktion selbst. Die VAX > hatte bis zu 3 memory-indirekte Parameter. Das waren also bis zu 6 > Speicherzugriffe pro Instruktion, die alle unaligned sein konnten, also > tatsächlich 12. Plus bis zu 2 für die Instruktion selbst, > Page-Fault-Handler mussten also sicherstellen, dass mindestens die > letzten 14 Pages nicht wieder rausgeswappt wurden, weil man sonst in > eine Endlosschleife von Page-Misses kommen konnte. Und die VAX war in der Hinsicht eine bemerkenswerte Fehlkonstruktion, die war für eine Zeit konstruiert, die eigentlich schon zu Ende war - externer Speicher war teuer und langsam, und Microcode war schneller. IBM hatte damals mit dem 801 gezeigt, wie es besser ging, aber das war aus politischen Gründen kein Markterfolg, um die /370 nicht zu gefährden. Und selbst heute wäre es schwierig, eine effiziente VAX-Implementierung zu bauen. Natürlich könnte man die Instruktionen in Micro-Ops splitten, wie auf den modernen x86-Prozessoren, aber die Abhängigkeiten und die große Anzahl von Operanden mit Speicherzugriffen und increment/decrement würden eine Komplexiztät erfordern, die richtig bremsen würde.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-01 09:27 +0100 |
| Message-ID | <vnkpdb.1go.1@stefan.msgid.phost.de> |
| In reply to | #47334 |
Am 01.02.2025 um 08:39 schrieb Thomas Koenig: > Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >> Wie Stefan geschrieben hat, ist das kein unlösbares Problem, ich würde >> sogar annehmen, dass die Standard-Implementationen (ob in Hardware oder >> Software) das bereits lösen, aber es ist etwas, das man bedenken muss. > > Natürlich muss das bedacht werden. Eine sinnvolle Variante ein > instruction buffer von hinreichender Größe. Die Logik des instruction > buffer kümmert sich um page faults, cache misses und den ganzen Rest, > und Instruktion werden erst ausgeführt, wenn sie komplett im Buffer > sind. Und das ist nicht so einfach, wie es bei dir klingt. Wenn bei der zweiten Hälfte einer Instruktion ein Page Fault auftritt, wird der entsprechende Fault Handler ausgelöst. Der muss jetzt loslaufen, und z.B. die fehlende Speicherseite von einem rotierenden Medium laden, was im Zweifelsfall ein paar Millionen Zyklen dauern kann. Währenddessen können andere Tasks laufen. Da wird nicht der Instruction Buffer im halbvollen Zustand angehalten. Und wenn die Software im Fault Handler nicht sehr, SEHR vorsichtig ist, verdrängen die anderen Tasks währenddessen die Seite mit der ersten Hälfte der Instruktion (die ist immerhin ein paar Millionen Zyklen lang nicht angefasst worden). Bei einer Architektur, die den Page Table Walk nicht wie x86 in Hardware macht, kommt das gleiche Problem dann noch mal für den TLB dazu. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-01 09:35 +0000 |
| Message-ID | <vnkpsl$1erq$1@dont-email.me> |
| In reply to | #47335 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 01.02.2025 um 08:39 schrieb Thomas Koenig:
>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>> Wie Stefan geschrieben hat, ist das kein unlösbares Problem, ich würde
>>> sogar annehmen, dass die Standard-Implementationen (ob in Hardware oder
>>> Software) das bereits lösen, aber es ist etwas, das man bedenken muss.
>>
>> Natürlich muss das bedacht werden. Eine sinnvolle Variante ein
>> instruction buffer von hinreichender Größe. Die Logik des instruction
>> buffer kümmert sich um page faults, cache misses und den ganzen Rest,
>> und Instruktion werden erst ausgeführt, wenn sie komplett im Buffer
>> sind.
>
> Und das ist nicht so einfach, wie es bei dir klingt.
Ich habe nicht behauptet, dass es trivial ist, ich habe nur
behauptet, dass es sich lohnt :-)
> Wenn bei der zweiten Hälfte einer Instruktion ein Page Fault auftritt,
> wird der entsprechende Fault Handler ausgelöst.
Ist genauso, wenn es am Anfang einer Instruktion passiert.
> Der muss jetzt
> loslaufen, und z.B. die fehlende Speicherseite von einem rotierenden
> Medium laden, was im Zweifelsfall ein paar Millionen Zyklen dauern kann.
Korrekt, passiert mit einem Page Fault am Anfang der Instruktion
genauso.
> Währenddessen können andere Tasks laufen. Da wird nicht der Instruction
> Buffer im halbvollen Zustand angehalten.
N.B: Erst mal gibt es ja (eine moderne, performante
OoO-Implementierung vorausgesetzt) ein paar hundert Instruktionen,
die noch in Rente geschickt werden müssen (was ist eigentlich der
deutsche Ausdruck für "retire"?), das kann man einschließlich
der vorherigen Instruktion machen.
> Und wenn die Software im Fault
> Handler nicht sehr, SEHR vorsichtig ist, verdrängen die anderen Tasks
> währenddessen die Seite mit der ersten Hälfte der Instruktion (die ist
> immerhin ein paar Millionen Zyklen lang nicht angefasst worden).
Sehe ich nicht als Problem. Die vorherige Instruktion ist retired,
die neue, unvollständige, kann man, wenn der Prozess nach ein paar
zig Millionen Zyklen wieder zum Zuge kommt, neu laden. Die hat
ja, abgesehen vom Instruction Buffer, noch gar keine Spuren in
der Mikroarchitektur hinterlassen.
> Bei einer Architektur, die den Page Table Walk nicht wie x86 in Hardware
> macht, kommt das gleiche Problem dann noch mal für den TLB dazu.
Wer macht denn heute noch Software page table walk? Alpha (und MIPS?)
sind ja schon fast folkloristisch zu nennen...
Aber vernünftiges Handlen von Konstanten ist nicht nur bei Load/Store,
sondern auch bei Floating point wichtig.
Beispiel:
double foo (double a, double b)
{
return b * 3.4 + a + 1.2;
}
x86_64 (mit -O3 -mfma):
foo:
.LFB0:
.cfi_startproc
vfmadd231sd .LC0(%rip), %xmm1, %xmm0
vaddsd .LC1(%rip), %xmm0, %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section .rodata.cst8,"aM",@progbits,8
.align 8
.LC0:
.long 858993459
.long 1074475827
.align 8
.LC1:
.long 858993459
.long 1072902963
Aarch64:
foo:
sub sp, sp, #16
str d0, [sp, 8]
str d1, [sp]
ldr d31, [sp]
mov x0, 3689348814741910323
movk x0, 0x400b, lsl 48
fmov d30, x0
fmul d30, d31, d30
ldr d31, [sp, 8]
fadd d31, d30, d31
mov x0, 3689348814741910323
movk x0, 0x3ff3, lsl 48
fmov d30, x0
fadd d31, d31, d30
fmov d0, d31
add sp, sp, 16
ret
My66000:
fmac r1,r2,#0x400B333333333333,r1
fadd r1,r1,#0x3FF3333333333333
ret
Man spart dadurch eine ganze Menge Instruktionen, Zeit und Register...
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-02-01 11:16 +0100 |
| Message-ID | <slrnvprt3d.2649b.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #47339 |
On 2025-02-01 09:35, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Stefan Reuther <stefan.news@arcor.de> schrieb:
>> Am 01.02.2025 um 08:39 schrieb Thomas Koenig:
>>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>>> Wie Stefan geschrieben hat, ist das kein unlösbares Problem, ich würde
>>>> sogar annehmen, dass die Standard-Implementationen (ob in Hardware oder
>>>> Software) das bereits lösen, aber es ist etwas, das man bedenken muss.
>>>
>>> Natürlich muss das bedacht werden. Eine sinnvolle Variante ein
>>> instruction buffer von hinreichender Größe. Die Logik des instruction
>>> buffer kümmert sich um page faults, cache misses und den ganzen Rest,
>>> und Instruktion werden erst ausgeführt, wenn sie komplett im Buffer
>>> sind.
>>
>> Und das ist nicht so einfach, wie es bei dir klingt.
>
> Ich habe nicht behauptet, dass es trivial ist, ich habe nur
> behauptet, dass es sich lohnt :-)
Was zu beweisen wäre (was wir hier vermutlich alle nicht können, weder
positiv noch negativ).
>> Und wenn die Software im Fault Handler nicht sehr, SEHR vorsichtig
>> ist, verdrängen die anderen Tasks währenddessen die Seite mit der
>> ersten Hälfte der Instruktion (die ist immerhin ein paar Millionen
>> Zyklen lang nicht angefasst worden).
>
> Sehe ich nicht als Problem. Die vorherige Instruktion ist retired,
> die neue, unvollständige, kann man, wenn der Prozess nach ein paar
> zig Millionen Zyklen wieder zum Zuge kommt, neu laden.
Und genau um dieses neu laden geht es. Die Page, auf der der Anfang der
Instruktion liegt, könnte inzwischen nämlich nicht mehr vorhanden sein,
was den nächsten Cache-Miss auslöst. Und wenn der behandelt ist, ist
vielleicht die Page, auf der die zweite Hälfte der Instruktion liegt,
nicht mehr vorhanden, und so weiter.
Wie bereits geschrieben: Natürlich ist das lösbar, und da
weitverbreitete ISAs wie x86 dieses Problem auch haben, ist es auch
bereits gelöst, aber es ist halt zusätzliche Komplexität.
hp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-01 12:03 +0000 |
| Message-ID | <vnl2hv$357b$1@dont-email.me> |
| In reply to | #47340 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2025-02-01 09:35, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Stefan Reuther <stefan.news@arcor.de> schrieb: >>> Am 01.02.2025 um 08:39 schrieb Thomas Koenig: >>>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >>>>> Wie Stefan geschrieben hat, ist das kein unlösbares Problem, ich würde >>>>> sogar annehmen, dass die Standard-Implementationen (ob in Hardware oder >>>>> Software) das bereits lösen, aber es ist etwas, das man bedenken muss. >>>> >>>> Natürlich muss das bedacht werden. Eine sinnvolle Variante ein >>>> instruction buffer von hinreichender Größe. Die Logik des instruction >>>> buffer kümmert sich um page faults, cache misses und den ganzen Rest, >>>> und Instruktion werden erst ausgeführt, wenn sie komplett im Buffer >>>> sind. >>> >>> Und das ist nicht so einfach, wie es bei dir klingt. >> >> Ich habe nicht behauptet, dass es trivial ist, ich habe nur >> behauptet, dass es sich lohnt :-) > > Was zu beweisen wäre (was wir hier vermutlich alle nicht können, weder > positiv noch negativ). > > >>> Und wenn die Software im Fault Handler nicht sehr, SEHR vorsichtig >>> ist, verdrängen die anderen Tasks währenddessen die Seite mit der >>> ersten Hälfte der Instruktion (die ist immerhin ein paar Millionen >>> Zyklen lang nicht angefasst worden). >> >> Sehe ich nicht als Problem. Die vorherige Instruktion ist retired, >> die neue, unvollständige, kann man, wenn der Prozess nach ein paar >> zig Millionen Zyklen wieder zum Zuge kommt, neu laden. > > Und genau um dieses neu laden geht es. Die Page, auf der der Anfang der > Instruktion liegt, könnte inzwischen nämlich nicht mehr vorhanden sein, > was den nächsten Cache-Miss auslöst. Und wenn der behandelt ist, ist > vielleicht die Page, auf der die zweite Hälfte der Instruktion liegt, > nicht mehr vorhanden, und so weiter. Prinzipiell sehe ich vier Möglichkeiten, das zu lösen: - Einfach in einer Schleife laufen lassen. Wenn das System so voll ist, dass das ein großes Problem gibt, dann ist es sowieso auf der Kante zum Abschmieren wegen Speichermangel, das spezielle Problem spielt dann vermutlich keine große Rolle mehr. - Unvollständige Instruktionen als Teil des Thread-Kontexts abspeichern (was vermtulich die schlechteste Lösung ist) - Das VM-System so auslegen, dass der Instruction Buffer zwei aufeinanderfolgende Pages anfordern kann - Dem Problem aussitzen, wie es Power in v3.1 (aka Power 10) macht. Die haben ja mittlerweile auch 64-bit-Instruktionen und verbieten einfach, dass die über eine 64-Byte-Grenze rübergehen. Zero cost nops machen es möglich. Wenn Instruktionen bis 20 Bytes lang werden können, ist das allerdings keine gute Lösung. > > Wie bereits geschrieben: Natürlich ist das lösbar, und da > weitverbreitete ISAs wie x86 dieses Problem auch haben, ist es auch > bereits gelöst, aber es ist halt zusätzliche Komplexität. Wenn ich mir den generierten Assemblercode so anschaue, ist es das die zusätzliche Komplexität wert :-)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-02 09:35 +0100 |
| Message-ID | <vnne9f.3lc.1@stefan.msgid.phost.de> |
| In reply to | #47341 |
Am 01.02.2025 um 13:03 schrieb Thomas Koenig: > Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >> Und genau um dieses neu laden geht es. Die Page, auf der der Anfang der >> Instruktion liegt, könnte inzwischen nämlich nicht mehr vorhanden sein, >> was den nächsten Cache-Miss auslöst. Und wenn der behandelt ist, ist >> vielleicht die Page, auf der die zweite Hälfte der Instruktion liegt, >> nicht mehr vorhanden, und so weiter. > > Prinzipiell sehe ich vier Möglichkeiten, das zu lösen: > > - Einfach in einer Schleife laufen lassen. Wenn das System > so voll ist, dass das ein großes Problem gibt, dann ist > es sowieso auf der Kante zum Abschmieren wegen Speichermangel, > das spezielle Problem spielt dann vermutlich keine große > Rolle mehr. Das wird die Lösung sein, die in der Praxis eingesetzt wird. Ich bin Softwerker, der nach dem Studium fast in der Forschung zu formaler Verifikation gelandet wäre. Ich will also Software, die garantiert ein Ergebnis bringt. "In einer Schleife laufen lassen bis es zufällig mal klappt" bekommt daher auf jeden Fall Minuspunkte. Idealerweise müsste also der Page Fault Handler die Instruktion parsen und genau die von dieser Instruktion benötigten Speicherseiten festhalten, dass sie nicht verdrängt werden. Eine Instruktion über zwei Seiten, die ein misalignedes Datum zugreift, blockt also vier Seiten. Das wird nur getoppt von Intel 'movsw' bzw. 'movsd', das gleich 6 Seiten blocken kann... Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-02 10:22 +0000 |
| Message-ID | <vnnh0k$koeg$2@dont-email.me> |
| In reply to | #47346 |
Stefan Reuther <stefan.news@arcor.de> schrieb: > Am 01.02.2025 um 13:03 schrieb Thomas Koenig: >> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >>> Und genau um dieses neu laden geht es. Die Page, auf der der Anfang der >>> Instruktion liegt, könnte inzwischen nämlich nicht mehr vorhanden sein, >>> was den nächsten Cache-Miss auslöst. Und wenn der behandelt ist, ist >>> vielleicht die Page, auf der die zweite Hälfte der Instruktion liegt, >>> nicht mehr vorhanden, und so weiter. >> >> Prinzipiell sehe ich vier Möglichkeiten, das zu lösen: >> >> - Einfach in einer Schleife laufen lassen. Wenn das System >> so voll ist, dass das ein großes Problem gibt, dann ist >> es sowieso auf der Kante zum Abschmieren wegen Speichermangel, >> das spezielle Problem spielt dann vermutlich keine große >> Rolle mehr. > > Das wird die Lösung sein, die in der Praxis eingesetzt wird. > > Ich bin Softwerker, der nach dem Studium fast in der Forschung zu > formaler Verifikation gelandet wäre. Ich will also Software, die > garantiert ein Ergebnis bringt. > > "In einer Schleife laufen lassen bis es zufällig mal klappt" bekommt > daher auf jeden Fall Minuspunkte. Das ist ein generelles Problem dabei, wie viele moderne Systeme so betrieben werden - Speicher wird schon irgendwie reichen, und wenn es nicht tut, wird der Benutzer es schon merken. Siehe /proc/sys/vm/overcommit_memory auf Linux, oder, was mich persönlich noch mehr nervt, die Beschränkung von Stack-Größen. > Idealerweise müsste also der Page Fault Handler die Instruktion parsen > und genau die von dieser Instruktion benötigten Speicherseiten > festhalten, dass sie nicht verdrängt werden. Das hatte ich upghread versucht zu beschreiben. Die Information über die Größe der Instruktion steckt im ersten Wort, da kann die Logik um den Instruction Buffer zwei nebeneinander liegende Seiten anfordern (die, auf die er selber ist, und die nächste). >Eine Instruktion über zwei > Seiten, die ein misalignedes Datum zugreift, blockt also vier Seiten. > Das wird nur getoppt von Intel 'movsw' bzw. 'movsd', das gleich 6 Seiten > blocken kann... Hmm... wie viele waren das auf der VAX? @100(r3) griff ja auf Memory[Memory[r3+100]] zu, d.h. erst mal r3 + 100 berechnent, Zugriff darauf (+1), dann nochmal Zugriff drauf (+2). Wenn ich das jetzt richtig zusammenkriege, hätte addl3 @100(r3),@150(r4),@200(r5) also sieben potentielle page faults richtig zu handlen. Und wenn man sich vorstellt, das in Micro-Ops zu cracken, dann müsste man die alle wieder rückwäerts abwickeln, wenn einer davon Ärger macht. Irgendwie versteht man, warum DEC mit der Alpha einen so radikal anderen Weg gegangen ist...
[toc] | [prev] | [next] | [standalone]
| From | Markus Elsken <markus.elsken@ewetel.net> |
|---|---|
| Date | 2025-02-02 13:59 +0100 |
| Message-ID | <m098hvF2lg4U1@mid.individual.net> |
| In reply to | #47346 |
Moin! Am 02.02.25 um 09:35 schrieb Stefan Reuther: > "In einer Schleife laufen lassen bis es zufällig mal klappt" bekommt > daher auf jeden Fall Minuspunkte. So funktioniert doch Forschung - so lange mit wechselnden Parametern oder Zutaten experimentieren, bis die richtige Veriante gefunden ist. mfg Markus
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-02-02 14:25 +0100 |
| Message-ID | <slrnvpushp.3gug8.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #47350 |
On 2025-02-02 12:59, Markus Elsken <markus.elsken@ewetel.net> wrote:
> Am 02.02.25 um 09:35 schrieb Stefan Reuther:
>> "In einer Schleife laufen lassen bis es zufällig mal klappt" bekommt
>> daher auf jeden Fall Minuspunkte.
>
> So funktioniert doch Forschung
Alltäglicher Betrieb ist aber nicht Forschung.
hp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-02 21:40 +0000 |
| Message-ID | <vnoont$sha2$1@dont-email.me> |
| In reply to | #47346 |
Stefan Reuther <stefan.news@arcor.de> schrieb: > Am 01.02.2025 um 13:03 schrieb Thomas Koenig: >> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >>> Und genau um dieses neu laden geht es. Die Page, auf der der Anfang der >>> Instruktion liegt, könnte inzwischen nämlich nicht mehr vorhanden sein, >>> was den nächsten Cache-Miss auslöst. Und wenn der behandelt ist, ist >>> vielleicht die Page, auf der die zweite Hälfte der Instruktion liegt, >>> nicht mehr vorhanden, und so weiter. >> >> Prinzipiell sehe ich vier Möglichkeiten, das zu lösen: >> >> - Einfach in einer Schleife laufen lassen. Wenn das System >> so voll ist, dass das ein großes Problem gibt, dann ist >> es sowieso auf der Kante zum Abschmieren wegen Speichermangel, >> das spezielle Problem spielt dann vermutlich keine große >> Rolle mehr. > > Das wird die Lösung sein, die in der Praxis eingesetzt wird. > > Ich bin Softwerker, der nach dem Studium fast in der Forschung zu > formaler Verifikation gelandet wäre. Ich will also Software, die > garantiert ein Ergebnis bringt. > > "In einer Schleife laufen lassen bis es zufällig mal klappt" bekommt > daher auf jeden Fall Minuspunkte. [2. Antwort] (Ich verwende jetzt das Imperfekt, obwohl zOS noch existiert :-) Bei System/360 und folgenden Computern unter MVS musste man in der JOB-Karte eine REGION angeben, also etwa so //MYJOB JOB ASDF,(ACCOUNT),REGION=10M Solange das System nicht genug Speicher hatte, lief der Job nicht los. Wenn der Job mehr als 10 Megabyte Speicher belegte, gab es einen ABEND. Es war sogar möglich, Hauptspeicher zu spezifizieren statt virtuellen Speicher. Deutlich einfacher zu verifizieren, dass da nichts überläuft. Nur sind diese Systeme heute auf absolute Nischen zurückgedrückt...
[toc] | [prev] | [next] | [standalone]
| From | Clemens Schüller <cs.usenet@mailbox.org> |
|---|---|
| Date | 2025-02-02 22:52 +0100 |
| Message-ID | <m2wme8m2u0.queerchen@cmschueller.my-fqdn.de> |
| In reply to | #47353 |
Thomas Koenig schrieb am 02. Feb. 2025 um 22:40: > Bei System/360 und folgenden Computern unter MVS musste man in > der JOB-Karte eine REGION angeben, also etwa so > > //MYJOB JOB ASDF,(ACCOUNT),REGION=10M > > Solange das System nicht genug Speicher hatte, lief der Job nicht los. > Wenn der Job mehr als 10 Megabyte Speicher belegte, gab es einen ABEND. > Es war sogar möglich, Hauptspeicher zu spezifizieren statt virtuellen > Speicher. Erinnert mich an meine Lehrzeit im Möbelhandel: Es gab Berichte, deren Erstellung ein paar Stunden dauern konnte: Am Ende der Definition konnte man S für Soforterstellung auswählen. Dann kam die Abfrage, welchen Drucker man verwenden möchte - das Problem dabei war, dass der Drucker dann für Stunden blockiert war :-( Dann gab es noch JK für Jobkette - damit wurde die Erstellung in den Hintergrund gelegt und er wurde abgearbeitet, wenn die Auslastung gering war. Man bekam eine Nachricht, wenn der Bericht erstellt und druckbereit war. Was aber kaum einer wusste: Es gab auch noch JK! (man beachte das Rufzeichen), damit konnte man den Server anweisen, den Auftrag zu priorisieren und den Bericht auch bei hoher Last zu erstellen. Server lief übrigens unter OpenVMS LieGrü aus Graz, Clemens -- np: Shakespears Sister - Hello (Turn Your Radio On)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-03 10:24 +0000 |
| Message-ID | <vnq5hf$177ik$1@dont-email.me> |
| In reply to | #47354 |
Clemens Schüller <cs.usenet@mailbox.org> schrieb: > Thomas Koenig schrieb am 02. Feb. 2025 um 22:40: > > >> Bei System/360 und folgenden Computern unter MVS musste man in >> der JOB-Karte eine REGION angeben, also etwa so >> >> //MYJOB JOB ASDF,(ACCOUNT),REGION=10M >> >> Solange das System nicht genug Speicher hatte, lief der Job nicht los. >> Wenn der Job mehr als 10 Megabyte Speicher belegte, gab es einen ABEND. >> Es war sogar möglich, Hauptspeicher zu spezifizieren statt virtuellen >> Speicher. > > Erinnert mich an meine Lehrzeit im Möbelhandel: > > Es gab Berichte, deren Erstellung ein paar Stunden dauern konnte: > > > Am Ende der Definition konnte man S für Soforterstellung auswählen. Dann > kam die Abfrage, welchen Drucker man verwenden möchte - das Problem > dabei war, dass der Drucker dann für Stunden blockiert war :-( Wow, das klingt suboptimal, den Drucker für sowas zu blockieren. VMS hatte doch Printer Queues. Da hatte wohl jemand keine Ahnung... > Dann gab es noch JK für Jobkette - damit wurde die Erstellung in den > Hintergrund gelegt und er wurde abgearbeitet, wenn die Auslastung > gering war. Man bekam eine Nachricht, wenn der Bericht erstellt und > druckbereit war. Und dann war vermutlich mitten in der Nacht... Wie war denn die Druckerausgabe geregelt? Gab es da einen Operator oder stand der irgendwo rum? > Was aber kaum einer wusste: Es gab auch noch JK! (man beachte das > Rufzeichen), damit konnte man den Server anweisen, den Auftrag zu > priorisieren und den Bericht auch bei hoher Last zu erstellen. Und die Leute, die das wussten, konnten früh nach Hause gehen - sehr praktisch :-) > Server lief übrigens unter OpenVMS
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-03 17:21 +0100 |
| Message-ID | <vnqtud.4v8.1@stefan.msgid.phost.de> |
| In reply to | #47353 |
Am 02.02.2025 um 22:40 schrieb Thomas Koenig: > Bei System/360 und folgenden Computern unter MVS musste man in > der JOB-Karte eine REGION angeben, also etwa so > > //MYJOB JOB ASDF,(ACCOUNT),REGION=10M > > Solange das System nicht genug Speicher hatte, lief der Job nicht los. > Wenn der Job mehr als 10 Megabyte Speicher belegte, gab es einen ABEND. > Es war sogar möglich, Hauptspeicher zu spezifizieren statt virtuellen > Speicher. > > Deutlich einfacher zu verifizieren, dass da nichts überläuft. Nur sind > diese Systeme heute auf absolute Nischen zurückgedrückt... Das kannst du ja heute auch noch haben (z.B. ulimit). Es ist nur schwer zu ermitteln, welchen Wert man da als Größe einträgt. Eigentlich soll ich für meine Embedded-Infotainment-Software einen solchen Wert abliefern. OK, prima, ich kann meine Stack-Bedarfe und meine RAM-Bedarfe zusammenzählen. Aber dann kommt Wayland und mappt mir ein paar GB Adressraum für Framebuffer rein, könnte man ja mal brauchen. PulseAudio mapped mir 64 MByte für IPC. Das firmeneigene Kommunikationsframework auch. Irgendwelche Hardware-Libraries mappen mir den MMR-Adressraum. Und wie zähle ich eigentlich die Megabytes der glibc? Und dann kommt der Lieferant mit seiner als "ultra-fast" beworbenen Library, die gerne mal für eine Datenbankanfrage 300 Threads spawned und zweieinhalb Minuten braucht, und der Support sagt: das Ding ist schnell, ihr seid die ersten, die sich beschweren. Das letzte Mal als ich einen wirklich verlässlichen Wert für meinen Speicherverbrauch angeben konnte, war auf einem System ohne Paging MMU und ohne Shared Libraries. Denn da war es funktionsnotwendig, den Adressraum den Applikationen fest zuzuteilen, und der Linker hat gesagt, wenn's nicht passt. Und das war halt vor 10+ Jahren. Also immerhin ontopic. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-03 18:03 +0000 |
| Message-ID | <vnr0dr$1d0p0$1@dont-email.me> |
| In reply to | #47357 |
Stefan Reuther <stefan.news@arcor.de> schrieb: > Am 02.02.2025 um 22:40 schrieb Thomas Koenig: >> Bei System/360 und folgenden Computern unter MVS musste man in >> der JOB-Karte eine REGION angeben, also etwa so >> >> //MYJOB JOB ASDF,(ACCOUNT),REGION=10M >> >> Solange das System nicht genug Speicher hatte, lief der Job nicht los. >> Wenn der Job mehr als 10 Megabyte Speicher belegte, gab es einen ABEND. >> Es war sogar möglich, Hauptspeicher zu spezifizieren statt virtuellen >> Speicher. >> >> Deutlich einfacher zu verifizieren, dass da nichts überläuft. Nur sind >> diese Systeme heute auf absolute Nischen zurückgedrückt... > > Das kannst du ja heute auch noch haben (z.B. ulimit). Es ist nur schwer > zu ermitteln, welchen Wert man da als Größe einträgt. > > Eigentlich soll ich für meine Embedded-Infotainment-Software einen > solchen Wert abliefern. OK, prima, ich kann meine Stack-Bedarfe und > meine RAM-Bedarfe zusammenzählen. > > Aber dann kommt Wayland und mappt mir ein paar GB Adressraum für > Framebuffer rein, könnte man ja mal brauchen. Urgh. > PulseAudio mapped mir 64 > MByte für IPC. Das firmeneigene Kommunikationsframework auch. > Irgendwelche Hardware-Libraries mappen mir den MMR-Adressraum. Mumps-Measles-Röteln-Impfung? Myanmar? > Und wie > zähle ich eigentlich die Megabytes der glibc? Das ist bei shared libraries tatsächlich eine interessante Frage, wie man das verrechnet. > Und dann kommt der Lieferant mit seiner als "ultra-fast" beworbenen > Library, die gerne mal für eine Datenbankanfrage 300 Threads spawned und > zweieinhalb Minuten braucht, und der Support sagt: das Ding ist schnell, > ihr seid die ersten, die sich beschweren. Leider gibt es mittlerweile viel zu viele Leute, die keine Ahnung vom Programmieren haben und versuchen, dies durch das Auftürmen von Abstraktionsebenen und Bibliotheken zu kompensieren. Und vieler solcher Leute programmieren dann den Schrott, den man als kommerzielle Software erhält... > Das letzte Mal als ich einen wirklich verlässlichen Wert für meinen > Speicherverbrauch angeben konnte, war auf einem System ohne Paging MMU > und ohne Shared Libraries. Denn da war es funktionsnotwendig, den > Adressraum den Applikationen fest zuzuteilen, und der Linker hat gesagt, > wenn's nicht passt. Und das war halt vor 10+ Jahren. Also immerhin ontopic. Das war auf den Groß-Hobeln eigentlich recht einfach. Die von mir verwendete Programmiersprache hatte damals keinen Stack, die Größe der statischen Variablen konnte man relativ gut ausrechnen. Codegröße war weniger einfach, vor allem wenn externe Libraries eingebunden wurden (und der Linker war laaaaaaaaaaaaaaangsam), aber dynamische Libraries gab's nicht, und Probleme auf eine andere Größe anpassen hieß typischerweise, in einem PDS member einen Parameter zu ändern, der die Größe von COMMON-Blöcken bestimmt hat.
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web