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

Am 17.08.2019 um 13:53 schrieb Wolfgang Allinger:

diskutieren :-(

DoDi

Reply to
Hans-Peter Diettrich
Loading thread data ...

Ja wie in jeder Skriptsprache halt. Dass du das so besonders findest, wundert mich.

nur C sondern eben auch alle anderen Programmiersprachen, die llvm beherrscht (C++, go, Haskell, Fortran, Rust, Javascript, Ruby, C# um nur

dass 30 Jahre Programmiersprachenentwicklung scheinbar spurlos an dir

Standard-Sprachumfang verwendest. Ziemlich unglaublich, dass du das

kann.

Nein.

Deine groben zusammengelogenen Faustformeln interessiert kein Mensch.

und sag wie viel der braucht. Stattdessen schwadronierst du nur rum, kriegst es aber nicht gebacken auch nur EINE belegte Zahl zu nennen.

Noch mehr dahergefibertes Gelaber. Ich habe gemessen: C = 1, Forth =

500. Alles dokumentiert, der Code offen, die Messmethode dazu. Und du kriegst es nicht widerlegt. Komisch, oder? [mehr fibriges Gelaber gesnippt]

Ich habe nie behauptet, dass jemand, der Forth verwendet, ein

demonstriert und objektiv belegt, dass Forth deutlich langsamer (Faktor

Johannes

Reply to
Johannes Bauer

Aaaaaaaaahahahahaha! BWAHAHAHAHAHAHA!

Respekt, Respekt, du bist ja ein echter Spezialexperte.

Glaub es mir einfach!!!1111elf

Aaaaaaaaah ja klar, der NDA hindert dich daran, ein Hello World

Das kommt ja wohl aufs Target an. Du erzeugst Bytecode und der wird

Bytecode von Interpretation.

Na dann faktenchecken wir doch mal deine Behauptungen. Der RTX2000 ist

ISR auch wieder verlassen, da geht deine letzte Instruktion hin.

FORTH halt nun mal ohne Spezialhardware (Forth im Core) langsam ist, deutlich langsamer sogar manchmal (Faktor 500...) als C.

Niemand bei Verstand erwartet etwas anderes. Nur du tust so, als ob Forth die eierlegende Wollmichsau ist. In der Gruppe hier sind quasi nur Ingenieure. Die durchschauen dein Zelotentum ALLE.

gibt halt intellektuell grundlegend unehrliche Leute wie du, die einfach Fakten wegignorieren, die ihnen nicht passen.

Joa das war ja auch meine Aussage. Zitat "irgendwelchen Spezialanwendungen Hardware gebaut wurde, die das performant interpretiert".

Nur ist die Welt halt nicht so: Alle modernen Prozessoren sind eben

sich durchaus weiterentwickelt. Dann hat man halt auch mehr Auswahl an Hardware als nur n Paar obskure Spezialprozessoren.

Was soll denn ein "C Kern" sein? Hast du auch nur die leisteste Ahnung

mal retargetiert, ja, und der kann dann u.a. C kompilieren. Ist nicht

die weder "zukaufen" muss noch selber machen.

einen C Compiler gibt, ohne dass man was erstellen muss?

Johannes

Reply to
Johannes Bauer

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
 Click to see the full signature
Reply to
Wolfgang Allinger

Dummbatz.

nicht... wg. NDA sabbelst Du was von Hello World und Geschwurbel?

Nein, ist Eigenheit von Forth

Und Forth hat zwei Interpreter, den inner und den outer interpreter. Der

nennen, obwohl das bei FORTH noch wal wieder was ganz anderes ist.

Wenn ich das noch richtig im Kopf habe, macht der RTX den 'RETI' ohne

25a her, dass ich das zuletzt gemacht habe.

Au, jetzt legste aber dreist zu. Ich les noch ein bischen, aber...

[...] [...]

[...]
[...]

einzelne Seele in 1-3 Tagen.

Nochmal ...leck mich und hasta la vista

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
 Click to see the full signature
Reply to
Wolfgang Allinger

aus den Augen und mach dich nicht doch nicht weiter zum Brot. Und die

weder interessant noch relevant.

Du laberst und laberst und laberst und laberst, aber kriegst es nicht gebacken, ein WINZIGES Programm zu testen und die objektive Messung,

um dich. Du warst bestimmt auch schon immer jemand, der bei "Mensch

Niemand hat bestritten dass FORTH auf Spezialhardware (z.B. RTX20xx)

geeigent sein kann. Niemand hat bestritten, dass es Leute gibt, die RPN

bedienen ist.

Das EINZIGE Argument war, dass FORTH auf einer 08/15 Architektur (z.B.

tut. Und das Argument war dir sogar extensiv belegt worden.

Und nichtmal damit kommst du klar und interpretierst jegliche objektive

einem so unsachlich argumentierenden, hochnotpeinlichen Choleriker nicht zusammenarbeiten muss.

Gute Besserung und alles Liebe, Dein Johannes

Reply to
Johannes Bauer

Johannes Bauer :

Eure Stilfragen beiseite, sei festgehalten, dass die obige Prozedur nicht korrekt ist.

selbst auch miserablen Stil zelebriert. Wahrscheinlich, weil der Blick nur

ein C-Compiler irgendwo mitlief, das scheint immer noch so zu sein. Offenbar sehr zu ungunsten der Resultate. Akademische Spielkiste.

Der Unterschied: Subroutinen in Forth verbrauchen wenig Overhead, indem

jede Forth-Routine (Forth-Wort) einen neuen Stackframe einrichtet, dann ist die Brauchbarkeit ziemlich im Eimer.

auf den Hardware-Bus und die Devices des Rechners.

darf der eigentlich kindlichen Bindung an ein ewiges ozeanisches Wogen gern der Rest der Welt als entweder bedrohlich oder verabscheuungswert vorkommen.

Kannma schon. Wenn es nur darum geht, muss man das nicht weiter ernstnehmen.

Reply to
Ewald Pfau

Hmm, naja wie gesagt, wenn es etwas besseres gibt auf FORTH-Seite, dann

10 langsamer als C), aber der Faktor 500 hat mich schon sehr erschreckt. Insbesondere weil gforth von Wolfgang selbst als reife Implementierung

aufstellt. Wenn der aber keine Aussage machen kann oder will, dann muss er sich nicht wundern wenn ein Fachfremder Messungen macht, die halt (aus purem Unwissen heraus) nicht das Optimum herauskitzeln aus der Implementierung.

Welcher Overhead wird wo gespart? Und gilt das dann nur bei Unterroutinenaufrufen? Da wird in der Regel bei einem modernen, guten C Compiler auch kein Stackframe erzeugt, wenn das nicht notwendig ist.

Auf dem kann ich aber nicht testen :-)

Hm, ne, darum geht's nicht. Allgemein sind das keine Kategorien

Eine Technologie (z.B. Programmiersprache) hat Vorteile und Nachteile. Es ist gemeinhin klar, dass *alles* ein Kompromiss darstellt.

der Werkzeuge und Hardware, Gehalt der Ingenieure die man braucht, usw usf. Das gilt ganz allgemein.

Wenn sich jetzt einer hinstellt und sagt, Technologie X ist in ALLEN

nehme sie halt in Kauf, weil ich im Embedded-Bereich meistens eben damit insgesamt noch am besten fahre.

Johannes

Reply to
Johannes Bauer

Nun ja, Forth ist eher schon eine Lebensanschauung und der bin ich in weiten

bei Desktopzeugs einfach bessere Karten. Aber zu Zeiten, als ich auch noch die Stringroutinen des awk je nach Bedarf in Forth nachgestellt habe, ging das so, dass der Mensch eben mit seinem Werkzeug zienlich eng verwachsen

z.B. Primzahlen rechnen lassen, das ging dann mehr und mehr in Assembler.

Secondaries stehen (also in Forth-Worten, die aus Tokens bestehen).

Output eines Compilers konsumiert als wie eine Service-Leistung.

Ebene ist das auch eher die Vorstellung von ihrem Zielpublikum, siehe die

formatting link

Payware mit etwas Vorlaufzeit zum Evaluieren und Kennenlernen (und dann gibt es zumindest noch weitere Elaborate, etwa aus Southampton).

von kurzen Routinen, plus die Wirkung des Optimizers.

Derart langsam finde ich das auch inakzeptabel. Hatte einst eine Idee von Langsamkeit, als bei mir ein Forth-Interpreter, mit sehr wenig Assembler

500 langsamer - vielleicht, hab's nicht gemessen. Hab mich nur dabei nett

Dunkel nebelt durch die Erinnerung ein Modell heran, wo ad hoc je ein Forth-Wort per C zu einer Sammlung von anderen kompiliert wurde, und dann eben brav die Maschine mit zwei Stacks auf der Maschine mit nur einem Stack

Laufzeitumgebung an die Parameter, die auf dem Forth-Stack liegen sollten, der aber erst einmal zu emulieren ist, wenn der eine Stack zugleich der

Wollte jetzt nicht die gefinkelten C-Compiler dagegenhalten.

Wenn man das nicht will, schreibt man mit Variablen (oder Local Values) und

ROT TUCK OVER usw.

Denkweise ist ein wenig anders als beim Algebra-fixierten Mainstream.

Andersherum, ein paar Variablen, dann werden die Parameter nicht mehr anonym auf dem Stack herumgeschoben, weil dann die Namen im Quelltext stehen.

Solange man aber mit dem Stack auskommt, ist vor allem einmal ein Vorteil, dass der Code nach Belieben reentrant ist, es also keine Nebenwirkungen bei

Local Values, aber die gehen dann in die Richtung, dass ein Frame bei Aufruf zwischengesichert werden und beim Verlassen wieder restauriert werden muss -

der Zwischenzeit, nicht mehr geschaut habe solches dann mehr).

Abarbeitung der Tokens eben keine andere Instanz, die quasi hinter dem

laufzeittechnisch.

weiterschaltet. Und das ist schnell: den reservierten IP inkrementieren,

reserviert, sonst wird der Ablauf wieder ineffizient. Landet man bei einer Token-Liste, dann wird der IP gesichert und umgeladen, und gleich mit NEXT wieder in der neuen Liste begonnen, auch das geht flott. Und all dies

ziemlich eisernes Regime, wie die Resourcen der CPU zu verbraten sind. Die beiden Stacks als SP, RP, den Instruction Pointer IP plus ein Umladeregister, eventuell dazu Top-Of-Stack in einem Register.

gestrickt, also von Assembler weg hochgezogen. Diese Denkweise ist auf den Desktops nun aber eher rar geworden, wenn man nicht in Richtung Redmond schaut, wo Intel mit sozusagen einbetonierter 80x86-Historie das Fahrwasser vorgibt.

lowlevel-Umgebung des Open-Boot im BIOS von Desktops.

Modell jedes kurze Forthwort ein eigenes C-Kompilat darstellen soll, hat der

weniger zu tun.

Zuletzt dass ich damit herumgetan hatte (also schon lange nicht mehr), waren bei meinem Leib- und Magen-Werkzeug die Optimierungen Forth-intern, d.h.,

darstellen lassen, wurden aufgefunden und zusammengefasst.

strikten One-Pass-Compilers. Es ist ja nicht traditionellerweise das Kompilat das Ziel, weswegen ein Quelltet geladen wird, sondern, abstrakter,

Passagen wiederauftaucht.

Man kann sich aber, seit dem ANS/ISO-Modell, mit den Mitteln zur Interpretersteuerung unterwegs gern seinen Mehr-Pass-Compiler stricken. Das

monokausal gestrickte Denkweise, wozu der Quelltext und wozu der Compiler

kann.

reloziierbaren Objektcode zu generieren, als externes Modul gesichert, um es ohne Quelltext ein andermal zu laden.

Aber aus der Arbeitsteilung, wie die Werkzeuge nun, wenige Jahrzehnte

Bei vielfach andersartiger Sichtweise muss das Ding ja nicht auf jedes

man mit dem Werkzeug umgeht, nicht auf dem Radar aufscheinen wird. Sprich,

der eigenen Ideen, noch bevor der geplagte Programmierer dann sein Werk beginnen will. Letzteres hat der Mainstream nicht vorgesehen. Die Welt bestehe aus Algorithmen und die schreibe man in Algebra.

Reply to
Ewald Pfau

Am 18.08.19 um 20:43 schrieb Ewald Pfau:

Keine Maschine, die (Rx++) und (--Ry) kann muss an Stacks Mangel leiden. Sagen wir alle nach der PDP-11.

Nein, das war mal relativ schnell zu 6502-Zeiten. Auf heutiger Hardware ist das der direkte Weg zum Untergang. Wenn man alle 5 Maschinen-instruktionen die Pipeline flusht, noch dazu mit unbekanntem Sprungziel,

folgerichtig ausgestorben. (Und eine 16 bit Stackmaschine in Hardware in HP's dynamischen NMOS, das war eben der Zeitgeist, damals.)

Und die 500 Renaming-Register kann man auch wegwerfen, wenn sich das ganze Programm immer nur mit dem TopOfStack und den NextOnStack

ein Hauptspeicherzugriff > 100.

einen da nicht weiter. Eine Instruktion pro Takt ist heute nichts mehr wert.

sind jetzt multiskalare RISCs mit Hunderten von Registern und

riecht noch etwas streng nach X86. Das hat aber mit dem, was nach der Decodierung abgearbeit wird, absolut

Gerhard

Reply to
Gerhard Hoffmann

Wie Spectre und Meltdown zeigen hat INTeL das mit der spekulativen

mehr warum sie immer schneller als AMD waren. Wenn man an der Sicherheit spart ist es leichter schneller als die Konkurrenz zu sein.

Gerrit

Reply to
Gerrit Heitsch

Dabei ist der 86 gar nicht so link gewesen, wenn man erst mal eingesehen hat, dass die Segmentregister eine MMU sind und nix mit der CPU zu tun haben.

Aber, was hatten die $(ANDEREN) immer so tolle CPUs!!11elf!!

Da war der 32032 von National (startete als 16032) super-duper-symmetrisch, sogar Arrays in den Registern. Erstickt an seinen Bugs.

Micro-VAX.

Die 68000-Familie.

sich dann gezeigt hat, dass es Instruktionen gibt die niemals terminieren, weil immer noch ein page fault / exeption/ wasauchimmer reinpasst. Beim 68060 war Schluss mit lustig. Nicht mehr zu verstehen. Auch nicht richtig schnell, irgendwie.

Z8000/Z80000. Kam nie in die Puschen.

Transputer.

war ehrlich gesagt auch nicht mehr sehr dahinter her.

Fairchild Clipper.

rauf oder runterzuschieben konnte eine enge Schleife beschleunigen

IBM Power PC. Ja, hatten wir embedded in einem Virtex. Es gab nie einen Nachfolger von Xilinx, von IBM irgendwie auch nicht.

DEC Alpha.

HP700 / Snakes / KingKobra War schnarch-langsam. Ich hab' noch so ein Teil unter HP-UX in einem Agilent 16702B-Logikanalyzer. War schon damals schlimm. Das HP-Nachfolgedesign haben sie geschaft Intel unterzuschieben. Taugte auch auf Intel's Prozess nix und war dann irgendwie Intel's Fehler.

SUN.

MIPS. Soll jetzt open source sein. Hat nicht gereicht. Ich fand sie eigentlich ganz angenehm.

Ja, der ARM hat's geschafft. Der hatte den Bonus, die wirklich

Und AMD steht im Augenblick ganz gut da. Treuer Intel-Vasall seit dem 8080, abgesehen von dem Seitensprung mit dem Z8000.

Vermutlich habe ich den ein oder anderen Intel-Roadkill vergessen.

Reply to
Gerhard Hoffmann

Am 18.08.2019 um 21:57 schrieb Gerhard Hoffmann:

sich da die Frage, was davon bei Steuerungsprogrammen besonders

hatte ich ja schon angemerkt.

DoDi

Reply to
Hans-Peter Diettrich
  • Gerhard Hoffmann :

Als der Alpha 21064 1992 rauskam - 64 Bit! 200 MHz! - zitterten der Konkurrenz die Knie. Intel machte damals noch 486er, Sun den

und das waren alles 32-Bit-Chips.

Ein Doktorand von unserem Institut ging ca. '94 zu Intel und wurde ein,

Pleite, Compaq war nicht an Prozessoren interessiert und die Alpha-Ingenieure gingen zu Hunderten zu Intel, HP oder AMD. 1999 meinte der Kollege: "Angst? Wir haben vor keinem mehr Angst".

- Andi

Reply to
Andreas Karrer

Technisch sicher nicht, in der Vermarktung schon: Man stelle sich

/ralph

--
----------------------------------------------------------------------------- 
                                                              https://aisg.at 
 Click to see the full signature
Reply to
Ralph Aichinger

Das war das zentrale Problem von DEC - lauter Ingenieure, die Null Ahnung vom Business hatten...

Reply to
Eric Bruecklmeier

Und weiter: Es gibt 2 Arten der Geheimhaltung:

Es verging zu meinen DEC user Tagen, nicht ein Tag, wo ich in den meterlangen AKtenordnern zu PDP11, RSX11M, RT02, RT11, LSI11... DECUS

dort waren u.a. viele Gurus von DECUS. Internet gabs nicht, und Telefon reichte nicht. Haben uns auch gegenseitig HW und SW (jau, die lustigen

Und um wieder OT zu werden :)

Anlage ging. Jeder zeigte auf den anderen und ich sass in der Patsche bei

interaktiv die Sache erfolgreich debugged und hatte am Ende eine gute Sammlung von Test 'Worten' in FORTH, die dann von unseren Serviceleuten,

Doku, die sich auf dem Controller durch eine aufgekratzte Leiterbahn, eine

1n914 und etwas Wrapdraht flicken lies. Hab danach FORTH vergessen bis zu einem grossen Projekt mit zuwenig Manpower, zuviel Rotstiften, Chaotischem oberen Damagement und unglaublich knappen Zeitrahmen...: Herr Allinger,

waren und absolut nix lief. Die HW Lieblinge der GL fielen nicht in

Ich hatte gerade Berichte von Mitch Bradley (SUN) gelesen, wo er

neue CPU (die er einfach mit FORTH emuliert hat) fertiggestellt hatte. Er

sein, dass der Controller im Plan lag, wo doch die CPU noch garnicht

der spinnt, der Hardwarenix!

Als dann die CPU lief und der Controller samt HDD und Treiber auf Anhieb auch, war grosses Theater im Management. Mitch musste dann tausendmal

das Open-Boot (s.h. ebenda) und von da an gabs Open-Boot auf allen SUN.

interessiert und Dein Labor dauernd voller Fremder ist :)

auf die 2 Stack Architektur von FORTH verzichtete, ist (mir)

Andere Berichte sagten, dass FORTH Programmierer 3-30x produktiver als in allen anderen Programmiersprachen sind. Wenn das stimmte, dann sah ich da meine einzige Chance. Ich erinnerte mich an meine Erfahrungen, hab dann mich und 2 weitere Ings verschworen, es mit FORTH zu probieren. Wenige Tage vor dem Projektstart, war ich mit 3 meiner MA auf einem DEC

Ich engagierte Flesch Forth Systeme um uns auf den Pott zu bringen und 3 Wochen zu pampern, bis wir mit dem LMI Forth samt Metacompiler alleine weiter arbeiten konnten. Wir benutzen 3 Mostek Z80 Entwicklungssysteme die an unserer PDP11/34 per CL (20mA 9600Bd) hingen. Ein Flesch Mann war immer zugegen um als wandelndes Lexicon und Bezaubernde Jeannie (ok, Barbara Eden war sexier :) auf Fingerschnipp zu helfen.

Projekt hab ich dann noch von dem zu klein werdenden Z80 auf 64180 umgestellt, die beiden anderen haben nichts bemerkt, ausser dass alles

mitten im Projekt auch noch die Pferde gewechselt (z80 -> 64180) Ich war erstaunt, was Wut (auf die GL) an Energien und Motivation (auch bei den anderen Beiden) freisetzen konnte.

Aber statt Lob aus der GL kam nur: Siehste, man muss die Softies nur ordentlich treten, dann klappt das auch!

mitbekamen (und noch ein weiterer), wollten sie mit mir gehen.

ordentlich Projekte von dem alten AG mitbekommen. War ne prima Starthilfe.

Der einzige Fehler war, dass wir alle 4 gleichberechtige Partner waren.

Hat mich meine Einlage von 20.000DM gekostet und den 924S hat dann einer

und dann an einen Zahnarzt weiterverkauft) :o

Ein jap. Sprichwort sagt: Wer von der Hoffnung lebt, wird wenigstens nicht dick!

Hat bei mir gefunzt, nur noch FORTH und embedded HW+SW, ordentlich an Umfang (nicht nur Bankkonto) zugelegt :) und mich und meine Frau und meine

finanziert.

inzwischen in Rente gegangen.

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
 Click to see the full signature
Reply to
Wolfgang Allinger

Am 19.08.2019 um 14:11 schrieb Wolfgang Allinger:

ich konnte ihr nie was abgewinnen und RPN finde ich schlichtweg abartig.

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

Profiklaus in d.r.f.
Reply to
Eric Bruecklmeier

.

Die polnische Notation selbst, +(3,4) statt 3+4, hat was.

--




/ \  Mail | -- No unannounced, large, binary attachments, please! --
Reply to
Axel Berger

Tja, ich fahre heute auch nicht mehr mit der Kutsche ins Amt.

Stellt sich nur die Frage, was?

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

Profiklaus in d.r.f.
Reply to
Eric Bruecklmeier

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.