Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #261747 > unrolled thread
| Started by | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| First post | 2019-08-15 17:45 -0400 |
| Last post | 2019-08-19 00:23 +0200 |
| Articles | 20 on this page of 131 — 21 participants |
Back to article view | Back to de.sci.electronics
FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 17:45 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-16 09:22 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-16 22:53 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-16 20:55 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-16 22:26 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-16 22:47 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-16 23:34 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-17 08:27 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-17 09:23 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-17 06:17 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-17 20:36 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-17 18:31 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-17 09:25 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-17 07:53 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-17 19:15 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-17 09:44 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-17 10:41 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ewald Pfau <anderswo@gmx.net> - 2019-08-17 08:34 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-17 08:05 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Helmut Schellong <rip@schellong.biz> - 2019-08-17 14:51 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-16 23:13 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-17 08:37 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-17 07:12 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-17 20:57 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-17 19:02 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-18 08:41 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ewald Pfau <anderswo@gmx.net> - 2019-08-18 07:30 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-18 10:15 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ewald Pfau <anderswo@gmx.net> - 2019-08-18 18:43 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-18 21:57 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-08-18 22:13 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-18 23:50 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Karrer <ak-9a@gmx.ch> - 2019-08-19 00:43 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-19 07:21 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-19 11:02 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-19 08:11 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-19 14:44 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Axel Berger <Spam@Berger-Odenthal.De> - 2019-08-19 15:51 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-19 15:56 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Helmut Schellong <rip@schellong.biz> - 2019-08-19 16:40 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-19 16:53 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Helmut Schellong <rip@schellong.biz> - 2019-08-19 17:15 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-19 17:17 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Helmut Schellong <rip@schellong.biz> - 2019-08-19 18:56 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Klaus Butzmann <kb.usenet@butzomail.de> - 2019-08-19 21:49 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange"ISRs Axel Berger <Spam@Berger-Odenthal.De> - 2019-08-20 01:04 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange"ISRs Axel Berger <Spam@Berger-Odenthal.De> - 2019-08-19 17:26 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange"ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-20 01:42 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange"ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-20 02:48 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-19 17:56 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Helmut Schellong <rip@schellong.biz> - 2019-08-19 19:07 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Andreas Karrer <ak-9a@gmx.ch> - 2019-08-19 15:17 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Ewald Pfau <anderswo@gmx.net> - 2019-08-19 20:03 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-19 23:14 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-20 18:56 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-21 02:23 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-21 02:26 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-21 06:30 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Helmut Schellong <rip@schellong.biz> - 2019-08-21 13:27 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 15:41 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-21 15:13 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 10:47 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs Axel Berger <Spam@Berger-Odenthal.De> - 2019-08-20 01:13 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-19 17:52 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-20 17:58 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 15:50 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 18:13 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 19:17 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hanno Foest <hurga-news2@tigress.com> - 2019-08-21 20:16 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-21 21:02 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hanno Foest <hurga-news2@tigress.com> - 2019-08-21 22:47 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 22:59 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-08-22 17:47 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan Engler <stefan@epiket.de> - 2019-08-21 21:43 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 22:05 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 23:07 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 23:55 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hanno Foest <hurga-news2@tigress.com> - 2019-08-22 00:12 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 00:34 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hanno Foest <hurga-news2@tigress.com> - 2019-08-22 00:47 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 01:25 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-08-22 01:06 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 00:11 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-08-22 23:07 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Axel Berger <Spam@Berger-Odenthal.De> - 2019-08-23 00:50 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ewald Pfau <anderswo@gmx.net> - 2019-08-23 06:57 +0000
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-24 10:26 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hanno Foest <hurga-news2@tigress.com> - 2019-08-21 23:59 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 01:04 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hanno Foest <hurga-news2@tigress.com> - 2019-08-22 01:46 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 02:57 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 20:28 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 20:58 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 23:10 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan Engler <stefan@epiket.de> - 2019-08-21 21:29 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 22:12 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Alfred Gemsa <gemsa@gmx.de> - 2019-08-21 22:33 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 23:41 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Alfred Gemsa <gemsa@gmx.de> - 2019-08-22 00:18 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 01:17 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Alfred Gemsa <gemsa@gmx.de> - 2019-08-22 01:42 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-22 06:58 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-22 07:02 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Alfred Gemsa <gemsa@gmx.de> - 2019-08-22 14:15 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 01:55 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Volker Bartheld <news2019@bartheld.net> - 2019-08-22 11:21 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Alfred Gemsa <gemsa@gmx.de> - 2019-08-22 12:13 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 23:25 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 00:00 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 00:38 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 01:10 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 01:37 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 03:14 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 07:18 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 02:46 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 11:57 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-22 12:34 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-22 17:21 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-22 07:48 -0400
Re: Benchmarks Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-23 10:56 +0200
Re: Benchmarks Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-23 14:41 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-21 23:14 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2019-08-22 08:40 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-20 01:32 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-20 12:10 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-20 07:48 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-08-20 14:42 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-20 08:56 -0400
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-21 15:45 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "h.-d.winzler" <horst.d.winzler@web.de> - 2019-08-21 13:28 +0200
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-19 00:23 +0200
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-16 23:13 -0400 |
| Message-ID | <EryrWR4EQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261784 |
On 16 Aug 19 at group /de/sci/electronics in article qj6u7q$3mr$1@news2.open-news-network.org <dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote: > On 15.08.19 23:45, Wolfgang Allinger wrote: >> So nun zum Schluss: >> >> Schau mal nach Gforth für Windoof, Linux, Android, MAC oder was weis ich >> noch alles. Ist eins der mächtigsten Systeme, das ich kenne. > Also vermutlich auch eines der am besten optimiertesten. > Deine Argumente sind, zusammenfassend, etwa: > 1. Forth ist "schön" debuggbar > 2. Forth ist einfach zu schreiben, weil skriptbar > Das sind beides subjektive und qualitative Argumente. Auf meine Frage im > anderen Thread bezüglich der Performance antwortest du ausweichend mit > (ich paraphrasiere) "ich bin schon in Rente" und deswegen könntest du > das nicht testen. > Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer > Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den > auf Wikipedia präsentierten RC4-Forth Code in C von Hand neu > implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia > folgende. > Dann Gforth, dass du oben empfohlen hast, als Benchmarking verwendet. > Resultate hier: https://github.com/johndoe31415/forthvsc > Der Performance Hit ist für den Key Schedule Faktor 316, für den > Datenstrom Faktor 655. Also im Mittel, sagen wir, Faktor 500 lansgsamer. > Das ist also in etwa so als wenn ich auf dem System A meinen µC mit 16 > MHz clocke und auf dem System B denselben Code von 32 kHz Uhrenquarz > laufen lasse. Es sind WELTEN. > Wie man damit also irgendwas kritisches hinkriegen soll ist mir völlig > schleierhaft. Faktor 500 ist jenseits von Gut und Böse. Das ist einfach > nur unbenutzbar. Ich kann das Argument ja gut verstehen, dass du die > Sprache schön findest. Ich finde z.B. auch Python echt schön. Aber würde > ich auf nem µC nie einsetzen, weil man halt genau da üblicherweise die > Performance braucht und nicht im Überfluss hat. > Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von > irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann > muss man aber halt auch so ehrlich sein und die Nachteile (totale > Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich. Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster US Prüfanlagen, kannst ja mal die Datenrate nachrechnen... Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe. BTW Forth Rechner sitzen auch in den Zündern von Granaten, ganz sicher nicht, weil sie sooo langsame Echt Zeit sind und halten beim start über 30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss, wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar andere Werte müssen dazu auch noch in Echtzeit verwurstet werden. Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte das vögeln erklären will. Ja die Bahnhofnutte nehme ich :> Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und das in den 1980ern. Ich hab dann später auch oft C166 genommen, die waren etwa 1/3 langsamer, holten das aber locker mit ihrer tollen Peripherie gegenüber dem RTX auf. Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen bekommen. Auch kein Akt. Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-17 08:37 +0200 |
| Message-ID | <qj87b7$52q$1@news2.open-news-network.org> |
| In reply to | #261794 |
On 17.08.19 05:13, Wolfgang Allinger wrote: >> Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von >> irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann >> muss man aber halt auch so ehrlich sein und die Nachteile (totale >> Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich. > > Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster > US Prüfanlagen, kannst ja mal die Datenrate nachrechnen... > > Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe. LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts entgegenzusetzen hast, hast du das Argument in dem Bereich verloren. > BTW Forth Rechner sitzen auch in den Zündern von Granaten, ganz sicher > nicht, weil sie sooo langsame Echt Zeit sind und halten beim start über > 30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom > nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss, > wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau > eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar > andere Werte müssen dazu auch noch in Echtzeit verwurstet werden. Du wechselst bei deiner Argumentation STÄNDIG das Ziel. Und DEINE Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem Granatenzündcode und Echtzeitberechnungen von Flugraketen. Ach, kannst du nicht, weil das ist alles nur Hörensagen? Messungen hast du nicht? Dann ist es nur Geschwurbel. Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl, die objektiv belegt ist, auch wenn du mit der Realität nicht so klar kommst. Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware gebaut wurde, die das performant interpretiert. Aber auf einem "normalen" Target läuft es halt echt Kacke langsam. > Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte > das vögeln erklären will. Ja die Bahnhofnutte nehme ich :> Ein Oberprimaner, der sich für unheimlich schlau hält aber außer Anekdoten keinerlei Evidenz liefern kann oder will. Und dann ins Rumstammeln kommt und wütend wird, wenn sogar die Bahnhofsnutte in der Lage ist, seine zusammengelogenen Behauptungen mal zu überprüfen. > Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz > getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem > Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und > das in den 1980ern. Also deine Behauptung und neuerliche Anekdote ist, dass du eine Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur wärst, der du behauptest zu sein, dann hättest du das auch sofort durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware implementiert, sonst ist es ja kein Argument für Forth) die Anzahl der Instruktionen, um was sinnvolles zu machen durch. > Ich hab dann später auch oft C166 genommen, die waren etwa 1/3 langsamer, > holten das aber locker mit ihrer tollen Peripherie gegenüber dem RTX auf. > Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen > bekommen. Auch kein Akt. Ja, C Compiler gibt es halt für jedes Target ohne dass man das erst Compiler portieren müsste. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-17 07:12 -0400 |
| Message-ID | <Es1rcJWUQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261797 |
On 17 Aug 19 at group /de/sci/electronics in article qj87b7$52q$1@news2.open-news-network.org <dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote: > On 17.08.19 05:13, Wolfgang Allinger wrote: >>> Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von >>> irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann >>> muss man aber halt auch so ehrlich sein und die Nachteile (totale >>> Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich. >> >> Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster >> US Prüfanlagen, kannst ja mal die Datenrate nachrechnen... >> >> Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe. > LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts > entgegenzusetzen hast, hast du das Argument in dem Bereich verloren. Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das nachzugroffeln. >> BTW Forth Rechner sitzen auch in den Zündern von Granaten, ganz sicher >> nicht, weil sie sooo langsame Echt Zeit sind und halten beim start über >> 30.000g aus. Auch Flugabwehrraketen werden mit Forth in Echtzeit autonom >> nachgesteuert. Rechne mal nach, wie genau man da alles erfassen muss, >> wenn bei Ankunft das programmierte Ende der SW auf 2m+-20cm genau >> eingehalten werden muss. Ja Luftdruck, Temperatur und noch so ein paar >> andere Werte müssen dazu auch noch in Echtzeit verwurstet werden. > Du wechselst bei deiner Argumentation STÄNDIG das Ziel. Und DEINE > Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem > Granatenzündcode und Echtzeitberechnungen von Flugraketen. Ach, kannst > du nicht, weil das ist alles nur Hörensagen? Messungen hast du nicht? > Dann ist es nur Geschwurbel. Du spinnst, haste mal was von NDA gehört oder kennst Dich im MIL Bereich aus? > Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie > performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl, > die objektiv belegt ist, auch wenn du mit der Realität nicht so klar kommst. > Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware > gebaut wurde, die das performant interpretiert. Aber auf einem > "normalen" Target läuft es halt echt Kacke langsam. Schmeisst Du hier ständig Interpreter und Compiler durcheinander? Wenn FORTH fertig mit dem Lesen einer Quelle ist, ist wenige Maschinenzyklen später auch das Kompilat fertig! >> Es kommst mir so vor, wie ein Oberprimaner, der einer alten Bahnhofnutte >> das vögeln erklären will. Ja die Bahnhofnutte nehme ich :> > Ein Oberprimaner, der sich für unheimlich schlau hält aber außer > Anekdoten keinerlei Evidenz liefern kann oder will. Und dann ins > Rumstammeln kommt und wütend wird, wenn sogar die Bahnhofsnutte in der > Lage ist, seine zusammengelogenen Behauptungen mal zu überprüfen. Nänä Bahnhofsnutte hab ich schon gewählt, nicht das Wort im Munde rumdrehen! >> Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz >> getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem >> Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und >> das in den 1980ern. > Also deine Behauptung und neuerliche Anekdote ist, dass du eine > Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist > schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur > wärst, der du behauptest zu sein, dann hättest du das auch sofort > durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware > implementiert, sonst ist es ja kein Argument für Forth) die Anzahl der > Instruktionen, um was sinnvolles zu machen durch. Ich hab ja nicht gesagt, dass die 2MHz was besonders sinnvolles gemacht haben. Der RTX2000 führt eine leere Interrupt Service Routine in 400ns aus. Jeder zusätzliche (Anwendertakt) 100ns. zB. Einen Zähler zu incrementieren 100ns. In diesen 100ns konnte der bis zu 4 (5?) Befehle gleichzeitig ausführen. zB. noch an nem Portbit wackeln. Dazu war eben noch genügend Zeit, um per SIO mit dem Target zu arbeiten. Nix HW, alles SW! Watt nu? Das habe ich gemessen und vorgeführt, kann leicht anhand des Datenblattes RTX2000 überprüft werden. Wenn man will. Das ist eben der Unterschied zwischen Ingenieuren hüstel Bahnhofsnutten und Physikern :p Und tut mir leid, dass der RTX2000 keinen Assembler als Maschinencode hat. Nur FORTH :p Er besteht IIRC aus etwas mehr als 4.000 Gattern. Der Vorläufer NOVIX 4000 hatte daher seinen Namen. Ich weis auch nicht, was moderne uC für eine leere IRsrv brauchen. Ist mir auch egal, die RTX2000 waren ja schon mal ne Hausnummer. Noch nen Massenartikel: die Zündschlüssel für viele Autos, besonders Mercedes, hatten einen MARC 4 (4!!! bit FORTH Processor) von Temic (ex Telefunken) drin. Nein, MERCEDES hat das nicht besonders geschickt und vorbildlich implementiert, sitzen auf zu hohem Ross :) Einer der MIL Wegwerfartikel hatte auch nen MARC4 drin, im Gegensatz zu den Düsseldorfern, die haben 100 Tausende RTX im Desert Storm verfeuert. Desterwegen sind die Dinger inzwischen auch sehr rar geworden. Waren Granaten, die im Endanflug über kleine Finnen mit Schrittmotoren (armer Johannes), sowie mit Video und Radar im Kopf gesteuert wurden. Anfangsbeschleunigung umme 30.000g :o Und ich glaube nicht, dass das eine langsame Anwendung war :p Oder die FORTH wegen Lahmheit genommen haben. Es wurde seinerzeit gemunkelt, dass die Patriots auch mit RTX2000 flogen, aber hab das nie verifizieren können. NDA rulez. Jedenfalls war der Markt plötzlich leergefegt und RTX wurden in Gold aufgewogen (u.a. wg. RAD- Hard). Hab da mal die restlichen 10 aus meinem Handlager gut versilbert :) Die Honks bei Harris haben alle Entwickler gefeuert und wollten so richtig Absahnen, als dann der Nachschub klemmte, und die Entwickler in aller Welt gute neue Jobs hatten, war es für Harris zu spät. Keine Ahnung, obs Harris noch gibt. Gier frisst Hirn! >> Ich hab dann später auch oft C166 genommen, die waren etwa 1/3 langsamer, >> holten das aber locker mit ihrer tollen Peripherie gegenüber dem RTX auf. >> Ah ich vergass, die C166 mussten die Forth engine erst noch beigebogen >> bekommen. Auch kein Akt. > Ja, C Compiler gibt es halt für jedes Target ohne dass man das erst > Compiler portieren müsste. Hab ich irgendwo geschrieben, dass ich für den C166 nicht einen fertigen Kernel genommen habe? Ich hatte in meinem Ing. Büro die Kernels für 2 Dutzend verschiedenen CPU Familien im Köcher. Ja alle zugekauft und einen selber gemacht um das auch mal probiert zu haben. Wieviel C Kerne hast Du schon geschrieben? Was hast Du an dem Begriff "erstellen eines Target für eine NEUE CPU" nicht verstanden? Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-17 20:57 +0200 |
| Message-ID | <qj9imo$a98$1@news2.open-news-network.org> |
| In reply to | #261820 |
On 17.08.19 13:12, Wolfgang Allinger wrote: >>> Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster >>> US Prüfanlagen, kannst ja mal die Datenrate nachrechnen... >>> >>> Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe. > >> LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts >> entgegenzusetzen hast, hast du das Argument in dem Bereich verloren. > > Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das > nachzugroffeln. Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA! Kann nichtmal ein Programm, das die Komplexität eines "Hello World" nur marginal überschreitet, selbst ausführen und Messungen durchführen. Respekt, Respekt, du bist ja ein echter Spezialexperte. Ich hab hier übrigens auch kalte Fusion am Laufen und ein Perpetuum Mobile, aber ich hab jetzt keine Zeit noch Lust die Pläne hochzuladen. Glaub es mir einfach!!!1111elf >> Du wechselst bei deiner Argumentation STÄNDIG das Ziel. Und DEINE >> Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem >> Granatenzündcode und Echtzeitberechnungen von Flugraketen. Ach, kannst >> du nicht, weil das ist alles nur Hörensagen? Messungen hast du nicht? >> Dann ist es nur Geschwurbel. > > Du spinnst, haste mal was von NDA gehört oder kennst Dich im MIL Bereich > aus? Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World auszuführen! Is klar, Münchhausen. >> Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie >> performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl, >> die objektiv belegt ist, auch wenn du mit der Realität nicht so klar kommst. > >> Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware >> gebaut wurde, die das performant interpretiert. Aber auf einem >> "normalen" Target läuft es halt echt Kacke langsam. > > Schmeisst Du hier ständig Interpreter und Compiler durcheinander? > Wenn FORTH fertig mit dem Lesen einer Quelle ist, ist wenige > Maschinenzyklen später auch das Kompilat fertig! Das kommt ja wohl aufs Target an. Du erzeugst Bytecode und der wird interpretiert. Auf einer Maschine, die Bytecode nativ ausführen kann wie dem RTX2000 wird der direkt ausgeführt, aber üblicherweise redet man bei Bytecode von Interpretation. >>> Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz >>> getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem >>> Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und >>> das in den 1980ern. > >> Also deine Behauptung und neuerliche Anekdote ist, dass du eine >> Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist >> schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur >> wärst, der du behauptest zu sein, dann hättest du das auch sofort >> durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware >> implementiert, sonst ist es ja kein Argument für Forth) die Anzahl der >> Instruktionen, um was sinnvolles zu machen durch. > > Ich hab ja nicht gesagt, dass die 2MHz was besonders sinnvolles gemacht > haben. Der RTX2000 führt eine leere Interrupt Service Routine in 400ns > aus. Jeder zusätzliche (Anwendertakt) 100ns. zB. Einen Zähler zu > incrementieren 100ns. In diesen 100ns konnte der bis zu 4 (5?) Befehle > gleichzeitig ausführen. zB. noch an nem Portbit wackeln. Dazu war eben > noch genügend Zeit, um per SIO mit dem Target zu arbeiten. Nix HW, alles > SW! Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist eine 10MHz MCU. Die Interruptlatenzzeit sind vier Zyklen. Das heißt, du hast bei deiner 2 MHz IRQ Frequenz noch genau eine Instruktion übrig, wenn du überhaupt im ISR angekommen bist. Und irgendwann willst du die ISR auch wieder verlassen, da geht deine letzte Instruktion hin. Hör doch endlich auf so dummdreist und durchschaubar rumzulügen. Jede technische Lösung hat Vor- und Nachteile. Gib doch einfach zu, dass FORTH halt nun mal ohne Spezialhardware (Forth im Core) langsam ist, deutlich langsamer sogar manchmal (Faktor 500...) als C. Niemand bei Verstand erwartet etwas anderes. Nur du tust so, als ob Forth die eierlegende Wollmichsau ist. In der Gruppe hier sind quasi nur Ingenieure. Die durchschauen dein Zelotentum ALLE. > Watt nu? Das habe ich gemessen und vorgeführt, kann leicht anhand des > Datenblattes RTX2000 überprüft werden. Wenn man will. Ja, habe ich ja oben überprüft. Bist aufgeflogen. > Das ist eben der Unterschied zwischen Ingenieuren hüstel Bahnhofsnutten > und Physikern :p Ach ne, würde ich gar nicht auf den Unterschied schieben, sondern es gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach Fakten wegignorieren, die ihnen nicht passen. > Und tut mir leid, dass der RTX2000 keinen Assembler als Maschinencode hat. > Nur FORTH :p Er besteht IIRC aus etwas mehr als 4.000 Gattern. Der > Vorläufer NOVIX 4000 hatte daher seinen Namen. Joa das war ja auch meine Aussage. Zitat "irgendwelchen Spezialanwendungen Hardware gebaut wurde, die das performant interpretiert". Nur ist die Welt halt nicht so: Alle modernen Prozessoren sind eben NICHT spezifisch für eine Sprache geschrieben, sondern die ISAs haben sich durchaus weiterentwickelt. Dann hat man halt auch mehr Auswahl an Hardware als nur n Paar obskure Spezialprozessoren. > Ich weis auch nicht, was moderne uC für eine leere IRsrv brauchen. Ist mir > auch egal, die RTX2000 waren ja schon mal ne Hausnummer. > > Noch nen Massenartikel: die Zündschlüssel für viele Autos, besonders > Mercedes, hatten einen MARC 4 (4!!! bit FORTH Processor) von Temic (ex > Telefunken) drin. Nein, MERCEDES hat das nicht besonders geschickt und > vorbildlich implementiert, sitzen auf zu hohem Ross :) > Einer der MIL Wegwerfartikel hatte auch nen MARC4 drin, im Gegensatz zu > den Düsseldorfern, die haben 100 Tausende RTX im Desert Storm verfeuert. > Desterwegen sind die Dinger inzwischen auch sehr rar geworden. > > Waren Granaten, die im Endanflug über kleine Finnen mit Schrittmotoren > (armer Johannes), sowie mit Video und Radar im Kopf gesteuert wurden. > Anfangsbeschleunigung umme 30.000g :o > Und ich glaube nicht, dass das eine langsame Anwendung war :p Oder die > FORTH wegen Lahmheit genommen haben. Ich empfehle dir Paracetamol gegen das Fiber, dann morgen früh gleich zum Arzt. Das könnte was ernstes sein. >> Ja, C Compiler gibt es halt für jedes Target ohne dass man das erst >> Compiler portieren müsste. > > Hab ich irgendwo geschrieben, dass ich für den C166 nicht einen fertigen > Kernel genommen habe? Ich hatte in meinem Ing. Büro die Kernels für 2 > Dutzend verschiedenen CPU Familien im Köcher. Ja alle zugekauft und einen > selber gemacht um das auch mal probiert zu haben. Wieviel C Kerne hast Du > schon geschrieben? Was soll denn ein "C Kern" sein? Hast du auch nur die leisteste Ahnung davon, wie ein moderner Compiler überhaupt funktioniert? Ich habe LLVM mal retargetiert, ja, und der kann dann u.a. C kompilieren. Ist nicht schwierig, wenn man weiß was man macht. Muss man aber i.d.R. nicht, weil es eben für quasi JEDEN Prozessor schon einen C Compiler gibt, und man die weder "zukaufen" muss noch selber machen. > Was hast Du an dem Begriff "erstellen eines Target für eine NEUE CPU" > nicht verstanden? Was hast du denn daran nicht verstanden, dass es für jedes Target schon einen C Compiler gibt, ohne dass man was erstellen muss? Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-17 19:02 -0400 |
| Message-ID | <Es1rrZvjQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261825 |
On 17 Aug 19 at group /de/sci/electronics in article qj9imo$a98$1@news2.open-news-network.org <dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote: > On 17.08.19 13:12, Wolfgang Allinger wrote: >>>> Son gequirlter Quatsch. Im parallelen Posting beschreibe ich zwei Monster >>>> US Prüfanlagen, kannst ja mal die Datenrate nachrechnen... >>>> >>>> Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe. >> >>> LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts >>> entgegenzusetzen hast, hast du das Argument in dem Bereich verloren. >> >> Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das >> nachzugroffeln. > Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA! > Kann nichtmal ein Programm, das die Komplexität eines "Hello World" nur > marginal überschreitet, selbst ausführen und Messungen durchführen. > Respekt, Respekt, du bist ja ein echter Spezialexperte. Dummbatz. > Ich hab hier übrigens auch kalte Fusion am Laufen und ein Perpetuum > Mobile, aber ich hab jetzt keine Zeit noch Lust die Pläne hochzuladen. > Glaub es mir einfach!!!1111elf >>> Du wechselst bei deiner Argumentation STÄNDIG das Ziel. Und DEINE >>> Behauptungen sind krude, dann zeig doch mal Messungen von angeblichem >>> Granatenzündcode und Echtzeitberechnungen von Flugraketen. Ach, kannst >>> du nicht, weil das ist alles nur Hörensagen? Messungen hast du nicht? >>> Dann ist es nur Geschwurbel. >> >> Du spinnst, haste mal was von NDA gehört oder kennst Dich im MIL Bereich >> aus? > Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World > auszuführen! Is klar, Münchhausen. Du idiotisches vielbeiniges Rumpelstilzchen hüpfst ständig auf verschiedenen Beinen rum. Erst faselst Du was, ich solle was über die Proggies in den Granaten veröffentlichen, als ich dann sage, darf ich nicht... wg. NDA sabbelst Du was von Hello World und Geschwurbel? Was bist Du für ein Arschloch! >>> Butter bei die Fische! Zeigen, nicht Labern. Zeig doch mal wie >>> performant das sein kann. Der Faktor 500 ist jetzt schonmal eine Zahl, >>> die objektiv belegt ist, auch wenn du mit der Realität nicht so klar >>> kommst. >> >>> Kann durchaus sein, dass in irgendwelchen Spezialanwendungen Hardware >>> gebaut wurde, die das performant interpretiert. Aber auf einem >>> "normalen" Target läuft es halt echt Kacke langsam. >> >> Schmeisst Du hier ständig Interpreter und Compiler durcheinander? >> Wenn FORTH fertig mit dem Lesen einer Quelle ist, ist wenige >> Maschinenzyklen später auch das Kompilat fertig! > Das kommt ja wohl aufs Target an. Nein, ist Eigenheit von Forth > Du erzeugst Bytecode und der wird > interpretiert. Auf einer Maschine, die Bytecode nativ ausführen kann wie > dem RTX2000 wird der direkt ausgeführt, aber üblicherweise redet man bei > Bytecode von Interpretation. Und Forth hat zwei Interpreter, den inner und den outer interpreter. Der outer ist praktisch die User Schnittstelle und der inner halt für den Ablauf des compilierten Code zuständig. wg. mir kannste das Bytecode nennen, obwohl das bei FORTH noch wal wieder was ganz anderes ist. >>>> Noch ganz zum Schluss: beim RTX2000 hab ich einen IR Eingang mit 2MHz >>>> getriggert und auf einem weiteren mich mich 9600Bd seriell mit dem >>>> Kerlchen unterhalten, ohne das man da was von der Grundlast merkte. und >>>> das in den 1980ern. >> >>> Also deine Behauptung und neuerliche Anekdote ist, dass du eine >>> Interruptfrequenz von 2 MHz in den 80ern so "nebenbei" hattest? Das ist >>> schlicht und ergreifend gelogen und wenn du nur halb der Ingenieur >>> wärst, der du behauptest zu sein, dann hättest du das auch sofort >>> durchschaut. Rechne mal bei einen minimalen ISR (nicht in Hardware >>> implementiert, sonst ist es ja kein Argument für Forth) die Anzahl der >>> Instruktionen, um was sinnvolles zu machen durch. >> >> Ich hab ja nicht gesagt, dass die 2MHz was besonders sinnvolles gemacht >> haben. Der RTX2000 führt eine leere Interrupt Service Routine in 400ns >> aus. Jeder zusätzliche (Anwendertakt) 100ns. zB. Einen Zähler zu >> incrementieren 100ns. In diesen 100ns konnte der bis zu 4 (5?) Befehle >> gleichzeitig ausführen. zB. noch an nem Portbit wackeln. Dazu war eben >> noch genügend Zeit, um per SIO mit dem Target zu arbeiten. Nix HW, alles >> SW! > Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist > eine 10MHz MCU. Die Interruptlatenzzeit sind vier Zyklen. Das heißt, du > hast bei deiner 2 MHz IRQ Frequenz noch genau eine Instruktion übrig, > wenn du überhaupt im ISR angekommen bist. Und irgendwann willst du die > ISR auch wieder verlassen, da geht deine letzte Instruktion hin. Die komplette leere IRsrv dauert mit Aufruf *und* Rückkehr 400ns, dann noch 100ns für bis zu 4(5?) gleichzeitige Befehle reicht um einen Zähler zu incrementieren, zusammen also 500ns. Und dann kannste mit 2MHz - 10Hz (für Dich Erbsenzähler) noch locker mit dem Kernel per COM quasseln. Wenn ich das noch richtig im Kopf habe, macht der RTX den 'RETI' ohne zusätzliche Zeit, hängt mit der Art, wie Forth funzt zusammen. Aber ist 25a her, dass ich das zuletzt gemacht habe. Au, jetzt legste aber dreist zu. Ich les noch ein bischen, aber... > Hör doch endlich auf so dummdreist und durchschaubar rumzulügen. Jede > technische Lösung hat Vor- und Nachteile. Gib doch einfach zu, dass > FORTH halt nun mal ohne Spezialhardware (Forth im Core) langsam ist, > deutlich langsamer sogar manchmal (Faktor 500...) als C. > Niemand bei Verstand erwartet etwas anderes. Nur du tust so, als ob > Forth die eierlegende Wollmichsau ist. In der Gruppe hier sind quasi nur > Ingenieure. Die durchschauen dein Zelotentum ALLE. [...] > Ja, habe ich ja oben überprüft. Bist aufgeflogen. [...] > Ach ne, würde ich gar nicht auf den Unterschied schieben, sondern es > gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach > Fakten wegignorieren, die ihnen nicht passen. [...] > Hardware als nur n Paar obskure Spezialprozessoren. [...] > Ich empfehle dir Paracetamol gegen das Fiber, dann morgen früh gleich > zum Arzt. Das könnte was ernstes sein. >> Was hast Du an dem Begriff "erstellen eines Target für eine NEUE CPU" >> nicht verstanden? > Was hast du denn daran nicht verstanden, dass es für jedes Target schon > einen C Compiler gibt, ohne dass man was erstellen muss? Ach und wer erstellt die 1. Version für ein Target? Egal ob C oder Forth? Bei C wächst das bei Dir wohl von den Bäumen, bei Forth erledigt das eine einzelne Seele in 1-3 Tagen. > Gruß, > Johannes Nochmal ...leck mich und hasta la vista Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-18 08:41 +0200 |
| Message-ID | <qjaruk$csi$1@news2.open-news-network.org> |
| In reply to | #261829 |
On 18.08.19 01:02, Wolfgang Allinger wrote: >>>>> Ich hab da keine Zeit zum zerpflücken Deiner kruden Vorwürfe. >>> >>>> LOL ich habe *gemessen*. Wenn du objektive Zahlen nichts >>>> entgegenzusetzen hast, hast du das Argument in dem Bereich verloren. >>> >>> Keine Ahnung, was Du da mit RC4 gemacht hast, hab weder Zeit noch Lust das >>> nachzugroffeln. > >> Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA! > >> Kann nichtmal ein Programm, das die Komplexität eines "Hello World" nur >> marginal überschreitet, selbst ausführen und Messungen durchführen. >> Respekt, Respekt, du bist ja ein echter Spezialexperte. > > Dummbatz. Ja, dachte ich mir schon. Jetzt wisch dir deine dicken Krokodilstränen aus den Augen und mach dich nicht doch nicht weiter zum Brot. Und die nächste Diskussion, die du vom Zaun brichst, führst du vielleicht mit objektiv belegbaren Fakten, deine Anekdoten und "gefühlten" Werte sind weder interessant noch relevant. Du laberst und laberst und laberst und laberst, aber kriegst es nicht gebacken, ein WINZIGES Programm zu testen und die objektive Messung, dass der Forth-Code Faktor 500 mal langsamer ist, zu entkräften. Stattdessen kriegst du einen cholerischen Fiberanfall und schlägst wild um dich. Du warst bestimmt auch schon immer jemand, der bei "Mensch ärgere dich nicht" mit einem Armwisch das komplette Brett abgeräumt hat, sobald ein eigenes Männchen geschlagen wurde. Und nochmal für dich zusammenfassend: Niemand hat bestritten dass FORTH auf Spezialhardware (z.B. RTX20xx) effizient ausführen kann. Niemand hat bestritten, dass eine Sprache wie FORTH (oder ADA, etc.) für Spezialanwendungen (Raumfahrt/Safety) geeigent sein kann. Niemand hat bestritten, dass es Leute gibt, die RPN hübsch finden oder dass ein interaktiver Interpreter komfortabel zu bedienen ist. Das EINZIGE Argument war, dass FORTH auf einer 08/15 Architektur (z.B. x86_64) eben etwa fünfhundertmal langsamer ist, als C-Code, der dasselbe tut. Und das Argument war dir sogar extensiv belegt worden. Und nichtmal damit kommst du klar und interpretierst jegliche objektive Kritik als persönlichen Angriff. Meine Güte bin ich froh dass ich mit einem so unsachlich argumentierenden, hochnotpeinlichen Choleriker nicht zusammenarbeiten muss. Gute Besserung und alles Liebe, Dein Johannes
[toc] | [prev] | [next] | [standalone]
| From | Ewald Pfau <anderswo@gmx.net> |
|---|---|
| Date | 2019-08-18 07:30 +0000 |
| Message-ID | <grsd5bF4irgU1@mid.individual.net> |
| In reply to | #261832 |
Johannes Bauer <dfnsonfsduifb@gmx.de>: > Du laberst und laberst und laberst und laberst, aber kriegst es nicht > gebacken, ein WINZIGES Programm zu testen und die objektive Messung, > dass der Forth-Code Faktor 500 mal langsamer ist, zu entkräften. Eure Stilfragen beiseite, sei festgehalten, dass die obige Prozedur nicht korrekt ist. Wenn einer die Farbe x als miserabel betrachtet, ein Chamäloeon mit der Farbe x sieht und dann herumposaunt, Chamäleons sind miserabel, dann hat er selbst auch miserablen Stil zelebriert. Wahrscheinlich, weil der Blick nur bis vor die eigenen Fúße reicht. Wenn ich nun selbst nur einen Funken Interesse hätte, was was ich aber nicht habe, daran, was da als GForth im Umlauf ist und offenbar den Ruf schädigt, könnte ich vielleicht auseinanderklauben, was da schiwf gewickelt ist. Diese Maschine bezog ihren Anspruch auf Universalität zuzeiten daraus, dass stets ein C-Compiler irgendwo mitlief, das scheint immer noch so zu sein. Offenbar sehr zu ungunsten der Resultate. Akademische Spielkiste. Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem keine Frames eingerichtet werden müssen. Wenn aber ein anderer Conpiler fúr jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist die Brauchbarkeit ziemlich im Eimer. Ein anderes Forth wäre das Open-Boot, wahrscheinlich auf dem Rechner, auf dem dies hier gelesen wird, und wenn man vom BIOS hochfährt, läuft dort ebendieser Token-basierte Forthdialekt als Maschinenmonitor, für den Zugriff auf den Hardware-Bus und die Devices des Rechners. Aber ach, wenn man ständig Heiuweh nach dem Massenkungeln im Mainstream hat, darf der eigentlich kindlichen Bindung an ein ewiges ozeanisches Wogen gern der Rest der Welt als entweder bedrohlich oder verabscheuungswert vorkommen. Kannma schon. Wenn es nur darum geht, muss man das nicht weiter ernstnehmen.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-18 10:15 +0200 |
| Message-ID | <qjb1ek$gpn$1@news2.open-news-network.org> |
| In reply to | #261834 |
On 18.08.19 09:30, Ewald Pfau wrote:
> Johannes Bauer <dfnsonfsduifb@gmx.de>:
>
>> Du laberst und laberst und laberst und laberst, aber kriegst es nicht
>> gebacken, ein WINZIGES Programm zu testen und die objektive Messung,
>> dass der Forth-Code Faktor 500 mal langsamer ist, zu entkräften.
>
> Eure Stilfragen beiseite, sei festgehalten, dass die obige Prozedur nicht
> korrekt ist.
>
> Wenn einer die Farbe x als miserabel betrachtet, ein Chamäloeon mit der
> Farbe x sieht und dann herumposaunt, Chamäleons sind miserabel, dann hat er
> selbst auch miserablen Stil zelebriert. Wahrscheinlich, weil der Blick nur
> bis vor die eigenen Fúße reicht.
Hmm, naja wie gesagt, wenn es etwas besseres gibt auf FORTH-Seite, dann
würde ich das auch gerne ausprobieren. Kennst du eine Alternative? Ich
kenne mich, wiegesagt da einfach nicht aus. Hätte jetzt auch vermutet,
dass der Overhead schon geringer sein kann (mein Bauchgefühl sagt Faktor
10 langsamer als C), aber der Faktor 500 hat mich schon sehr erschreckt.
Insbesondere weil gforth von Wolfgang selbst als reife Implementierung
bezeichnet wurde hätte ich gedacht, dass das zumindest für so simple
Fälle gut optimiert ist.
Die Beweislast liegt üblicherweise bei demjenigen, der die Behauptung
aufstellt. Wenn der aber keine Aussage machen kann oder will, dann muss
er sich nicht wundern wenn ein Fachfremder Messungen macht, die halt
(aus purem Unwissen heraus) nicht das Optimum herauskitzeln aus der
Implementierung.
> Wenn ich nun selbst nur einen Funken Interesse hätte, was was ich aber nicht
> habe, daran, was da als GForth im Umlauf ist und offenbar den Ruf schädigt,
> könnte ich vielleicht auseinanderklauben, was da schiwf gewickelt ist. Diese
> Maschine bezog ihren Anspruch auf Universalität zuzeiten daraus, dass stets
> ein C-Compiler irgendwo mitlief, das scheint immer noch so zu sein.
> Offenbar sehr zu ungunsten der Resultate. Akademische Spielkiste.
Hmm, verstehe ich nicht. Du meinst die übersetzen von Forth nach C und
von C nach Assembler und führen das dann aus? Aber wäre das dann nicht
nur einmaliger Overhead und würde eben mit längerer Ausführungszeit
vernachlässigbar sein?
> Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem
> keine Frames eingerichtet werden müssen. Wenn aber ein anderer Conpiler fúr
> jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist
> die Brauchbarkeit ziemlich im Eimer.
Das ist ein interessantes Argument, das ich schonmal bei Rafael gehört
habe, aber das sich mir nicht wirklich erschließt. Also konkret gefragt:
Welcher Overhead wird wo gespart? Und gilt das dann nur bei
Unterroutinenaufrufen? Da wird in der Regel bei einem modernen, guten C
Compiler auch kein Stackframe erzeugt, wenn das nicht notwendig ist.
> Ein anderes Forth wäre das Open-Boot, wahrscheinlich auf dem Rechner, auf
> dem dies hier gelesen wird, und wenn man vom BIOS hochfährt, läuft dort
> ebendieser Token-basierte Forthdialekt als Maschinenmonitor, für den Zugriff
> auf den Hardware-Bus und die Devices des Rechners.
Auf dem kann ich aber nicht testen :-)
> Aber ach, wenn man ständig Heiuweh nach dem Massenkungeln im Mainstream hat,
> darf der eigentlich kindlichen Bindung an ein ewiges ozeanisches Wogen gern
> der Rest der Welt als entweder bedrohlich oder verabscheuungswert vorkommen.
>
> Kannma schon. Wenn es nur darum geht, muss man das nicht weiter ernstnehmen.
Hm, ne, darum geht's nicht. Allgemein sind das keine Kategorien
("bedrohlich" etc.) in den ein vernünfigtiger Techniker denken sollte.
Eine Technologie (z.B. Programmiersprache) hat Vorteile und Nachteile.
Es ist gemeinhin klar, dass *alles* ein Kompromiss darstellt.
Entwicklungskosten, Laufzeitkosten, Hardwareabhängigkeit, Verfügbarkeit
der Werkzeuge und Hardware, Gehalt der Ingenieure die man braucht, usw
usf. Das gilt ganz allgemein.
Wenn sich jetzt einer hinstellt und sagt, Technologie X ist in ALLEN
Aspekten der Technologie Y überlegen, dann ist das halt Quatsch und das
ärgert mich. Es kommt halt auf den Anwendungsfall an, was jeweils besser
geeignet ist. Mir sind die Nachteile von C durchaus bewußt, aber ich
nehme sie halt in Kauf, weil ich im Embedded-Bereich meistens eben damit
insgesamt noch am besten fahre.
Viele Grüße,
Johannes
[toc] | [prev] | [next] | [standalone]
| From | Ewald Pfau <anderswo@gmx.net> |
|---|---|
| Date | 2019-08-18 18:43 +0000 |
| Message-ID | <grtkhvFcratU1@mid.individual.net> |
| In reply to | #261835 |
Johannes Bauer <dfnsonfsduifb@gmx.de>: > On 18.08.19 09:30, Ewald Pfau wrote: > Hmm, naja wie gesagt, wenn es etwas besseres gibt auf FORTH-Seite, dann > würde ich das auch gerne ausprobieren. Kennst du eine Alternative? Nun ja, Forth ist eher schon eine Lebensanschauung und der bin ich in weiten Stücken nicht mehr gar so in Treue verknüpft. PHP, die Bash oder awk haben bei Desktopzeugs einfach bessere Karten. Aber zu Zeiten, als ich auch noch die Stringroutinen des awk je nach Bedarf in Forth nachgestellt habe, ging das so, dass der Mensch eben mit seinem Werkzeug zienlich eng verwachsen ist, und es je nach Aufgabe biegt und windet, bis es passt. Hatte über Jahre z.B. Primzahlen rechnen lassen, das ging dann mehr und mehr in Assembler. Man weiß dann, was man tut, und lässt nur den Oberflächenkomfort in Secondaries stehen (also in Forth-Worten, die aus Tokens bestehen). Für die typischen Erwartungen dieser nunmehr anderen Zeiten wird eher der Output eines Compilers konsumiert als wie eine Service-Leistung. Dazu verweise ich denn auf eines der Softwarehäuser für Forth, auf deren Ebene ist das auch eher die Vorstellung von ihrem Zielpublikum, siehe die Rubrik für uCs: https://www.forth.com/embedded/ Payware mit etwas Vorlaufzeit zum Evaluieren und Kennenlernen (und dann gibt es zumindest noch weitere Elaborate, etwa aus Southampton). Dort auf der Seite sind zwei Beispiele für den generierten Assembller-Output von kurzen Routinen, plus die Wirkung des Optimizers. > Ich kenne mich, wiegesagt da einfach nicht aus. Hätte jetzt auch vermutet, > dass der Overhead schon geringer sein kann (mein Bauchgefühl sagt Faktor > 10 langsamer als C), aber der Faktor 500 hat mich schon sehr erschreckt. Derart langsam finde ich das auch inakzeptabel. Hatte einst eine Idee von Langsamkeit, als bei mir ein Forth-Interpreter, mit sehr wenig Assembler innen drin, für einen 8051er, zum ersten Mal lief. Er machte dasselbe wie das Forth für den Desktop daneben, etwa äquivalente Sourcen (aber weit weniger in Assembler, viel mehr in Secondaries) für die Grundlagen. Faktor 500 langsamer - vielleicht, hab's nicht gemessen. Hab mich nur dabei nett amüsiert. Aber auf dem Desktop ist das schon etwas arg daneben. > Hmm, verstehe ich nicht. Du meinst die übersetzen von Forth nach C und > von C nach Assembler und führen das dann aus? Aber wäre das dann nicht > nur einmaliger Overhead und würde eben mit längerer Ausführungszeit > vernachlässigbar sein? Dunkel nebelt durch die Erinnerung ein Modell heran, wo ad hoc je ein Forth-Wort per C zu einer Sammlung von anderen kompiliert wurde, und dann eben brav die Maschine mit zwei Stacks auf der Maschine mit nur einem Stack nachgebildet wurde. Und das verlangt eben die Klimmzüge dafür, wie kommt die Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten, der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der Returnstack ist. Ob das jetzt das Modell von dieser Implementation war, weiß ich nicht mehr, nur, dass hier Klimmzüge anfallen. Diese Klimmzüge sind dann aber komplett low-level ständig im Einsatz, das sind dann lauter leere Kilometer an Prozessorzeit. Eine fette Party für Flaschenhälse. >> Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem >> keine Frames eingerichtet werden müssen. Wenn aber ein anderer Conpiler fúr >> jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist >> die Brauchbarkeit ziemlich im Eimer. > > Das ist ein interessantes Argument, das ich schonmal bei Rafael gehört > habe, aber das sich mir nicht wirklich erschließt. Also konkret gefragt: > Welcher Overhead wird wo gespart? Wollte jetzt nicht die gefinkelten C-Compiler dagegenhalten. Die Optimiererei fängt in Forth beim programmierenden Personal an, das die Übersetzung von Algorithmen in stack-basierte Formulierungen auf die Beine bringt, auf dass möglichst wenig Akrobatik beim Verkehr des Herumschiebens der anonymen Parameter auf dem Stack anfällt. Wenn man das nicht will, schreibt man mit Variablen (oder Local Values) und ist dann der algebraischen Notierung (wie in C usw.) gleich wieder näher. Das macht man spätestens, wenn der Code überfrachtet wird mit den DUP SWAP ROT TUCK OVER usw. Aber das ist auch ein Grund für die Tendenz, kurze Routinen unbedingt zu bevorzugen, da ist der Verkehr auf dem Stack überschaubarer. Also die Denkweise ist ein wenig anders als beim Algebra-fixierten Mainstream. Andersherum, ein paar Variablen, dann werden die Parameter nicht mehr anonym auf dem Stack herumgeschoben, weil dann die Namen im Quelltext stehen. Solange man aber mit dem Stack auskommt, ist vor allem einmal ein Vorteil, dass der Code nach Belieben reentrant ist, es also keine Nebenwirkungen bei dessen Aufruf gibt. Beim expliziten Speichern fällt das weg (außer bei Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf zwischengesichert werden und beim Verlassen wieder restauriert werden muss - aber vielleicht bügeln fixe Forth-Optimierer da auch schon einiges weg, in der Zwischenzeit, nicht mehr geschaut habe solches dann mehr). Wenn man sich mit dem klassischen Modell begnügen kann, dass auch für große Abläufe der Stack als Datenspeicher ausreicht, dann gibt es bei der Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem Rücken bedient werden muss, bevor die Routine direkt dem Zweck entsprechend abläuft. Sie ist dann direkt und ohne Umschweife zur Verfügung, laufzeittechnisch. Der einzige Overhead ist dann das NEXT, das von einem Token zum nächsten weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren, lesen, die gelesene Adresse anspringen. Hierfür ist ein CPU-Register als IP reserviert, sonst wird der Ablauf wieder ineffizient. Landet man bei einer Token-Liste, dann wird der IP gesichert und umgeladen, und gleich mit NEXT wieder in der neuen Liste begonnen, auch das geht flott. Und all dies berührt den Datenstack nicht. Es muss also nur der Laufzeitapparat umgeladen werden, die Daten selbst bleiben transparent in Verfügung. Man kann das dann anders auch sehen: Die klassische Implementation führt ein ziemlich eisernes Regime, wie die Resourcen der CPU zu verbraten sind. Die beiden Stacks als SP, RP, den Instruction Pointer IP plus ein Umladeregister, eventuell dazu Top-Of-Stack in einem Register. Assembler plus Optimierung möchten aber lieber die ganze CPU für sich. Das ist ein Punkt und der nächste dann gleich - Forth wird auf eine CPU hin gestrickt, also von Assembler weg hochgezogen. Diese Denkweise ist auf den Desktops nun aber eher rar geworden, wenn man nicht in Richtung Redmond schaut, wo Intel mit sozusagen einbetonierter 80x86-Historie das Fahrwasser vorgibt. Für uCs hingegen ist das ein gangbares Szenario, eben wie auch für die lowlevel-Umgebung des Open-Boot im BIOS von Desktops. > Und gilt das dann nur bei Unterroutinenaufrufen? Da wird in der Regel bei > einem modernen, guten C Compiler auch kein Stackframe erzeugt, wenn das > nicht notwendig ist. Die Optimierer sind schon hypsch mächtig geworden, ja. Wenn aber für obiges Modell jedes kurze Forthwort ein eigenes C-Kompilat darstellen soll, hat der Optimierer für den Ablauf des Codes, von mehr Distanz betrachtet, eher weniger zu tun. Zuletzt dass ich damit herumgetan hatte (also schon lange nicht mehr), waren bei meinem Leib- und Magen-Werkzeug die Optimierungen Forth-intern, d.h., typische Abfolgen (die nach hunderten zählen), die sich leicht in Assembler darstellen lassen, wurden aufgefunden und zusammengefasst. Und über all dem aber, um das nicht zu vergessen, sitzt die Idee des strikten One-Pass-Compilers. Es ist ja nicht traditionellerweise das Kompilat das Ziel, weswegen ein Quelltet geladen wird, sondern, abstrakter, irgendeine Erledigung von irgendeiner Aufgabe. Da könnte die Bindung an die Eigenart auch störend werden, wenn alles, was geschieht, in mehreren Passagen wiederauftaucht. Man kann sich aber, seit dem ANS/ISO-Modell, mit den Mitteln zur Interpretersteuerung unterwegs gern seinen Mehr-Pass-Compiler stricken. Das gehört zum Chamäleon dazu, ebenso, wie man unterwegs kurz umschalten kann, einen BASIC-Interpreter stricken (bzw. für FORTRAN kam das gelegentlich in Umlauf) und hernach ein Stück algebraische Notation abarbeiten. Diese monokausal gestrickte Denkweise, wozu der Quelltext und wozu der Compiler diene, ist eine gutes Stück zu eng, für das, was man so alles aufführen kann. Hatte das einst in Übung, eben, um per zweimal Laden eines Quelltextes einen reloziierbaren Objektcode zu generieren, als externes Modul gesichert, um es ohne Quelltext ein andermal zu laden. Aber aus der Arbeitsteilung, wie die Werkzeuge nun, wenige Jahrzehnte später, ein Stück anders ineinandergreifen sollen, ist mehr eine Engspursichtweise geworden, so ein Allzweckgerät geht dann in Richtung Exot .. und soll doch vor allem in Sachen Laufzeiten im erträglichen Rahmen mithalten können. Wenn es da herausfällt, ist auch mir das dann zu wenig. Bei vielfach andersartiger Sichtweise muss das Ding ja nicht auf jedes Siegertreppchen, aber mitspielen sollte es schon können. Interessant ist mithin auch, dass man einige zu lösende Fälle um vieles anders anpackt, oder überhaupt erst integrativ erledigen kann, verglichen mit den Mainstream-Werkzeugen - wo manche Art von Lösung rein von der Art her, wie man mit dem Werkzeug umgeht, nicht auf dem Radar aufscheinen wird. Sprich, man hat deutlich mehr Freiheiten, und bezahlt dafür mit entsprechend mehr Disziplin, die zur Bändigung abverlangt wird - und sei es zur Bändigung nur der eigenen Ideen, noch bevor der geplagte Programmierer dann sein Werk beginnen will. Letzteres hat der Mainstream nicht vorgesehen. Die Welt bestehe aus Algorithmen und die schreibe man in Algebra.
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2019-08-18 21:57 +0200 |
| Message-ID | <qjcajd$rpl$1@solani.org> |
| In reply to | #261851 |
Am 18.08.19 um 20:43 schrieb Ewald Pfau: > Johannes Bauer <dfnsonfsduifb@gmx.de>: > Dunkel nebelt durch die Erinnerung ein Modell heran, wo ad hoc je ein > Forth-Wort per C zu einer Sammlung von anderen kompiliert wurde, und dann > eben brav die Maschine mit zwei Stacks auf der Maschine mit nur einem Stack > nachgebildet wurde. Und das verlangt eben die Klimmzüge dafür, wie kommt die > Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten, > der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der > Returnstack ist. Ob das jetzt das Modell von dieser Implementation war, weiß > ich nicht mehr, nur, dass hier Klimmzüge anfallen. > Keine Maschine, die (Rx++) und (--Ry) kann muss an Stacks Mangel leiden. Sagen wir alle nach der PDP-11. > Diese Klimmzüge sind dann aber komplett low-level ständig im Einsatz, das > sind dann lauter leere Kilometer an Prozessorzeit. Eine fette Party für > Flaschenhälse. > > >>> Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem >>> keine Frames eingerichtet werden müssen. Wenn aber ein anderer Conpiler fúr >>> jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist >>> die Brauchbarkeit ziemlich im Eimer. > > Aber das ist auch ein Grund für die Tendenz, kurze Routinen unbedingt zu > bevorzugen, da ist der Verkehr auf dem Stack überschaubarer. Also die > Denkweise ist ein wenig anders als beim Algebra-fixierten Mainstream. > > Andersherum, ein paar Variablen, dann werden die Parameter nicht mehr anonym > auf dem Stack herumgeschoben, weil dann die Namen im Quelltext stehen. > > Solange man aber mit dem Stack auskommt, ist vor allem einmal ein Vorteil, > dass der Code nach Belieben reentrant ist, es also keine Nebenwirkungen bei > dessen Aufruf gibt. Beim expliziten Speichern fällt das weg (außer bei > Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf > zwischengesichert werden und beim Verlassen wieder restauriert werden muss - > aber vielleicht bügeln fixe Forth-Optimierer da auch schon einiges weg, in > der Zwischenzeit, nicht mehr geschaut habe solches dann mehr). > > Wenn man sich mit dem klassischen Modell begnügen kann, dass auch für große > Abläufe der Stack als Datenspeicher ausreicht, dann gibt es bei der > Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem > Rücken bedient werden muss, bevor die Routine direkt dem Zweck entsprechend > abläuft. Sie ist dann direkt und ohne Umschweife zur Verfügung, > laufzeittechnisch. > > Der einzige Overhead ist dann das NEXT, das von einem Token zum nächsten > weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren, > lesen, die gelesene Adresse anspringen. Hierfür ist ein CPU-Register als IP Nein, das war mal relativ schnell zu 6502-Zeiten. Auf heutiger Hardware ist das der direkte Weg zum Untergang. Wenn man alle 5 Maschinen-instruktionen die Pipeline flusht, noch dazu mit unbekanntem Sprungziel, dann bleibt von einem Pentium allenfalls ein 8086 übrig. Und ja, ich mal eine UCSD-Pcode-Maschine für den Z8000 geschrieben und auch eine für Andrew Tannenbaum's Free University Compiler Kit; das war OK für damals. Mit heutiger Hardware ist das sinnlos und völlig folgerichtig ausgestorben. (Und eine 16 bit Stackmaschine in Hardware in HP's dynamischen NMOS, das war eben der Zeitgeist, damals.) Und die 500 Renaming-Register kann man auch wegwerfen, wenn sich das ganze Programm immer nur mit dem TopOfStack und den NextOnStack beschäftigt. Wenn schon ein Cache-Zugriff -zig Takte braucht und ein Hauptspeicherzugriff > 100. Heutige Maschinen brauchen _Überblick_ damit sie mit der Hardware Parallelität herausfischen können. Tunnelsicht auf den TOS bringt einen da nicht weiter. Eine Instruktion pro Takt ist heute nichts mehr wert. > reserviert, sonst wird der Ablauf wieder ineffizient. Landet man bei einer > Token-Liste, dann wird der IP gesichert und umgeladen, und gleich mit NEXT > wieder in der neuen Liste begonnen, auch das geht flott. Und all dies > berührt den Datenstack nicht. Es muss also nur der Laufzeitapparat umgeladen > werden, die Daten selbst bleiben transparent in Verfügung. > > Man kann das dann anders auch sehen: Die klassische Implementation führt ein > ziemlich eisernes Regime, wie die Resourcen der CPU zu verbraten sind. Die > beiden Stacks als SP, RP, den Instruction Pointer IP plus ein > Umladeregister, eventuell dazu Top-Of-Stack in einem Register. > > Assembler plus Optimierung möchten aber lieber die ganze CPU für sich. Das > ist ein Punkt und der nächste dann gleich - Forth wird auf eine CPU hin > gestrickt, also von Assembler weg hochgezogen. Diese Denkweise ist auf den > Desktops nun aber eher rar geworden, wenn man nicht in Richtung Redmond > schaut, wo Intel mit sozusagen einbetonierter 80x86-Historie das Fahrwasser > vorgibt. In aktuellen Intel-CPUs ist von 8086-Historie nichts mehr übrig. Das sind jetzt multiskalare RISCs mit Hunderten von Registern und spekulativer Ausführung. Einzig die Codierung der Instruktionsbündel riecht noch etwas streng nach X86. Das hat aber mit dem, was nach der Decodierung abgearbeit wird, absolut & überhaupt nichts mehr zu tun. Gruß, Gerhard
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-08-18 22:13 +0200 |
| Message-ID | <qjcbh8$94f$1@news.bawue.net> |
| In reply to | #261853 |
On 8/18/19 9:57 PM, Gerhard Hoffmann wrote: > > In aktuellen Intel-CPUs ist von 8086-Historie nichts mehr übrig. Das > sind jetzt multiskalare RISCs mit Hunderten von Registern und > spekulativer Ausführung. Wie Spectre und Meltdown zeigen hat INTeL das mit der spekulativen Ausführung spektakulär verkackt. Zumindest mich wundert seitdem nicht mehr warum sie immer schneller als AMD waren. Wenn man an der Sicherheit spart ist es leichter schneller als die Konkurrenz zu sein. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2019-08-18 23:50 +0200 |
| Message-ID | <qjch7b$vvk$1@solani.org> |
| In reply to | #261854 |
Am 18.08.19 um 22:13 schrieb Gerrit Heitsch: > On 8/18/19 9:57 PM, Gerhard Hoffmann wrote: > >> >> In aktuellen Intel-CPUs ist von 8086-Historie nichts mehr übrig. Das >> sind jetzt multiskalare RISCs mit Hunderten von Registern und >> spekulativer Ausführung. > > Wie Spectre und Meltdown zeigen hat INTeL das mit der spekulativen > Ausführung spektakulär verkackt. Zumindest mich wundert seitdem nicht > mehr warum sie immer schneller als AMD waren. Wenn man an der Sicherheit > spart ist es leichter schneller als die Konkurrenz zu sein. > > Gerrit > Das ist völliger Blödsinn. Wer nichts macht, macht auch keine Fehler. An spekulativer Ausführung führt kein Weg vorbei. Und einige dieser Fehler waren auch im ARM, trotz völlig andere Mikroarchitektur. Intel ist immer gleich der Prügelknabe. Dabei ist der 86 gar nicht so link gewesen, wenn man erst mal eingesehen hat, dass die Segmentregister eine MMU sind und nix mit der CPU zu tun haben. Aber, was hatten die $(ANDEREN) immer so tolle CPUs!!11elf!! Da war der 32032 von National (startete als 16032) super-duper-symmetrisch, sogar Arrays in den Registern. Erstickt an seinen Bugs. Micro-VAX. Hübsch, angenehm, lahm. Die 68000-Familie. Ätsch, der x86 kann kein double-memory-indirekt-deferred. Wir schon. Bis sich dann gezeigt hat, dass es Instruktionen gibt die niemals terminieren, weil immer noch ein page fault / exeption/ wasauchimmer reinpasst. Beim 68060 war Schluss mit lustig. Nicht mehr zu verstehen. Auch nicht richtig schnell, irgendwie. Z8000/Z80000. Kam nie in die Puschen. Transputer. Ich hatte auch mal ein Cluster von 4 Stück. Das habe ich mal jemandem geliehen für'n Supercluster und nie zurückbekommen, war ehrlich gesagt auch nicht mehr sehr dahinter her. Fairchild Clipper. War schon eine 3-Chip-Lösung. Kaputte Cachelines wurden mit dem Laser abgehängt zur Verbesserung der Ausbeute. Ein Programm ein paar Bytes rauf oder runterzuschieben konnte eine enge Schleife beschleunigen oder ganz erschröcklich verlangsamen. Blieb exotisch. IBM Power PC. Ja, hatten wir embedded in einem Virtex. Es gab nie einen Nachfolger von Xilinx, von IBM irgendwie auch nicht. DEC Alpha. Was gab das Tiraden in comp.arch, wie überlegen der war! HP700 / Snakes / KingKobra War schnarch-langsam. Ich hab' noch so ein Teil unter HP-UX in einem Agilent 16702B-Logikanalyzer. War schon damals schlimm. Das HP-Nachfolgedesign haben sie geschaft Intel unterzuschieben. Taugte auch auf Intel's Prozess nix und war dann irgendwie Intel's Fehler. SUN. Ja, die Sonne ist über dem Sparc untergegangen. MIPS. Soll jetzt open source sein. Hat nicht gereicht. Ich fand sie eigentlich ganz angenehm. Ja, der ARM hat's geschafft. Der hatte den Bonus, die wirklich allerletzte Alternative zu sein. Sammelt auch fleißig Komplexität. Und AMD steht im Augenblick ganz gut da. Treuer Intel-Vasall seit dem 8080, abgesehen von dem Seitensprung mit dem Z8000. Vermutlich habe ich den ein oder anderen Intel-Roadkill vergessen. Gruß, Gerhard
[toc] | [prev] | [next] | [standalone]
| From | Andreas Karrer <ak-9a@gmx.ch> |
|---|---|
| Date | 2019-08-19 00:43 +0000 |
| Message-ID | <slrnqljs4t.31fv.ak-9a@chimborazo.ee.ethz.ch> |
| In reply to | #261855 |
* Gerhard Hoffmann <dk4xp@arcor.de>: > DEC Alpha. > Was gab das Tiraden in comp.arch, wie überlegen der war! Der *war* überlegen. Als der Alpha 21064 1992 rauskam - 64 Bit! 200 MHz! - zitterten der Konkurrenz die Knie. Intel machte damals noch 486er, Sun den SuperSPARC, IBM den Power1 für die RS/6000, alle mit max. etwa 50 MHz, und das waren alles 32-Bit-Chips. Ein Doktorand von unserem Institut ging ca. '94 zu Intel und wurde ein, zwei Jahre später einer der Chef-Architekten des ersten IA-64-Chips, Merced. Nach seinen Erzählungen hatten sie damals bei Intel "vor niemandem Angst, ausser vor Alpha". Ein paar Jahre später machte DEC Pleite, Compaq war nicht an Prozessoren interessiert und die Alpha-Ingenieure gingen zu Hunderten zu Intel, HP oder AMD. 1999 meinte der Kollege: "Angst? Wir haben vor keinem mehr Angst". DEC hat sicher viele Fehler gemacht, aber Alpha gehörte nicht dazu. - Andi
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-08-19 07:21 +0200 |
| Message-ID | <qjdbli$hii$1@pi.h5.or.at> |
| In reply to | #261857 |
Andreas Karrer <ak-9a@gmx.ch> wrote:
> DEC hat sicher viele Fehler gemacht, aber Alpha gehörte nicht dazu.
Technisch sicher nicht, in der Vermarktung schon: Man stelle sich
vor, wie es aussehen würde, wenn sie damals die Alpha-Architektur
z.B. an AMD lizensiert hätten.
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <usenet@nerdcraft.de> |
|---|---|
| Date | 2019-08-19 11:02 +0200 |
| Message-ID | <grv6svFmob5U1@mid.individual.net> |
| In reply to | #261859 |
Am 19.08.2019 um 07:21 schrieb Ralph Aichinger: > Andreas Karrer <ak-9a@gmx.ch> wrote: >> DEC hat sicher viele Fehler gemacht, aber Alpha gehörte nicht dazu. > > Technisch sicher nicht, in der Vermarktung schon: Das war das zentrale Problem von DEC - lauter Ingenieure, die Null Ahnung vom Business hatten...
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-19 08:11 -0400 |
| Message-ID | <Es9sWu0UQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261865 |
On 19 Aug 19 at group /de/sci/electronics in article grv6svFmob5U1@mid.individual.net <usenet@nerdcraft.de> (Eric Bruecklmeier) wrote: > Am 19.08.2019 um 07:21 schrieb Ralph Aichinger: >> Andreas Karrer <ak-9a@gmx.ch> wrote: >>> DEC hat sicher viele Fehler gemacht, aber Alpha gehörte nicht dazu. >> >> Technisch sicher nicht, in der Vermarktung schon: > Das war das zentrale Problem von DEC - lauter Ingenieure, die Null > Ahnung vom Business hatten... Und bei DEC war der Kunde König, solange DEC der Kaiser war :( Und weiter: Es gibt 2 Arten der Geheimhaltung: 1. Nichts zu veröffentlichen 2. Alles zu veröffentlichen (DEC) Es verging zu meinen DEC user Tagen, nicht ein Tag, wo ich in den meterlangen AKtenordnern zu PDP11, RSX11M, RT02, RT11, LSI11... DECUS nicht irgendwas gesucht und nicht gefunden habe :( Dafür aber vieles entdeckte, was ich vergangene Woche dringend hätte gebrauchen können. Bin manchesmal von Hürth zum TÜV in Köln (einige Dutzend km) gefahren, dort waren u.a. viele Gurus von DECUS. Internet gabs nicht, und Telefon reichte nicht. Haben uns auch gegenseitig HW und SW (jau, die lustigen Papertape-Rollen) ausgeliehen oder vorgeführt. In vielen Prüfanlagen von uns steckte DEC. Und um wieder OT zu werden :) Mit der berühmten BYTE vom Aug1980(?) kam ich zum 1. Mal in Kontakt zu FORTH. Hatte Mordsprobleme mit einer LSI02(?), RT11, Fremdcontroller für Wechselwinchester und latürnich die Winchester von einem anderen Zulieferer (IOMEGA?). DEC hatte nix kleines, was für Mannlochgängige KKW Anlage ging. Jeder zeigte auf den anderen und ich sass in der Patsche bei dem beliebten Kinderspielchen 'Schweinchen ärgern' oder 'Fang den Hut'. Hab dann vom TÜV nen Lochstreifen mit FigForth ergeiert und dann damit interaktiv die Sache erfolgreich debugged und hatte am Ende eine gute Sammlung von Test 'Worten' in FORTH, die dann von unseren Serviceleuten, als auch von DEC genutzt wurden. IIRC war das eine mistverständliche DEC Doku, die sich auf dem Controller durch eine aufgekratzte Leiterbahn, eine 1n914 und etwas Wrapdraht flicken lies. Hab danach FORTH vergessen bis zu einem grossen Projekt mit zuwenig Manpower, zuviel Rotstiften, Chaotischem oberen Damagement und unglaublich knappen Zeitrahmen...: Herr Allinger, sie sind nicht hier als Abteilungsleiter angestellt, um über Probleme zu berichten, sondern um Lösungen vorzustellen! Das Projekt bekam ich (mit meiner Abt. Für System und SW Entwicklung) aufs Auge gedrückt, nachdem die HW Entwickler mit C in die Scheisse geritten waren und absolut nix lief. Die HW Lieblinge der GL fielen nicht in Ungnade, sondern die blöden Softies waren mal wieder zu dumm und zu faul!! Ich hatte gerade Berichte von Mitch Bradley (SUN) gelesen, wo er berichtete, wie er mit FORTH einen HDD Controller für eine nicht fertige neue CPU (die er einfach mit FORTH emuliert hat) fertiggestellt hatte. Er wurde in den Meetings immer als Spinner belächelt, konnte doch garnicht sein, dass der Controller im Plan lag, wo doch die CPU noch garnicht lauffähig war... Klarer Fall von zuviel Lötdämpfe und vernebeltem Gehirn, der spinnt, der Hardwarenix! Als dann die CPU lief und der Controller samt HDD und Treiber auf Anhieb auch, war grosses Theater im Management. Mitch musste dann tausendmal erklären, wie er das Unmögliche geschafft hat. Er erfand dabei auch gleich das Open-Boot (s.h. ebenda) und von da an gabs Open-Boot auf allen SUN. MB: es ist schlimm, wenn sich keine Sau für Deine Arbeit interessiert und nur über Dich lächelt. Aber noch schlimmer ist es, wenn sich jeder dafür interessiert und Dein Labor dauernd voller Fremder ist :) Später hat Mitch auch Java Entwicklung geleitet, warum der da allerdings auf die 2 Stack Architektur von FORTH verzichtete, ist (mir) unverständlich. Andere Berichte sagten, dass FORTH Programmierer 3-30x produktiver als in allen anderen Programmiersprachen sind. Wenn das stimmte, dann sah ich da meine einzige Chance. Ich erinnerte mich an meine Erfahrungen, hab dann mich und 2 weitere Ings verschworen, es mit FORTH zu probieren. Wenige Tage vor dem Projektstart, war ich mit 3 meiner MA auf einem DEC Seminar über Superprogramming. Ich engagierte Flesch Forth Systeme um uns auf den Pott zu bringen und 3 Wochen zu pampern, bis wir mit dem LMI Forth samt Metacompiler alleine weiter arbeiten konnten. Wir benutzen 3 Mostek Z80 Entwicklungssysteme die an unserer PDP11/34 per CL (20mA 9600Bd) hingen. Ein Flesch Mann war immer zugegen um als wandelndes Lexicon und Bezaubernde Jeannie (ok, Barbara Eden war sexier :) auf Fingerschnipp zu helfen. Ich für die HW, Forth-Kern und IR-Service, der 2. Ing nur für die Anwendungsprogramme und der 3. Ing für die Bediener-Oberfläche. Mitten im Projekt hab ich dann noch von dem zu klein werdenden Z80 auf 64180 umgestellt, die beiden anderen haben nichts bemerkt, ausser dass alles viel schneller lief und deutlich mehr Speicher zur Verfügung stand. Mission accomplished, haben Faktor >10 an Produktivität geschafft und mitten im Projekt auch noch die Pferde gewechselt (z80 -> 64180) Ich war erstaunt, was Wut (auf die GL) an Energien und Motivation (auch bei den anderen Beiden) freisetzen konnte. Aber statt Lob aus der GL kam nur: Siehste, man muss die Softies nur ordentlich treten, dann klappt das auch! Mit der Erfahrung an Produktivität... beschloss ich dann, die Fa. zu verlassen um mein eigenes Ing-Büro. zu machen. Als das die anderen Beiden mitbekamen (und noch ein weiterer), wollten sie mit mir gehen. Ok, wir haben dann eine 4Mann SW-GmbH gegründet und zähneknirschend ordentlich Projekte von dem alten AG mitbekommen. War ne prima Starthilfe. Der einzige Fehler war, dass wir alle 4 gleichberechtige Partner waren. Hab dann nach 5a und einem Firmen 924S :) eingesehen, dass nur Häuptlinge und keine Indianer nicht klappte und dann mein eigenes Ing.Büro gemacht. Hat mich meine Einlage von 20.000DM gekostet und den 924S hat dann einer meiner exPartner weitergefahren (übrinx insgesamt fast problemlose 400Tkm und dann an einen Zahnarzt weiterverkauft) :o Ein jap. Sprichwort sagt: Wer von der Hoffnung lebt, wird wenigstens nicht dick! Hat bei mir gefunzt, nur noch FORTH und embedded HW+SW, ordentlich an Umfang (nicht nur Bankkonto) zugelegt :) und mich und meine Frau und meine Katzen gut 'am Kacken gehalten' (O-Ton, Jürgen von Manger) sowie meine geliebten Transaxle Porsche (weitere 4 von 7 Stück) samt ETW etc. finanziert. Der Rest ist Geschichte und ich nach rund 200 Aufträgen ausgewandert und inzwischen in Rente gegangen. Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <usenet@nerdcraft.de> |
|---|---|
| Date | 2019-08-19 14:44 +0200 |
| Message-ID | <grvjskFpd3cU2@mid.individual.net> |
| In reply to | #261884 |
Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger: > Hat bei mir gefunzt, nur noch FORTH und embedded HW+SW, ordentlich an > Umfang (nicht nur Bankkonto) zugelegt :) und mich und meine Frau und meine > Katzen gut 'am Kacken gehalten' (O-Ton, Jürgen von Manger) sowie meine > geliebten Transaxle Porsche (weitere 4 von 7 Stück) samt ETW etc. > finanziert. > > Der Rest ist Geschichte und ich nach rund 200 Aufträgen ausgewandert und > inzwischen in Rente gegangen. > Es freut mich für Dich, daß Du mit dieser Sprache so erfolgreich warst, ich konnte ihr nie was abgewinnen und RPN finde ich schlichtweg abartig. -- Ich muss nicht kultiviert *aussehen* - ich bin es. Profiklaus in d.r.f.
[toc] | [prev] | [next] | [standalone]
| From | Axel Berger <Spam@Berger-Odenthal.De> |
|---|---|
| Date | 2019-08-19 15:51 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs |
| Message-ID | <5D5AA968.4F0FBC7A@Berger-Odenthal.De> |
| In reply to | #261886 |
Eric Bruecklmeier wrote: > und RPN finde ich schlichtweg abartig. Das war ein Kompromiß, der von den Grenzen der Technik erzwungen wurde, als Taschenrechner selbst für meinen Vater noch zu teuer waren. Ich bin nicht mit HP sondern, für auch noch fast 1000 DM, mit dem TI58 eingestiegen und später einem gebrauchten TI59. Es mag sein, daß man lernen kann, wie eine Maschine zu denken, und sich dann damit wohlfühlt. Ich wollte das nicht. Längere Formeln fehlerfrei vom Papier abzutippen war auch so schon schwer und fehlerträchtig genug. Die polnische Notation selbst, +(3,4) statt 3+4, hat was. -- /¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067 \ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de / \ Mail | -- No unannounced, large, binary attachments, please! --
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <usenet@nerdcraft.de> |
|---|---|
| Date | 2019-08-19 15:56 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs |
| Message-ID | <grvo59FqetsU1@mid.individual.net> |
| In reply to | #261895 |
Am 19.08.2019 um 15:51 schrieb Axel Berger: > Eric Bruecklmeier wrote: >> und RPN finde ich schlichtweg abartig. > > Das war ein Kompromiß, der von den Grenzen der Technik erzwungen wurde, Tja, ich fahre heute auch nicht mehr mit der Kutsche ins Amt. > als Taschenrechner selbst für meinen Vater noch zu teuer waren. Ich bin > nicht mit HP sondern, für auch noch fast 1000 DM, mit dem TI58 > eingestiegen und später einem gebrauchten TI59. Es mag sein, daß man > lernen kann, wie eine Maschine zu denken, und sich dann damit wohlfühlt. > Ich wollte das nicht. ich würde mir das heute freiwillig nicht antun wollen. > Längere Formeln fehlerfrei vom Papier abzutippen > war auch so schon schwer und fehlerträchtig genug. > > Die polnische Notation selbst, +(3,4) statt 3+4, hat was. Stellt sich nur die Frage, was? -- Ich muss nicht kultiviert *aussehen* - ich bin es. Profiklaus in d.r.f.
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2019-08-19 16:40 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs |
| Message-ID | <qjecbr$4tv$1@solani.org> |
| In reply to | #261897 |
On 08/19/2019 15:56, Eric Bruecklmeier wrote: > Am 19.08.2019 um 15:51 schrieb Axel Berger: >> Die polnische Notation selbst, +(3,4) statt 3+4, hat was. > > Stellt sich nur die Frage, was? Einfachheit bei der Implementierung/Algorithmus. Es muß '(3, 4)+' heißen. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz www.schellong.de www.schellong.com www.schellong.biz http://www.schellong.de/c.htm
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | de.sci.electronics
csiph-web