FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "

[Eric Bruecklmeier]

Am 20.08.2019 um 13:48 schrieb Wolfgang Allinger:

usenet@nerdcraft.de> (Eric Bruecklmeier) wrote:

[...]

Es ist tatsächlich häufig so, daß irgendeine neue Erkenntnis für den
einen Richtungsweisend sein kann, während Andere gar nix damit anfangen
kĂśnnen. Ging mir z.B. mit ruby und netlogo so. Aber alles keine GrĂźnde
persĂśnlich zu werden - zumal wenn man den professionellen Hintergrund
des GegenĂźber gar nicht kennen kann...

ACK, aber bei den AnwĂźrfen von Johannes ist mir der Kragen geplatzt, muss
auch mal sein

Der Kommentar zielte nicht primär auf Dich ab...


--
Ich muss nicht kultiviert *aussehen* - ich bin es.

Profiklaus in d.r.f.

 

[Wolfgang Allinger]

On 20 Aug 19 at group /de/sci/electronics in article gs2860FcnqbU1@mid.individual.net
<usenet@nerdcraft.de> (Eric Bruecklmeier) wrote:

Am 20.08.2019 um 13:48 schrieb Wolfgang Allinger:

usenet@nerdcraft.de> (Eric Bruecklmeier) wrote:

[...]

ACK, aber bei den Anwürfen von Johannes ist mir der Kragen geplatzt, muss
auch mal sein

Der Kommentar zielte nicht primär auf Dich ab...

Auch gut, Schuh wieder ausgezogen



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!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

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!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 19 Aug 19 at group /de/sci/electronics in article gs0huiF1nn6U1@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 19.08.2019 um 22:03 schrieb Ewald Pfau:

Nun, in Forth macht man das im direkten Zugriff, was bei den
Riesencompilern erst das Resultat der Übersetzung ist, wo ja das
Datenhandling im Geiste immer noch und weiterhin mit der Vorstellung von
Spaghetti-Code funktioniert, erst die großen Compiler machen daraus eine
Übersetzung, wodurch die Daten in die Schachtelung via Stack hineingenommen
werden.

Ich sehe keinen großen Vorteil beim Programmieren, wenn jedes einzelne
FORTH Wort den Stack ändert, womit sich die Offsets aller darin
liegenden temporären Variablen ändern. Dummerweise reicht es meist
nicht, nur die obersten zwei Elemente des Stacks zu verarbeiten. Da ist
es durchaus hilfreich, wenn der Compiler sich um die Adressrechnung
kümmert. Spätestens bei 3 ineinander verschachtelten FOR Schleifen
möchte ich kein UPN mehr schreiben, und stattdessen lieber auf benannte
lokale Variablen zugreifen. Aber wie bereits erwähnt, number chrunching
ist ja nicht die Domäne von FORTH.

FORTH hat I und J (früher sogar K) für die Indizes der übergeordneten
Loops. Da kannste dann in der Schleife direkt die Werte auf den Stack
bringen und weiterwuseln.

Praktisch, wenn man sich durch (String-)Arrays oder sonstige
mehrdimensionalen SpeicherFrames hangeln muss. Habs aber selten benutzt.
Bei embedded gibts kaum so einen wilden Datenhaufen.

Ich persönlich mag keine Localen Variablen, wird ein übles Gefrickel und
man(ich) verliere die Fähigkeiten von Reentrant Definitionen.

Wenn man gut genug ausfakturiert, werden die Worte klein und übersichtlich
und leicht zu testen. Alles was mehr als 3-4 Zeilen hat, ist eh zu
umständlich.

Was anderes ist latürnich ein ellenlanger Ablauf für eine
Maschinensteuerung samt Mess und Kalibrier Aufgaben. Die wird dann
zeilenweise abgehampelt und nur mit spez. Worten s.u. bedarfsweise
angehalten.

Ich hab den kooperativen MultiTasker aus F-PC debugged und so sauber
gemacht, dass selbst ABORTs in Tasks klappten. Was in Augen der FORTH
Gurus samt Tom Zimmer nicht möglich sei, egal, das wusste ich nicht und
habs sauber hinbekommen

Meine ordentliche Erfahrung in RT/IR und HW/SW zahlen sich da eben aus.
Dazu noch einen 100us sauberen umgebogenen Windoof Timer IR Service, der
eine Gruppe von 16 Timern/Uhren/Flaggen abhampelte und den normalen DOS/
Windoof Timer dann alle 55msec (oder so) ausführte. Ging von DOS bis XP
prima.

Geht nur ab W7(?) nicht mehr, da liessen sie einen nicht mehr an den
Timer, bzw. ich hatte da keine Lösung gefunden.


Eine weitere Extension von mir waren dann eine Gruppe von Worten, die eine
Task auf ein externes Ereignis (also Zelle) warten lies, bis TRUE wurde
und dann zurückkehrte bzw. wenn die vorgegebene Zeit abgelaufen war.

WAIT AWAIT rechneten dann einen Grenzwert für meine Sysclock aus, nach
deren Überschreitung aus WAIT/AWAIT zurückgekehrt wurde.

Die Restzeit des Timers wurde dann als Flag übergeben.
So waren praktisch keinen WarteSchleifen mehr im Ablauf zu sehen.


WAITms WAITsec ( nTICKs -- ) für reine Tickerwarte Zeiten
AWAITms AWAITsec ( aCELL nTicks -- ? )

innerhalb WAIT und AWAIT steckte dann PAUSE

\ aCELL = zu überwachende Zelle
\ nTicks = timer ticks msec|sec

Sah dann in einer Task etwa so aus

: SHOWtask \ soll POS 77 anfahren

17 VENTIL auf
3 LICHT aus
55 mm Rechts fahren
7 WAITsec
17 VENTIL zu
4 LICHT an
' Pos77 578 AWAITms
DUP 0=
?ABORT" Position 77 nicht erreicht"
TUEDIES
MACHDAS...
END-TASK
;

so mal ein Beispiel für einen dt. Kunden, deren Serviceleute konnten dann
die Abläufe in dt. nachvollziehen. Die "Programmstopper" hab ich dann nach
links rausgezogen, damit man sich leichter durch die Quelle durchhangeln
kann.



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!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Gerhard Hoffmann]

Am 21.08.19 um 00:56 schrieb Wolfgang Allinger:

FORTH hat I und J (frĂźher sogar K) fĂźr die Indizes der Ăźbergeordneten
Loops. Da kannste dann in der Schleife direkt die Werte auf den Stack
bringen und weiterwuseln.

Das sind ja fast Zustände wie in Fortran.

God is real unless declared integer!

 

[Gerhard Hoffmann]

Am 21.08.19 um 02:23 schrieb Gerhard Hoffmann:

Am 21.08.19 um 00:56 schrieb Wolfgang Allinger:

FORTH hat I und J (frĂźher sogar K) fĂźr die Indizes der Ăźbergeordneten
Loops. Da kannste dann in der Schleife direkt die Werte auf den Stack
bringen und weiterwuseln.

Das sind ja fast Zustände wie in Fortran.

God is real unless declared integer!

Ingrid sagt noch, dass identifier mit ijk am Anfang automatisch
als integer vordeklariert waren.

 

[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:

FORTH hat I und J (früher sogar K) für die Indizes der übergeordneten
Loops. Da kannste dann in der Schleife direkt die Werte auf den Stack
bringen und weiterwuseln.

Das sind ja fast Zustände wie in Fortran.

Jau, nur leichter zu verstehen und debuggen, weil gute Namen und Wegfall
der Klammeritis. Der größte Vorteil: interaktiv, keine stundenlangen
Copiler-Läufe.

Kann mich noch entsinnen an den 1. Assembler für 8080, der für mich
zugreifbar war (1978?). Der war in FORTRAN geschrieben und lief auf einer
TR440 im AEG Forschungszentrum in FFM. Ich hab alles in meinem Büro in
Wuppertal auf ner hp2100 per ASR33 und Facit Stanze auf LOchstreifen
gefummelt, nen Termin in FFM ausgemacht, mit meinem 914 nach FFM gedüst,
das Geraffel abgegeben bei den Weisskitteln, ne Stunde in der Kantine
verbracht und dann zur 'Materialausgabe'.

Wenn da nen 20cm dicker Stapel Leporello Papier lag, wusste ich schon:
Speicherdump der 440, Fehler im Compiler oder dem Assembler, neuer Versuch
nach Abgabe von zusätzlichen Lochkarten mit den Korrekturen oder Würgarum.

Wenns nur nen 1cm hoher Stapel war, lagen mein Listing, LS und der neue
BIN LS vor. Listing kontrollieren ob fehlerfrei, wenn nicht, dann noch ne
LK und Kantinen/Kaffe Runde. Zurück nach W, BIN LS in EPROMs gebrannt, auf
8080 Platine gesteckt und weiter gings.

Fahrtzeit W-FFM unter 1h, ja damals ging das noch mit dem 914. Hat Spass
gemacht.

Nach so ca. 5 Reisetagen kam dann endlich mein Entwicklungsrack mit 8080
und einer EPROM Karte mit gebranntem Macro ASM von einem Stuttgarter Ing-
Büro. Der konnte mit ner ASR33 umgehen, nix Stanze und Leser

> God is real unless declared integer!

Jau

vorher erfand der Teufel noch den FORTRAN Compiler für die AEG 60/10. Eine
absolute Scheisshausidee. War ein 32 (!!!) Pass Compiler. Die 60/10 hatte
4 pages zu je 1k(12bit). Da wurde dann der 1. Pass per LS in page 1
eingelesen, die Source in die 2. page, die 3. page als intermediate und
die 4. page fürs OBJ.

Dann wieder der LS (300m Rolle) mit dem Fortan Compiler in den Leser,
nächster pass rein, LS blieb stehen, der Pass hampelte sich an Source und
intermediate weiter, nach Minuten wurde dann der nächste Pass eingeladen
und und und. d.h. der Compiler rannte auf LS an der Quelle im
(Kern)Speicher vorbei. 1 page konnte ca. 2-3k Source in komprimierter Form
(auch so einen AEG Spezialität, gab extra ein Umkodierer-LS dafür, lief in
einem Pass!). Wenn die Quelle grösser war, dann eben x-mal 32 Passes

Wie sich später rausstellte, hatten die Crackpots bei AEG Seeligenstadt
das nur mit irgendeinem aufgeblähten 'Hello World' probiert. Und ich war
der 1. Vollidiot der da versuchte einen in FORTRAN geschriebenen TRACON
Compiler (TRAffic Configurator und ONline controller, HLL für
Ampelsteuerungen) auf die 60/10 zu portieren. Auf hp2100 lief der
einwandfrei. Ich hab dann aufgegeben, unhandelbar mit 32 passes.

Und ich war ein Meister im Umgang mit 300m LS, der schnellste Flicker und
Aufroller mit nem umgebauten Elektrorasierer/Radierer (gabs u.a. bei hp)
mit Teller für 20m und hab damit Vollgas freihändig in der Luft 300m
aufgerollt. Oft genug mit dem Stunt Bier gewonnen im Lochstreifen Zirkus


Mit der Aktion 914/FFM s.o. hab ich dann einen MiniTRACON Compiler für den
8080 entwickelt, so dass die Verkehrsingenieure ihre TRACON Sourcen
reinlesen konnten, später dann auch per LS-Leser (hp mit 400 Sprossen/sec)
und Facit Stanze (75 Sprossen/sec), die TTY schaffte nur 10/sec.

Ich staune, was ich alter Sack noch alles im Kopp habe

Dann gabs da auch statt Rollen noch die Faltlochstreifen (DEC) und die
kleinen Real-to-real Rollen (auch DEC) waren auch nicht schlecht, gab
weniger Streifensalat.

Später kam dann die Spanabhebende DV (Floppy) und meine LS Künste waren
nicht mehr gefragt

Und dann ab 1980/84 FORTH

Uff OT Kurve gerade noch gerissen.





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!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Helmut Schellong]

On 08/21/2019 12:30, Wolfgang Allinger wrote:

On 20 Aug 19 at group /de/sci/electronics in article qji2ur$jdi$1@solani.org
dk4xp@arcor.de> (Gerhard Hoffmann) wrote:

Das sind ja fast Zustände wie in Fortran.

Jau, nur leichter zu verstehen und debuggen, weil gute Namen und Wegfall
der Klammeritis. Der größte Vorteil: interaktiv, keine stundenlangen
Copiler-Läufe.

Compilerläufe dauern bei mir bei Quellen mit etwa 5 MB Größe
seit den 1990er Jahren etwa 4-8 Sekunden.
Das ist schlicht unbedeutend.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm

 

[h.-d.winzler]

Am 18.08.19 um 23:50 schrieb Gerhard Hoffmann:

Am 18.08.19 um 22:13 schrieb Gerrit Heitsch:
On 8/18/19 9:57 PM, Gerhard Hoffmann wrote:



Die 68000-Familie.

zu verstehen. Auch nicht richtig schnell, irgendwie.

mW sind 68000 Derivate im industriellen, besonders im
Sicherheitsbereich, weit Ăźberwiegend noch im Einsatz.

--
---hdw---

 

[Gerhard Hoffmann]

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

 

[Johannes Bauer]

On 21.08.19 13:27, Helmut Schellong wrote:

Jau, nur leichter zu verstehen und debuggen, weil gute Namen und Wegfall
der Klammeritis. Der größte Vorteil: interaktiv, keine stundenlangen
Copiler-Läufe.

Compilerläufe dauern bei mir bei Quellen mit etwa 5 MB Größe
seit den 1990er Jahren etwa 4-8 Sekunden.
Das ist schlicht unbedeutend.

Vielleicht nutzt der Wolfi ja einen C-Compiler, der in Forth
implementiert wurde. Mit Faktor 500 auf deine 4-8 Sekunden kommt man auf
die von Wolfgang geschriebene Größenordnung.

SCNR,
Johannes

 

[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.

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

 

[Johannes Bauer]

On 20.08.19 13:48, Wolfgang Allinger wrote:

ACK, aber bei den AnwĂźrfen von Johannes ist mir der Kragen geplatzt, muss
auch mal sein

Ja Mensch, das ist aber auch echt schlimm, wenn man objektiven Messungen
nur subjektives Gelaber entgegenzusetzen hat und nicht mal die geringste
Kompetenz, Messungen selbst zu ĂźberprĂźfen. Von dem nĂśtigen Hintergrund,
gemessene Differenzen zu erklären, mal ganz zu schweigen.

Voll gemein, die Realität! Und voll gerechtfertigt, dein Anfall!

XOXOXOXO
Johannes

 

[Hans-Peter Diettrich]

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

 

[Hans-Peter Diettrich]

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

 

[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.

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

 

[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.

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

 

[Hans-Peter Diettrich]

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

 

[Stefan Engler]

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.

 

[Stefan Engler]

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.