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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2019-08-21 15:13 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs |
| Message-ID | <qjjg1c$gnv$1@solani.org> |
| In reply to | #261991 |
Am 21.08.19 um 12:30 schrieb Wolfgang Allinger: > > On 20 Aug 19 at group /de/sci/electronics in article qji2ur$jdi$1@solani.org > <dk4xp@arcor.de> (Gerhard Hoffmann) wrote: > >> Am 21.08.19 um 00:56 schrieb Wolfgang Allinger: (Epos gesnippt) Ja, 8080-Assembler haben damals viele geschrieben. Wir auch. Mit Macros & was man sonst so braucht. Mit Lochkarten und auf einer TR-4, in Fortran. Mehr als ein Schuhkarton von Karten war nicht handhabbar. Der TR4-Fortran-Compiler war gut genug, um Spice 2G4 zu compilieren.Das war schon mal was. Die TR440 war meistens unerreichbar,nur für einen Kurs. Die TR-4 durfte abends nach Schichtende der Operators von den E-Technik-Studenten selbst betrieben werden. Mein erster PC, für ein paar Stunden :-) Später in Berlin ein Compiler für PL/Z8000 auf einer /370. Aus erzieherischen Gründen in ELAN, nicht in Fortran. OMG. Geschwätzigkeit als Ziel. Ein paar Stockwerke höher stand eine PDP11/40E mit der ersten Unix-Installation auf dieser Seite des Atlantiks. Die Bekehrung zu C und Yacc hat keine 3 Tage gedauert. Was für ein Fortschritt! Gruß, Gerhard
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-21 10:47 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs |
| Message-ID | <gs56bhF13ecU1@mid.individual.net> |
| In reply to | #261976 |
Am 21.08.2019 um 00:56 schrieb Wolfgang Allinger: > Geht nur ab W7(?) nicht mehr, da liessen sie einen nicht mehr an den > Timer, bzw. ich hatte da keine Lösung gefunden. Das sieht so aus, als ob Dein FORTH unter Windows lief. Da läßt sich natürlich mehr machen als auf einem dummen OS. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Axel Berger <Spam@Berger-Odenthal.De> |
|---|---|
| Date | 2019-08-20 01:13 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und"lange" ISRs |
| Message-ID | <5D5B2D1A.B43CD671@Berger-Odenthal.De> |
| In reply to | #261922 |
Ewald Pfau wrote: > dass eben die klammerlose Notation zufällig sehr fein mit > dem Maschinenelement Stapel harmoniert. Genau, der Mensch richtet sich nach der Maschine. > Das sind Menschen, die Code schreiben, und beim Verfolgen der Windungen in > einem Spaghettisalat ist der Horizont der etwas gründlicheren > Nachvollziehbarkeit rasch an seinen Grenzen. Ja, Das ist mir hierbei vollkommen egal. *Einer* muß sich *einmal* sehr lange und ausgiebig quälen und schwitzen und wenn's dann läuft, haben es tausende jedes Mal einfacher. Das eben ist das Schöne an Programmen. > Hirnschmalz einbringen, um das Handling möglichst > effizient zu ermöglichen. Jedes Mal neu, statt nur einmal für den (großen, komplexen, aufwendigen) Compiler. Das ist der Unterschied. > So etwas kennt die Kundschaft > der Riesencopiler schon lange nicht mehr. Das will ich auch nicht kennen -- zumindest nicht immer und täglich im simplen, wenig anspruchsvollen Alltagsgeschäft. Mein Programmieren kommt über das Skripten von repetitiven Routineaufgaben nicht weit hinaus. -- /¯\ 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 | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-19 17:52 +0200 |
| Message-ID | <gs0012FsbmfU1@mid.individual.net> |
| In reply to | #261886 |
Am 19.08.2019 um 14:44 schrieb Eric Bruecklmeier: > Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger: >> 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. Nur der kleine Geist braucht Ordnung, der große überblickt das Chaos ;-) An der Uni waren die meisten Studenten hoffnungslos aufgeschmissen, wenn sie mal statt TI einen HP Taschenrechner benutzen sollten. Umgekert ist mir das nie begegnet. Und wer C für eine brauchbare Programmiersprache hält, kann bessere Entwicklungswerkzeuge sowieso nicht mehr verstehen :-( DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-20 17:58 -0400 |
| Message-ID | <EsDtVosEQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261910 |
On 19 Aug 19 at group /de/sci/electronics in article gs0012FsbmfU1@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > Am 19.08.2019 um 14:44 schrieb Eric Bruecklmeier: >> Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger: >>> 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. > Nur der kleine Geist braucht Ordnung, der große überblickt das Chaos ;-) > An der Uni waren die meisten Studenten hoffnungslos aufgeschmissen, wenn > sie mal statt TI einen HP Taschenrechner benutzen sollten. Umgekert ist > mir das nie begegnet. Und wer C für eine brauchbare Programmiersprache > hält, kann bessere Entwicklungswerkzeuge sowieso nicht mehr verstehen :-( THX FULLACK gebunkert :) 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-21 15:50 +0200 |
| Message-ID | <qjji75$fd5$1@news2.open-news-network.org> |
| In reply to | #261910 |
On 19.08.19 17:52, Hans-Peter Diettrich wrote: > Und wer C für eine brauchbare Programmiersprache > hält, kann bessere Entwicklungswerkzeuge sowieso nicht mehr verstehen :-( C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller Software auf C-Software basieren. Die Alternative Erklärung wäre, dass alle Entwickler, die teilweise kompliziertesten Code schreiben, der auch gut performen muss (Betriebssysteme, Datenbanken, Kommunikationssysteme) komplett ahnungslos sind. Occams Rasiermesser sagt: Deine Aussage ist Quatsch. Noch dazu, weil eine Kategorisierung in "brauchbar/unbrauchbar" eher unbrauchbar ist und komplett wegignoriert, dass Programmiersprachen zu Recht unterschiedlich sind, weil sie eben andere Aspekte haben. Es gibt da keine "Beste" und wer das behauptet, hat schlicht keine Ahnung. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-21 18:13 +0200 |
| Message-ID | <gs5ac5F1uscU1@mid.individual.net> |
| In reply to | #262002 |
Am 21.08.2019 um 15:50 schrieb Johannes Bauer: > On 19.08.19 17:52, Hans-Peter Diettrich wrote: > >> Und wer C für eine brauchbare Programmiersprache >> hält, kann bessere Entwicklungswerkzeuge sowieso nicht mehr verstehen :-( > > C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller > Software auf C-Software basieren. Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht so fehlerbehaftet. > Die Alternative Erklärung wäre, dass alle Entwickler, die teilweise > kompliziertesten Code schreiben, der auch gut performen muss > (Betriebssysteme, Datenbanken, Kommunikationssysteme) komplett > ahnungslos sind. Auch das ist richtig. Von C Programmierern wird Pascal belächelt, ohne daß sie die Vorteile von Pascal in der Programmentwicklung überhaupt kennen. Performance ist nicht das Problem, es läuft ja nachher beides auf der selben Hardware. Wer die Weiterentwicklung von C/C++ beobachtet, der stellt fest, daß dort immer mehr Paradigmen einfließen, die in Pascal schon seit Jahrzehnten Standard waren. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-21 19:17 +0200 |
| Message-ID | <qjjuag$p6n$1@news2.open-news-network.org> |
| In reply to | #262015 |
On 21.08.19 18:13, Hans-Peter Diettrich wrote: >> C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller >> Software auf C-Software basieren. > > Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht > so fehlerbehaftet. Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima funktioniert. >> Die Alternative Erklärung wäre, dass alle Entwickler, die teilweise >> kompliziertesten Code schreiben, der auch gut performen muss >> (Betriebssysteme, Datenbanken, Kommunikationssysteme) komplett >> ahnungslos sind. > > Auch das ist richtig. Ahja, alle sind doof nur du hast das Licht gesehen und den Zugang zur Weisheit. War ja klar. > Von C Programmierern wird Pascal belächelt, ohne > daß sie die Vorteile von Pascal in der Programmentwicklung überhaupt > kennen. Darum ging es gerade gar nicht. Ich nutze kein Pascal, habe das mal als Kind gelernt und fand es ganz nett. Aber eine Programmiersprache, für die es halt keine gescheiten Compiler gibt, keine gescheiten Language Bindings, in der ich performance-kritischen Code nicht hinschreiben kann, sodass es schnell funktioniert, die wäre jetzt nicht meine erste Wahl. Belächeln tu ich es nicht, du scheinst da ein Problem mit deinem Selbstbewußtsein zu haben. > Performance ist nicht das Problem, es läuft ja nachher beides > auf der selben Hardware. LOL, "Performance ist nicht das Problem" sagen immer genau die, die eben NICHT dieselbe Performance hinkriegen. Das haben die Java-Leute schon *jahrzehnte* herumposaunt. Ist gar kein Problem, RAM-Verbauch auch gar kein Problem, alles gar kein Problem. Außer für die, die damit arbeiten müssen. Die merken nämlich, ja es ist ein Problem. Das Argument "es läuft nachher beides auf derselben Hardware" ist so erschreckend blöd und falsch, dass ich mal in Abrede stellen möchte, dich überhaupt in dem Feld noch ernstnehmen zu müssen. Klar läuft alles auf der selben Hardware. Ja, und? Du meinst, du kannst beliebig viele Abstraktionsschichten einziehen (die mitunter ein Vorteil sein können) und hast dafür aber keinen Performance-Nachteil? Die magische Hardware möchte ich auch mal haben. Mach doch mal Messungen. Gerne auch Pascal vs. C. Und dann zeig doch, dass beides gleichschnell performt. Meine Hypothese ist, dass dir das genauso misslingen wird, wie es Wolfgang misslungen ist ein Hello World zur Ausführung zu bringen. Aber es ist echt witzig, dass immer die, die keine Performance demonstrieren können, sagen das wär ja alles kein Problem. Für dich vielleicht nicht. Für mich halt schon. > Wer die Weiterentwicklung von C/C++ beobachtet, > der stellt fest, daß dort immer mehr Paradigmen einfließen, die in > Pascal schon seit Jahrzehnten Standard waren. Äh, ne, ganz sicher nicht. Aber sowas von Tausendprozentig nicht. Was sind denn neue Paradigmen so in C++11, C++14, schauen wir doch mal: auto, constexpr, lambda-Funktionen. Kann Pascal alle snicht. Template Metaprogramming ja wohl sowas von auch nicht. LValue-Referenzen zur Effizienten Kopie von Objekten, nöp. Ich vermute, du hast von C++-Programmierung und dem, was in der C++-Welt mit C++20 so gerade vorgeht, schlicht und ergreifend keine Ahnung. Ich schon. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-08-21 20:16 +0200 |
| Message-ID | <gs5g3tF365qU1@mid.individual.net> |
| In reply to | #262018 |
Am 21.08.19 um 19:17 schrieb Johannes Bauer: >>> C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller >>> Software auf C-Software basieren. >> >> Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht >> so fehlerbehaftet. > > Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen > IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima > funktioniert. Für bestimmte Werte von "prima". Es gibt zigtausende CVEs, und alleine in Deutschland betrugen 2006 die jährlichen Verluste durch Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro. https://de.wikipedia.org/wiki/Programmfehler#Wirtschaftliche_Bedeutung Es ist seitdem sicher nicht weniger geworden. https://www.inc.com/will-yakowicz/cyberattacks-cost-companies-400-billion-each-year.html Nun lassen sich aber 70% aller Sicherheitsprobleme in Software von Microsoft auf unsicheren Umgang mit Arbeitsspeicher zurückführen https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ und bei den Programmiersprachen mit unsicherem Umgang mit Arbeitsspeicher ist C nun mal ganz weit vorne. Das mit den 70% ist wohl nicht nur bei Microsoft so, stichprobenartig: "70% of the high-risk bugs in Chrome 44 would have been prevented if Chrome were written in a memory-safe language instead of C/C++." http://trevorjim.com/lets-sunset-c-c++/ Das mit dem "brauchbar" ist halt so ne Sache. Es tut Dinge, sicher. Vielleicht sogar schnell. Und wenn man betriebsblind genug ist, sieht man auch die Kollateralschäden nicht. Obgleich die immer häufiger kommenden, immer größeren Sicherheitsupdates auch dem Betriebsblindesten zeigen sollten, daß Sprachen mit bekannten Sicherheitsimplikationen mit der immer weiter zunehmenden Komplexität der Software nicht so recht harmonieren. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2019-08-21 21:02 +0200 |
| Message-ID | <qjk4g0$l1$1@solani.org> |
| In reply to | #262020 |
Am 21.08.19 um 20:16 schrieb Hanno Foest: > Am 21.08.19 um 19:17 schrieb Johannes Bauer: > >>>> C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller >>>> Software auf C-Software basieren. >>> >>> Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht >>> so fehlerbehaftet. It's a bad craftsman who blames his tools. >> Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen >> IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima >> funktioniert. > > Für bestimmte Werte von "prima". Es gibt zigtausende CVEs, und alleine > in Deutschland betrugen 2006 die jährlichen Verluste durch > Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro. Bei 3000 Mrd BSP in 2006 erscheinen 84,4 Mrd Verluste in Mittel- und Großunternehmen nur durch Softwarefehler doch reichlich aus dem Vollen geschöpft. Da bin ich noch nicht mal dabei. Und keine Virusattacken. Und die Maurer, Bierbrauer und Bauern auch eher nicht. Die haben ja auch einen Anteil am BSP. Das ganz und gar UNGLAUBLICHE FIASKO von pleitegegangen Firmen im Kielwasser der Jahrtausendwende war 2006 ja wohl verdaut. > Nun lassen sich aber 70% aller Sicherheitsprobleme in Software von > Microsoft auf unsicheren Umgang mit Arbeitsspeicher zurückführen > > https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ > > > und bei den Programmiersprachen mit unsicherem Umgang mit > Arbeitsspeicher ist C nun mal ganz weit vorne. Das ist aber ein klassisches Eigentor, Windows wurde in Pascal geschrieben. Mit der Umstellung auf die C-Familie wurde das dann deutlich besser. Windows 7 ist eigentlich schon ganz brauchbar. Gerhard
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-08-21 22:47 +0200 |
| Message-ID | <gs5ov3F52g7U1@mid.individual.net> |
| In reply to | #262025 |
Am 21.08.19 um 21:02 schrieb Gerhard Hoffmann: >>>> Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht >>>> so fehlerbehaftet. > > It's a bad craftsman who blames his tools. Paßt nicht so recht, daß Hans-Peter ja gerade kein C verwenden möchte. >>> Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen >>> IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima >>> funktioniert. >> >> Für bestimmte Werte von "prima". Es gibt zigtausende CVEs, und alleine >> in Deutschland betrugen 2006 die jährlichen Verluste durch >> Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro. > > Bei 3000 Mrd BSP in 2006 erscheinen 84,4 Mrd Verluste in Mittel- und > Großunternehmen nur durch Softwarefehler doch reichlich aus dem Vollen > geschöpft. Die $400 Billion durch Hacker im Jahre 2015 auch? Ich hab Quellen angegeben. Die mögen nicht gut sein, aber besser als quellenfreie Zweifel sind sie allemal. >> Nun lassen sich aber 70% aller Sicherheitsprobleme in Software von >> Microsoft auf unsicheren Umgang mit Arbeitsspeicher zurückführen >> >> https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ >> >> und bei den Programmiersprachen mit unsicherem Umgang mit >> Arbeitsspeicher ist C nun mal ganz weit vorne. > > Das ist aber ein klassisches Eigentor, Windows wurde in Pascal > geschrieben. Mit der Umstellung auf die C-Familie wurde das dann > deutlich besser. Keine Ahnung, welches Windows du meinst, aber wenn man im Jahre 2015 von den letzten 12 Jahren spricht, dann geht es wohl nicht weiter zurück als Windows XP, und das wurde in C, C++ und Assembler geschrieben. Mal ganz abgesehen davon, daß es nicht nur um Windows geht und ich Pascal nicht mal erwähnt habe. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-21 22:59 +0200 |
| Message-ID | <gs5rb7F5imlU1@mid.individual.net> |
| In reply to | #262025 |
Am 21.08.2019 um 21:02 schrieb Gerhard Hoffmann: > Am 21.08.19 um 20:16 schrieb Hanno Foest: >> Am 21.08.19 um 19:17 schrieb Johannes Bauer: >> und bei den Programmiersprachen mit unsicherem Umgang mit >> Arbeitsspeicher ist C nun mal ganz weit vorne. > > Das ist aber ein klassisches Eigentor, Windows wurde in Pascal > geschrieben. Mit der Umstellung auf die C-Familie wurde das dann > deutlich besser. Windows 7 ist eigentlich schon ganz brauchbar. In den 90er Jahren enthielt jedes Modul im WinSDK ca. 50 haarsträubende Fehler, die der Compiler eines ordentlichen C++ Entwicklungssystems angemeckert hat. Oh f*ck - dieser Compiler stammte von den Delphi-Entwicklern! So viel zum Vorteil eines Umstiegs auf C :-] DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-08-22 17:47 +0200 |
| Message-ID | <qjmdeq$k2n$1@news.bawue.net> |
| In reply to | #262025 |
On 8/21/19 9:02 PM, Gerhard Hoffmann wrote: > Am 21.08.19 um 20:16 schrieb Hanno Foest: >> Am 21.08.19 um 19:17 schrieb Johannes Bauer: >> >>>>> C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller >>>>> Software auf C-Software basieren. >>>> >>>> Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht >>>> so fehlerbehaftet. > > It's a bad craftsman who blames his tools. Es gibt gute und schlechte Werkzeuge. Selbst der beste Handwerker wird mit schlechten Werkzeugen maximal mittelmässiges hinbekommen. > Das ist aber ein klassisches Eigentor, Windows wurde in Pascal > geschrieben. Mit der Umstellung auf die C-Familie wurde das dann > deutlich besser. Windows 7 ist eigentlich schon ganz brauchbar. Nicht wirklich. Selbst Windows 10 hat immer noch fundamentale Designfehler. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Stefan Engler <stefan@epiket.de> |
|---|---|
| Date | 2019-08-21 21:43 +0200 |
| Message-ID | <qjk6th$njs$1@dont-email.me> |
| In reply to | #262020 |
> Das mit den 70% ist wohl nicht nur bei Microsoft so, stichprobenartig: > "70% of the high-risk bugs in Chrome 44 would have been prevented if > Chrome were written in a memory-safe language instead of C/C++." Welche Programmiersprache ist denn memory-safe? (ADA mit der kompletten Verbotsliste für "sichere" Programme zählt jetzt mal nicht) Was bedeutet überhaupt memory-safe? Bitte auch an Listen, Objekte, Out-of-Memory und an Rekursion denken? https://en.wikipedia.org/wiki/Memory_safety Irgendwann werden wohl nur noch lookup tables übrigbleiben, die sich sicher ausführen lassen (bestimmt bekommt dann doch jemand eine Endlos- Schleife hin). CPU's werden mit vielen lookup tables (statt der echten Logik, die der Programmierer wollte -- macht der Compiler) hergestellt, da diese schnell, zuverlässig, stromsparend und preiswert sind.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-21 22:05 +0200 |
| Message-ID | <qjk86o$lu$1@news2.open-news-network.org> |
| In reply to | #262020 |
On 21.08.19 20:16, Hanno Foest wrote: >> Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen >> IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima >> funktioniert. > > Für bestimmte Werte von "prima". Naja, ich habe ja geschrieben "im Großen und Ganzen". Und das stimmt auch -- die Mehrzahl unserer Geräte läuft auf Linux heutzutage, die ganzen Android Smartphones, quasi das ganze Rückgrat des Internet auch (sowohl Server als auch Router). HPC ist quasi ausschließlich Linux und damit C. > Es gibt zigtausende CVEs, und alleine > in Deutschland betrugen 2006 die jährlichen Verluste durch > Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro. > > https://de.wikipedia.org/wiki/Programmfehler#Wirtschaftliche_Bedeutung > > Es ist seitdem sicher nicht weniger geworden. In C kann man Fehler machen, die schlimmere Auswirkungen haben als in anderen Programmiersprachen, das stimmt sicherlich. Aber jetzt zwei Fragen: Erstens: Habe ich je behauptet, dass C *einfach* zu programmieren ist? Zweitens: Ist es die Schuld des Werkzeugs oder des Bedieners, dass da Bugs in der Software sind? > und bei den Programmiersprachen mit unsicherem Umgang mit > Arbeitsspeicher ist C nun mal ganz weit vorne. Klar. Und trotzdem wird C nach wie vor sehr häufig verwendet. Jetzt kann man sich mit der Arroganz eines DoDi hinstellen und sagen: "Das ist nur weil alle blöd sind" oder man hält mal nicht alle anderen für Idioten und kommt auf ein Paar Aspekte, die andere Programmiersprachen halt nicht (in dem Umfang) leisten. > Das mit den 70% ist wohl nicht nur bei Microsoft so, stichprobenartig: > "70% of the high-risk bugs in Chrome 44 would have been prevented if > Chrome were written in a memory-safe language instead of C/C++." Google macht Chrome. Bei Google arbeiten mit Sicherheit viele der brilliantesten Software-Designer. Und *trotzdem* haben die sich für C als Implementierungssprache entschieden. Warum? Sind die Google-Ingenieure denn alle total blöd? Oder, was ich für wahrscheinlicher halte: Es gibt knallharte Gründe, warum die diese Abwägung getroffen haben. Performance wird da eben auch ganz oben mit dabei sein. Weil wenn der Chrome plötzlich 20% oder 50% langsamer als der Firefox ist, dann sind die Benutzer weg. Gerade Browser sind *knüppelhart* optimierte Softwaremonster und da spielt Performance eine sehr große Rolle. > Das mit dem "brauchbar" ist halt so ne Sache. Es tut Dinge, sicher. > Vielleicht sogar schnell. Und wenn man betriebsblind genug ist, sieht > man auch die Kollateralschäden nicht. Obgleich die immer häufiger > kommenden, immer größeren Sicherheitsupdates auch dem Betriebsblindesten > zeigen sollten, daß Sprachen mit bekannten Sicherheitsimplikationen mit > der immer weiter zunehmenden Komplexität der Software nicht so recht > harmonieren. Das ist genau das undifferenzierte Argument, das mich an der ganzen Diskussion hier so ärgert: Wer C einsetzt ist einfach nur betriebsblind. Komplett die Vorteile wegignorieren und einfach nur das, was *du* für wichtiger hälst, hochpriorisieren. Das ist eines Ingenieurs absolut unwürdig. Man stelle sich vor, ich würde mich in d.s.e hinstellen und sagen: "Schaut her, das hier ist der BESTE Transistor". Zu Recht würden mir da alle den Vogel zeigen und mich auslachen. Denn, wie bei jedem Werkzeug, gibt es viele Dimensionen: Verfügbarkeit, Preis, Geschwindigkeit, Second Source, das *alles* spielt eine Rolle. Nur wenn es dann um Software-Werkzeuge geht, stellen sich Wolfgang, DoDi und ihresgleichen hin und posaunen Arrogant herum dass derjenige der "Transisor X" verwendet ja einfach nur n bissl doof ist und betriebsblind und weiß der Geier. Obwohl es da genau dieselben Dimensionen gibt: Geschwindigkeit, Verfügbarkeit, Language-Bindings, Portabilität, Speichersicherheit, etc etc. Ich habe *nie* geschrieben, dass C die "beste" Sprache wäre. Nie, dass sie einfach oder idiotensicher zu programmieren ist. Sondern lediglich, dass es, nach Assembler, vermutlich die performanteste Sprache ist. Und solche Fakten schlicht zu ignorieren ist intellektuell unehrlich. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-21 23:07 +0200 |
| Message-ID | <gs5rb7F5imlU2@mid.individual.net> |
| In reply to | #262035 |
Am 21.08.2019 um 22:05 schrieb Johannes Bauer: > Ich habe *nie* geschrieben, dass C die "beste" Sprache wäre. Nie, dass > sie einfach oder idiotensicher zu programmieren ist. Sondern lediglich, > dass es, nach Assembler, vermutlich die performanteste Sprache ist. Das ist eine unbewiesene/unbeweisbare Behauptung. Richtig ist lediglich, daß C die meist*verwendete*[1] Sprache ist. Nicht mal die Performance kannst Du richtig einschätzen, die ist bei den heutigen (Intel-)Prozessoren mit einer Hochsprache oft besser als mit Assembler. > Und > solche Fakten schlicht zu ignorieren ist intellektuell unehrlich. Fakten, alternative? [1] Millionen Fliegen können bekanntlich nicht irren :-( DoDi
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-21 23:55 +0200 |
| Message-ID | <qjkejv$5rd$1@news2.open-news-network.org> |
| In reply to | #262049 |
On 21.08.19 23:07, Hans-Peter Diettrich wrote: > Am 21.08.2019 um 22:05 schrieb Johannes Bauer: > >> Ich habe *nie* geschrieben, dass C die "beste" Sprache wäre. Nie, dass >> sie einfach oder idiotensicher zu programmieren ist. Sondern lediglich, >> dass es, nach Assembler, vermutlich die performanteste Sprache ist. > > Das ist eine unbewiesene/unbeweisbare Behauptung. Richtig ist lediglich, > daß C die meist*verwendete*[1] Sprache ist. Ach komm, bist du wirklich ein Lügner vom Kaliber des Allinger? Versuchst du tatsächlich das OFFENSICHTLICHE zu leugnen? Was für eine moralische Bankrotterklärung. Aber, hey, ich spoonfeede dich jetzt mal und dann schauen wir mal ob du zugeben kannst, was für Müll du hier zusammengelogen hast: https://attractivechaos.github.io/plb/ http://ptrace.fefe.de/wp/timings2019.txt https://julialang.org/benchmarks/ Dass C die meistverwendete Programmiersprache ist, kommt auch nur darauf an, wie man's misst. Auf TIOBE zumindest nur Platz 2, auf GitHub gemessen definitiv noch weiter unten. Es ist ansich auch gar nicht definitiert was "meistverwendet" überhaupt heißt, als Laufzeit? Oder Codezeilen? Oder Anzahl Programmierer? > Nicht mal die Performance kannst Du richtig einschätzen, die ist bei den > heutigen (Intel-)Prozessoren mit einer Hochsprache oft besser als mit > Assembler. Handgeschriebens Assembler ist schon deswegen IMMER mindestens genauso gut wie jede Hochsprache, weil ich einfach einen Compiler nehmen kann, das zu Assembler runterkompilieren und dann meinen mindestens gleichguten Assembler-Code habe. Dass du solch simple Fakten nicht verstehst, zeigt eindrucksvoll deine komplette und unfassbare Ahnungslosigkeit. Noch gepaart mit einer Überheblichkeit, die ihresgleichen sucht. Mensch, wenn die nur mal alle auf dich hören würden, oh erleuchteter DoDi. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-08-22 00:12 +0200 |
| Message-ID | <gs5tunF6325U1@mid.individual.net> |
| In reply to | #262057 |
Am 21.08.19 um 23:55 schrieb Johannes Bauer: > Handgeschriebens Assembler ist schon deswegen IMMER mindestens genauso > gut wie jede Hochsprache, weil ich einfach einen Compiler nehmen kann, > das zu Assembler runterkompilieren und dann meinen mindestens > gleichguten Assembler-Code habe. Hä? Das ist wirr. Die Frage ist, ob du von Hand genausogut optimieren kannst wie ein Compiler. Und das wurde schon vor 2 Jahrzehnten von qualifizierter Seite bezweifelt - spätestens, wenn der Code umfangreicher wird. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-22 00:34 +0200 |
| Message-ID | <qjkgsp$7fa$1@news2.open-news-network.org> |
| In reply to | #262060 |
On 22.08.19 00:12, Hanno Foest wrote: > Am 21.08.19 um 23:55 schrieb Johannes Bauer: > >> Handgeschriebens Assembler ist schon deswegen IMMER mindestens genauso >> gut wie jede Hochsprache, weil ich einfach einen Compiler nehmen kann, >> das zu Assembler runterkompilieren und dann meinen mindestens >> gleichguten Assembler-Code habe. > > Hä? Das ist wirr. Die Frage ist, ob du von Hand genausogut optimieren > kannst wie ein Compiler. Und das wurde schon vor 2 Jahrzehnten von > qualifizierter Seite bezweifelt - spätestens, wenn der Code > umfangreicher wird. Wenn ich Assembler schreibe, kann ich mich immer *jedes* Compilers bedienen. Also konkret: Ich habe die Möglichkeit, mein Programm durch zig verschiedene Compiler zu assemblieren und *zusätzlich* die Möglichkeit, das zu verändern oder ganz neu zu schreiben. Deswegen ist es notwendigerweise immer mindestens gleichschnell. Ob man das "blind" hinkriegen könnte, ist eine ganz andere Frage. Und dass es viel mehr Wissen braucht, noch zusätzlich was ganz anderes. Üblicherweise wird "umfangreicher" Code aber auch nicht mehr in Assembler geschrieben, sondern eben nur die kritischen Pfade. Die, wo es eben einen Unterschied macht, ob Hochsprache oder nicht. Fakt ist, dass performance-kritischer Code sich heute immernoch an Assembler bedient. Sieht man z.B. dutzendfach in OpenSSL. Oder bei djb's Kryptocode. Oder bei BLAS. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-08-22 00:47 +0200 |
| Message-ID | <gs600pF6ggaU1@mid.individual.net> |
| In reply to | #262062 |
Am 22.08.19 um 00:34 schrieb Johannes Bauer: > Wenn ich Assembler schreibe, kann ich mich immer *jedes* Compilers > bedienen. Nein. Wenn du Assembler schreibst, dann schreibst du Assembler. Wenn du einen Compiler Assembler schreiben läßt, dann kompilierst du. Das Kompilat handzuoptimieren ist dann noch mal was anderes. Am Ende kommt zwar immer Assembler raus, aber der Vorgang ist ein anderer. Jedenfalls, wenn man die Bedeutung von "etwas schreiben" nicht zur Unkenntlichkeit verbiegen möchte. > Fakt ist, dass performance-kritischer Code sich heute immernoch an > Assembler bedient. Sieht man z.B. dutzendfach in OpenSSL. Oder bei djb's > Kryptocode. Oder bei BLAS. Sicher. Und wie wurde der im Einzelfall erzeugt? Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | de.sci.electronics
csiph-web