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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-22 01:25 +0200 |
| Message-ID | <qjkjte$9ts$1@news2.open-news-network.org> |
| In reply to | #262065 |
On 22.08.19 00:47, Hanno Foest wrote: > 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. Hm, ich sehe einen Compiler durchaus als Werkzeug, sich Tipps und Ideen zu holen. > 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. Es ist jedenfalls nicht abzustreiten, dass ich selbst in händisch geschriebenem Assembler zumindest theoretisch die Möglichkeit hätte, jeden Compiler zu outperformen. Dass /ich/ das nicht kann und vermutlich die allermeisten Programmierer ebensowenig, ist schon ein separates Thema. >> 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? Händisch geschrieben, wenn du dir den anschaust. Bzw bei OpenSSL schreiben die händisch ein perl-Skript dass dann ASM erzeugt. Also nutzen quasi perl als Makroassembler. Der Curve25519 Code sah auch nach handgeschriebenem Zeug aus. Ich finde jetzt djb's Sachen nicht, aber hier ist ein Beispiel: https://github.com/msotoodeh/curve25519/blob/master/source/asm64/amd64.masm/Mult.asm Viele Grüße, Johannes -- "Performance ist nicht das Problem, es läuft ja nachher beides auf der selben Hardware." -- Hans-Peter Diettrich in d.s.e.
[toc] | [prev] | [next] | [standalone]
| From | Hergen Lehmann <hlehmann.expires.5-11@snafu.de> |
|---|---|
| Date | 2019-08-22 01:06 +0200 |
| Message-ID | <edv03g-gea.ln1@hergen.dyndns.org> |
| In reply to | #262062 |
Am 22.08.19 um 00:34 schrieb Johannes Bauer: > 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. In der Praxis: Nein. Zum einen ist der von einem optimierenden Compiler erzeugte Code oft nur sehr mühsam menschenlesbar. Zu anderen besitzt ein guter Compiler derart viel Wissen über den internen Aufbau der Ziel-CPU und die optimale Befehlsreihenfolge zur optimalen Ausnutzung der Parallelverarbeitung, das ein Mensch da nur noch mit Versuch-und-Irrtum mithalten kann. Man sich das für kurze, ganz besonders performancekritische Codeabschnitte antun, aber nicht für ein vollständiges, nicht-triviales Programm. Hergen
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-22 00:11 +0200 |
| Message-ID | <gs5vg6F6djfU1@mid.individual.net> |
| In reply to | #262057 |
Am 21.08.2019 um 23:55 schrieb Johannes Bauer: [...] <gähn> > Mensch, wenn die nur mal alle auf dich hören würden, oh erleuchteter DoDi
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2019-08-22 23:07 +0200 |
| Message-ID | <20190822230741.5fadb056@Achmuehle.WOR> |
| In reply to | #262057 |
Hallo Johannes (und hallo Hans-Peter), Du schriebst am Wed, 21 Aug 2019 23:55:11 +0200: [C vs. Pascal] Muß ich doch mal ein paar Bemerkungen dazu loslassen, wenn da schon die Fetzen fliegen... Meiner Meinung nach ist die größere Verbreitung von C gegenüber Pascal einfach der Tatsache geschuldet, daß es wesentlich mehr USAmerikaner gibt als Schweizer, und dazu noch wesentlich mehr Programmier-Dilletanten als Informatik-Professoren und -Studierende (C wurde als Freizeitprojekt zusammengebastelt, während Pascal als Lehrmittel entwickelt wurde.) Und wie bei der Entwicklung von Autos der Verbrennungsmotor die Produktion des ersten Serienautos (H. Ford, T-Model) alle anderen Antriebsvarianten aus handwerklicher Fertigung wegfegte, breitete sich C durch seine Verwendung in nicht-informatischen Anwendungen auf weitverbreiteten Maschinen mit einer riesigen Nutzerbasis rapide aus, während Pascal nur im universitären Umfeld mäßige Beachtung fand, sich aber immerhin erheblich länger hielt als entsprechendes beim Auto. Und schließlich wurden für C dann eben aufgrund seiner weiten Verbreitung enorme Anstrengungen unternommen, das miserable Grunddesign durch ständige Erweiterungen und Verbesserungen an den Umsetzwerkzeugen immer weiter zu entwickeln und sogar marginal sicherer zu machen gegenüber dem kaum lohnenswert eresheinenden Pascal, dessen Implementationen sowieso schon erhebliche Sicherheitsvorkehrungen beinhalteten, daß die _Compiler_ dafür heute erheblich besseren - meist im Sinne von schnellerem - Code produzieren können als die für alle anderen Programmiersprachen. Dasselbe gilt natürlich auch für die dafür entwickelten Bibliotheken. An der Sprachdefinition liegt das nicht - beides sind Turing-vollständige Programmiersprachen und somit in der Lage, alle relevanten Aufgaben zu implementieren. Der Unterschied liegt ganz allein in den dafür im Lauf der Zeit entwickelten und daher inzwischen zur Verfügung stehenden _Werkzeugen_, den Compilern, die die Ausgangsprogramme in etwas für die Zielmaschine Ausführbares übersetzen und die fertig verfügbaren Bibliotheken, die viele Aufgaben mit wenig Aufwand implementierbar machen. D.h. dann auch weiter, daß Streitereien um "Performance" - wo immer auch zu fragen ist, welcher Teil der Vorstellung (Performance) denn relevant ist - praktisch ausschließlich die verfügbaren _Implementierungen_ bewerten. Und ob da die Ausführungsgeschwindigkeit immer an vorderster Stelle steht? C ist berüchtigt dafür, daß Programme, die damit geschrieben sind, zwar schnell, aber unsicher wären. Umgekehrtes gilt für Pascal. Sorry für den langen Sermon. In short: your statements are moot. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Axel Berger <Spam@Berger-Odenthal.De> |
|---|---|
| Date | 2019-08-23 00:50 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs |
| Message-ID | <5D5F1C29.E1B315C@Berger-Odenthal.De> |
| In reply to | #262130 |
Sieghard Schicktanz wrote: > C ... das miserable Grunddesign Das würde ich gar nicht so sehen. C ist extrem effizient und bietet maximale Freiheit. Es gibt gute Gründe, das zu nutzen, und fähige Leute, die damit umgehen können. Von letzteren aber nicht wirklich viele. Dafür fehlem ihm alle die Gängelungen, die Normalsterblichen helfen, Fehler zu vermeiden. Alle mir bekannten Bugs und Schwächen des Ataribetriebssystems waren die typischen C-Fehler. Ich habe in meinem Leben genau ein C-Programm geschrieben und einen Käferauspuff gewechselt, aus demselben Grund. Das sind die Sachen, die man einmal selbst gemacht haben muß, um genau zu wissen, warum man es nie wieder tun will. Strings und Arrays, Zeiger, Zeiger auf Zeiger, Zeiger auf Zeiger für Zeiger, Zeiger auf ... Natürlich habe ich mich in der Ebene mehrfach verlaufen, bevor es lief. Und es war ein sehr simples Progrämmchen, in dem Fehler offensichtlich und versteckte Fehler, nachdem es lief, unwahrscheinlich sind. Wenn andere Leute mit sehr viel Arbeit einen wirklich guten Compiler für mich geschrieben haben, dann kann ich mit Pascal und vergleichbarem hervoragend leben. -- /¯\ 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 | Ewald Pfau <anderswo@gmx.net> |
|---|---|
| Date | 2019-08-23 06:57 +0000 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs |
| Message-ID | <gs9h2rFtl9dU1@mid.individual.net> |
| In reply to | #262132 |
Axel Berger <Spam@berger-odenthal.de>: > Das würde ich gar nicht so sehen. C ist extrem effizient und bietet > maximale Freiheit. Freiheit? Das ist die Freiheit des Sklaven in dem Käfig, dass jegliche Abläufe in Ketten von Identitätskonstrukten gezwängt werden müssen, als wie von der algebraischen Notation diktiert. Eigentlich unnötig. Und wenn das fast die ganze Welt so macht, dann lautet das Diktat wiederum, das sei quasi ein Naturgesetz. Und das wiederum ist Unfug. Das bringt mich auf Details, die mir da noch offen scheinen. Würde man sich im Mainstrean besinnen, dass die Bändigung der Maschinen vielmehr eine Aufgabe aus der Logik ist, als denn eine solche aus der Mathematik, dann sähe man auch gleich, dass Identität nur eine Relation unter anderen Relationen ist, die kaum automatisch die Bevorzugung verdient haben muss, wie sie ihr in der Algebra angedeit. Nun wachsen aber die Sklaven zur Maschinencodierung wie Massenfrüchte in Plantagen, als da Algebra zugleich gängiger Schulstoff ist, diese Hirnwindungen als gut einbetoniert angenommen werden können, und mit algebraischer Fundierung des Werkzeugs billig Nachwuchs eingekauft werden kann. Das wiederum kann mit einer historischen Ursache gesehen werden, nachdem um und kurz nach 1900 der Wiener Kreis von Wissenschaftlern um Ernst Mach sich daran machte, die verquasten Ansichten von erlauchten Konstrukten zur Herrschaftssicherung plus deren Ansprüchen an pure Willkür in der Erkenntnisweise aus den Angeln zu heben. Diese Revolution war leise und zivilisiert, daber nachhaltig, ging als logischer bzw. wissenschaftstheoretischer Positivismus um die Welt, von Wien zunächst weniger nach Deutschland, das viel stärker der Romantik verhaftet blieb, als vielmehr über Oxford und Cambridge in den englischsprachigen Teil der Welt. Und hiermit wurde postuliert, dass über das Ideal der naturwissenschaftlichen Sichtweise letztlich die Mathematik die einheitliche Methode zur Betrachtung ausnahmslos alles Irdischen geeignet sein müsse. Von mir aus gesehen nimmt sich das so aus, dass diese Sichtweise spätestens dann mit der Generation der nach 1960 Geborenen als fundamentales Selbstverständnis in Fleisch und Blut übergegangen war, als Anspruch, per Algorithmen Alles und Jedes nach Lust und Herzenslaune kontrollieren zu können. Zugleich aber, dass dieser Anspruch von Anfang an zwar in der historischen Abfolge hilfreich und effizient war, kann er als umfassender Anspruch als überzogen gelten. Das Pendel ging weiter hin und her, aus welchen Quellen sichere Fundierung von Anschauungen und Begründungen zu beziehen sei - der Autor, bei dem ich da einiges lernte, H. von Wright (sein Bändchen "Erklären und Verstehen" kann leicht weiterempfohlen werden), einst Ordinarius in Helsinki, beschreibt hierzu als Gegenpol die Verankerung in der Pflege der Sprache. Nun, vielleicht kann man Husserls Phänomenologie dazunehmen, aber dieser Autor war wiederum Logiker. Zur Rettung des nicht-Algebraischen muss ich noch anführen dass die Kunst des Kopfrechnens sich kaum algebraisch abspult, viel mehr eben im Gebrauch von Stapeln, auf denen man Zwischenergebnisse ablegt. Allerdings wurde dies nicht garso sehr mehr kultiviert. Die Kunst der A|lgebra ist visuell fixiert, die Identitätszuweisungen plus den Formeln auf den Seiten des Gleichheitszeichens sind zuerst für das Auge und dann für das visuelle Gedächtnis. Das ist aber nicht die einzige Form, womit sich Abfolgen darstellen lassen. Nur hat die visuelle Form die besseren Karten, in einem Weltverständnis, wo dem zu Sehenden alles geglaubt wird, hingegen das, was man sich dazu denken sollte, dann aber kaum mehr etwas. Man wartet, bis man es sieht. Katastrophen müssen erst passieren, bevor man der Idee Platz einräumt, dass sie möglich sind. Das spielt auf demselben Bolzplatz für den euphorischen Kindergarten. Könnte wohl sein, dass die Denkweise in historischen Abfolgen, plus deren rigorose Strukturierung, etwas weniger effizient ist. Wenn das zugleich mit sich bringt, Details von Anfang an immer erst auf Herz und Nieren genau zu prúfen, bevor man sie auf die Menschheit loslässt, ist in Summe die Effizienz aber wiederum besser, als da die ganzen Schlampereien, die beim Hopplahopp und Ruckzuck unvermeidliche Weggesellen sind, sehr viel schlechtere Karten haben. Aus diesem Blickwinkel allerdings wird die ganze Welt viel langweiliger, wenn man so arbeitet, per Arbeitsweise sicherzustellen, dass die Konstrukte in sich stabil sind und nicht erst mit tausend Tricksereien nach und nach erst stabil werden. Rein von der gesellschaftlichen Sitten her ist es dann aber wiederum, wie gehabt, nicht so leicht, die Coder-Sklaven in Massen von den Bäumen schütteln zu können. Alles und Jedes unter die Kontrolle per Algorithmen überführen zu wollen, wenn stattdessen den tapferen Handwerkern Verantwortung für ihr Tun zuzuschanzen sei, beim Codieren, scheint auf ersten Blick vielleicht billiger, ist es in weiterer Folge aber nicht. Kurz, der Mensch entkommt sich selber nicht.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Knaepper <rainerk@smial.prima.de> |
|---|---|
| Date | 2019-08-24 10:26 +0200 |
| Subject | Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs |
| Message-ID | <EsT9keYirLB@smial.prima.de> |
| In reply to | #262132 |
Spam@Berger-Odenthal.De (Axel Berger) am 23.08.19 um 00:50: > Sieghard Schicktanz wrote: >> C ... das miserable Grunddesign > Das würde ich gar nicht so sehen. C ist extrem effizient und bietet > maximale Freiheit. Kein Wunder, ist es doch im Wesentlichen konzeptionell ein etwas erweiterter Assembler. > Strings und Arrays, Zeiger, Zeiger auf Zeiger, Zeiger auf Zeiger > für Zeiger, Zeiger auf ... ... und genau wie Assembler mit allen Freiheiten ausgestattet, sich beliebig ins Knie zu schießen. Rainer -- Wenn man mit Raubkopien wirklich Gruppen wie BroSis, die Backstreet Boys oder gar Britney Spears verhindern könnte, würde ich noch heute ein paar CD-Brenner und einen Zentner Rohlinge bestellen. (B. Mangelsdorff in ger.ct)
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-08-21 23:59 +0200 |
| Message-ID | <gs5t6nF5ttsU1@mid.individual.net> |
| In reply to | #262035 |
Am 21.08.19 um 22:05 schrieb Johannes Bauer: >>> 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). Ja, sicherlich. Es tut irgendwelche Dinge. Ob gut, billig, effektiv, nebenwirkungsfrei etc. ist völlig egal, wenn man wegen der installierten Basis, in die sich Änderungen und Erweiterungen einpassen müssen, kaum Alternativen hat und infolgedessen die Programmierer auch keine kennen: If you only have a hammer, everything looks like a nail. Aber "gut genug", um aus dem lokalen Minimum nicht rauszumüssen, ist es wohl. > 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? Natürlich ist es die Schuld des Werkzeugs, wenn es Fehler ermöglicht, die mit einem anderen Werkzeug erst gar nicht vorkommen können. Was ist das denn für eine Frage? >> 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. Windows wird auch sehr häufig verwendet. Liegt das an der überragenden Qualität von Windows, oder an der installierten Basis, und daran, daß die Leute nichts anderes kennen? >> 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 konnten sie nicht gut genug programmieren, um die 70% high-risk bugs zu vermeiden, die ihnen C als Fußangel ermöglicht hat. Bist du sicher, daß das ein Argument für C ist? Rat mal, wie das bei schlechteren Programmierern aussieht. > Oder, was ich für wahrscheinlicher halte: Es gibt knallharte Gründe, > warum die diese Abwägung getroffen haben. Natürlich: Angesichts der Popularität von C bekommst du für ein Großprojekt kaum genügend Programmierer für eine andere Programmiersprache zusammen. Und natürlich, daß Bugs nichts kosten (Unter anderem, weil sich die Leute an sie gewöhnt haben. Alles ist kaputt. Isnumalso. Netter Talk zum Thema: https://www.youtube.com/watch?v=pW-SOdj4Kkk). Im Augenblick ist es so, daß Softwarehersteller an Bugs Geld verdienen: Sie sind ein Grund für Serviceverträge, Updates, neue Versionen. Ich bin mit ziemlich sicher, daß die Softwarelandschaft deutlich anders aussehen würde, wenn Bugs die Hersteller Geld *kosten* würden. >> 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. Wenn du hier komplett die Nachteile wegignorierst, bis zu dem Zeitpunkt, wo ich sie dir an die Stirn tackere, ist das schon irgendwo betriebsblind. Ich hingegen brauche nicht zu erwähnen, daß Dinge, die in großem Maße eingesetzt werden, sicher irgendwo auch Vorteile haben: Das ist selbstverständlich. > Man stelle sich vor, ich würde mich in d.s.e hinstellen und sagen: > "Schaut her, das hier ist der BESTE Transistor". Nur hab ich nichts als bestes bezeichnet. Und auch nicht C als schlechtestes. Deine Einstellung ist mir lediglich gegenüber C zu undifferenziert kritiklos. *Wenn* ich einen Tip für eine gute C-Ablösung nennen sollte, wäre das wohl Rust. Die Benchmarks sehen ganz brauchbar aus [1]. Aber ich kenn das Dings nicht persönlich, und vielleicht ist es lediglich die neueste Sau, die durchs Dorf getrieben wird: Man wird es sehen. Nur finde ich es etwas arm, daß wir seit 40 Jahren oder so die gleichen Fehler machen, obgleich uns Software helfen könnte, diese Fehler zu vermeiden. Auf welchem Wege auch immer. Hanno [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html -- 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 01:04 +0200 |
| Message-ID | <qjkilh$903$1@news2.open-news-network.org> |
| In reply to | #262058 |
On 21.08.19 23:59, Hanno Foest wrote: > Am 21.08.19 um 22:05 schrieb Johannes Bauer: > >>>> 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). > > Ja, sicherlich. Es tut irgendwelche Dinge. Ob gut, billig, effektiv, > nebenwirkungsfrei etc. ist völlig egal, wenn man wegen der installierten > Basis, in die sich Änderungen und Erweiterungen einpassen müssen, kaum > Alternativen hat und infolgedessen die Programmierer auch keine kennen: Naja, das glaube ich nicht so ganz. Im Business-Umfeld, wenn man mal von embedded absieht, wird ja wohl auf der einen Seite .net gemacht und auf der anderen Java. Von C und C++ ist da eher wenig zu spüren, meine ich. > Natürlich ist es die Schuld des Werkzeugs, wenn es Fehler ermöglicht, > die mit einem anderen Werkzeug erst gar nicht vorkommen können. Was ist > das denn für eine Frage? Das heißt, wenn ich mich mit einem Messer schneide, ist es die Schuld des Messers, weil das mit einem anderen Werkzeug, dem Löffel, nicht hätte passieren können? Wenn ich mit meinem Auto einen Unfall baue, ist es die Schuld des Autos, weil das zu Fuß gar nicht möglich gewesen wäre? Ich bitte dich. Sind denn dann folgerichtig eigentlich nicht alle Programmiersprachen, in denen man bugbehafteten Code schreiben kann, deiner Argumentation folgend, defekt? Die Argumentation ist mir ein bisschen zu hilflos. Jedes Werkzeug hat seine Vor- und Nachteile. Eine Kreissäge ist gefährlicher als ein Fuchsschwanz. Und du wirst im Einzelfall abwägen, was für deinen Anwendungsfall das geeignetere Werkzeug ist. Beides hat seine Daseinsberechtigung. >>> 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. > > Windows wird auch sehr häufig verwendet. Liegt das an der überragenden > Qualität von Windows, oder an der installierten Basis, und daran, daß > die Leute nichts anderes kennen? Microsoft hat mit Windows einige Sachen echt richtig gemacht: Zum Beispiel die Abwärtskompatibilität war ein überzeugendes Argument. Dass man sogar in Win95 noch DOS-Programme "einfach so" ausführen konnte. Das ist nicht von der Hand zu weisen. >> Google macht Chrome. Bei Google arbeiten mit Sicherheit viele der >> brilliantesten Software-Designer. > > Und trotzdem konnten sie nicht gut genug programmieren, um die 70% > high-risk bugs zu vermeiden, die ihnen C als Fußangel ermöglicht hat. > Bist du sicher, daß das ein Argument für C ist? Rat mal, wie das bei > schlechteren Programmierern aussieht. Das sollte auch kein Argument für C sein, sondern, dass die Wahl der Programmiersprache eben eine Wahl ist, bei der mehrere Dimensionen eine Rolle spielen. Google-Ingenieure wissen sehr gut, dass korrektes C viel schwieriger zu schreiben ist, als andere Programmiersprachen. Und trotzdem sind die Vorteile derart überwältigend, dass sie es dennoch gewählt haben. Unter anderem, das muss man natürlich auch dazu sagen, weil sie eben den Tradeoff machen: Schnelle Software und dafür vielleicht den einen oder anderen Security-Bug in Kauf nehmen -- wohlweislich, dass Google ihre Security sehr gut im Griff hat und extrem flott Patches ausrollen kann und auch tut. Es ist halt alles ein Kompromiss, das ist nicht schwarz/weiß. >> Oder, was ich für wahrscheinlicher halte: Es gibt knallharte Gründe, >> warum die diese Abwägung getroffen haben. > > Natürlich: Angesichts der Popularität von C bekommst du für ein > Großprojekt kaum genügend Programmierer für eine andere > Programmiersprache zusammen. .net und Java. Ich hatte versucht, auf verschiedenen Stellenbörsen mal Vergleiche anzustellen, aber die Zahlen sind gefaked, die da angezeigt werden. Ist mir bei Stepstone und jobs.de passiert dass "Java Entwickler" und ".net Entwickler" diesebe Anzahl an Treffern haben (irgendwas hohes Vierstelliges), da ist was faul. Und die Seite von der Arbeitsagentur macht bei 200 Ergebnissen dicht. Also kann ich's nciht objektiv belegen, aber im Enterprise-Umfeld spielt C so gut wie keine Rolle. > Und natürlich, daß Bugs nichts kosten (Unter anderem, weil sich die > Leute an sie gewöhnt haben. Alles ist kaputt. Isnumalso. Netter Talk zum > Thema: https://www.youtube.com/watch?v=pW-SOdj4Kkk). Ah, ja den kannte ich schon. Ist ein guter Talk. > Im Augenblick ist es so, daß Softwarehersteller an Bugs Geld verdienen: > Sie sind ein Grund für Serviceverträge, Updates, neue Versionen. Ich bin > mit ziemlich sicher, daß die Softwarelandschaft deutlich anders aussehen > würde, wenn Bugs die Hersteller Geld *kosten* würden. Zweifelsfrei. Das ist traurig, aber mittlerweile Realität. Da kann jetzt aber C nichts dafür. Die ganze SaaS Mentalität geht mir auch auf den Senkel. Dass man z.B. Altium Designer nicht mehr kaufen kann, sondern mieten muss. Ekelhaft. >> Das ist genau das undifferenzierte Argument, das mich an der ganzen >> Diskussion hier so ärgert: Wer C einsetzt ist einfach nur betriebsblind. > > Wenn du hier komplett die Nachteile wegignorierst, bis zu dem Zeitpunkt, > wo ich sie dir an die Stirn tackere, ist das schon irgendwo > betriebsblind. Ich hingegen brauche nicht zu erwähnen, daß Dinge, die in > großem Maße eingesetzt werden, sicher irgendwo auch Vorteile haben: Das > ist selbstverständlich. Halt, halt! Hier gilt, völlig ungelogen, nämlich für mich das EXAKT selbe Gegenargument: Ich finde die Nachteile von C so derart und obszön offensichtlich (Speichersicherheit, Speicherverwaltung, Typsicherheit, teilweise obskure Syntax z.B. switch/case) dass ich sie nicht erwähne, weil sie jeder schon in- und auswendig kennt. >> Man stelle sich vor, ich würde mich in d.s.e hinstellen und sagen: >> "Schaut her, das hier ist der BESTE Transistor". > > Nur hab ich nichts als bestes bezeichnet. Und auch nicht C als > schlechtestes. Deine Einstellung ist mir lediglich gegenüber C zu > undifferenziert kritiklos. Nein, da hast du mein Argument definitiv in den falschen Hals gekriegt. Ich plädiere lediglich dafür, dass man für den Anwendungsfall entscheiden sollte, was das geeignete Werkzeug ist. Damit es halt nicht immer der Hammer ist, den man verwendet. Auf genau solche dogmatische, undifferenzierte Einstellungen reagiere ich völlig allergisch. > *Wenn* ich einen Tip für eine gute C-Ablösung nennen sollte, wäre das > wohl Rust. Die Benchmarks sehen ganz brauchbar aus [1]. Rust oder Go, sehe ich ganz ähnlich. Sind mir beide noch zu wenig "abgehangen" allerdings. Go gefällt mir persönlich besser von der Syntax her, da finde ich Rust teilweise schon sehr anstrengend. > Aber ich kenn > das Dings nicht persönlich, und vielleicht ist es lediglich die neueste > Sau, die durchs Dorf getrieben wird: Man wird es sehen. Nur finde ich es > etwas arm, daß wir seit 40 Jahren oder so die gleichen Fehler machen, > obgleich uns Software helfen könnte, diese Fehler zu vermeiden. Auf > welchem Wege auch immer. Neue Programmiersprachen sind in den letzten 10 Jahren wirklich inflationär erfunden worden. Und ich traue dem nicht so wirklich -- habe mal vor Jahren D programmiert und fand das wirklich gut, aber wenn da halt immer das Damoklesschwert "single source" über dem COmpiler schwebt, will ich das nicht machen. Mono sieht auch schick aus, aber wer weiß ob sich Microsoft da nicht irgendwann den Rappel kriegt und einen Lizenzstreit lostritt, wie es bei Oracle/Java der Fall war. Man muss aber schon auch dazusagen, dass selbst bei der ganz normalen alten C-Programmierung sowohl die Werkzeuge extrem viel besser geworden sind als vor 10-20 Jahren und damit auch die Bugvermeidung deutlich einfacher ist als früher. Die Diagostics vom Compiler sind so viel besser, Konstukte die früher üblich/erlaubt waren sind jetzt (in C11) deprecated, Tool-Unterstützung zum finden von UB (z.B. ubsan/asan) sind EXTREM gut. Aber man muss sie halt nutzen und zu nutzen wissen. Und zwar idealerweise von Anfang an, weil wenn du erst drauflosentwickelst und nach 50kLOC dann den ASAN anwirfst, wirst du vermutlich nicht mehr froh. Viele Grüße, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-08-22 01:46 +0200 |
| Message-ID | <gs63e7F7639U1@mid.individual.net> |
| In reply to | #262066 |
Am 22.08.19 um 01:04 schrieb Johannes Bauer: >>>>> 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). >> >> Ja, sicherlich. Es tut irgendwelche Dinge. Ob gut, billig, effektiv, >> nebenwirkungsfrei etc. ist völlig egal, wenn man wegen der installierten >> Basis, in die sich Änderungen und Erweiterungen einpassen müssen, kaum >> Alternativen hat und infolgedessen die Programmierer auch keine kennen: > > Naja, das glaube ich nicht so ganz. Im Business-Umfeld, wenn man mal von > embedded absieht, wird ja wohl auf der einen Seite .net gemacht und auf > der anderen Java. Allerdings erwähntest du oben konkret Linux, Android, das ganze Rückgrat des Internet, insofern ist das ein anderes Thema. >> Natürlich ist es die Schuld des Werkzeugs, wenn es Fehler ermöglicht, >> die mit einem anderen Werkzeug erst gar nicht vorkommen können. Was ist >> das denn für eine Frage? > > Das heißt, wenn ich mich mit einem Messer schneide, ist es die Schuld > des Messers, weil das mit einem anderen Werkzeug, dem Löffel, nicht > hätte passieren können? Nicht alles, was hinkt, ist ein Vergleich. Wenn du schneiden willst, wirst du wohl ein Werkzeug zum Schneiden brauchen. Aber wer braucht eine Programmiersprache zur Erzeugung von Bufferoverflows? - Wenn du unbedingt einen physischen Vergleich braucht, würde ich eine Schußwaffe ohne Sicherung, aber dafür mit besonders nervösem Abzug nennen: Mag für irgendwen nützlich sein, ist aber im Allgemeinen keine gute Idee. Auch wenn sie billig ist, und Django damit noch eine hundertstel Sekunde schneller. > Die Argumentation ist mir ein bisschen zu hilflos. Jedes Werkzeug hat > seine Vor- und Nachteile. Eine Kreissäge ist gefährlicher als ein > Fuchsschwanz. Und du wirst im Einzelfall abwägen, was für deinen > Anwendungsfall das geeignetere Werkzeug ist. Beides hat seine > Daseinsberechtigung. Aber nur deswegen, weil die Erzeuger der Software nicht die Nebenwirkung der hunderten Milliarden Schäden, die ich im Vorvorposting ansprach, tragen muß. Privatwirtschaftlich ist das natürlich super: Die Schäden trägt die Allgemeinheit, die Gewinne streicht das Softwarehaus ein. Volkswirtschaftlich dürfte das anders aussehen. Erinnert mich an Umweltverschmutzung: Ist nicht eingepreist, interessiert uns nicht, scheiß was drauf. Wären die Schäden durch Sicherheitsprobleme besser eingepreist, wären Programmiersprachen, die die weitaus größte Kategorie von Bugs ermöglichen, kein Thema mehr. Software dreimal so langsam (und danach sieht es nicht aus)? - Egal! Die Patches gegen Meltdown, Spectre, und der Virenscanner auf dem Rechner schaffen das auch, und das stört keine Sau. Insofern bin ich mir bezüglich der Daseinsberechtigung, jedenfalls außerhalb von Nischen, nicht mehr so wirklich sicher. 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 02:57 +0200 |
| Message-ID | <qjkpad$dof$1@news2.open-news-network.org> |
| In reply to | #262072 |
On 22.08.19 01:46, Hanno Foest wrote: >> Naja, das glaube ich nicht so ganz. Im Business-Umfeld, wenn man mal von >> embedded absieht, wird ja wohl auf der einen Seite .net gemacht und auf >> der anderen Java. > > Allerdings erwähntest du oben konkret Linux, Android, das ganze Rückgrat > des Internet, insofern ist das ein anderes Thema. Ja aber du schriebst doch, dass man keine Programmierer für was anderes als C findet, und das stimmt doch nicht, weil die ganzen Business-Informatiker eben Java und .net können. Oder hab ich dich da falsch verstanden? >> Die Argumentation ist mir ein bisschen zu hilflos. Jedes Werkzeug hat >> seine Vor- und Nachteile. Eine Kreissäge ist gefährlicher als ein >> Fuchsschwanz. Und du wirst im Einzelfall abwägen, was für deinen >> Anwendungsfall das geeignetere Werkzeug ist. Beides hat seine >> Daseinsberechtigung. > > Aber nur deswegen, weil die Erzeuger der Software nicht die Nebenwirkung > der hunderten Milliarden Schäden, die ich im Vorvorposting ansprach, > tragen muß. Privatwirtschaftlich ist das natürlich super: Die Schäden > trägt die Allgemeinheit, die Gewinne streicht das Softwarehaus ein. > Volkswirtschaftlich dürfte das anders aussehen. Erinnert mich an > Umweltverschmutzung: Ist nicht eingepreist, interessiert uns nicht, > scheiß was drauf. Das ist ein interessanter und richtiger Punkt. Der ist meines Erachtens allerdings nicht nur für sicherheitsrelevante Bugs zutreffend, sondern für alle Arten von Softwarefehlern. Es gibt bei allen Produkten, die ich kaufen kann, eine Gewährleistung nur bei Software ist es gang und gebe, dass der größte dysfunktionale Rotz an den Konsumenten vertickt wird und alle finden das okay. Ich bin da 100%ig bei dir, dass wir eben auch Produkthaftung bräuchten für Software. Im Prinzip gibt es die ja schon in Deutschland, aber in der Praxis ist mir kein Fall bekannt, wo mal jemand zur Rechenschaft gezogen würde. Allerdings, meine ich, kriegt man eben auch C sicher hin, wenn man das Geld investiert: Zeitaufwand, Testaufwand, Testwerkzeug. Aber klar, wenn Cisco einfach nur ganz schnell den neusten Router auf den Markt wirft, dann ist da halt Softwarequalität offenbar nur sekundär. Wenn überhaupt. Das ist wiederum der Gier der Konzerne geschuldet, Kapitalismus im Endstadium eben. > Wären die Schäden durch Sicherheitsprobleme besser eingepreist, wären > Programmiersprachen, die die weitaus größte Kategorie von Bugs > ermöglichen, kein Thema mehr. Software dreimal so langsam (und danach > sieht es nicht aus)? - Egal! Die Patches gegen Meltdown, Spectre, und > der Virenscanner auf dem Rechner schaffen das auch, und das stört keine > Sau. Virenscanner sind ja eh die größte Verarsche, die ich je gesehen habe. So ein totaler Müll. Die haben es echt geschafft, die Verantwortung den NUTZERN in die Schuhe zu schieben und können dieses ekelhafte "Produkt" Virenscanner sogar noch VERKAUFEN. Das ist echt eine Meisterleistung. > Insofern bin ich mir bezüglich der Daseinsberechtigung, jedenfalls > außerhalb von Nischen, nicht mehr so wirklich sicher. Ja naja, ich mag manche Aspekte von C und andere weniger. Wenn es geht, programmiere ich mittlerweile am liebsten Python. Ganz ohne C könnte ich glaube ich aber nicht, gerade dass es so ubiquitär ist über alle Architekturen und Platformen hinweg, das macht es schon quasi zu einem extrem guten Makroassembler. Viele Grüße, Johannes -- "Performance ist nicht das Problem, es läuft ja nachher beides auf der selben Hardware." -- Hans-Peter Diettrich in d.s.e.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-21 20:28 +0200 |
| Message-ID | <gs5h9jF3eqlU1@mid.individual.net> |
| In reply to | #262018 |
Am 21.08.2019 um 19:17 schrieb Johannes Bauer: > 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. Jupp, insbesondere die Lücken für Viren etc. >> 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, Die ersten C Compiler und Bibliotheken waren auch nicht besonders "gescheit". Wenn die in ihrem K&R Stand verblieben wären, würde sich heute auch niemand mehr mit C befassen. >> 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. Der Vergleich von Äpfeln mit Birnen, typisch für viele Apostel :-( > Mach doch mal Messungen. Gerne auch Pascal vs. C. Das würde ich *Dir* einmal empfehlen, mir ist der kaum meßbare Unterschied bekannt. >> 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. Nun ja, mit solchen Aposteln lohnt sich eine weitere Diskussion 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, Eben weil ich mitbekomme, was sich da abspielt :-] schlicht und ergreifend keine Ahnung. Ich schon. Deine Beschränktheit auf C++ disqualifiziert Dich nur. Prählen könntest Du eher mit Kenntnis von C#, Ada oder OPL. Aber mit C Scheuklappen... DoDi
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-21 20:58 +0200 |
| Message-ID | <qjk48f$tg9$1@news2.open-news-network.org> |
| In reply to | #262021 |
On 21.08.19 20:28, Hans-Peter Diettrich wrote: >> Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen >> IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima >> funktioniert. > > Jupp, insbesondere die Lücken für Viren etc. Uargh, du kennst also nicht mal den Unterschied zwischen Viren und Würmern. >> 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, > > Die ersten C Compiler und Bibliotheken waren auch nicht besonders > "gescheit". Wenn die in ihrem K&R Stand verblieben wären, würde sich > heute auch niemand mehr mit C befassen. Und wieso meinst du hat sich jemand die Mühe gemacht, für C die Compiler zu verbessern? Einfach nur aus Jux & Dollerei? Reiner Zufall? >>> 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. > > Der Vergleich von Äpfeln mit Birnen, typisch für viele Apostel :-( Was sind hier denn jetzt Äpfel und was Birnen? Es gibt *dutzende* ähnliche Implementierungen von Software in sowohl C als auch in Java. Vom Webserver bis zur RS232-Library ist da alles dabei. Und im Gegenteil, die Java-Befürworter vergleichen sich ja gern selbst in der Performance mit C, das ist da ja nämlich der Goldstandard. >> Mach doch mal Messungen. Gerne auch Pascal vs. C. > > Das würde ich *Dir* einmal empfehlen, mir ist der kaum meßbare > Unterschied bekannt. Soll ich mir echt die Mühe machen, damit du mit genauso heruntergelassenen Hosen dastehst, wie Wolfgang? Wenn bei ner Pascal RC4 Implementierung dann Faktor 10 unterschied rauskommt, ist das noch "kaum messbar"? Oder ab welchem Faktor wirst du öffentlich proklamieren, dass du kompletten Unsinn geschrieben hast? Was ich vermute: Wenn ich solche Ergebnisse tatsächlich MESSE und dann hier poste, dann wirst du nur wieder das Ziel ändern: "Ach ne der COmpiler ist schlecht, das liegt überhaupt nicht an der Sprache blablabla". Weil du nicht die Größe hast, deine falschen Behauptungen zu revidieren. >>> 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. > > Nun ja, mit solchen Aposteln lohnt sich eine weitere Diskussion nicht. Ich *kenne* C++. Du hast Null Ahnung und kannst nicht EINEN EINZIGEN Beleg anführen für deine Behauptung. Statt eine zu liefern spielst du die beleidigte Leberwurst und hoffst, dass niemand deine komplette Ahnungslosigkeit bemerkt. >> 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, > > Eben weil ich mitbekomme, was sich da abspielt :-] Was bekommst du denn mit? Gib es doch zu: Du hast doch keinerlei Ahnung von den Sprachfeatures, die ich da gerade aufgelistet habe, richtig? Und musstest sie alle googeln, oder? > schlicht und ergreifend keine Ahnung. Ich schon. > > Deine Beschränktheit auf C++ disqualifiziert Dich nur. Prählen könntest > Du eher mit Kenntnis von C#, Ada oder OPL. Aber mit C Scheuklappen... Na du bist ja witzig -- denn DU warst der, der C++ ins Spiel gebracht hat. Du! Und dann stellt sich heraus, dass ich mich da ganz gut auskenne. Peinlich für dich, so fliegt deine Unkenntnis halt auf ganzer Linie auf. Wenn du wissen willst, was für Sprachen ich sonst noch so programmiere, kannst du ja mal in mein Github Repo schauen. Aber ich finde es echt immernoch erstaunlich dass du, als Informatiker (schon, oder?) die himmelschreiende Arroganz hast, anderen Leuten vorschreiben zu wollen was eine "bessere" Programmiersprache ist. Du siehst ein Auto und sagst, die machen ganz viele Unfälle und das ist schlimm. Autos sind megaschlecht. UNd dann stellst du mir ein Fahrrad hin und sagst: "Hier das ist VIEL besser, dem Auto total überlegen, und die Geschwindigkeit ist echt nicht so wichtig". Das ist aber halt eben MEINE Entscheidung als Ingenieur, was in MEINER Applikation wichtig ist und nicht die eines vollkommen Ahnungslosen, sich selbst überschätzenden DoDi. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-21 23:10 +0200 |
| Message-ID | <gs5rb7F5imlU3@mid.individual.net> |
| In reply to | #262024 |
Am 21.08.2019 um 20:58 schrieb Johannes Bauer: [...] <gähn> > Gruß, > Johannes DoDi
[toc] | [prev] | [next] | [standalone]
| From | Stefan Engler <stefan@epiket.de> |
|---|---|
| Date | 2019-08-21 21:29 +0200 |
| Message-ID | <qjk61t$9mt$1@dont-email.me> |
| In reply to | #262018 |
Am 21.08.2019 um 19:17 schrieb Johannes Bauer: >> 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 Pascal lässt sich genauso verwenden wie C und es gibt auch einige komerzielle Programme mit Pascal/Delphi. Wenn die schlecht übersetz- baren Funktionen vermieden werden, ist Pascal fast so schnell wie C. Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich selbst modifizierendes Programm übersetzt werden. Dies ist sehr aufwendig und für Harvard-Architekturen sogar untauglich. In C gibt es ein unglaubliche Vielzahl an Bibliotheken, die sich einfach nutzen lassen. Ganauso könnte ich aber auch argumentieren, dass Mono oder .Net oder C++ mit den Vtables von Windows wesentlich besser umgehen kann. Ich könnte jetzt mit FORTH eine Code für Atmel schreiben und dann auch noch einen Code für 8051 im Blauzahn-Modul oder ich nehme einfach die C-Bibliothek und ändere ein "fertiges" Beispiel ab. Was werde ich wohl machen? Ich kenne Leute die finden Basic (Bascom-AVR) aufgrund der vielen libs ganz toll. Warum nicht? Wenn es in den Bereich von DO-178C, ISO 26262 ... geht, tut man sich mit spezielle dafür entwickelten Programmiersprachen leichter. (und ein großer Hersteller hat es dennoch MAX-imal vergeigt) Es gibt Wettbewerbe ab wann eine "Sprache" voll Turing tauglich ist. Es wird immer Software in einer unüblichen Programmiersprache geben, wo jemand ein gutes Auskommen findet. Bei Excel-Formeln finde ich es problematisch, dass ich nicht wirklich ein Rücksprungadresse für Funktionen zur Verfügung habe. Ich kann zwar mit =Aufrufen(kernel32,rtlmovememory... ein RET positionieren aber, dass ist nicht der Sinn. Außerdem kann ich ab 2016er Versionen keine Makro-Formeln mehr in normalen Tabellenblätter als Namen deklarieren.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-21 22:12 +0200 |
| Message-ID | <qjk8k7$15u$1@news2.open-news-network.org> |
| In reply to | #262031 |
On 21.08.19 21:29, Stefan Engler wrote: > Am 21.08.2019 um 19:17 schrieb Johannes Bauer: >>> 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 > > Pascal lässt sich genauso verwenden wie C und es gibt auch einige > komerzielle Programme mit Pascal/Delphi. Wenn die schlecht übersetz- > baren Funktionen vermieden werden, ist Pascal fast so schnell wie C. Ich vermute mal, und das ist jetzt ausrücklich meine Mutmaßung -- das das auf den Usecase ankommt. Insbesondere glaube ich, dass bei einem Benchmark, bei dem einem Pointergefriemel hilft, Pascal deutlich langsamer abschneiden würde als C. Vielleicht messe ich ja wirklich mal. Würde mich ehrlich interessieren und von Leuten wie DoDi kriegt man ja keine objektiven Zahlen sondern nur "ich hab das gemessen aber sag dir mein Ergebnis nicht ätschbätsch" > Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund > des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich > selbst modifizierendes Programm übersetzt werden. Dies ist sehr > aufwendig und für Harvard-Architekturen sogar untauglich. Ja! Danke! JEDE Programmiersprache hat Nachteile, JEDE hat Vorteile. Genau das ist das, wie ein Ingenieur denkt. Ich muss einen Kompromiss finden, es gibt X verschiedene Dimensionen und halt üblicherweise keine global Optimale. Sondern jeweils nur in bestimmten Dimensionen optimal, und die muss eben jeder für sich (und für den jeweiligen Anwendungsfall) optimieren. > In C gibt es ein unglaubliche Vielzahl an Bibliotheken, die sich einfach > nutzen lassen. Ganauso könnte ich aber auch argumentieren, dass Mono > oder .Net oder C++ mit den Vtables von Windows wesentlich besser umgehen > kann. Genau, das ist beides vollommen richtig. Und vollkommen legitim. [...] > Es wird immer Software in einer unüblichen Programmiersprache geben, wo > jemand ein gutes Auskommen findet. Kann ich nur 100%ig unterschreiben. Die allermeisten Programmiersprachen haben ihre Daseinsberechtigung. Und die allermeisten Programmiersprachen sind nicht deswegen erfunden worden, weil den Erfindern langweilig war, sondern weil sie halt Wert auf einen Aspekt X gelegt haben, die Programmiersprache Y nicht so hatte. Man muss aber halt ehrlich in seinen Vergleichen sein und nicht Cherrypicking mit bestimmten Aspekten betreiben. Viele Grüße, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Alfred Gemsa <gemsa@gmx.de> |
|---|---|
| Date | 2019-08-21 22:33 +0200 |
| Message-ID | <qjk9qc$u69$1@news.albasani.net> |
| In reply to | #262036 |
Am 21.08.2019 um 22:12 schrieb Johannes Bauer: > Ich vermute mal, und das ist jetzt ausrücklich meine Mutmaßung -- das > das auf den Usecase ankommt. Insbesondere glaube ich, dass bei einem > Benchmark, bei dem einem Pointergefriemel hilft, Pascal deutlich > langsamer abschneiden würde als C. Vielleicht messe ich ja wirklich mal. > Würde mich ehrlich interessieren und von Leuten wie DoDi kriegt man ja > keine objektiven Zahlen sondern nur "ich hab das gemessen aber sag dir > mein Ergebnis nicht ätschbätsch" Quatsch, in Delphi kannst du auch *jede* Schweinerei kodieren, nur es geht da auch so, dass Delphi im Gegensatz zu einigen C-Programmen nicht als "Write-Only-Language" daherkommt. Meine Lieblings-URL dazu ist http://www.henning-thielemann.de/CHater.html Lies das mal in Ruhe, und vielleicht auch einige weiterführende Links. >> Es wird immer Software in einer unüblichen Programmiersprache geben, wo >> jemand ein gutes Auskommen findet. > > Kann ich nur 100%ig unterschreiben. Die allermeisten Programmiersprachen > haben ihre Daseinsberechtigung. Und die allermeisten Programmiersprachen > sind nicht deswegen erfunden worden, weil den Erfindern langweilig war, > sondern weil sie halt Wert auf einen Aspekt X gelegt haben, die > Programmiersprache Y nicht so hatte. > > Man muss aber halt ehrlich in seinen Vergleichen sein und nicht > Cherrypicking mit bestimmten Aspekten betreiben. Ich habe 25 Jahre Delphi hinter mir, und es gab kein Problem, was nicht zu lösen war, auch hardwarenahe Anwendungen, die heftige Datenraten abliefern mussten. Schneller Anwendungen gehen m.E nur noch durch CUDA, aber das ist mir als Alter Sack zu hoch (seit einem Jahr im Ruhestand). Gruß, Alfred.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-21 23:41 +0200 |
| Message-ID | <qjkdqd$5b7$1@news2.open-news-network.org> |
| In reply to | #262039 |
On 21.08.19 22:33, Alfred Gemsa wrote: >> Ich vermute mal, und das ist jetzt ausrücklich meine Mutmaßung -- das >> das auf den Usecase ankommt. Insbesondere glaube ich, dass bei einem >> Benchmark, bei dem einem Pointergefriemel hilft, Pascal deutlich >> langsamer abschneiden würde als C. Vielleicht messe ich ja wirklich mal. >> Würde mich ehrlich interessieren und von Leuten wie DoDi kriegt man ja >> keine objektiven Zahlen sondern nur "ich hab das gemessen aber sag dir >> mein Ergebnis nicht ätschbätsch" > > Quatsch, in Delphi kannst du auch *jede* Schweinerei kodieren, Dann ist es ja genauso unsicher wie C. Und wieder ist Cherrypicking am Start: In einem Thread wird behauptet, Pascal sei C überlegen, weil es genau diese Fähigkeit nicht hat. Du sagst jetzt, ja nee, ich kann das genauso schlecht wie C, unsicheren Speicherzugriff. > nur es > geht da auch so, dass Delphi im Gegensatz zu einigen C-Programmen nicht > als "Write-Only-Language" daherkommt. Nur weil es sich schrecklich anhört, wenn ich Geige spiele, heißt das nicht, dass die Geige ein untaugliches Musikinstrument ist. > Meine Lieblings-URL dazu ist > > http://www.henning-thielemann.de/CHater.html Naja, "Hass" ist schonmal ein ganz schlechtes Argument, sondern eher was für Dogmatiker. Leute also, die lieber Glauben als zu wissen. Inhaltlich extrem viel amateurhafte Anfängerfehler, die in der Praxis keine Rolle spielen. Und für die, nebenbei gemerkt, jeder vernünftige Compiler dutzendweise Warnungen generiert. > Lies das mal in Ruhe, und vielleicht auch einige weiterführende Links. Ja du, ich programmiere jetzt seit etwa 20 Jahren C, ich glaube ich kenne die Sprache ganz gut. Ihre Stärken und Schwächen. Aber danke, trotz herablassendem Ton. >> Man muss aber halt ehrlich in seinen Vergleichen sein und nicht >> Cherrypicking mit bestimmten Aspekten betreiben. > > Ich habe 25 Jahre Delphi hinter mir, und es gab kein Problem, was nicht > zu lösen war, auch hardwarenahe Anwendungen, die heftige Datenraten > abliefern mussten. Mit Delphi kriegst du halt aber z.B. keinen Kerneltreiber implementiert. Ist jetzt nur ein Beispiel, aber das habe ich schon gemacht. Delphi habe ich früher auch mal programmiert, insbesondere das GUI RAD hat mir wirklich gut gefallen. Sowas gut gelöstes suche ich immernoch vergeblich (obwohl GTK/Glade da mittlerweile fast, aber nur fast, rankommt). > Schneller Anwendungen gehen m.E nur noch durch CUDA, aber das ist mir > als Alter Sack zu hoch (seit einem Jahr im Ruhestand). Kommt immer drauf an, was man macht, was sich massiv parallelisieren lässt läuft natürlich auf einer GPU schneller. Auch sowohl CUDA als auch OpenCL orientieren sich syntaktisch übrigens an C++/C, nur ganz nebenbei. Viele Grüße, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Alfred Gemsa <gemsa@gmx.de> |
|---|---|
| Date | 2019-08-22 00:18 +0200 |
| Message-ID | <qjkg0c$ih7$1@news.albasani.net> |
| In reply to | #262055 |
Am 21.08.2019 um 23:41 schrieb Johannes Bauer: >> Quatsch, in Delphi kannst du auch *jede* Schweinerei kodieren, > > Dann ist es ja genauso unsicher wie C. Und wieder ist Cherrypicking am > Start: In einem Thread wird behauptet, Pascal sei C überlegen, weil es > genau diese Fähigkeit nicht hat. Du sagst jetzt, ja nee, ich kann das > genauso schlecht wie C, unsicheren Speicherzugriff. Ich bezog mich nur auf das hochgelobte "Pointergepfriemel". Der Kompiler ist schon richtig schlau, dass er vor unsicherem Code warnt. Nur beachten muss man das ja nicht. >> nur es >> geht da auch so, dass Delphi im Gegensatz zu einigen C-Programmen nicht >> als "Write-Only-Language" daherkommt. > > Nur weil es sich schrecklich anhört, wenn ich Geige spiele, heißt das > nicht, dass die Geige ein untaugliches Musikinstrument ist. Mozart ist besser als Katzenjammer ;-) > Mit Delphi kriegst du halt aber z.B. keinen Kerneltreiber implementiert. > Ist jetzt nur ein Beispiel, aber das habe ich schon gemacht. Das musst du mir erklären, ich sag mal ins Blaue, das stimmt nicht. > Delphi habe ich früher auch mal programmiert, insbesondere das GUI RAD > hat mir wirklich gut gefallen. Sowas gut gelöstes suche ich immernoch > vergeblich (obwohl GTK/Glade da mittlerweile fast, aber nur fast, rankommt). :-) Der Wermutstropfen: Delphi kostet richtig viele Ocken, C-GUIs gibt es meist für Umme. > Kommt immer drauf an, was man macht, was sich massiv parallelisieren > lässt läuft natürlich auf einer GPU schneller. Auch sowohl CUDA als auch > OpenCL orientieren sich syntaktisch übrigens an C++/C, nur ganz nebenbei. Da hast du leider recht. Gruß, Alfred.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-22 01:17 +0200 |
| Message-ID | <qjkjdg$9no$1@news2.open-news-network.org> |
| In reply to | #262061 |
On 22.08.19 00:18, Alfred Gemsa wrote: >> Mit Delphi kriegst du halt aber z.B. keinen Kerneltreiber implementiert. >> Ist jetzt nur ein Beispiel, aber das habe ich schon gemacht. > > Das musst du mir erklären, ich sag mal ins Blaue, das stimmt nicht. Hmmm. Naja, wie würdest du das denn machen? Hier hat das mal jemand gefragt: https://stackoverflow.com/questions/2263474/can-i-write-windows-drivers-with-delphi-2010 Bei Linux wüsste ich gar nicht, wo man anfängt. Also dir fehlen ja alle Language Bindings. Die konnte man glaube ich irgendwie kompatibel deklarieren, wenn ich mich recht errinere. Ich hab mal Win32-API Programmierung gemacht in Delphi und das ging auch irgendwie. Aber das ist echt zu lange her. >> Delphi habe ich früher auch mal programmiert, insbesondere das GUI RAD >> hat mir wirklich gut gefallen. Sowas gut gelöstes suche ich immernoch >> vergeblich (obwohl GTK/Glade da mittlerweile fast, aber nur fast, >> rankommt). > > :-) > > Der Wermutstropfen: Delphi kostet richtig viele Ocken, C-GUIs gibt es > meist für Umme. Puh, in der Tat. Habe gerade mal nachgesehen, die Professional-Version fängt bei 1.5kEUR an. Die nehmen's aber auch von den Lebenden. Als ich Delphi programmiert habe, das war erst Delphi 1 bis Delphi 3 und später irgendwann glaube ich Delphi 6, da hat das nie mehr als 300. Hm ja Mark oder EUR? Weiß nicht mehr. Die Delphi 6 Personal glaube ich sogar 100, ja EUR bestimmt oder. Dass sich das so krass im Preis erhöht hat, ist echt schade. Kann eh nicht verstehen dass Borland so verscherbelt wurde. Viele Grüße, Johannes -- "Performance ist nicht das Problem, es läuft ja nachher beides auf der selben Hardware." -- Hans-Peter Diettrich in d.s.e.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | de.sci.electronics
csiph-web