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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | "Michael Kraemer @ home" <M.Kraemer@gsi.de> |
|---|---|
| Date | 2025-02-04 12:01 +0100 |
| Message-ID | <m0eaecFri6mU1@mid.individual.net> |
| In reply to | #47360 |
Thomas Koenig wrote: > 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 ist bei OpenSauce nicht anders. > > 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. Du hast halt die falsche Sprache verwendet. Statt des ollen Fortran77 konnte man auf IBM's Dickschiffen auch PL/I verwenden: dynamische Speicherverwaltung, Multitasking, sogar dynamisches Nachladen von Prozeduren war moeglich, wenn auch mit Tricksen und ein paar Einschraenkungen. Wimre konnte man aber auch in IBM's F77 irgendwann die COMMONs dynamisch anlegen, d.h. erst zur Laufzeit zur vollen Groesse aufblasen.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-04 11:37 +0000 |
| Message-ID | <vnsu66$1quol$2@dont-email.me> |
| In reply to | #47361 |
Michael Kraemer @ home <M.Kraemer@gsi.de> schrieb: > Thomas Koenig wrote: > >> 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 ist bei OpenSauce nicht anders. > >> >> 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. > > Du hast halt die falsche Sprache verwendet. Ich habe die Einzig Wahre (TM) Sprache verwendet :-) > Statt des ollen Fortran77 konnte man auf IBM's Dickschiffen > auch PL/I verwenden: dynamische Speicherverwaltung, > Multitasking, sogar dynamisches Nachladen von Prozeduren war moeglich, > wenn auch mit Tricksen und ein paar Einschraenkungen. PL/I fand ich komisch, und habe ich auch nie verwendet; ich habe damals erst auf einer Mainframe, dann auf UNIX-Workstations und schließlich auf einer Kombination aus Workstations und IBM-kompatiblem Vektorrechner (Fujitsu VP) gearbeitet. Und wie Workstations hatten keinen PL/I - Compiler, und ob der Vektorrechner überhaupt einen PL/I - Compiler hatte... die Libraries waren auf jeden Fall alle in Fortran. > Wimre konnte man aber auch in IBM's F77 irgendwann die COMMONs > dynamisch anlegen, d.h. erst zur Laufzeit zur vollen Groesse > aufblasen. Hmm... MVS hat doch sowas wie BSS, was erst mal nur im virtuellen Speicher angelegt wird, oder? Oder was meinst du? Ich hatte damals mit einem Fujitsu-Compiler für BS/3000 angefangen, dann kam ein IBM-Compiler für die 3090, dann die HP-Workstations und später parallel dazu noch der Fujitsu-Compiler für die VP.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2025-02-04 12:55 +0100 |
| Message-ID | <vnsv71$1vkig$1@news1.tnib.de> |
| In reply to | #47362 |
Thomas Koenig <tkoenig@netcologne.de> wrote: >Michael Kraemer @ home <M.Kraemer@gsi.de> schrieb: >> Thomas Koenig wrote: >>> 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. >> >> Du hast halt die falsche Sprache verwendet. > >Ich habe die Einzig Wahre (TM) Sprache verwendet :-) > >> Statt des ollen Fortran77 konnte man auf IBM's Dickschiffen >> auch PL/I verwenden: dynamische Speicherverwaltung, >> Multitasking, sogar dynamisches Nachladen von Prozeduren war moeglich, >> wenn auch mit Tricksen und ein paar Einschraenkungen. > >PL/I fand ich komisch, und habe ich auch nie verwendet; ich habe >damals erst auf einer Mainframe, dann auf UNIX-Workstations >und schließlich auf einer Kombination aus Workstations und >IBM-kompatiblem Vektorrechner (Fujitsu VP) gearbeitet. Und wie >Workstations hatten keinen PL/I - Compiler, und ob der Vektorrechner >überhaupt einen PL/I - Compiler hatte... die Libraries waren auf >jeden Fall alle in Fortran. Ein Kollege von mir (Freelancer, Softwerker) hat letzte Woche eine ernst gemeinte Anfrage für ein Projekt mit APL bekommen. Grüße Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-04 12:26 +0000 |
| Message-ID | <vnt113$1rcju$1@dont-email.me> |
| In reply to | #47363 |
Marc Haber <mh+usenetspam1118@zugschl.us> schrieb: > Ein Kollege von mir (Freelancer, Softwerker) hat letzte Woche eine > ernst gemeinte Anfrage für ein Projekt mit APL bekommen. Wow, das ist wirklich folkoristisch... Hmm... ein bisschen rumgegooglet findet tatsächlich einige Leute, die das noch verwenden. Dijstra mochte die Sprache anscheinend überhaupt nicht, das macht sie schonmal sympathisch. Aber ich glaube, ich bleibe mal bei meinen "Hauptsrpachen" Fortran, C, Perl und (was ich mir gerade ein wenig anschaue) Julia. Und Assembler (je nach Architektur) ist ein bisschen wie Latein, man muss es nicht unbedingt schreiben können, aber lesen schon.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-02-04 14:51 +0100 |
| Message-ID | <m0ekb3Ft3fhU1@mid.individual.net> |
| In reply to | #47364 |
Am 04.02.25 um 13:26 schrieb Thomas Koenig:
> Marc Haber <mh+usenetspam1118@zugschl.us> schrieb:
>
>> Ein Kollege von mir (Freelancer, Softwerker) hat letzte Woche eine
>> ernst gemeinte Anfrage für ein Projekt mit APL bekommen.
>
> Wow, das ist wirklich folkoristisch...
Mir hat APL gefallen.
Kryptisch wie Kommandofolgen für Editoren,
aber praktisch für schnelle Anweisungen für Berechnungen.
Mit einer touchscreen Tastatur und einen
script Konverter nach Python.. ( schöner Traum )
> Hmm... ein bisschen rumgegooglet findet tatsächlich einige Leute,
> die das noch verwenden. Dijstra mochte die Sprache anscheinend
> überhaupt nicht, das macht sie schonmal sympathisch.
Der soll ja auch lieber Pascal als C gemocht haben.
> Aber ich
> glaube, ich bleibe mal bei meinen "Hauptsprachen" Fortran, C, Perl
> und (was ich mir gerade ein wenig anschaue) Julia.
In Anwendung sind bei mir in ca 90% Python ca 9% C.
Reste in bash und JavaScript programmiert.
Mit Freuden ausrangiert: Pascal und Java.
C++ war für meine kleinen Programme zu aufwendig.
Als Nebensprache wäre vielleicht noch Rust sinnvoll.
> Und Assembler (je nach Architektur) ist ein bisschen wie Latein,
> man muss es nicht unbedingt schreiben können, aber lesen schon.
Meine 8 Bit computer habe ich zu fast 100% in hexcode programmiert.
Assembler war beruflich IBM mainframe kompatibel, privat Motorola
( Atari ST )
Hermann
mit etwas Programmiererfahrung in Lisp und FORTH
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kraemer @ home" <M.Kraemer@gsi.de> |
|---|---|
| Date | 2025-02-04 21:55 +0100 |
| Message-ID | <m0fd85F3p4gU1@mid.individual.net> |
| In reply to | #47362 |
Thomas Koenig wrote:
> PL/I fand ich komisch, und habe ich auch nie verwendet; ich habe
> damals erst auf einer Mainframe, dann auf UNIX-Workstations
> und schließlich auf einer Kombination aus Workstations und
> IBM-kompatiblem Vektorrechner (Fujitsu VP) gearbeitet.
Die eher einfach gestrickten Zahlenfresser waren halt
schon mit dem frugalen FORTRAN jener Jahre zufrieden zu stellen ;-)
Wer's eher bequemer haben wollte, war aber mit PL/I besser bedient.
C/370 fuer MVS kam erst um 1990.
Es gab aber auch Wahnsinnige, die versuchten, sowas wie calloc()/free()
auf der Basis von COMMONs und Array-Indices zu "emulieren".
> Und wie
> Workstations hatten keinen PL/I - Compiler, und ob der Vektorrechner
> überhaupt einen PL/I - Compiler hatte... die Libraries waren auf
> jeden Fall alle in Fortran.
naja, IBM/MVS und "interlanguage communication" ist ein Thema fuer sich...
Die Crux war allerdings, dass PL/I eine sehr maechtige Sprache ist
und ausserhalb der IBM-Welt in den 1980ern nur von DEC richtig bedient wurde.
Sogar fuer Ultrix gab's mal einen Compiler.
Die fuer VMS und Tru64 sind dann bei Kednos gelandet, wimre,
eine ca 1-Mann-Firma, die es inzwischen wohl nicht mehr gibt.
Die unixoide Welt wurde von Liant beackert, die gibt's wohl auch nicht mehr.
Ein "IBM PL/I For AIX V3.1" von 2011 habe ich noch herumliegen, laeuft.
Patches von Mai 2023 gab's von IBM auch noch, ist also noch nicht ganz tot.
Vektorisierung gab's leider nicht.
Was einigermassen seltsam ist, denn die Sprache kennt Vektor-Statements,
also sowas
DCL ( A(3), B(3) ) BINARY FLOAT(53);
A(*) = sin( B(*) );
da haette der compiler nicht erst muehsam eine DO-Schleife auf
Vektorisierbarkeit abklopfen muessen.
>
>>Wimre konnte man aber auch in IBM's F77 irgendwann die COMMONs
>>dynamisch anlegen, d.h. erst zur Laufzeit zur vollen Groesse
>>aufblasen.
>
>
> Hmm... MVS hat doch sowas wie BSS, was erst mal nur im virtuellen
> Speicher angelegt wird, oder? Oder was meinst du?
Sowas:
//FORTVS EXEC PGM=FORTVS, 00070000
// PARM=('OPT(3),GOSTMT,SOURCE,NOSDUMP,XREF,DC($COIL$,$GBRM$', 00080099
// '$MCG4$,$BINT$,$EPD$,$GBH$,$GCMP$,$GPHT$,$GX$)') 00090099
mit "DC" definiert man eine Liste von "Dynamic Commons"
(ich hatte damals die Marotte, sie mit $'s als irgendwie heilig zu markieren :-)
Wimre kamen die DC's mit MVS/XA auf, als es von 24 auf 31 bit aufgebohrt wurde.
Waer ja auch zu bloede, Zillionen von Nullen als OBJ oder LOAD zu speichern.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-05 07:06 +0000 |
| Message-ID | <vnv2l0$29jbi$1@dont-email.me> |
| In reply to | #47367 |
Michael Kraemer @ home <M.Kraemer@gsi.de> schrieb:
> Thomas Koenig wrote:
>
>> PL/I fand ich komisch, und habe ich auch nie verwendet; ich habe
>> damals erst auf einer Mainframe, dann auf UNIX-Workstations
>> und schließlich auf einer Kombination aus Workstations und
>> IBM-kompatiblem Vektorrechner (Fujitsu VP) gearbeitet.
>
> Die eher einfach gestrickten Zahlenfresser waren halt
> schon mit dem frugalen FORTRAN jener Jahre zufrieden zu stellen ;-)
Und natürlich REXX, und später auch awk.
> Wer's eher bequemer haben wollte, war aber mit PL/I besser bedient.
> C/370 fuer MVS kam erst um 1990.
Und war irgendwie komisch, wenn man es neben eine UNIX-Implemenierung
von C hielt. Über "Hello, world" bin ich da kaum rausgekommen.
> Es gab aber auch Wahnsinnige, die versuchten, sowas wie calloc()/free()
> auf der Basis von COMMONs und Array-Indices zu "emulieren".
Das war durchaus üblich, und es gibt heute noch Software-Pakete,
die das machen. Daher ja auch die Regeln in Fortran, die
vorschreiben, dass ein "double precision" doppelt so viel Speicher
belegt wie ein "real" oder ein "integer".
Und die heutigen Probleme kommen z.T. daher, dass die Leute damals
schlampig programmiert und Typen durcheinandergeworfen haben
(und EQUIVALENCE für unschöne Dinge eingesetzt).
>
>> Und wie
>> Workstations hatten keinen PL/I - Compiler, und ob der Vektorrechner
>> überhaupt einen PL/I - Compiler hatte... die Libraries waren auf
>> jeden Fall alle in Fortran.
>
> naja, IBM/MVS und "interlanguage communication" ist ein Thema fuer sich...
>
> Die Crux war allerdings, dass PL/I eine sehr maechtige Sprache ist
> und ausserhalb der IBM-Welt in den 1980ern nur von DEC richtig bedient wurde.
> Sogar fuer Ultrix gab's mal einen Compiler.
> Die fuer VMS und Tru64 sind dann bei Kednos gelandet, wimre,
> eine ca 1-Mann-Firma, die es inzwischen wohl nicht mehr gibt.
> Die unixoide Welt wurde von Liant beackert, die gibt's wohl auch nicht mehr.
PL/1 sollte ja die gemeinsame Nachfolge von FORTRAN und COBOL werden,
aber so richtig angenommen wurde das nie.
> Ein "IBM PL/I For AIX V3.1" von 2011 habe ich noch herumliegen, laeuft.
> Patches von Mai 2023 gab's von IBM auch noch, ist also noch nicht ganz tot.
>
> Vektorisierung gab's leider nicht.
> Was einigermassen seltsam ist, denn die Sprache kennt Vektor-Statements,
> also sowas
>
> DCL ( A(3), B(3) ) BINARY FLOAT(53);
> A(*) = sin( B(*) );
>
> da haette der compiler nicht erst muehsam eine DO-Schleife auf
> Vektorisierbarkeit abklopfen muessen.
Die Technik brauchte man aber sowieso; Vektorisierung war ja nicht
nur auf einfache Statements beschränkt, sondern auch maskiert.
Aber die Vektorisierung auf der IBM 3090 hat eh nicht getaugt.
>>>Wimre konnte man aber auch in IBM's F77 irgendwann die COMMONs
>>>dynamisch anlegen, d.h. erst zur Laufzeit zur vollen Groesse
>>>aufblasen.
>>
>>
>> Hmm... MVS hat doch sowas wie BSS, was erst mal nur im virtuellen
>> Speicher angelegt wird, oder? Oder was meinst du?
>
> Sowas:
>
> //FORTVS EXEC PGM=FORTVS, 00070000
> // PARM=('OPT(3),GOSTMT,SOURCE,NOSDUMP,XREF,DC($COIL$,$GBRM$', 00080099
> // '$MCG4$,$BINT$,$EPD$,$GBH$,$GCMP$,$GPHT$,$GX$)') 00090099
Hmm... nie verwendet.
> mit "DC" definiert man eine Liste von "Dynamic Commons"
DC ist eigentlich im Assembler "Define Constant", haben die das für was
anderes verwendet?
> (ich hatte damals die Marotte, sie mit $'s als irgendwie heilig zu markieren :-)
> Wimre kamen die DC's mit MVS/XA auf, als es von 24 auf 31 bit aufgebohrt wurde.
> Waer ja auch zu bloede, Zillionen von Nullen als OBJ oder LOAD zu speichern.
Das wäre tatsächlich dämlich, aber es ist auch dämlich, Textzeilen mit
10 Zeichen mit 80 Zeichen abzuspeichern .-)
Aber auf einem System mit virtuellem Speicher sollte das nicht allzu
schlimm sein, genauso wie BSS heute - das kostet nur die page tables,
solange die nicht angefasst werden.
[toc] | [prev] | [next] | [standalone]
| From | Michael Kraemer <m.kraemer@gsi.de> |
|---|---|
| Date | 2025-02-06 11:05 +0100 |
| Message-ID | <m0jfs6Fnn1fU1@mid.individual.net> |
| In reply to | #47370 |
On 05.02.2025 08:06, Thomas Koenig wrote:
> Und natürlich REXX, und später auch awk.
awk auf MVS?
ReXX/MVS kam auch relativ spät (Ende 1980er wimre) und
war nur halb kompatibel mit ReXX/AmigaOS.
Also nur eingeschränkt nützlich.
Aber immer noch freundlicher als CLISTen.
Ich erinnere mich dumpf, damit mal ein primitives "make" für MVS
emuliert zu haben.
>> Wer's eher bequemer haben wollte, war aber mit PL/I besser bedient.
>> C/370 fuer MVS kam erst um 1990.
>
> Und war irgendwie komisch, wenn man es neben eine UNIX-Implemenierung
> von C hielt. Über "Hello, world" bin ich da kaum rausgekommen.
Auf den ersten Blick könnte man C für eine Art Schmalspur-PL/I halten.
Bei näherem Hinsehen merkt man aber, dass die beiden Sprachen
eigentlich diametral entgegengesetzte Konzepte haben.
>> Es gab aber auch Wahnsinnige, die versuchten, sowas wie calloc()/free()
>> auf der Basis von COMMONs und Array-Indices zu "emulieren".
>
> Das war durchaus üblich, und es gibt heute noch Software-Pakete,
> die das machen. Daher ja auch die Regeln in Fortran, die
> vorschreiben, dass ein "double precision" doppelt so viel Speicher
> belegt wie ein "real" oder ein "integer".
>
> Und die heutigen Probleme kommen z.T. daher, dass die Leute damals
> schlampig programmiert und Typen durcheinandergeworfen haben
> (und EQUIVALENCE für unschöne Dinge eingesetzt).
Das ist eigentlich unvermeidlich, wenn man COMMON/Arrays/Indices
zur Speicherverwaltung missbrauchen will.
Manchmal braucht man REAL*8, manchmal nur *4.
> PL/1 sollte ja die gemeinsame Nachfolge von FORTRAN und COBOL werden,
> aber so richtig angenommen wurde das nie.
Das Ur-Problem eierlegender Wollmilchsäue.
Den FORTRANern war's zu cobolisch,
den Cobolianern zu fortranesk.
>
>> Ein "IBM PL/I For AIX V3.1" von 2011 habe ich noch herumliegen, laeuft.
>> Patches von Mai 2023 gab's von IBM auch noch, ist also noch nicht ganz tot.
>>
>> Vektorisierung gab's leider nicht.
>> Was einigermassen seltsam ist, denn die Sprache kennt Vektor-Statements,
>> also sowas
>>
>> DCL ( A(3), B(3) ) BINARY FLOAT(53);
>> A(*) = sin( B(*) );
>>
>> da haette der compiler nicht erst muehsam eine DO-Schleife auf
>> Vektorisierbarkeit abklopfen muessen.
>
> Die Technik brauchte man aber sowieso; Vektorisierung war ja nicht
> nur auf einfache Statements beschränkt, sondern auch maskiert.
Vektorisierung lohnt sich eh nur, wenn man sein Problem mit
Vektor-Statements formulieren kann, plus evtl Maskierung wg if/then/else.
PL/I hätte diese Denke auf elegante Weise unterstützen können.
Da fällt mir mein alter Prof ein.
Der schwörte auf Matlab auf seinem PC/AT.
Damit ginge "das ganz einfach", behauptete er.
Matrix-Inversion per Einzeiler.
Nur hatte der PC halt kein VF.
> Aber die Vektorisierung auf der IBM 3090 hat eh nicht getaugt.
Würde ich widersprechen wollen.
Für die überschaubaren Zusatzkosten (relativ zum host) eines VF
gab's auch die versprochene Leistung.
Dass man damit eine Cray einholen könne hat IBM nie behauptet wimre.
Es gab natürlich Nullchecker, die erwarteten, dass der compiler
aus ihren schlampig programmierten Skalar-Wüsten automatisch flotte
Vektorprogramme macht. Die konnten nur enttäuscht werden.
> DC ist eigentlich im Assembler "Define Constant", haben die das für was
> anderes verwendet?
Verschiedene Baustellen.
Im Assembler heisst DC natürlich "Define Constant".
DC im VS-Fortran Kontext steht für "Dynamic Common",
entweder per Compiler-Option oder händisch im Quell-Text:
@PROCESS DC($AUX$)
SUBROUTINE XYT(...)
COMMON /$AUX$/ ...
VS-Fortran kannte also schon sowas wie pragmas.
Natürlich war man gut beraten, das per compiler-option anzuweisen statt
einzeln in jedem PDS member.
>> (ich hatte damals die Marotte, sie mit $'s als irgendwie heilig zu markieren :-)
>> Wimre kamen die DC's mit MVS/XA auf, als es von 24 auf 31 bit aufgebohrt wurde.
>> Waer ja auch zu bloede, Zillionen von Nullen als OBJ oder LOAD zu speichern.
>
> Das wäre tatsächlich dämlich, aber es ist auch dämlich, Textzeilen mit
> 10 Zeichen mit 80 Zeichen abzuspeichern .-)
Dagegen gab's ja die VB Dateien, die hat IBM's Fortran dann auch
irgendwann verdaut.
Nachdem die Lochkarte entgültig verschwunden war.
"Variable Length" Lochkarten wären halt irgendwie unpraktisch gewesen.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-06 21:18 +0000 |
| Message-ID | <vo38v2$34btf$1@dont-email.me> |
| In reply to | #47376 |
Michael Kraemer <m.kraemer@gsi.de> schrieb:
> On 05.02.2025 08:06, Thomas Koenig wrote:
>
>> Und natürlich REXX, und später auch awk.
>
> awk auf MVS?
Natürlich nicht, das war dann auf UNIX.
> ReXX/MVS kam auch relativ spät (Ende 1980er wimre) und
> war nur halb kompatibel mit ReXX/AmigaOS.
> Also nur eingeschränkt nützlich.
> Aber immer noch freundlicher als CLISTen.
Und viel freundlicher als JCL :-)
> Ich erinnere mich dumpf, damit mal ein primitives "make" für MVS
> emuliert zu haben.
>
>>> Wer's eher bequemer haben wollte, war aber mit PL/I besser bedient.
>>> C/370 fuer MVS kam erst um 1990.
>>
>> Und war irgendwie komisch, wenn man es neben eine UNIX-Implemenierung
>> von C hielt. Über "Hello, world" bin ich da kaum rausgekommen.
>
> Auf den ersten Blick könnte man C für eine Art Schmalspur-PL/I halten.
> Bei näherem Hinsehen merkt man aber, dass die beiden Sprachen
> eigentlich diametral entgegengesetzte Konzepte haben.
C war vor allem klein und flexibel - es musste sich auf einer PDP-11
kompilieren lassen.
>> Und die heutigen Probleme kommen z.T. daher, dass die Leute damals
>> schlampig programmiert und Typen durcheinandergeworfen haben
>> (und EQUIVALENCE für unschöne Dinge eingesetzt).
>
> Das ist eigentlich unvermeidlich, wenn man COMMON/Arrays/Indices
> zur Speicherverwaltung missbrauchen will.
> Manchmal braucht man REAL*8, manchmal nur *4.
Geht tatsächlich standard-konform, mit EQUIVALENCE.
Bei
INTEGER NMEM
PARAMETER (NMEM=10000)
REAL A(2*NMEM)
COMMON /FOO/ A
DOUBLE PRECISION B(NMEM)
EQUIVALENCE (A,B)
(Syntax jage ich jetzt nicht durch einen Compiler) konntest du einen
Teil als double precision - Workspace passen, wenn du einen Teil
von B weitergebeben hat, und einen anderen Teil als real.
>
>> PL/1 sollte ja die gemeinsame Nachfolge von FORTRAN und COBOL werden,
>> aber so richtig angenommen wurde das nie.
>
> Das Ur-Problem eierlegender Wollmilchsäue.
> Den FORTRANern war's zu cobolisch,
> den Cobolianern zu fortranesk.
>
>>
>>> Ein "IBM PL/I For AIX V3.1" von 2011 habe ich noch herumliegen, laeuft.
>>> Patches von Mai 2023 gab's von IBM auch noch, ist also noch nicht ganz tot.
>>>
>>> Vektorisierung gab's leider nicht.
>>> Was einigermassen seltsam ist, denn die Sprache kennt Vektor-Statements,
>>> also sowas
>>>
>>> DCL ( A(3), B(3) ) BINARY FLOAT(53);
>>> A(*) = sin( B(*) );
>>>
>>> da haette der compiler nicht erst muehsam eine DO-Schleife auf
>>> Vektorisierbarkeit abklopfen muessen.
Wie hat PL/I Abängigkeiten? Dürfen da z.B. zwei Argumente an
eine Unterroutine übergeben werden, die überlappen?
>>
>> Die Technik brauchte man aber sowieso; Vektorisierung war ja nicht
>> nur auf einfache Statements beschränkt, sondern auch maskiert.
>
> Vektorisierung lohnt sich eh nur, wenn man sein Problem mit
> Vektor-Statements formulieren kann, plus evtl Maskierung wg if/then/else.
> PL/I hätte diese Denke auf elegante Weise unterstützen können.
Der erste richtig erfolgreiche Vektor-Computer war nun mal die
Cray I, und Cray hatte weder was mit großen Sprachen noch mit
kaufmännischen Dingen was am Hut (wobei die I/O von Cray
extrem fix war).
> Da fällt mir mein alter Prof ein.
> Der schwörte auf Matlab auf seinem PC/AT.
> Damit ginge "das ganz einfach", behauptete er.
> Matrix-Inversion per Einzeiler.
> Nur hatte der PC halt kein VF.
Hatte er wenigstens einen 8087 dabei? Der war zwar fürchterlich
langsam, aber immer noch schneller als FP mit 16-bit-Instruktionen...
>
>> Aber die Vektorisierung auf der IBM 3090 hat eh nicht getaugt.
>
> Würde ich widersprechen wollen.
> Für die überschaubaren Zusatzkosten (relativ zum host) eines VF
> gab's auch die versprochene Leistung.
> Dass man damit eine Cray einholen könne hat IBM nie behauptet wimre.
Der Faktor war sehr überschaubar. Ich hatte damals auf einem
Vektorrechner von Fujitsu gearbeitet (und Jobs mit JCL und JES2
hin- und hergeschaufelt, SYSOUT=(A,INTRDR) und so), und der hatte
echt Speed. Da lohnte es sich, draufzugehen, auch wenn man eine
Workstation zur Verfügung hatte, der hatte auch gewaltig viel
Hauptspeicher.
Die 3090, mit oder ohne VF... war einfach viel zu umständlich
zu bedienen, eine Workstation war da einfach besser.
> Es gab natürlich Nullchecker, die erwarteten, dass der compiler
> aus ihren schlampig programmierten Skalar-Wüsten automatisch flotte
> Vektorprogramme macht. Die konnten nur enttäuscht werden.
Man sollte schon wissen, was man tat, klar.
>> DC ist eigentlich im Assembler "Define Constant", haben die das für was
>> anderes verwendet?
>
> Verschiedene Baustellen.
>
> Im Assembler heisst DC natürlich "Define Constant".
>
> DC im VS-Fortran Kontext steht für "Dynamic Common",
> entweder per Compiler-Option oder händisch im Quell-Text:
>
> @PROCESS DC($AUX$)
> SUBROUTINE XYT(...)
> COMMON /$AUX$/ ...
>
> VS-Fortran kannte also schon sowas wie pragmas.
Ich bin zwischen VS Fortran und Fujitsu Fortran hin und her gewechselt.
Der Fujitsu-Compiler war sehr streng F77, der konnte nicht mal END DO...
> Natürlich war man gut beraten, das per compiler-option anzuweisen statt
> einzeln in jedem PDS member.
Oh ja, PDS... auch eine Fehlkonstruktion. Schreibe auf mehr als ein
Member gleichzeitg und bekomme Bruch. Also DISP=OLD, aber damit wird
dann das ganze PDS gesperrt. Und der Zugriff bei großen PDS wurde auch
immer problematischer, daher hat IBM da zwei neue Dateiformate
definiert (zwei, weil sie es beim ersten verhauten hatten).
>
>>> (ich hatte damals die Marotte, sie mit $'s als irgendwie heilig zu markieren :-)
>>> Wimre kamen die DC's mit MVS/XA auf, als es von 24 auf 31 bit aufgebohrt wurde.
>>> Waer ja auch zu bloede, Zillionen von Nullen als OBJ oder LOAD zu speichern.
>>
>> Das wäre tatsächlich dämlich, aber es ist auch dämlich, Textzeilen mit
>> 10 Zeichen mit 80 Zeichen abzuspeichern .-)
>
> Dagegen gab's ja die VB Dateien, die hat IBM's Fortran dann auch
> irgendwann verdaut.
> Nachdem die Lochkarte entgültig verschwunden war.
Wurde bei uns am RZ nicht empfohlen, das war FB80 (und die optimale
Blockgröße dann an den Plattentyp anpassen, yay!). Das zum
Benutzer durchzuschleifen, war keine gute Idee.
Das war eine große Leistung von UNIX, den ganzen Krempel einfach zu
einem "Stream of Bytes" zu vereinfachen.
> "Variable Length" Lochkarten wären halt irgendwie unpraktisch gewesen.
Lochstreifen gab es, aber nicht bei anderen Rechnern.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-04 17:50 +0100 |
| Message-ID | <vntk1a.308.1@stefan.msgid.phost.de> |
| In reply to | #47360 |
Am 03.02.2025 um 19:03 schrieb Thomas Koenig: > Stefan Reuther <stefan.news@arcor.de> schrieb: >> 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? Memory Mapped Registers. Am Ende genau wie die Framebuffer: eine Hardware-Ressource. Zählt die nun als Speicherbedarf oder nicht? >> 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 ist nichtmal eine Frage der Qualität (auch wenn ich dieses besondere Stück Software ganz besonders liebe). Es macht sich halt niemand die Gedanken, den Ressourcenbedarf seines Stücks Software zu quantifizieren. Das geht mir als Autor ganz genauso. Wie soll ich den Speicherbedarf meines JSON-Parsers quantifizieren, wenn es vom Anwender abhängt, was der für Daten da reinsteckt? Wie quantifiziere ich den Unterschied zwischen "Anführungszeichen, 100 MByte Text, Anführungszeichen" und "50 Millionen '[', 50 Millionen ']'"? (Beides je 100 MByte Eingabe, aber letzteres braucht *deutlich* mehr Parserressourcen, da es eine verschachtelte Struktur erzeugt.) >> 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. Es gibt auch Tools zur Berechnung der Stack-Größe. Bei Green Hills wäre das z.B. 'gstack'. Zumindest als ich das benutzt habe, scheiterte es an Funktionspointern (und damit an C++ mit virtuellen Funktionen). Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Michael Kraemer @ home" <M.Kraemer@gsi.de> |
|---|---|
| Date | 2025-02-04 22:31 +0100 |
| Message-ID | <m0ffb9F441eU1@mid.individual.net> |
| In reply to | #47366 |
Stefan Reuther wrote: > Das geht mir als Autor ganz genauso. Wie soll ich den Speicherbedarf > meines JSON-Parsers quantifizieren, wenn es vom Anwender abhängt, was > der für Daten da reinsteckt? ein paar Testfaelle spezifizieren (best/worst case), und gucken, was "top" dazu sagt?
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-04 22:06 +0000 |
| Message-ID | <vnu30k$21cgc$1@dont-email.me> |
| In reply to | #47366 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 03.02.2025 um 19:03 schrieb Thomas Koenig:
>> 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 ist nichtmal eine Frage der Qualität (auch wenn ich dieses besondere
> Stück Software ganz besonders liebe). Es macht sich halt niemand die
> Gedanken, den Ressourcenbedarf seines Stücks Software zu quantifizieren.
>
> Das geht mir als Autor ganz genauso. Wie soll ich den Speicherbedarf
> meines JSON-Parsers quantifizieren, wenn es vom Anwender abhängt, was
> der für Daten da reinsteckt? Wie quantifiziere ich den Unterschied
> zwischen "Anführungszeichen, 100 MByte Text, Anführungszeichen" und "50
> Millionen '[', 50 Millionen ']'"? (Beides je 100 MByte Eingabe, aber
> letzteres braucht *deutlich* mehr Parserressourcen, da es eine
> verschachtelte Struktur erzeugt.)
Wenn du das als Baum aufbaust: Soundoviele Bytes pro Node, soundsoviele
Bytes Overhead pro Identifier oder String oder wasimmer du da auch
drin hast.
>> 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.
>
> Es gibt auch Tools zur Berechnung der Stack-Größe. Bei Green Hills wäre
> das z.B. 'gstack'.
Spätestens, wenn ein Programm Rekursion verwendet, sollte das
problematisch werden, oder halt mit alloca() oder Konsorten.
Aber das war auch ein "Vorteil" beim Berechnen der Speichermenge
unter MVS und den dortigen FORTRAN-Compilern: Rekursion war
da verboten (auch in der OS calling sequence nicht vorgesehen),
und jede Art von dynamischer Speicherverwaltung war in FORTRAN 77
verboten. Mittlerweile geht
subroutine foo(n)
real :: a(n,n)
damals noch nicht. Daher muss man bei LAPACK auch immer einen
"Working Space" mit übergeben (was nervt und fehleranfällig ist).
> Zumindest als ich das benutzt habe, scheiterte es an
> Funktionspointern (und damit an C++ mit virtuellen Funktionen).
Macht es nur ein klein wenig nutzlos...
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-05 17:02 +0100 |
| Message-ID | <vo05ju.498.1@stefan.msgid.phost.de> |
| In reply to | #47369 |
Am 04.02.2025 um 23:06 schrieb Thomas Koenig: > Stefan Reuther <stefan.news@arcor.de> schrieb: >> Das geht mir als Autor ganz genauso. Wie soll ich den Speicherbedarf >> meines JSON-Parsers quantifizieren, wenn es vom Anwender abhängt, was >> der für Daten da reinsteckt? Wie quantifiziere ich den Unterschied >> zwischen "Anführungszeichen, 100 MByte Text, Anführungszeichen" und "50 >> Millionen '[', 50 Millionen ']'"? (Beides je 100 MByte Eingabe, aber >> letzteres braucht *deutlich* mehr Parserressourcen, da es eine >> verschachtelte Struktur erzeugt.) > > Wenn du das als Baum aufbaust: Soundoviele Bytes pro Node, soundsoviele > Bytes Overhead pro Identifier oder String oder wasimmer du da auch > drin hast. Auch dann macht es noch einen Unterschied, wie lang meine Strings sind und wie malloc damit umgeht (von Libraries, de 78 Byte Metadaten für 2 Byte Payload allokieren mal abgesehen). Am Ende bleibt dann halt tatsächlich nur: Benchmark-Fall definieren und messen. >>> 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. >> >> Es gibt auch Tools zur Berechnung der Stack-Größe. Bei Green Hills wäre >> das z.B. 'gstack'. > > Spätestens, wenn ein Programm Rekursion verwendet, sollte das > problematisch werden, Ja, das merkt das Tool. > oder halt mit alloca() oder Konsorten. Wer alloca benutzt, dem hau ich persönlich auf die Finger. >> Zumindest als ich das benutzt habe, scheiterte es an >> Funktionspointern (und damit an C++ mit virtuellen Funktionen). > > Macht es nur ein klein wenig nutzlos... Das kommt halt auf die Aufgabe an. Wenn man ein Motorsteuergerät baut, ist das sinnvoll. Und dafür gibt es dann Coding Styles wie MISRA, die Rekursion und Funktionszeiger verbieten. Spaßig wird das dann, wenn Leute versuchen, diese Regeln auf Dinge anzuwenden, die größer als ein Motorsteuergerät sind, und dabei den Klappentext "du darfst jede Regel brechen, wenn du es begründen kannst" ignorieren. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-01-31 11:19 +0100 |
| Message-ID | <vnibjn.4q8.1@stefan.msgid.phost.de> |
| In reply to | #47330 |
Am 30.01.2025 um 21:59 schrieb Thomas Koenig:
> Stefan Reuther <stefan.news@arcor.de> schrieb:
>> Am 29.01.2025 um 22:00 schrieb Thomas Koenig:
>>> 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.
Es geht nicht darum, wie viele das sind, sondern wie komplex die
aufzulösen sind. Und ein Miss mitten in der Instruktion ist halt schwer,
siehe Peters Post.
Die Frage ist halt, ob man sich das ans Bein binden will für Performance
in relativ seltenen Spezialfällen.
> 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
Das ist offenbar eine etwas umständlichere ISA. Für AArch64 macht gcc
das draus:
foo:
add x1, x0, x1, lsl 3
mov x0, 992608256
movk x0, 0xd04c, lsl 32
movk x0, 0xf6e5, lsl 48
add x1, x1, x0
mov x0, 52719
movk x0, 0x90ab, lsl 16
movk x0, 0x5678, lsl 32
movk x0, 0x1234, lsl 48
str x0, [x1, 6408]
ret
und das wäre in etwas, was ich erwartet hätte. Eine Alternative wäre
(händisch, ungetestet)
foo:
add x1, x0, x1, lsl 3
ldr x2, =0x123456789ABCDEF
ldr x3, =(0xFEDCBA987654321*8)
str x2, [x1, x3]
ret
.pool
wobei "=" ARM's Pseudo-Assembler-Syntax für PC-relative Adressierung des
Konstantenpools ist.
> 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?
In der Metrik dürfte dann aber x86 *noch* besser sein...
>>> 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.
"kein Hazard" nur dann, wenn man genau eine Instruktion anschaut.
Interessant wird es erst, wenn man mehrere Instruktionen gleicher Art
hintereinander packt, zum Beispiel, weil die zu pushenden Daten eben
nicht in nebeneinanderliegenden Registern liegen.
>> 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:
Sicher, dass die ein Compiler erzeugt hat?
Ich habe diverse aktuelle und weniger aktuelle Compiler über
https://gcc.godbolt.org/ befragt.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-01 08:43 +0000 |
| Message-ID | <vnkmsa$t7k$1@dont-email.me> |
| In reply to | #47332 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 30.01.2025 um 21:59 schrieb Thomas Koenig:
>> Stefan Reuther <stefan.news@arcor.de> schrieb:
>>> Am 29.01.2025 um 22:00 schrieb Thomas Koenig:
>>>> 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.
>
> Es geht nicht darum, wie viele das sind, sondern wie komplex die
> aufzulösen sind. Und ein Miss mitten in der Instruktion ist halt schwer,
> siehe Peters Post.
Siehe meine Antwort darauf (gerade eben geschrieben, also nach deinem
Post hier, konntest du also nicht kennen, als du das hier geschrieben
hast).
> Die Frage ist halt, ob man sich das ans Bein binden will für Performance
> in relativ seltenen Spezialfällen.
Ordentliches Handling von Konstanten bringt tatsächlich erstaunlich
viel.
>
>> 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
>
> Das ist offenbar eine etwas umständlichere ISA.
Das kann man wohl sagen, das Design ist ziemlich kaputt.
>Für AArch64 macht gcc
> das draus:
> foo:
> add x1, x0, x1, lsl 3
> mov x0, 992608256
> movk x0, 0xd04c, lsl 32
> movk x0, 0xf6e5, lsl 48
> add x1, x1, x0
> mov x0, 52719
> movk x0, 0x90ab, lsl 16
> movk x0, 0x5678, lsl 32
> movk x0, 0x1234, lsl 48
> str x0, [x1, 6408]
> ret
>
> und das wäre in etwas, was ich erwartet hätte.
Ach ja, die komischen ARM-Konstanten...
Ich muss jetzt zugeben, ich kenne die ARM-Latenzen nicht so richtig.
Ich vermute/hoffe mal, dass mov, movk und add eine Latenz von einem
Zyklus haben (sonst hätten die was falsch gemacht).
Auf einer hinreichend großen OoO-Maschine wären dann die Zyklen zum
Zusammenbasteln der beiden Konstanten
> add x1, x0, x1, lsl 3 ; 1
> mov x0, 992608256 ; 1
> movk x0, 0xd04c, lsl 32 ; 2
> movk x0, 0xf6e5, lsl 48 ; 3
> add x1, x1, x0 ; 4
> mov x0, 52719 ; 1
> movk x0, 0x90ab, lsl 16 ; 2
> movk x0, 0x5678, lsl 32 ; 3
> movk x0, 0x1234, lsl 48 ; 4
> str x0, [x1, 6408]
> ret
Also vier Zyklen, um jeweils eine 64-Bit-Konstante zusammenzupasten.
>Eine Alternative wäre
> (händisch, ungetestet)
>
> foo:
> add x1, x0, x1, lsl 3
> ldr x2, =0x123456789ABCDEF
> ldr x3, =(0xFEDCBA987654321*8)
> str x2, [x1, x3]
> ret
> .pool
>
> wobei "=" ARM's Pseudo-Assembler-Syntax für PC-relative Adressierung des
> Konstantenpools ist.
Nicht sicher, ob das wirklch besser wäre. Die Latenzen von loads
aus dem Cache gehen in letzter Zeit immer weiter rauf, Intel ist
mittlerweile bei fünf Zylken angekommen. Selbst wenn die Werte im
L1 - Cache sind, würen das nicht unbedingt schneller.
>
>> 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?
>
> In der Metrik dürfte dann aber x86 *noch* besser sein...
Schaun mer mal:
0: 48 b8 21 43 65 87 09 movabs $0xfedcba0987654321,%rax
7: ba dc fe
a: 48 01 c6 add %rax,%rsi
d: 48 b8 ef cd ab 90 78 movabs $0x1234567890abcdef,%rax
14: 56 34 12
17: 48 89 04 f7 mov %rax,(%rdi,%rsi,8)
1b: c3 ret
Fünf Instruktionen, 28 Bytes.
>
>>>> 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.
>
> "kein Hazard" nur dann, wenn man genau eine Instruktion anschaut.
> Interessant wird es erst, wenn man mehrere Instruktionen gleicher Art
> hintereinander packt, zum Beispiel, weil die zu pushenden Daten eben
> nicht in nebeneinanderliegenden Registern liegen.
Korrekt. Und bei x86 kommen halt typischerweise mehrere
push-Instruktionen hintereinander, bei ARM (32-bit) macht eine
die gleiche Arbeit wie mehere bei x86.
>
>>> 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:
>
> Sicher, dass die ein Compiler erzeugt hat?
Ja, das weiß ich zufälligerweise _ganz_ genau :-)
Source findest du unter
https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgfortran/generated/matmul_r4.c;hb=refs/heads/master
Übersetzt war das mit gcc (GCC) 15.0.1 20250116 (experimental), als Teil
des builds.
Ansonsten kannst du dir, falls du gfortran installierst hast, das
auch auf deinem System anschauen:
/usr/lib/gcc/x86_64-linux-gnu/13$ objdump -d libgfortran.a | grep -A 20 matmul_r4_avx:
Disassembly of section .text.matmul_r4_avx:
0000000000000000 <matmul_r4_avx>:
0: f3 0f 1e fa endbr64
4: 41 55 push %r13
6: 4c 8d 6c 24 10 lea 0x10(%rsp),%r13
b: 48 83 e4 e0 and $0xffffffffffffffe0,%rsp
f: 41 ff 75 f8 push -0x8(%r13)
13: 55 push %rbp
14: 48 89 e5 mov %rsp,%rbp
17: 41 57 push %r15
19: 4d 89 cf mov %r9,%r15
1c: 41 56 push %r14
1e: 49 89 d6 mov %rdx,%r14
21: 41 55 push %r13
23: 49 89 f5 mov %rsi,%r13
26: 41 54 push %r12
28: 53 push %rbx
29: 48 89 fb mov %rdi,%rbx
2c: 48 81 ec e8 05 00 00 sub $0x5e8,%rsp
33: 89 8d 70 ff ff ff mov %ecx,-0x90(%rbp)
> Ich habe diverse aktuelle und weniger aktuelle Compiler über
> https://gcc.godbolt.org/ befragt.
Wird vermutlich davon abhängen, was du genau für Programme
reingepackt hast.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-02 09:22 +0100 |
| Message-ID | <vnndfu.4ms.1@stefan.msgid.phost.de> |
| In reply to | #47336 |
Am 01.02.2025 um 09:43 schrieb Thomas Koenig: > Stefan Reuther <stefan.news@arcor.de> schrieb: >> Ich habe diverse aktuelle und weniger aktuelle Compiler über >> https://gcc.godbolt.org/ befragt. > > Wird vermutlich davon abhängen, was du genau für Programme > reingepackt hast. Sowas: https://gcc.godbolt.org/z/vfTWrjc5G https://gcc.godbolt.org/z/YEMeqnd4c Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-02 09:59 +0000 |
| Message-ID | <vnnflr$koeg$1@dont-email.me> |
| In reply to | #47347 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 01.02.2025 um 09:43 schrieb Thomas Koenig:
>> Stefan Reuther <stefan.news@arcor.de> schrieb:
>>> Ich habe diverse aktuelle und weniger aktuelle Compiler über
>>> https://gcc.godbolt.org/ befragt.
>>
>> Wird vermutlich davon abhängen, was du genau für Programme
>> reingepackt hast.
>
> Sowas:
>
> https://gcc.godbolt.org/z/vfTWrjc5G
Also
void foo();
void bar()
{
foo(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18);
}
was von 64-bit ARM in
bar:
sub sp, sp, #96
stp x29, x30, [sp, 80]
add x29, sp, 80
mov w0, 18
str w0, [sp, 72]
mov w0, 17
str w0, [sp, 64]
mov w0, 16
str w0, [sp, 56]
mov w0, 15
str w0, [sp, 48]
mov w0, 14
str w0, [sp, 40]
mov w0, 13
str w0, [sp, 32]
mov w0, 12
str w0, [sp, 24]
mov w0, 11
str w0, [sp, 16]
mov w0, 10
str w0, [sp, 8]
mov w0, 9
str w0, [sp]
mov w7, 8
mov w6, 7
mov w5, 6
mov w4, 5
mov w3, 4
mov w2, 3
mov w1, 2
mov w0, 1
bl foo
ldp x29, x30, [sp, 80]
add sp, sp, 96
ret
übersetzt wird.
(Der ARM-Code sieht auch nicht ganz optimal aus. Die calling convention
verwendet ja für jedes Argument 8 Byte, daher könnte auch irgendwas
in der Richtung
mov x0, 18
mov x1, 17
stp x1, x0, [sp, 72]
Instruktionen sparen)
> https://gcc.godbolt.org/z/YEMeqnd4c
Das ist jetzt spannend. MinGW gcc 13.1.0 nimmt
bar:
sub rsp, 152
mov DWORD PTR 136[rsp], 18
mov DWORD PTR 128[rsp], 17
mov DWORD PTR 120[rsp], 16
während gcc x86-64 gcc(trunk), nach anpassen des Prototypes
(wg. Default C23), also
void foo(int, int, int, int, int, int, int, int,
int, int, int, int, int, int, int, int,
int, int);
void bar()
{
foo(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18);
}
generiert:
bar:
sub rsp, 8
push 18
push 17
push 16
push 15
push 14
push 13
push 12
push 11
push 10
push 9
push 8
push 7
mov r9d, 6
mov r8d, 5
mov ecx, 4
mov edx, 3
mov esi, 2
mov edi, 1
call foo
add rsp, 104
ret
genauso wie die standard (vermutlich Linux-) gccs.
Anscheinend haben die MinGW-Leute da irgendwelche Anpassungen
vorgenommen, aus welchem Grund auch immer.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2025-02-03 17:29 +0100 |
| Message-ID | <vnqued.378.1@stefan.msgid.phost.de> |
| In reply to | #47348 |
Am 02.02.2025 um 10:59 schrieb Thomas Koenig:
> bar:
> sub sp, sp, #96
> stp x29, x30, [sp, 80]
> add x29, sp, 80
> mov w0, 18
> str w0, [sp, 72]
> mov w0, 17
> str w0, [sp, 64]
[...]
> (Der ARM-Code sieht auch nicht ganz optimal aus. Die calling convention
> verwendet ja für jedes Argument 8 Byte, daher könnte auch irgendwas
> in der Richtung
>
> mov x0, 18
> mov x1, 17
> stp x1, x0, [sp, 72]
>
> Instruktionen sparen)
Wenn wir schon soweit abschweifen: der gcc kommt auch nicht auf die
Idee, bei
struct foo {
int a;
char b;
char c;
};
void bar(struct foo* p) {
p->a = 1;
p->b = 0;
p->c = 0;
}
die Stores für b+c zusammenzufassen. Dabei wäre das, genau wie deine
Anmerkung, eine triviale Peephole-Optimierung. clang bekommt das
immerhin hin.
>> https://gcc.godbolt.org/z/YEMeqnd4c
>
> Das ist jetzt spannend. MinGW gcc 13.1.0 nimmt
>
> bar:
> sub rsp, 152
> mov DWORD PTR 136[rsp], 18
> mov DWORD PTR 128[rsp], 17
> mov DWORD PTR 120[rsp], 16
[...]
> Anscheinend haben die MinGW-Leute da irgendwelche Anpassungen
> vorgenommen, aus welchem Grund auch immer.
Windows hat zumindest durchaus gerne mal eine etwas andere Meinung als
die *ixe, wie ein Stackframe auszusehen hat. Windows hat ja Structured
Exception Handling (try/catch) auch in C.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-02-03 17:04 +0000 |
| Message-ID | <vnqsub$1c8nu$1@dont-email.me> |
| In reply to | #47356 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 02.02.2025 um 10:59 schrieb Thomas Koenig:
>> bar:
>> sub sp, sp, #96
>> stp x29, x30, [sp, 80]
>> add x29, sp, 80
>> mov w0, 18
>> str w0, [sp, 72]
>> mov w0, 17
>> str w0, [sp, 64]
> [...]
>> (Der ARM-Code sieht auch nicht ganz optimal aus. Die calling convention
>> verwendet ja für jedes Argument 8 Byte, daher könnte auch irgendwas
>> in der Richtung
>>
>> mov x0, 18
>> mov x1, 17
>> stp x1, x0, [sp, 72]
>>
>> Instruktionen sparen)
Ich war schon am Schreiben des PR, aber da ist mir aufgefallen, dass
das natürlich nur für little-endian tut.
>
> Wenn wir schon soweit abschweifen: der gcc kommt auch nicht auf die
> Idee, bei
>
> struct foo {
> int a;
> char b;
> char c;
> };
> void bar(struct foo* p) {
> p->a = 1;
> p->b = 0;
> p->c = 0;
> }
>
> die Stores für b+c zusammenzufassen. Dabei wäre das, genau wie deine
> Anmerkung, eine triviale Peephole-Optimierung. clang bekommt das
> immerhin hin.
"gcc kriegt nicht hin" ist ein bisschen verallgemeindernd:
$ cat foo.c
struct foo {
int a;
char b;
char c;
};
void bar(struct foo* p) {
p->a = 1;
p->b = 0;
p->c = 0;
}
$ gcc -O3 -S foo.c
$ cat foo.s
.file "foo.c"
.text
.p2align 4
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
xorl %eax, %eax
movl $1, (%rdi)
movw %ax, 4(%rdi)
ret
.cfi_endproc
.LFE0:
.size bar, .-bar
.ident "GCC: (GNU) 15.0.1 20250116 (experimental)"
.section .note.GNU-stack,"",@progbits
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2025-01-29 19:56 +0100 |
| Message-ID | <pbaq6l-6iv.ln1@news.martinen.de> |
| In reply to | #47319 |
Am 27.01.25 um 22:30 schrieb Thomas Koenig: > Christian Weisgerber <naddy@mips.inka.de> schrieb: >> On 2025-01-25, Thomas Koenig <tkoenig@netcologne.de> wrote: > >>> Bei A32 wussten sie nicht so ganz, was mit den 32 bit im Befehlswort >>> anfangen (waren ja auch nur 16 Register), und haben deshalb in bit >>> 28 bis 31 jeder Instruktion einen 4-bit-Condition reingepackt, >>> Abhängig von den Flags kann man jede Instruktion skippen. Klingt für mich krude. Aber außer basics in 6502-Assembler hab ich sonst nirgends weiter rein geschnuppert. Die ganzen 80x86 Befehle und optionen, Suffixe, Präfixe über die ich in einem Intel Buch las schienen mir damals umfangreich und flexibel. Aber was weiß ich da schon. ;) >> Beim dritten Operanden der Arithmetik-Befehle hat sich bei AArch64 >> viel geändert. Statt eines einheitlichen Schemas gibt es jetzt >> mehrere Varianten von Immediate, Shift, Extend, usw., die sich für >> einzelne Untergruppen (Add/Sub, Move, Logik) unterscheiden. Klingt noch komplizierter. Und nicht nach Orthogonalem Befehlssatz. > Die ISA, die das am besten hinbekommt, die gibt es leider (noch?) > nicht auf dem Markt. Die stammt von Mitch Alsup, dem damaligen > Chefentwickler des Motorola 88000, der sich danach auch in diversen > anderen Firmen gearbeitet hat, u.a. bei AMD, Ross (die mit den > SPARCs) und Samsung. Der hat sich in seiner Rente vorgenommen, die > ideale ISA zu entwickeln. Das ist eine Load/Store - Architektur mit > ein paar CISCigen Elementen. Der Name der Architektur ist > My 66000. [...] Uiuiui. > (Mit add ist da einiges redundant, mit div z.B. nicht). > > 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. Wegens Befehlssatz, RISC/CISC & ISA fing ich diesen Post an, mit der Frage weiter unten... > (Wer sich für dafür interessieren sollte: Mitch Alsup hängt auf > comp.arch ab, hat sich aber letztens mit Linus Torvalds auch > eine Diskusison über Page Tables auf Real World Tech. Ich hatte da eben eine Krass-Spektakel-Idee aber vielleicht ist die ja ein alter Hut. Hat mal jemand die ausführbaren Kompilate üblicher Anwendungsprogramme aus verschiedenen Gattungen auf maschinen- ebene analysiert um nicht einfach Optimierungen für eine CPU oder Eigenschaft zu finden, sondern um einen hypothetischen Optimalen Befehlssatz zu finden mit dem idealerweise alle Programme einfacher und/oder Sicherer und Schneller erzeugt und ausgeführt werden könnten. Ich meine so komplett ohne auf eine bestimmte Architektur zu schielen sondern darauf welche Befehlssequenzen im Kompilat am häufigsten zu finden sind und wodurch man sie ggf. auf einer (Realen/Hypothetischen) CPU ersetzen könnte. Ob man da evtl. der Vergleichbarkeit wegen Compiler-optimierungen eher abschalten müßte oder eine generische allgemeine Einstellung nehmen (und neu kompilieren) müßte kann ich nur vermuten. Bei Closed-source wird so was eher nicht gehen aber bei open-source schon. Ich glaube Codeanalysen gehen doch wohl meist auf Optimierungen des Compilers auf CPU, Architektur und Plattform ein. Aber nicht auf ein hypothetisches "Das bessere sei der Feind des Guten" Konstrukt. Oder? Bye/ /Kay -- Posted via Leafnode
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web