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

Auch gut, Schuh wieder ausgezogen :)

Wolfgang

THX FULLACK gebunkert :)

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

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

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

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

Am 21.08.19 um 00:56 schrieb Wolfgang Allinger:

Das sind ja fast Zustände wie in Fortran.

God is real unless declared integer!

Am 21.08.19 um 02:23 schrieb Gerhard Hoffmann:

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

Am 21.08.2019 um 00:56 schrieb Wolfgang Allinger:

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

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

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

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

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

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

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.

Am 18.08.19 um 23:50 schrieb Gerhard Hoffmann:

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

Am 21.08.19 um 12:30 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

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

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

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

Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht so fehlerbehaftet.

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

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima funktioniert.

Ahja, alle sind doof nur du hast das Licht gesehen und den Zugang zur Weisheit. War ja klar.

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.

LOL, "Performance ist nicht das Problem" sagen immer genau die, die eben NICHT dieselbe Performance hinkriegen. Das haben die Java-Leute schon

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.

Gruß, Johannes

Am 21.08.19 um 19:17 schrieb Johannes Bauer:

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.

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++."

Hanno

Jupp, insbesondere die Lücken für Viren etc.

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.

Der Vergleich von Äpfeln mit Birnen, typisch für viele Apostel :-(

Das würde ich *Dir* einmal empfehlen, mir ist der kaum meßbare Unterschied bekannt.

Nun ja, mit solchen Aposteln lohnt sich eine weitere Diskussion nicht.

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

Uargh, du kennst also nicht mal den Unterschied zwischen Viren und Würmern.

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?

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.

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.

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.

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?

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

Am 21.08.19 um 20:16 schrieb Hanno Foest:

It's a bad craftsman who blames his tools.

Bei 3000 Mrd BSP in 2006 erscheinen 84,4 Mrd Verluste in Mittel- und Großunternehmen nur durch Softwarefehler doch reichlich aus dem Vollen geschöpft. Da bin ich noch nicht mal dabei. Und keine Virusattacken. Und die Maurer, Bierbrauer und Bauern auch eher nicht. Die haben ja auch einen Anteil am BSP. Das ganz und gar UNGLAUBLICHE FIASKO von pleitegegangen Firmen im Kielwasser der Jahrtausendwende war 2006 ja wohl verdaut.

Das ist aber ein klassisches Eigentor, Windows wurde in Pascal geschrieben. Mit der Umstellung auf die C-Familie wurde das dann deutlich besser. Windows 7 ist eigentlich schon ganz brauchbar.

Gerhard