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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-15 17:45 -0400 |
| Subject | FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs |
| Message-ID | <Erur3OZjQoB@allinger-307049.user.uni-berlin> |
## forwarded copy of: EruqxzAUQoB@allinger-307049.user.uni-berlin ## date : 15.08.19 ## newsgroup/archive: de.sci.electronics ## user : all2001@spambog.com (Wolfgang Allinger) Örks, das sollte unter anderem subject raus, neuer Versuch, damit mans wiederfindet :) On 15 Aug 19 at group /de/sci/electronics in article grl5qvFi07iU1@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > Am 15.08.2019 um 13:53 schrieb Wolfgang Allinger: >> FORTH ist METAsprache, Scriptsprache, HLL und ASM, und zwar alles in >> einem, so schnell mein Hirn und Finger wollen. > Hmm, welches FORTH hast Du da (für Skripte...) verwendet? Kannst jedes dafür nehmen, was auf entsprechende Umgebung zugreifen kann. Ich hab z.B. ausführbare Schriftstücke an meine Kunden verschickt, also z.B. startup_4712.src, das System hab ich so eingerichtet, dass es beim Start in einem bestimmten Verzeichnis (START :) nach ner neuen Datei gesucht hat, wenn es die gefunden hat wurde die einfach interpretiert/ compiliert und die Anlage war wieder auf dem neuesten Stand. So konnte man Patches oder Versuche einspielen, so dass der Kunde die Abläufe/Parameter anpassen konnte. Wenn er zB. ne Kalibrierung geändert hatte konnte er damit arbeiten, wenn er wollte, dann einfach "startup_4712.src FSAVE" (kurz für FileSave) tippern und ENTER. Beim nächsten Start war es dann, als wenns immer schon so geplant war. Wenns nix war, dann per Editor, zB. dem im benutzten FORTH eingebauten oder einen externen nehmen und startup_xxxx.src verbasteln. Und warten, bis der eingewiesene Programmierer oder der Allinger ne angepasste exe lieferte. FORTH ist halt ein Interpiler und Compreter :) gleichzeitig. Die Kunden (häufig Maschbauer) waren begeister, wie einfach sie was verfummeln oder probieren konnten. kurzes langatmiges Gesabbel von mir: Beispiel Anfrage: wir ham jetzt 999 Geräte die nach einer besonderen Justierung justiert werden sollen, wie geht das? Ich hab denen dann eine datei geschickt, wo die HLL Definitionen drinstanden. Konnte er dann beim nächsten Start mit der Eingabe Typ999 starten, wenn er wieder ein paar normale Geräte dazwischen fahren wollte, dann eben nur START eingeben bzw. das als letztes Wort in die update_Typ999 reinfrickeln, oder wenns dauerhaft bleiben sollte, dann eben \ (Backslash) START einflicken und darunter die Zeile Typ999 reinschreiben. Falls doch wieder wankelmütig, dann eben das Kommentarwort "\ " vor Start weg und gut wars. Alles was FORTH im Eingabestrom (prompt OK ) liest, wird bei einem <SP> oder EOL als Wort behandelt und im Wörterverzeichnis nachgeschlagen und ausgeführt, wenns nicht gefunden wurde, wurde versucht es als Zahl zu verwursten, wenn ja, dann wurde die Zahl auf den STACK gelegt und weiter geparst, wenn nicht, weil BlaFasel nicht gefunden wurde, kommt ein "Blafasel is undefined" , der STACK wird gelöscht und der Eingabe prompt 'OK ' erscheint wieder für einen neuen Try und Error :) (Mausmelodie tüdel füdel und das war der Forth Outer Interpreter :) Der Outer Interpreter ist einfach die Endlosschleife, die auf Keys wartet. Mit dem einfachen Wort ":" name bla blu blubber ; wird der Compiler eingeschaltet und versucht eine neue Definition 'name' zusammenzubringen, falls der Eingabestrom nur definierte Sachen finden, passiert of(f)ensichtlich nix, bis das Wort ';' den Compiler wieder ausschaltet und die Endlosschleife (Outer Interpreter) wieder einschaltet und auf neue Worte wartet. Sonst kommt halt "blubber" is undefined. Das ist die Colon- Definition, also der HLL Compiler. undefined? Ja stimmt, HIV han ich verjässe, also fix : blubber tüdelfüdel Tschingerrassabum Mausmelodie ; <CR> eintippern und das Problem ist hoffentlich behoben. Dann blubber eintippen und beobachten Was passiert? War nix? Doch lieber : blubber füdel fiep tröt ; <CR> blubber is redifined OK Äh, hüstel, wollemer nit FORGET blubber<CR> OK und alles ist wieder sauber. Ahh ja, und wie ist das kompiliert? Der Compiler setzt ins RAM an die Stelle für den Eintrag name eine Liste mit den Anfängen von füdel fiep tröt rein. Das Wörterbuch zeigt einfach auf den Beginn von name und feddich is die Laube. Und wie läuft dann so ein Proggie ab? Wenn das Wort im Eingabestrom gefunden wurde, hampelt der Inner Interpreter eifach die aktuelle Liste ab. Also eine Liste mit Verweisen auf Listen von Listen... Es wird also solange die Aufgabe vor sich hergeschoben, bis irgendwann in diesem gefädelten Code irgendjemand aufgerufen wird, der weis was damit anzufangen ist und dann zurückkehrt hinter den letzten Aufruf. Kannste Dir also etwa so vorstellen, wie eine Liste mit CALL 1234 CALL 4567 CALL 8134 ... vobei der CALL niht drinsteht, sondern nur die Verweisadresse und der Inner Interpreter macht dann die CALLs. Zack, so einfach ist FORTH. Ein weiteres wichtiges Wortpaar ist CODE ... END-CODE das macht im Prinzip das gleiche wie : ... ; aber eben in Assembler, das ist dann für Kenner und Könner. Der Anwender wird CODE END-CODE kaum brauchen, das mach dann ggf. ich oder ein anderer Kenner. Der Kunde schickt mir nur seine Latte von neuen :- Definitionen und sagt, funzt alles, aber zu langsam, muss 3x schneller ablaufen. Ich frickel dann interaktiv raus, wo wie die Zeit verplempert wird und verbessere das oder schreib das Wort als CODE-Definition. Ist nur ein simples umkodieren, um den Algorithmus brauch ich mich ja nicht zu kümmern, den hat der Kunde ja schon als gut befunden. Macht die Sache unglaublich einfach. Meist sind das nur wenige Stellen, die mit CODE getuned werden müssen. Und zum Test wird halt eine oder mehrere Testschleifen definiert, wo die :- und die CODE- Definition beide mit den gleichen Parametern aufgerufen und die Ergebnisse verglichen werden, wenn abweicht, Schleifenabbruch und weitersuchen, sonst kommt OK und alles ist womöglich schon ok. Wer bisher durchgehalten hat: BRAVO nun kommt das ENDE bald :) Auch sonstige Parameter standen in der Startup Datei zB. Hubweg wurde mit der syntax 12,3 inch als Hubweg festgelegt. Oh heute cm? kein Problem, dann eben 17,3 cm als Hubweg eintippern, wg. mir erst mal zur Probe interaktiv, dann per editor in die Start. Ja alle meine Projekte wurden als META Sprache in den jeweiligen Anwender eigenen Fachsprache geschrieben, wegen mir auch in seiner Landesprache. Ist praktisch Bestandteil von (Vollausbau) FORTH. Genauso wie METAkompiler. Wenn ich die Fachsprache des Kunden kapiert habe, bin ich auch einfacher auf seiner Ebene für Klärungen und ich habe vieles von ihm zu seinem Nutzen gelernt und wir reden weniger aneinander vorbei. WIN-WIN 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. Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket. So genug für heute. May the FORTH be with you! 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] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-16 09:22 +0200 |
| Message-ID | <grn472Fcm4U4@mid.individual.net> |
| In reply to | #261747 |
Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger: > 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. > > Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht > mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket. Für Spectrum, RT-11, RSX-11M und Windows habe ich auch schon Forth Systeme geschrieben, kein Problem. Nur hilft die Mächtigkeit wenig, wenn es um Echtzeit auf einem Mikrocontroller geht, bei dem selbst die primitiven Worte immer einen indirekten Sprung zum nächsten Wort mit sich herumschleppen. Bei einem 8-Bit µC läppert sich der Aufwand für den Sprung oft zu mehr Code als für das Wort selbst zusammen. Deshalb fand ich die native Compiler-Lösung interessant, wie sie ja auch bei Java für µC benutzt wird. Entwickeln kann man dann mit dem Interpiler, und später reinrassigen Maschinencode laufen lassen. Bis dahin unterscheidet sich FORTH kaum von BASIC, was die Laufzeit betrifft. DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-16 22:53 -0400 |
| Message-ID | <EryrW4tjQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261756 |
On 16 Aug 19 at group /de/sci/electronics in article grn472Fcm4U4@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger: >> 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. >> >> Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht >> mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket. > Für Spectrum, RT-11, RSX-11M und Windows habe ich auch schon Forth > Systeme geschrieben, kein Problem. Nur hilft die Mächtigkeit wenig, wenn > es um Echtzeit auf einem Mikrocontroller geht, bei dem selbst die > primitiven Worte immer einen indirekten Sprung zum nächsten Wort mit > sich herumschleppen. Bei einem 8-Bit µC läppert sich der Aufwand für den > Sprung oft zu mehr Code als für das Wort selbst zusammen. Deshalb fand > ich die native Compiler-Lösung interessant, wie sie ja auch bei Java für > µC benutzt wird. Entwickeln kann man dann mit dem Interpiler, und später > reinrassigen Maschinencode laufen lassen. > > Bis dahin unterscheidet sich > FORTH kaum von BASIC, was die Laufzeit betrifft. Nö, IIRC FORTH ist locker Faktor 10 schneller. Ich hab für 8051&Co harte Echtzeit gemacht. Das größte war mal mit 16 RTX2000, von denen jeder 16 8051 ersetzte, also 256 8051 Equivalent für 256 Kanäle. RTX2000 weil ich hatte mich geweigert mehr als 64 8051 gleichzeitig zu hüten. Kann man machen, muss man aber nicht. Die Anlage wurde dann nochmal in 3facher Ausfertigung gebaut, also 768 Kanäle für eine US Rohrprüfanlage ohne rotierende Prüfkammern. Jeder Kanal kam mit 20kHz IFF rein, jeweils 16bit Laufzeit und 8bit Amplitude, latürnich (US) tiefenabhängiger Jitter, desterwegen kamen die IRs irgendwann asynchron in dem bis 20kHz Grundtakt. Und nicht ein einziger IR durfte verschlabbert werden. Prüfdichte 1 Schuss/mm2 bei 1m/s Vorschub. Jeder mm2 in Aussen, Innen, Längs und Querrichtung, Wanddicke, dazu noch über Laufzeiten die Excentrizität und die Ovalität vermessen, latürnich im um Bereich, alle andere wäre langweilig. Die Aussenfehler, bzw. Aussenwandsignale sind besonders üble Gesellen, die kommen schon im abklingenden Sendeimpuls zurück. Nachprüfen war ganz einfach. Nen paar 0,8mm Bohrungen in dem Test-Rohr mit unterschiedlichen Tiefen, Richtungen und wehe man hat eine Bohrung am Ende der Anlage nicht mit Farbpistolen angespritzt und markiert. Der Kunde fands auch nicht lustig, wenn die Compuster mal son ganzes Rohr komplett lackiert haben. Fehlersuche war etwas stressig :) Die Rohre wurden gerne an Rheinmetall geliefert und die mochten absolut keine Farbe auf den Rohren, nur ihr Testrohr musste in der Farbe des Tages Tüpfelchen haben. Überprüfung war auch leicht, vor und nach jeder Schicht/Los wurde das Testrohr aufgelegt, und wehe das Farbmuster hat sich verändert. 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-16 20:55 +0200 |
| Message-ID | <qj6u7q$3mr$1@news2.open-news-network.org> |
| In reply to | #261747 |
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. Viele Grüße, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-16 22:26 +0200 |
| Message-ID | <groi4bFa24sU1@mid.individual.net> |
| In reply to | #261784 |
Am 16.08.2019 um 20:55 schrieb Johannes Bauer: > 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. Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-) Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig aussagekräftig. Daß uncompiliertes FORTH nicht besonders effizient ist, darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren möchtest. Für eine pdp-11 habe ich in 10 Minuten ein Testprogramm für einen Plattencontroller geschrieben und die Problemlösung gefunden. Am PC ist sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung geht. > Wie man damit also irgendwas kritisches hinkriegen soll ist mir völlig > schleierhaft. Faktor 500 ist jenseits von Gut und Böse. Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische Controller Programme verbringen ihre Zeit fast nur mit Warten auf Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der Hardware. So läßt sich z.B. eine Mikrowelle oder ein 3D-Drucker mit einem langsamen 8-Bit Mikrocontroller betreiben, da geht auch mit 500000-facher Rechengeschwindigkeit nicht mehr (Takt:100-1000 + Maschinencode:5-500). Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen hartem low-level und flexiblem Anwendungscode zieht, läßt sich nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen wurde, dann ist ein Crash vorprogrammiert :-( Oft liegt es aber einfach in der Natur der Controller. Was verdammt nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in ein Controlregister schreibt, und was geht möglicherweise an anderer Stelle schief, wenn ich daran etwas ändere. An dieser Stelle hört dann aber auch die Übertragbarkeit von jeglichem Code auf, wenn die Hardware eines anderen Controllers anders funktioniert. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-16 22:47 +0200 |
| Message-ID | <qj74pm$8ki$1@news2.open-news-network.org> |
| In reply to | #261786 |
On 16.08.19 22:26, Hans-Peter Diettrich wrote: > Am 16.08.2019 um 20:55 schrieb Johannes Bauer: > >> 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. > > Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-) Naja, ich kann halt kein Forth. Und das Wikipedia-Beispielprogramm ist das einzige das ich hatte und es ist auch echt Embedded-tauglich. RC4 ist so klein, dass man ihn einfach runterimplementieren kann. Das Problem ist, dass wenn die Forth-Advokaten sich nicht die Mühe machen, Testprogramme zu liefern, die weniger Overhead haben (damit man sehen könnte wie nah man an C rankommt), dass dann halt jemand wie ich (der keine Ahnung von Forth hat) das übernehmen muss. Und dann schaffe ich halt wenigstens harte Zahlen, wo vorher nur rumgewiesel war. Jeder ist herzlich eingeladen neue Zahlen zu liefern, aber diese qualitativen Aussagen gehen mir auf den Keks. > Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht > von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig > aussagekräftig. Würde ich so nicht sagen. Ich habe in µCs, auch auf 8-Bittern schon digitale Signalverarbeitung gemacht, Multiply/Accumulate, Fixpointarithmetik. Da ist RC4 eigentlich gar nicht weit davon entfernt. Und Krypto mach heutzutage jeder IoT-Controller (das sind allerdings hauptsächlich Cortex-M3 und hauptsächlich AES-CCM oder AES-GCM). Wenn die Sprache also für Krypto ungeeignet ist, ist sie für moderne Kommunikation (über unvertraute Kanäle) ebenso ungeeignet. > Daß uncompiliertes FORTH nicht besonders effizient ist, > darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) > FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren > möchtest. Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert, sondern immer interpretiert? Das hatte ich anders verstanden. > Für eine pdp-11 habe ich in 10 Minuten ein Testprogramm für einen > Plattencontroller geschrieben und die Problemlösung gefunden. Am PC ist > sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der > Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar > ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung > geht. Naja, Fehlersuche kann natürlich schwierig sein. Aber die Fälle, die mir sagen wir im letzten Jahr wirklich Kopfzerbrechen gemacht haben, das waren allesamt welche bei denen kein Debugger, kein Interpreter-Commandline oder irgendwas mehr hilft, weil das in der Hardware nebenläufige Probleme (DMA) waren und ich ums verrecken nicht rausgekriegt hab, was das Problem war. Ich glaube Frank Buss hat mir damals geholfen und mich auf den richtigen Trichter gebracht. >> Wie man damit also irgendwas kritisches hinkriegen soll ist mir völlig >> schleierhaft. Faktor 500 ist jenseits von Gut und Böse. > > Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische > Controller Programme verbringen ihre Zeit fast nur mit Warten auf > Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der > Hardware. Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten, nachdem ich den Knopf gedrückt habe, sondern das soll "instantan" passieren. > So läßt sich z.B. eine Mikrowelle Stimmt. > oder ein 3D-Drucker mit > einem langsamen 8-Bit Mikrocontroller betreiben, Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann auch noch durch ordertliches (x16) Microstepping schwieriger gemacht wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf einem lahmen 8-Bitter nicht zu schaffen, würde ich sagen. Auf einem schnellen (16 MHz AVR) eventuell gerade so, wenn du nicht viel anderes machen musst. > Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend > write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen > hartem low-level und flexiblem Anwendungscode zieht, läßt sich > nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack > notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen > wurde, dann ist ein Crash vorprogrammiert :-( Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand linken muss, ne, das muss echt nicht sein. > Oft liegt es aber einfach in der Natur der Controller. Was verdammt > nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in > ein Controlregister schreibt, und was geht möglicherweise an anderer > Stelle schief, wenn ich daran etwas ändere. An dieser Stelle hört dann > aber auch die Übertragbarkeit von jeglichem Code auf, wenn die Hardware > eines anderen Controllers anders funktioniert. Klar, das gilt aber für alle Programmiersprachen gleichermaßen. Viele Grüße, Johannes
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-16 23:34 -0400 |
| Message-ID | <EryrWk8EQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261789 |
On 16 Aug 19 at group /de/sci/electronics in article qj74pm$8ki$1@news2.open-news-network.org <dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote: > On 16.08.19 22:26, Hans-Peter Diettrich wrote: >> Am 16.08.2019 um 20:55 schrieb Johannes Bauer: >> >>> 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. Na immerhin haste innerhalb 1 Stunde Forth schon bedienen können. Erinner Dich, wie lange haste dafür in anderen Spreachen gebraucht? >> Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-) [...] >> Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht >> von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig >> aussagekräftig. [...] >> Daß uncompiliertes FORTH nicht besonders effizient ist, >> darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) >> FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren >> möchtest. Hä? Forth compiliert doch schon während der Eingabe, es gibt keine unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt siehst, ist das Programm kompiliert. Ist nicht wie bei Basic! > Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler > schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert, > sondern immer interpretiert? Das hatte ich anders verstanden. >> Für eine pdp-11 habe ich in 10 Minuten ein Testprogramm für einen >> Plattencontroller geschrieben und die Problemlösung gefunden. Am PC ist >> sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der >> Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar >> ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung >> geht. >> Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend >> write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen >> hartem low-level und flexiblem Anwendungscode zieht, Ja auch in FORTH kann man schlechte Programme schreiben, geht sogar viel schneller. >> läßt sich >> nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack >> notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen >> wurde, dann ist ein Crash vorprogrammiert :-( Nebulös was Du hier beschreibst. Wer an Primitives rumpfuscht ist selber Schuld. Und wer keine klare Trennung zwischen HW und Anwendung hinkriegt, auch. Ich hab mal während einer Entwicklung komplett eine andere CPU samt Motherboard ausgewechselt, ohne dass die 2 anderen Programmierer irgendwas in ihren Anwendungsprogrammen und der Bedieneroberfläche ändern musten oder gar Probleme hatten. Ausser dass das ganze dann viel schneller lief. Ich hab den Kern und die IR angepasst und gut wars. > Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es > keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand > linken muss, ne, das muss echt nicht sein. Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil. >> Oft liegt es aber einfach in der Natur der Controller. Was verdammt >> nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in >> ein Controlregister schreibt, und was geht möglicherweise an anderer >> Stelle schief, wenn ich daran etwas ändere. An dieser Stelle hört dann >> aber auch die Übertragbarkeit von jeglichem Code auf, wenn die Hardware >> eines anderen Controllers anders funktioniert. > Klar, das gilt aber für alle Programmiersprachen gleichermaßen. 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:27 +0200 |
| Message-ID | <qj86oe$4o0$1@news2.open-news-network.org> |
| In reply to | #261795 |
On 17.08.19 05:34, Wolfgang Allinger wrote: > Na immerhin haste innerhalb 1 Stunde Forth schon bedienen können. > Erinner Dich, wie lange haste dafür in anderen Spreachen gebraucht? Es ist eine der längeren Zeiten, die ich gebraucht habe. Python waren vielleicht 5 Minuten, ein "hello world" in C braucht 10. Go waren auch etwa 5 Minuten, das weiß ich noch ganz genau, weil es nicht so lange her ist. Auch wenn du die RPN gut findest, mir stellen sich die Nackenhaare auf und ich finde das grotesk unübersichtlich. >>> Daß uncompiliertes FORTH nicht besonders effizient ist, >>> darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) >>> FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren >>> möchtest. > > Hä? Forth compiliert doch schon während der Eingabe, es gibt keine > unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt > siehst, ist das Programm kompiliert. > > Ist nicht wie bei Basic! Okay, dann hat sogar "kompiliertes" Forth eine Performance-Penalty Faktor 500. Das ist also NOCH übler als Hans-Peter dachte? > Ich hab den Kern und die IR angepasst und gut wars. Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter auf das Target portieren muss. >> Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es >> keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand >> linken muss, ne, das muss echt nicht sein. > > Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil. Ohne Linker ist offenbar 500 Mal besser als mit. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-17 09:23 +0200 |
| Message-ID | <grppjtFhtebU1@mid.individual.net> |
| In reply to | #261796 |
Am 17.08.2019 um 08:27 schrieb Johannes Bauer: >> Ich hab den Kern und die IR angepasst und gut wars. > > Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter > auf das Target portieren muss. Das sind nur 20-50 Worte, die portiert werden müssen, der Rest ist der immer gleiche FORTH Code. Ich habe heute noch den Karteikasten mit den Implementierungen der Worte zu meinem Lieblingsforth. >>> Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es >>> keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand >>> linken muss, ne, das muss echt nicht sein. Bei der Eingabe wird die Definition eines jeden Wortes im Wörterbuch gesucht, und entweder dessen Code ausgeführt oder die Adresse des Codes abgespeichert. Deshalb muß nachträglich nichts mehr gelinkt werden, das ist schon passiert. DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-17 06:17 -0400 |
| Message-ID | <Es1rc8pzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261796 |
On 17 Aug 19 at group /de/sci/electronics in article qj86oe$4o0$1@news2.open-news-network.org <dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote: > On 17.08.19 05:34, Wolfgang Allinger wrote: >> Na immerhin haste innerhalb 1 Stunde Forth schon bedienen können. >> Erinner Dich, wie lange haste dafür in anderen Spreachen gebraucht? > Es ist eine der längeren Zeiten, die ich gebraucht habe. Python waren > vielleicht 5 Minuten, ein "hello world" in C braucht 10. Go waren auch > etwa 5 Minuten, das weiß ich noch ganz genau, weil es nicht so lange her > ist. Hello World dauert in FORTH nur solange, wie man tippen muss :p OK> : Hello ." Hello World, hello Johannes" ; Hello <CR> mit dem <CR> ist es bereits kompiliert und ausgeführt, > Auch wenn du die RPN gut findest, mir stellen sich die Nackenhaare auf > und ich finde das grotesk unübersichtlich. Damit ist klar, dass Du zu denen gehörst, die niemals FORTH kennen und können wirst. Spar Dir die Mühe. >>>> Daß uncompiliertes FORTH nicht besonders effizient ist, >>>> darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) >>>> FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren >>>> möchtest. >> >> Hä? Forth compiliert doch schon während der Eingabe, es gibt keine >> unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt >> siehst, ist das Programm kompiliert. >> >> Ist nicht wie bei Basic! > Okay, dann hat sogar "kompiliertes" Forth eine Performance-Penalty > Faktor 500. Das ist also NOCH übler als Hans-Peter dachte? >> Ich hab den Kern und die IR angepasst und gut wars. > Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter > auf das Target portieren muss. Quatsch mit Sosse, auf neuen Kern anpassen (1-3d Manntage) muss man nur, wenn man FORTH auf einen neuen Processor bringen will und man im Netz keinen passenden Kernel findet. Mach das mal für C... MannMonate/Jahre? Wenn die Engine läuft, kannst Du alle bisher (nicht maschinenspezifische) FORTH Programme laufen lassen, die mit Standard I/O auskommen. Mach das mal in einer anderen Sprache oder versuch mal andere Interpreter auf eine neue CPU zu bringen, oder Dein geliebtes C. Ich kenne nur 2 CPUs, für die es kein FORTH gibt, die eine waren die Ur-PICs, und dann war da noch irgendeine, die ich und die Welt längst vergessen hat. Irgendwas war da mit der Art des Speicherzugriffs (Harvard Ecke?). >>> Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es >>> keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand >>> linken muss, ne, das muss echt nicht sein. >> >> Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil. > Ohne Linker ist offenbar 500 Mal besser als mit. Keine Ahnung wie Du auf diesen blöden Trip kommst. Als grobe Faustformeln: 1. Eine FORTH Anwendung oberhalb des Kernels braucht nur 1/10 des Platzes herkömmlicher Programme. Kleinster Kernel, den ich mal kompiliert hatte, passte in 2kB. Die größten Kernel, die ich kenne sind BigForth und Gforth. Gforth läuft überall, wo es C für gibt. Für WIN32 rund 6MB mit allem Schnätterateng. 2. FORTH Geschwindigkeit liegt auf der Scala ASM = 1 und Basic = 100, etwa bei 10. Mit Gewalt auch weit niedriger, bis an <2, aber dann ist alles in FORTH CODE-definitions umgefrickelt und völlig überflüssig, und alle IR sind auch CODE, was i.a. ebenfalls nicht benötigt wird. Man kann IR durchaus in HLL benutzen, wenn Du eine schnelle CPU oder nicht hyperventilierende IRs hast. Einer meiner Kunden hat seine Z80 und 8051 Systeme in der 100DM Klasse durch 1000DM+ RTX2000 boards ersetzt. Ich hatte Kammerflimmern, als ich das mitbekam... Ruhig Blut, Herr Allinger, mit FORTH auf einem RTX2000 können meine Programmierer, selbst die Anfänger, garnicht so umständlich und unoptimiert schreiben, dass er die Aufgabe nicht in 1-3 Tagen fertig hat. Und die machten da einiges für Steuerung teuerster Werkzeug Maschinen, kein PillePalle. Und wegen Positionierung, Rechenzeit, Komplexheit und Deiner hochgeliebten Schrittmotorsteuerungen: zu meiner Zeit hat KUKA die Roboter mit FORTH gesteuert. Der Greifarm des Space-Shuttle war auch in FORTH programmiert. Diverse Satelitten, Lokomotiven bei BR, Flughäfen (nä, nicht BER) und Shooting Ranges USMC werden auch mit FORTH betrieben. 99% aller FORTH anwendenden Firmen benutzen es als Betriebsgeheimnis, manchmal auch nicht so geheimnisvoll: Johannes (!) Reilhofer Getriebe Prüfstände und Delta- Analysatoren. Alles Nichtskönner? Alle mögen kein RPN? Die 1. Anwendung von FORTH war übrinx die Steuerung von astronomischen Teleskopen. Da mussten die Proggies auf Zuruf von den Astronomen geändert werden. Das höchste Ziel war damals Transportabilität und schnellste Anpassung. Mission acomplished. Für die, die sich ernsthaft für FORTH interessieren und bei RPN nicht kotzen: Forth-ev.de 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:36 +0200 |
| Message-ID | <qj9hf6$9a8$1@news2.open-news-network.org> |
| In reply to | #261818 |
On 17.08.19 12:17, Wolfgang Allinger wrote: >> Es ist eine der längeren Zeiten, die ich gebraucht habe. Python waren >> vielleicht 5 Minuten, ein "hello world" in C braucht 10. Go waren auch >> etwa 5 Minuten, das weiß ich noch ganz genau, weil es nicht so lange her >> ist. > > Hello World dauert in FORTH nur solange, wie man tippen muss :p > > OK> : Hello ." Hello World, hello Johannes" ; Hello <CR> > mit dem <CR> ist es bereits kompiliert und ausgeführt, Ja wie in jeder Skriptsprache halt. Dass du das so besonders findest, wundert mich. >> Auch wenn du die RPN gut findest, mir stellen sich die Nackenhaare auf >> und ich finde das grotesk unübersichtlich. > > Damit ist klar, dass Du zu denen gehörst, die niemals FORTH kennen und > können wirst. > > Spar Dir die Mühe. Ist halt meine persönliche Präferenz, dass ich etwas so hinschreibe wie ich es denke nämlich "eins plus eins" statt "eins eins plus". >> Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter >> auf das Target portieren muss. > > Quatsch mit Sosse, auf neuen Kern anpassen (1-3d Manntage) muss man nur, > wenn man FORTH auf einen neuen Processor bringen will und man im Netz > keinen passenden Kernel findet. Mach das mal für C... MannMonate/Jahre? Ich habe LLVM schon für den 6802 retargetiert. Auch etwa 1-3 Tage, würde ich sagen. Ist überhaupt kein Problem und kann dann, im übrigen, nicht nur C sondern eben auch alle anderen Programmiersprachen, die llvm beherrscht (C++, go, Haskell, Fortran, Rust, Javascript, Ruby, C# um nur einige zu nennen). Hätteste gar nicht gedacht, was? Liegt evtl daran dass 30 Jahre Programmiersprachenentwicklung scheinbar spurlos an dir vorübergegangen sind. > Wenn die Engine läuft, kannst Du alle bisher (nicht maschinenspezifische) > FORTH Programme laufen lassen, die mit Standard I/O auskommen. Mach das > mal in einer anderen Sprache oder versuch mal andere Interpreter auf eine > neue CPU zu bringen, oder Dein geliebtes C. C ist extrem portabel, das gilt aber für alle Sprachen, solange nur den Standard-Sprachumfang verwendest. Ziemlich unglaublich, dass du das nicht verstehst. Ich weiß auch nicht, wie ich's dir noch besser erklären kann. > Ich kenne nur 2 CPUs, für die > es kein FORTH gibt, die eine waren die Ur-PICs, und dann war da noch > irgendeine, die ich und die Welt längst vergessen hat. Irgendwas war da > mit der Art des Speicherzugriffs (Harvard Ecke?). Das ist ja schön für dich. Schreib mal wie viele CPUs, die du kennst, für die es keinen C compiler gibt. >> Ohne Linker ist offenbar 500 Mal besser als mit. > > Keine Ahnung wie Du auf diesen blöden Trip kommst. Der "blöde Trip" ist eine objektive Messung, die du jederzeit nachprüfen oder entkräften könntest. > Als grobe Faustformeln: Nein. Deine groben zusammengelogenen Faustformeln interessiert kein Mensch. Mach Messungen und publiziere Ergebnisse, dein Gelaber ist echt überflüssig. > 1. Eine FORTH Anwendung oberhalb des Kernels braucht nur 1/10 des Platzes > herkömmlicher Programme. Kleinster Kernel, den ich mal kompiliert hatte, > passte in 2kB. So und jetzt belegst du das mal. Compiliere doch mal den RC4 für FORTH und sag wie viel der braucht. Stattdessen schwadronierst du nur rum, kriegst es aber nicht gebacken auch nur EINE belegte Zahl zu nennen. > 2. FORTH Geschwindigkeit liegt auf der Scala ASM = 1 und Basic = 100, etwa > bei 10. Mit Gewalt auch weit niedriger, bis an <2, aber dann ist alles in > FORTH CODE-definitions umgefrickelt und völlig überflüssig, und alle IR > sind auch CODE, was i.a. ebenfalls nicht benötigt wird. Man kann IR > durchaus in HLL benutzen, wenn Du eine schnelle CPU oder nicht > hyperventilierende IRs hast. Noch mehr dahergefibertes Gelaber. Ich habe gemessen: C = 1, Forth = 500. Alles dokumentiert, der Code offen, die Messmethode dazu. Und du kriegst es nicht widerlegt. Komisch, oder? [mehr fibriges Gelaber gesnippt] > Alles Nichtskönner? Alle mögen kein RPN? Ich habe nie behauptet, dass jemand, der Forth verwendet, ein Nichtskönner ist. Das hast du dir zusammengefibert. Ich habe lediglich demonstriert und objektiv belegt, dass Forth deutlich langsamer (Faktor 500 steht im Raum) als der Äquivalente C Code ist. Mehr nicht. Dass ich RPN nicht mag, ist meine Präferenz, über Geschmack will ich nicht streiten. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-17 18:31 -0400 |
| Message-ID | <Es1rrLKzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261824 |
On 17 Aug 19 at group /de/sci/electronics in article qj9hf6$9a8$1@news2.open-news-network.org <dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote: > [mehr fibriges Gelaber gesnippt] > Gruß, > Johannes Hab ein schönes Leben und leck mich... 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 | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-17 09:25 +0200 |
| Message-ID | <grppjtFhtebU2@mid.individual.net> |
| In reply to | #261795 |
Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger: >>> Daß uncompiliertes FORTH nicht besonders effizient ist, >>> darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) >>> FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren >>> möchtest. > > Hä? Forth compiliert doch schon während der Eingabe, es gibt keine > unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt > siehst, ist das Programm kompiliert. > > Ist nicht wie bei Basic! Bei BASIC ist das nicht anders: Eingaben werden in Binärcode (p-code...) übersetzt. Daneben gibt es noch Compiler, die BASIC, JAVA, FORTH usw. in echten Maschinencode übersetzen können. Was bei BASIC allerdings nicht viel bringt, wenn dort ein VARIANT Datentyp verwendet wird - siehe VisualBasic. >> Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler >> schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert, >> sondern immer interpretiert? Das hatte ich anders verstanden. FORTH erlaubt Compilierung bei der Eingabe, was aber nicht Compilierung in Maschinencode bedeutet, und auch nicht unbedingt in anderweitig optimierten Code. Der Programmierer kann aber vorsehen, daß ein Wort im IMMEDIATE Mode (bei der Eingabe) normal abgespeichert wird, aber direkt weiteren FORTH Code erzeugt, wenn es in der abgespeicherten Version aufgerufen wird. Siehe dazu die eckigen Klammern [ und ]. Das wäre dann schon eine weitere Stufe der Compilierung. Daneben gibt es natürlich auch die Erzeugung von Maschinencode, mit Assembler-Einschüben wie in anderen Compilersprachen. Das Schreiben der FORTH-Assembler für meine diversen Mikroprozessoren hat mir viel Spaß gemacht, da man sich dank UPN kaum um irgendwelche spezielle Syntax Gedanken machen muß, der Parser wird ja von FORTH geliefert. >>> läßt sich >>> nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack >>> notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen >>> wurde, dann ist ein Crash vorprogrammiert :-( > > Nebulös was Du hier beschreibst. Schau Dir mal die Stack-Beschreibung an, die zu jedem Wort angegeben sein muß. Wenn daran etwas geändert werden muß, hat das einen ganzen Rattenschwanz von weiteren Änderungen zur Folge. HLL Compiler merken es normalerweise, wenn Parameterlisten geändert werden, bei FORTH ist mir so ein Mechanismus nicht bekannt. > Wer an Primitives rumpfuscht ist selber > Schuld. Und wer keine klare Trennung zwischen HW und Anwendung hinkriegt, > auch. Ich hab mal während einer Entwicklung komplett eine andere CPU samt > Motherboard ausgewechselt, ohne dass die 2 anderen Programmierer irgendwas > in ihren Anwendungsprogrammen und der Bedieneroberfläche ändern musten > oder gar Probleme hatten. Ausser dass das ganze dann viel schneller lief. > > Ich hab den Kern und die IR angepasst und gut wars. Ich habe mir seinerzeit etliche Bibliotheken angeschaut, die ohne umfangreiche Beschreibung schlicht unbrauchbar waren. Möglicherweise gab es so eine Dokumentation, aber wenn die nicht auf den Disketten mitgeliefert wurde, war man in der Zeit vor dem Internet mit dem Quelltext alleine einfach nur aufgeschmissen :-( DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-17 07:53 -0400 |
| Message-ID | <Es1rckIjQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261799 |
On 17 Aug 19 at group /de/sci/electronics in article grppjtFhtebU2@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:
> Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger:
>>>> Daß uncompiliertes FORTH nicht besonders effizient ist,
>>>> darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded)
>>>> FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren
>>>> möchtest.
>>
>> Hä? Forth compiliert doch schon während der Eingabe, es gibt keine
>> unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt
>> siehst, ist das Programm kompiliert.
>>
>> Ist nicht wie bei Basic!
> Bei BASIC ist das nicht anders: Eingaben werden in Binärcode (p-code...)
Nein, BASIC interpretiert immer wieder, erst ein BASCOM setzt das als (p-
code) um, aber dann ist die Interaktivität futsch!
> übersetzt. Daneben gibt es noch Compiler, die BASIC, JAVA, FORTH usw. in
> echten Maschinencode übersetzen können.
Bei FORTH die sog. META Compiler.
> Was bei BASIC allerdings nicht
> viel bringt, wenn dort ein VARIANT Datentyp verwendet wird - siehe
> VisualBasic.
>>> Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
>>> schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
>>> sondern immer interpretiert? Das hatte ich anders verstanden.
> FORTH erlaubt Compilierung bei der Eingabe, was aber nicht Compilierung
> in Maschinencode bedeutet, und auch nicht unbedingt in anderweitig
> optimierten Code.
Das eine sind die COLON (HLL) Definitionen, das andere die CODE (ASM)
Teile.
>
> Der Programmierer kann aber vorsehen, daß ein Wort im
> IMMEDIATE Mode (bei der Eingabe) normal abgespeichert wird, aber direkt
> weiteren FORTH Code erzeugt, wenn es in der abgespeicherten Version
> aufgerufen wird. Siehe dazu die eckigen Klammern [ und ]. Das wäre dann
> schon eine weitere Stufe der Compilierung. Daneben gibt es natürlich
> auch die Erzeugung von Maschinencode, mit Assembler-Einschüben wie in
> anderen Compilersprachen. Das Schreiben der FORTH-Assembler für meine
> diversen Mikroprozessoren hat mir viel Spaß gemacht, da man sich dank
> UPN kaum um irgendwelche spezielle Syntax Gedanken machen muß, der
> Parser wird ja von FORTH geliefert.
So isset, ein Beispiel, u.a. mit IMMEDIATE unten dran gepappt.
Und wem das nicht reicht, es gibt auch noch CREATE DOES> , was
Unterschiede zur Compile und zur Laufzeit macht. Hab ich u.a. gerne
genommen um IR Vectoren aufzusetzen oder etwas ähnliches für mein 'Micker-
Forth' für den 8031 zu machen. BTW auch die berühmten ARRAY Definitionen
sind elegant mit CREATE DOES> .
>>>> läßt sich
>>>> nachträglich kaum noch was ändern. Wenn z.B. eine Änderung am Stack
>>>> notwendig wird, und beim Update nur eine Verwendung des Wortes übersehen
>>>> wurde, dann ist ein Crash vorprogrammiert :-(
>>
>> Nebulös was Du hier beschreibst.
> Schau Dir mal die Stack-Beschreibung an, die zu jedem Wort angegeben
> sein muß. Wenn daran etwas geändert werden muß, hat das einen ganzen
> Rattenschwanz von weiteren Änderungen zur Folge. HLL Compiler merken es
> normalerweise, wenn Parameterlisten geändert werden, bei FORTH ist mir
> so ein Mechanismus nicht bekannt.
Hab nie erlebt, dass man an einer Stack Reihenfolge was ändern musste.
Kann mir auch keinen Reim drauf machen.
Wenn irgendwer halt ne andere Reihenfolge oder Menge braucht, soll er hat
ein neues Wort definieren, dann crasht nix.
Doof ist allerdings, wer die Warnung "... is redifined" in den Wind
schlägt. Aber wers braucht, kanns haben.
Dummrumpatchen im Kernel geht auch äusserst einfach, der Erfolg ist meist
sofort sichtbar.
> Ich habe mir seinerzeit etliche Bibliotheken angeschaut, die ohne
> umfangreiche Beschreibung schlicht unbrauchbar waren. Möglicherweise gab
> es so eine Dokumentation, aber wenn die nicht auf den Disketten
> mitgeliefert wurde, war man in der Zeit vor dem Internet mit dem
> Quelltext alleine einfach nur aufgeschmissen :-(
Ich hab nie behauptet, dass alle FORTH Programme oder Programmierer gut
waren. Im Gegenteil, auch Stümper konnten Programme zum laufen bringen
Hier mal ein Beispiel für (m)ein IMHO gut dokumentiertes Proggie:
Das ganze Vorgeplänkel dient u.a. der Guten Dokumentation,
Das Dicke Ende, also das interessanteste ist der Abschluss
mit "Feueralarm_bearbeiten", siehe ziemlich letzter Abschnitt.
Ich hoffe, ich habe alle Ümläüte korrekt erwischt und korrodiert :)
----x8---
\ FEUER Demo FEUERMELDER Anwendung ALL 11:26 14MAY93
\ Last changed screen # 000 ALL 11:26 14MAY93
\ (C) 1993 by Dipl.-Ing. Wolfgang Allinger 'ALL0593'
\ c/o Ingenieurbuero Allinger
\ Brander Weg 6 Tel/FAX: (+49)+212/66811
\ D-42699 Solingen Germany
\ noncommercial use granted !!!
\ Diese lauffähige Demo zeigt, wie eine anwenderfreundliche,
\ selbstdokumentierende Sprache am Beispiel eines FEUERMELDER
\ aussieht. Hinweis: alles in "( )" und nach "\" ist Kommentar.
\ ":" ... ";" sind neue Definitionen.
\ "Feueralarm?" und "Feueralarm_bearbeiten" sind 2!! Programme.
\ Diese Demo belegt weniger als 700 byte Programmspeicher und
\ läuft praktisch auf beliebigen Rechnern ohne Änderung.
\ HISTORY MASTER LOAD SCREEN ALL 11:19 14MAY93
DECIMAL \ default base
000 CONSTANT $VFEUER \ Version Kontrolle
: -FEUER FORGET $VFEUER ; \ entfernt dieses Programm wieder
2 ?SCREENS THRU \ 1 LOAD l"dt dann die Anwendungsbl"cke
\ bei SEQ file system auskommentieren !
\ ALL0593 v0.00 first release
\ .VFEUER ... constants ... USER Interface ALL 10:16 14MAY93
: .VFEUER $VFEUER CR . ; \ zeige Versionsnr.
-1 CONSTANT ja
\ Bereich Meldung .. alle für die jeweilige Umgebung anpassen
VARIABLE Meldung \ bits gesetzt wenns qualmt, n. Zeile setzt
5 Meldung ! \ zB: bit0 = Melder1, bit2 = Melder3
: Melder@ ( a -- u ) @ ; \ liefert Datum aus Adresse
Meldung CONSTANT Melder0 \ liefert Adresse der 1. Meldung
: Rauch ; \ evtl eine Maske.. für geräuchertes
16 CONSTANT bits/Meldung \ zB 16bit oder was auch immer
16 CONSTANT alle \ Anzahl Melder
\ Rauchmelder anwählen abfragen entdeckt? ALL 11:15 14MAY93
VARIABLE Rauchmelder \ 1 ... n
: anwählen ( d a -- ) NIP ( n 0 a -- n a ) ! ;
: abfragen ( a -- uMASKE uDATA )
@ 1- bits/Meldung /MOD ( -- rem qot )
Melder0 + Melder@ ( -- rem uDATA )
1 ROT ( -- uDATA 1 rem )
SHIFT ( -- uDATA uMASKE ) \ rem -> MASKE
SWAP ; ( -- uMASKE uDATA )
: entdeckt? ( uMASKE uDATA -- t=RAUCH) AND 0> ;
\ Feueralarm melden nächsten abgefragt? ALL 11:15 14MAY93
: Feueralarm ( -- ^string nMelder )
" Rauch an Melder Nr.: " ( -- ^string )
Rauchmelder @ ;
: melden ( ^string n -- ) CR SWAP COUNT TYPE . 7 EMIT ;
: nächsten ( -- d ) Rauchmelder @ 1+ 0 ;
: abgefragt? ( n a -- ? ) @ 1- <= ;
\ Feueralarm? ALL 11:02 14MAY93
: Feueralarm? 1. Rauchmelder anwählen
BEGIN
Rauchmelder abfragen
Rauch entdeckt? IF Feueralarm melden THEN
nächsten Rauchmelder anwählen
alle Rauchmelder abgefragt?
ja = UNTIL ;
\ Schlüsselworte GROSS, damits wenigstens noch ein bischen wie
\ Programm aussieht und nicht gleich von jedem verstanden wird!
\ Das ist gemein, aber es kommt noch besser!
\ Der GROSSEN Worte ist genug gewechselt, es folgen Taten!
\ Ab hier wirds gefährlich für Computer-Freaks ALL 11:01 14MAY93
\ Ein paar harmlose(?) Definitionen.. Vorsichtig anschleichen..
: abfragen. abfragen ; : anwählen, anwählen ;
: Falls ; : melden. melden ;
: dann ja = ;
: beginne [COMPILE] BEGIN ; IMMEDIATE
: aufhören [COMPILE] UNTIL ; IMMEDIATE
: ja, [COMPILE] IF ; IMMEDIATE
: Den [COMPILE] THEN ; IMMEDIATE
\ WARNUNG! Gleich haut's Sie möglicherweise vom Schemel,
\ denn nun kommt FORTH rücksichtslos mit seiner ganzen Kraft!!
\ Lassen Sie das nachfolgende bloß nicht Ihren Chef sehen!
\ Nicht weiterlesen, es könnte ein Weltbild zusammenbrechen!!!
\ Feueralarm_bearbeiten ist nun total einfach ALL 11:16 14MAY93
: Feueralarm_bearbeiten 1. Rauchmelder anwählen,
beginne
Rauchmelder abfragen.
Rauch entdeckt? Falls ja, Feueralarm melden.
Den nächsten Rauchmelder anwählen,
alle Rauchmelder abgefragt?
dann aufhören ;
\ Das soll ein Programm sein? Das versteht kein Programmierer!
\ Lieber (*(void(*)())0)() das ist doch wenigstens KERNIGhan.
\ ABER NICHT FÜR MICH und meine Kunden!!!
Feueralarm_bearbeiten \ und so einfach noch sofort zu starten!
\ Aufkleber am Heck: "TSCHÜSS C..."
---x8---
Zum Abschluss:
Ich hab vor einiger Zeit mal ein Info Paket für einen Interessenten hier
zusammengestellt, leider hat der sich das dann wohl nicht angeguckt.
Damit meine Liebesmüh nicht ganz vergeblich ist, wer es auch haben will,
kurze email und ich schicke den Kram.
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 | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-17 19:15 +0200 |
| Message-ID | <grqr23FoufcU1@mid.individual.net> |
| In reply to | #261819 |
Am 17.08.2019 um 13:53 schrieb Wolfgang Allinger: > > On 17 Aug 19 at group /de/sci/electronics in article grppjtFhtebU2@mid.individual.net > <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > >> Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger: > >>>>> Daß uncompiliertes FORTH nicht besonders effizient ist, >>>>> darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded) >>>>> FORTH Gruppe, wenn Du etwas über professionelle Anwendungen erfahren >>>>> möchtest. >>> >>> Hä? Forth compiliert doch schon während der Eingabe, es gibt keine >>> unkompilierten Programme, wenn das Forth läuft. Wenn Du den OK Prompt >>> siehst, ist das Programm kompiliert. >>> >>> Ist nicht wie bei Basic! > >> Bei BASIC ist das nicht anders: Eingaben werden in Binärcode (p-code...) > > Nein, BASIC interpretiert immer wieder, erst ein BASCOM setzt das als (p- > code) um, aber dann ist die Interaktivität futsch! Mit solchen "Experten" möchte ich nicht weiter über Programmiersysteme diskutieren :-( DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-17 09:44 +0200 |
| Message-ID | <grppjtFhtebU3@mid.individual.net> |
| In reply to | #261789 |
Am 16.08.2019 um 22:47 schrieb Johannes Bauer: > On 16.08.19 22:26, Hans-Peter Diettrich wrote: >> Numbercrunching ist wirklich nicht die Domäne von FORTH, und auch nicht >> von Mikrocontrollern. So ein Vergleich von Äpfeln und Birnen ist wenig >> aussagekräftig. > > Würde ich so nicht sagen. Ich habe in µCs, auch auf 8-Bittern schon > digitale Signalverarbeitung gemacht, Multiply/Accumulate, > Fixpointarithmetik. Da ist RC4 eigentlich gar nicht weit davon entfernt. Da war die Arithmetik aber sicher nicht mit den FORTH Primitives implementiert. Wenn schon die Grundrechenarten wegen der Fädeltechnik ein Vielfaches an Rechenzeit gegenüber Maschinencode kosten, kann man von darauf aufbauender Fädelei keine bessere Performance erwarten. >>> Wie man damit also irgendwas kritisches hinkriegen soll ist mir völlig >>> schleierhaft. Faktor 500 ist jenseits von Gut und Böse. >> >> Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische >> Controller Programme verbringen ihre Zeit fast nur mit Warten auf >> Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der >> Hardware. > > Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten, > nachdem ich den Knopf gedrückt habe, sondern das soll "instantan" passieren. HMI? Schlechtes Beispiel, wenn das Entprellen eines Knopfes schon 10-20ms kostet, egal wie schnell der Prozessor oder die Programmiersprache ist. Und auf Interrupts kann man auch in FORTH direkt reagieren, wieso nicht? >> So läßt sich z.B. eine Mikrowelle > > Stimmt. > >> oder ein 3D-Drucker mit >> einem langsamen 8-Bit Mikrocontroller betreiben, > > Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann > auch noch durch ordertliches (x16) Microstepping schwieriger gemacht > wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf > einem lahmen 8-Bitter nicht zu schaffen, würde ich sagen. Auf einem > schnellen (16 MHz AVR) eventuell gerade so, 16MHz *ist* für mich langsam. > wenn du nicht viel anderes machen musst. Mehr muß man beim Drucken auch nicht. Geht Microstepping überhaupt vernünftig in Software, bzw. warum sollte man das so machen? Motortreiber braucht man sowieso, und die gibt es passend mit Microstepping, Strombegrenzung etc. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-17 10:41 +0200 |
| Message-ID | <qj8ejk$ajj$1@news2.open-news-network.org> |
| In reply to | #261800 |
On 17.08.19 09:44, Hans-Peter Diettrich wrote: >> Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten, >> nachdem ich den Knopf gedrückt habe, sondern das soll "instantan" >> passieren. > > HMI? > > Schlechtes Beispiel, wenn das Entprellen eines Knopfes schon 10-20ms > kostet, egal wie schnell der Prozessor oder die Programmiersprache ist. > Und auf Interrupts kann man auch in FORTH direkt reagieren, wieso nicht? Ist eben genau ein gutes Beispiel: Das Entprellen dauert schon die meiste Zeit, die ist schon mal von der Reaktion fix weg. Da würde ich auch schon eher 50-75ms ansetzen. Und dann willst du dem Benutzer *sofort* signalisieren, was passiert ist. Wenn du da ein LCD oder sowas dran hast, das bissl mehr braucht als nur GPIO LED an/aus, dann merkst du das sehrwohl. Und es gibt genug Implementierungen die da extrem träge/ätzend sind. >>> So läßt sich z.B. eine Mikrowelle >> >> Stimmt. >> >>> oder ein 3D-Drucker mit >>> einem langsamen 8-Bit Mikrocontroller betreiben, >> >> Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann >> auch noch durch ordertliches (x16) Microstepping schwieriger gemacht >> wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf >> einem lahmen 8-Bitter nicht zu schaffen, würde ich sagen. Auf einem >> schnellen (16 MHz AVR) eventuell gerade so, > > 16MHz *ist* für mich langsam. Das ist aber verwöhnt. Würde 32 kHz als extrem langsam, 1 MHz als langsam, 16 MHz als schnell und 48 MHz als superschnell bezeichnen. >> wenn du nicht viel anderes machen musst. > > Mehr muß man beim Drucken auch nicht. > > Geht Microstepping überhaupt vernünftig in Software, bzw. warum sollte > man das so machen? Motortreiber braucht man sowieso, und die gibt es > passend mit Microstepping, Strombegrenzung etc. Motortreiber mit Microstepping machen aber halt nur das, was der Name vermuten lässt: Den Motor mit Microstepping *treiben*. Steppen musst du schon noch selber und bei Microstepping eben genau 16x so oft für dieselbe Geschwindigkeit. Da brauchst du also einen µC, der die Steps generiert (und die eben auch entsprechend des Gewindigkeitsprofils) und dann den Treiber zusätzlich, das ist kein Ersatz. Beim 3D-Drucker macht das sicher ein µC. Es gibt dann heutzutage immer öfter recht teuer verkauft sogenannte Closed-Loop Stepper, die nehmen dir das ab (da ist quasi ein µC + Treiber mit angeflanscht direkt an den Stepper und der nimmt z.B. via RS232 Kommandos entgegen, die ihn wie einen Servo aussehen lassen). Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Ewald Pfau <anderswo@gmx.net> |
|---|---|
| Date | 2019-08-17 08:34 +0000 |
| Message-ID | <grpsh8FihabU1@mid.individual.net> |
| In reply to | #261789 |
Johannes Bauer <dfnsonfsduifb@gmx.de>: > Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler > schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert, > sondern immer interpretiert? Das hatte ich anders verstanden. Interpretiert wird in mehreren Schichten. Der äußere Interpreter hat seit ANS/ISO-Forth vier definierte Dauerschleifen dafür, als letzter Fallback dann das QUIT (das heißt so), das als Dauerschleife von der Tastatur entgegennimmt, im Fehlerfall ein Standard-THROW exekutiert, als ABORT, womit alle Schachtelungen aufgehoben werden und der Text-Interpreter wieder neu beginnt. INCLUDED nimmt Text aus einer zeilenorientierten Datei entgegen. THRU macht dasselbe mit dem Block-Mechanismus, der überlebt hat, um Massenspeicher festverdrahtet in 1k-Blöcken durchnumeriert ansprechen zu können. Und dann, äh (hab schon länger nichts mehr damit gemacht), nochmal dasselbe mit einer Zeile, die als String-Parameter gegeben wird. Soweit der äußere Interpreter. Eine Schicht darunter wird man eher von Code reden, da nicht mehr Textfolgen abgearbeitet werden, sondern kompilierte Folgen im Speicher. Dass dennoch das Wort Interpreter ins Spiel kommt, liegt daran, dass die Modelle, wie kompiliert wurde, transparent mitgeteilt werden können. Bzw. war das Sitte zu der Zeit etwa bis MItte der 1990er, dem kundigen Nutzer das mitzuteilen, wie die Schacthelung von Code im Speicher organisiert ist. Nunmehr ist der kundige Nutzer auch nurmehr ein braver Konsument und fragt nicht mehr nach so etwas, bzw. ist eher irritiert. Aber gut, die Vokabel P-Code war über den Forth-Horizont hinaus geläufig, die das korrespondiert, dass der Code aus einer Abfolge von Tokens besteht. Und die Tokens, wenn sie zur Abarbeitung angesprungen werden, sind dann wiederum Abfolgen von Tokens. Erst die unterste Schicht von Tokens sind dann in Assembler kodiert. Noch in den Forth-79 und -83 wurde das fein kultiviert, mitzuteilen, auf welche Art die Tokens angesprungen wurden. Im kompaktesten Fall besteht selbst noch der Beginn eines Tokens aus einem Verweis auf ein Token, dem die Kette der folgenden Tokens mitgeteilt wird, und startet den Mechanismus des Schachtelns und Weiterschaltens (typischerweise ein kleines Code-Schnipsel, mit dem Namen NEXT). Das ist die kompakteste und dann auch zugleich langsamste Form, wie der Code repräsentiert und zum Laufen gebracht werden kann. Wenn man die Hardware-Architektur vor sich hat, wo der letztliche Assmember strikt Read-Only ist, und man aber ad hoc dazukompilieren will können, dann ist das zugleich die einzige Möglichkeit, eine etwas universellere Maschine zu implementieren. Die kann dann, mit ein wenig Forth-Assembler-Code im ROM, rein vom RAM laufen. Die macht dann zwar alles. Und braucht dann aber viel Geduld. Für uCs ist das eher eine akademische Übung. Oder der Teil von Entwicklerei, wo eben das minimale Forth-Assembler im ROM als Maschinen-Monitor dient, mittels dem per ad hoc dazukompilierten Routinen die Maschine auf ihr Befinden hin abfragt werden kann. Das geht dann ohne Emulatoren, weil man von einem sehr frühen Stadium weg am Objekt selbst modellieren kann, ohne dass man eine Emulation o.ä. braucht. Wenn der Zeittakt der Umgebung aber eher in Sekunden misst, ohne Milli oder Mikro, dann braucht es keinen weiteren Luxus zur Beschleunigung. Die wenigen Softwarehäuser, die es für Forth gibt, unterstützen dieses Modell aber kaum mehr. Dort ist Emulation angesagt, und erweitert wird für die kleinen Prozessoren dann im emulierten ROM per Assembler-kompiliertem Forth. Letzteres ist dan schon die dritte Variante des Interpretierens von Assembler-Code auf Maschinenebene, indem eben der Compiler alles, was im Compiler-Modus anfällt, als Kette von Assembler-Code ablegt. Je nach Grad der Optimierungen die man sich antut, wird dann jedes Stück Code, das ein Token hätte sein können, nun aber in Assembler dasteht, mehr oder weniger schlau mit dem Code zuvor und danach verkettet. Es muss ja weiterhin die Kompatibilität aufrecht bleiben wie von diesem Code aus tiefere Ebenen der Verschachtelung erreicht werden. Die zweite Zwischenvariante für den Address-Interpreter, mit dem Code abgearbeitet wird, statt Flließtext, besteht darin, dass er Beginn eines Tokens nicht selbst wiederum einen Zeiger auf das Token verweist, mit dem Verschachtelung und Weiterschalten im Code organisiert ist, sondern diese kleine Standard-Routine steht dann in Assembler zu Beginn von jedem Token. Das erste war also die indirekt gefädelte (threaded) Variante, das zweite die direkt gefädelte und das dritte der Inline-Code. Und über allem thront dann das Hirnschmalz, das in Optimierungen gesteckt wird. Oder auch nicht. Aus letzterem wird zwar auch eine lustige Maschine, aber viel machen kann man damit nicht wirklich, oder nur bei ausnehmend gemütlichen Anwendungen. *** > Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es > keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand > linken muss, ne, das muss echt nicht sein. Zum einen: In Forth wird er flinke Turnaround unterstützt, um Bottom-Up sekundenschnell austesten, ändern wieder testen, usw. zu können. Zugleich wird angenommen dass jemand der mit dieser Maschine arbeitet, genug Selbstdisziplin mitbringt, dass er sich nicht ständig selbst Fallen stellt. Man baut also eher ein Gerüst aus gut belastbaren weil ausgetesteten Routinen auf, und deren Schnittstellen sollten dann doch wohl auch weiterhin stabil bleiben. Wer dann nachher an den Schnittstellen herumdreht, bzw. das dann nicht im Griff hat, wenn er es trotzden macht, dem ist dann wohl nicht zu helfen. Es gibt da keinen reichen Onkel, als wie ein solcher sich die Riesenkompiler des Mainstream darstellen. Wenn man etwas ad hoc überprüft wissen will, muss man das selber einbauen. Dafür geht das dann leicht und locker dahin. Darüberhinaus: Indem die meiste Zeit der Blick auf den Text-Interpreter im Vordergrund stand, hat sich für Forth die Kultur des Austauschs von kompiliertem Code nicht entwickelt. Das ist keine Frage des Systems sondern der Historie. Man kann das auch in Fortg einbauen, dass es kompilierten Code als Schnipsel nachlädt. Das Modell des Open-Boot-Systems hat dann die Tokens normiert ... was ebenso für ein System gilt, das auf den Einsatz von Chipkarten hin gestrickt wurde, mit dem Handling von APDUs im Mittelpunkt, wie mit der ISO 7816 begonnen, läuft als ISO 20060 unter dem Kürzel OTA - Open Terminal Architecture (jaja, damit hab ich mich für eine ziemliche Zeit herumgeschlagen). Wenn dann Folgen von Tokens ausgetauscht werden, ist man bereits auf Code-Ebene, sodass gleich der Adress-Intrerpreter mit Code gefüttert wird, und nicht der äußere Interpreter mit Quelltext. Und das ist dann schon die Schicht, wie Libraries gestrickt sind. Man muss, abseits des Mainstreams, die Bedeutung etwas gründlicher abklopfen, was denn gemeint ist, wenn Libraries ausgetauscht werden. Die Architekturen sind weniger technisch als auch historisch bedingt. Wenn es darum ginge, sich des Mainstreams zu bedienen, wo massenweise die Code-Fragmente und die Headerfiles herumgurken, dann gibt es zur Übernahme in Forth eine harte Klippe, das ist die Konstruktion des Aufbaus mit prinzipiell zwei Stacks, und nicht nur einem - der Stack für die Verschachtelung, und der Stack für die Datenweitergabe. Auch das ist wohl nur historisch bedingt - wahrscheinlich auf die Denkfaulheit beim Umgang mit der Vokabel Der-Stack! zurückzuführen. Hätte das Personal zu seiner Zeit etwas stringenter in analytischen Dimensionen gedacht, wäre eine Architektur mit zwei Stapeln für die rein technisch bedingten Erfordernisse viel naheliegender. Der Vorteil, den Forth in dieser Hinsicht hat, ist immens, als da Verschachtelungen viel bililiger zu haben sind, wenn nicht bei jedem Sprung im Code zugleich der Zusanmenhang der Daten zwuschengesichert werden muss. Das erspart man sich, wenn die Parameter transparent auf einem gemeinsamen Stack durchgereicht werden. Von daher wurde typischerweise in Forth stets mit kleinen Routinen kodiert, mit den anonymen Parametern auf dem Stack. Forth und C haben zu einer Zeit schon koëxistiert, als noch nicht so krass klar war, dass C zum Mainstream würde. Da hat vor allem die Industrie nachgeholfen, indem mit Förderpaketen letzteres tapfer gepampert wurde, parallel dazu, dass Unix-Maschinen sich verbreiteten. C verbreitete sich erst einmal ganz spezifisch mit letzteren - aber auch ist hier die Tradition aufrecht geblieben, dass, auch in C, Quelltexte korrespondiert werden, es müssen nicht kompilierte Libraries sein, was in Umlauf kommt. Das Interesse, dass nur kompilierte Libraries im Umlauf sind, ist eher merkantiler Natur, in der Hoffnung, Problemlösungen für alles und jedes als uneinsehbaren kryptischen Datenhaufen in Plastik zu verpacken und teuer verkaufen zu können. Mit Quelltext geht das nicht so locker. Dank der Bewegung für offen zu verbreitende Software ist doch letzteres als eigentlich vernünftigere Ansicht um die Welt geschwappt. Das war der Punkt, wo Anfang der 1990er ein Team für das ANSI eine Normierung auskungelte, von allzu konkreten Implementierungsdetails Abschied zu nehmen und abstraktere Prinzipien stattdessen aufzunehmen, sodass unter diesem Titel dann Quelltext austauschbar würde - 1998 wurde ein ISO daraus.
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-17 08:05 -0400 |
| Message-ID | <Es1rcycEQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261803 |
On 17 Aug 19 at group /de/sci/electronics in article grpsh8FihabU1@mid.individual.net <anderswo@gmx.net> (Ewald Pfau) wrote: > Johannes Bauer <dfnsonfsduifb@gmx.de>: >> Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler >> schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert, >> sondern immer interpretiert? Das hatte ich anders verstanden. > Interpretiert wird in mehreren Schichten. [...] Sehr schöner Beitrag. Danke, Habs gespeichert 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 | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2019-08-17 14:51 +0200 |
| Message-ID | <qj8t7t$hp5$1@solani.org> |
| In reply to | #261789 |
On 08/16/2019 22:47, Johannes Bauer wrote: > On 16.08.19 22:26, Hans-Peter Diettrich wrote: >> Am 16.08.2019 um 20:55 schrieb Johannes Bauer: >> >>> 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. >> >> Traue keinem Benschmark den Du nicht selbst gefälscht hast ;-) > > Naja, ich kann halt kein Forth. Und das Wikipedia-Beispielprogramm ist > das einzige das ich hatte und es ist auch echt Embedded-tauglich. RC4 > ist so klein, dass man ihn einfach runterimplementieren kann. > > Das Problem ist, dass wenn die Forth-Advokaten sich nicht die Mühe > machen, Testprogramme zu liefern, die weniger Overhead haben (damit man > sehen könnte wie nah man an C rankommt), dass dann halt jemand wie ich > (der keine Ahnung von Forth hat) das übernehmen muss. Und dann schaffe > ich halt wenigstens harte Zahlen, wo vorher nur rumgewiesel war. Jeder > ist herzlich eingeladen neue Zahlen zu liefern, aber diese qualitativen > Aussagen gehen mir auf den Keks. Harte Fakten werden nicht gemocht, weil sie alle 'Optionen' ersticken. Ich habe auch mal einen Test gemacht, auf ein und derselben Plattform, mit gleichen Mitteln und Aufgaben auf Software-Ebene. Ergebnisse des jeweiligen Zeitbedarfs (1996): C 1 Pascal 5 COBOL 80 C ist nicht zu toppen! Das bewahrheitet sich immer wieder. -- 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 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | de.sci.electronics
csiph-web