Hallo, vielleicht ist schon jemand von euch auf die Programmiersprache Forth gestoßen und hat sich etwas damit befasst. Die Sprache könnte man gut auf dem AVR umsetzen und hätte dann die Möglichkeit, über ein Interface (z.B. LCD + Tastatur oder Terminal) den AVR direkt zu programmieren (ohne PC), wobei Kommandos direkt ausgeführt oder in den Speicher compiliert werden. So hat man die Möglichkeit, die Ergebnisse eines Befehls (z.B. LED anschalten) sofort zu sehen, ohne erst das Programm übertragen zu müssen. Außerdem kann die Fehlersuche direkt im System unter realen Bedingungen erfolgen, ohne beispielsweise auf JTAG-ICE zurückgreifen zu müssen. Meiner Meinung nach ist Forth ideal für Mikrocontroller, zumal der Programmumfang nicht mehr auf Flash, sondern auf beliebige Speichermedien ausgedehnt werden kann.. Daniel
ich weiss zwar nicht, wie du dir das vorstellst, habe auch keinerlei Ahnung von Forth. Allerdings ist der AVR angeblich von der Struktur her auf C zugeschnitten, und ein AVR kann prinzipiell nur Programme ausführen, die im internen Flash stehen, da gibts kein RAM, welches Programmcode aufnehmen könnte, weder intern noch extern. Also, um download und Programmierung des Flash kommt man nicht drumherum. Bei den Megas ist das immerhin über den bootlader möglich. Aber was speziell erhoffst du dir von einem forth-System?
Forth wird normalerweise nicht in Maschinencode kompiliert, sondern von einem Interpreter auf dem Prozessor ausgeführt.
na gut, und was nutzt das? Ob ich nun ein komlett compiliertes Programm runterlade, oder einen Pseudocode, der dann mittels Interpreter ausgeführt wird? Ich sehe da keinen Vorteil, im Gegenteil. Ein richtiger Betriebssystem-Kern, der dann erforderlich wird, wird einen großen Teil des Programmspeichers auffressen, ebenso die Gesamtleistungsfähigkeit. Mikrocontrollerprogramme sind meiner Meinung nach immer sehr speziell, und arbeiten auch in jeder Anwendung mit einer anderen externen Hardware. Und was für einen PC unabdingbar ist (Standardschnittstellen, Harware per device-driver ansprechbar) ist für MCs weder sinnvoll noch machbar aufgrund der stets begrenzten Resourcen.
@crazy horse: Bei den speziellen Einsatzzwecken hast du recht. Es gibt aber auch Anwendungen, die flexibel für Änderungen und Einstellungen sein müssen. Beispielsweise wäre ein Roboter besser mit Forth zu steuern, um nicht jedesmal ein geändertes Programm assemblieren zu müssen, nur um einen neuen Kurs zu fahren. Da Forth aus den Anfängen der Computertechnik stammt, ist es sehr sparsam mit Speicher und nach dem Minimalprinzip aufgebaut. Der Kern ist sehr klein und würde einen AVR nicht überfordern. Die Forth-Programme sind nur ca. 4x langsamer als Assemblerprogramme, was man vernachlässigen kann. Daniel
Hallo! Es ist zwar interessant, was es alles gibt, aber ich finde auch, dass das direkte Flashes besser ist. Man drück nur auf den Knopf und schon wird das Programm erstellt, der Prozessor geslöscht und neu bespielt und das in wenigen Sekunden. Außerdem muss man den Prozessor sowieso flashen, da man ja die Firmware draufspielen muss. Auch einen Geschwindigkeitsverlust um den Faktor vier finde ich extrem viel. Ein weiterer Nachteil besteht darin, dass man für jedem Prozessor anscheinend ein eigenes Board benötigt. @Thomas: Aber ich will dir deine Sache nicht vermießen. Jeder soll mit den Werkzeugen arbeiten, die er selbst am besten findet und mit denen er am besten umgehen kann. Martin
Hallo, Hier gehts irgendwie um Interpreter oder direkt coden. Meine Meinung sieht so dazu aus: Interpreter ist gut, solange nur einfach Abläufe (eben SPS Funktionen; sprich irgend welche Abläufe) zu lösen sind. Somit will ich auch schonwieder auf ein Projekt verweisen, welches irgendwie voll super wäre, wo man wie bei SPS mit Kontaktplan usw... programmiert, und wo es dann für alle Prozessoren (8051, AVR, MSP430) einen Interpreter dafür gibt. Will man da aber etwas mehr machen, kann man Interpreter schon vergessen (vgl. C-Control). Die Gründe: 1. Viel zu langsam 2. Prozessoren kann man nicht richtig ausnützen (sprich alle zur Verfügung stehenden Funktionen) Na, ja. Meine Meinung halt. mfg W.K.
Na hallo !! erstmal vielen Dank für die Antworten und unterschiedlichen Meinungen. Habe gemerkt, dass die meisten von euch mit dem AVR eine konkrete Aufgabe lösen wollen und er in Geräten mit einer festen Funktion ans Werk geht. Für solche Zwecke macht ein Interpreter keinen Sinn, da stimme ich euch zu. Mein eigentlicher Gedanke war, mit dem AVR einen Mikrorechner zu bauen, der UNABHÄNGIG vom PC läuft, also mit LCD+Tastatur und einer Interpreter-Sprache ausgestattet ist, die Befehle direkt ausführen kann oder in den Speicher schreiben kann. Damit die Nachteile einer Interpreter-Sprache nicht so ins Gewicht fallen, habe ich daher Forth gewählt, da sie keine reine Interpreter-Sprache ist, sondern wie eine virtuelle Maschine funktioniert (es gibt auch echte Forth-Prozessoren). Da die Forth-Architektur sehr verwandt mit der RISC-Architektur ist, würde sie gut zum AVR passen. Für alle, die Forth noch nicht kennen: Forth interpretiert nicht im klassischen Sinne, wie in Basic, wo zu jedem Befehl über eine Tabelle o.ä. die Adresse des zugehörigen Maschinencode ermittelt wird, sondern Forth compiliert! in den Speicher, so dass bei der Ausführung schon die Adressen alle feststehen. Der IP muss nur noch mit diesen Adressen geladen werden, was der Adressinterpreter von Forth übernimmt und seine Umsetzung bestimmt die Geschwindigkeit des Programms. In der Regel besteht er nur aus 5 Assembler-Befehlen. @ThomasB: Danke. Interessante Seite! @Martin: Ich finde den Geschwindigkeitsverlust nicht so hoch... :) @Weinga: Forth ist nicht mit Basic zu Vergleichen. Forth wurde damals vor 30 Jahren zur Steuerung von Radioteleskopen eingesetzt, wo umfangreiche mathematische Berechnungen in Echtzeit durchgeführt werden mussten und für Steuerungsänderungen keine Zeit war, um erst das Programm auf einem anderen Rechner zu ändern und dann wieder in den Zielrechner übertragen zu werden. Forth ist schnell genug !! Bis dann Daniel
Hallo Henk, wird mich bestimmt das ganze Wochenende kosten, deinen Code durchzuforsten :) Hab gleich mal noch ein paar Fragen an dich: - Befindet sich das Wörterbuch im SRAM ? - Äußerer Interpreter mit dabei ? - Wenn ja, dann laufen Ein- und Ausgaben über RS232 ? Habe gestern entdeckt, dass Forth,Inc. (www.forth.com) für einige viele Dollars einen Forth-Compiler (SwiftX) für AVRs anbietet. Bis dann Daniel
1. am ende der flash ist mit dw das wichtigste teil das Wörterbuch ein gebunden. das wird am anfang zum SRAM kopiert. 2. das ist der Äußerer Interpreter. 3. mittels DEFER kan man EMIT KEY und ACCEPT "umleiten", damit ich auch in AVR Studio debuggen kan. Sie stehen entweder auf DROP DUP ACCEPTBOOT oder TX! RX@ ACCEPT 4. die code is noch immer in entwiklung. Sie is zusammen gebasteld nach CAMEL SOL usw. bitte schreibe fehler ignorieren weil ich kein deutscher bin.
Ich hatte mich bereits vor etlichen Jahren mal mit der Programmiersprache Forth beschäftigt, das Resultat war sehr enttäuschend! Die Daseinsberechtigung und der Charakter dieser Sprache schlägt sich sehr eindeutig in den zur Verfügung stehenden Ressourcen nieder. Literatur gibt es so gut wie garkeine und die Implementationen sind Kraut und Rüben. Es wurde zwar mal ein Versuch gestartet diese Sprache zu standardisieren, aber kein Forth Dialekt hält sich daran. Es wird zwar immer gesagt, Forth sei schnell aber wie Andreas richtig bemerkt hat, ist Forth eigentlich eine Interpretersprache. Der Sourcecode wird in eine Art Metacode umgesetzt, der dann interpretiert wird. Es gibt zwar auch einige wenige echte Forth Compiler, aber das sind auch nur Dinge, die irgendwo im Entwicklungsstadium hängengeblieben sind. Das Problem bei Forth Compilern ist nämlich die Umsetzung auf die gängigen (von Neumann'schen) Prozessorarchitekturen und das passt hinten und vorne nicht weil dies keine stackorientierten Maschinen sind. Es gab (oder gibt noch?) auch Prozessoren, die speziell für Forth konzipiert wurden aber das hat sich auch alles im Sande verlaufen. Dazu kommt noch, dass die Programmiersprache Forth aufgrund ihrer (anderen oder fehlenden) Struktur sehr unübersichtlich ist und sich grössere Projekte nur mit erheblichem Aufwand realisieren lassen. Gut, letztendlich muss jeder selbst wissen wo sein persönlicher Geschmack liegt und was ihm am besten liegt. Es gibt ja in diesem Forum auch einige Assembler-Hardliner, die einen C-Compiler nicht mal mit Gummihandschuhen anfassen würden. Soll mir auch recht sein. Aber von Forth halte ich persönlich, ehrlich gesagt, garnichts! Man könnte zwar einen kleinen Interpreter programmieren und den Programmcode als Token in den EEPROM laden und dort abarbeiten (so was in der Art wie hier: http://users.cableaz.com/~cappels/dproj/ab163/at163b.htm), aber ob es unbedingt Forth sein muss? Notker
@Notker: 1. Die Daseinsberechtigung und der Charakter von Forth ist weniger von den Resourcen, als von dem Anwendungzweck abhängig. 2. Da Forth schon in der Raumfahrt eingesetzt wurde und auch kommerziell, können doch nicht alle Implementationen Kraut & Rüben sein :) 3. Literatur ist tatsächlich selten, ist eben eine vergessene und unterschätzte Sprache. Die deutschen Bücher werden meist nicht mehr aufgelegt. Hilft nur Internet. 4. Forth ist einfach. An die RPN-Notation muss man sich allerdings gewöhnen. Dabei steckt diese RPN (Postfix) Notation in jeden von uns, ohne dass man es merkt :) Jeder hat doch schon einen normalen Taschenrechner bedient: dort werden manche Operationen hinter den Zahlen (Operanten) gedrückt (SIN, COS, ...) Andere wiederum (PLUS, MINUS, ...) zwischen den Operanten, was dann die bekannte Infix-Notation ist. Forth zieht durchgänging die Postfix-Notation durch, kann man sich schnell daran gewöhnen. 5. Du hast über fehlende Forth-Compiler geklagt, die richtigen Maschinencode erzeugen. Kein Wunder, dass du von Forth nicht viel hältst. Du hast die Denkweise hinter Forth nicht verstanden. Solche echten Forth-Compiler sind deshalb so selten, weil sie gegen Forth selbst sprechen: nämlich interaktiv zu sein. Die Leistungsfähigkeit von Forth beruht darauf, während der Laufzeit (ohne PC) einfach erweiterbar zu sein.. und das in einem guten Verhältnis zur Ausführungs-Geschwindigkeit. 6. Da es zur Programmierung unter Forth wenig Regeln und Standards gibt, kann man damit auch viel Unnützes und Unübersichtliches anstellen. Es liegt also an jedem selbst, ob der Quelltext übersichtlich bleibt oder nicht. Auf der anderen Seite ist Forth aber höchst strukturiert, keine Möglichkeit, Spagetti-Code zu schreiben. Der Erfinder von Forth ist gegen Standards, da die sich auch schwer durchsetzen lassen: beim Programmieren wird die Sprache selbst erweitert. Einen ANSI-Standard gibt's trotzdem. 7. Eine Abarbeitung im EEProm ist zu langsam, muss schon SRAM sein. Daniel
> Die Daseinsberechtigung und der Charakter von Forth ist weniger von > den Resourcen, als von dem Anwendungzweck abhängig. Ich habe nicht geschrieben wovon sie abhängig ist, ich habe geschrieben, worin sie sich eindeutig niederschlägt (s.o.). > Da Forth schon in der Raumfahrt eingesetzt wurde und auch > kommerziell, können doch nicht alle Implementationen Kraut & Rüben sein > :) Es wurde mal von einem etwas exzentrisch denkenden Menschen entwickelt um ein Radioteleskop zu steuern. Mit Raumfahrt hat das aber wohl nur entfernt zu tun. > Literatur ist tatsächlich selten, ist eben eine vergessene und > unterschätzte Sprache. Die deutschen Bücher werden meist nicht mehr > aufgelegt. Also wenn das wirklich so eine tolle und unterschätzte Sache wäre, ich denke mal, da hätte es auch bestimmt ein paar Versuche mehr gegeben, hierüber ein wirklich gutes Buch zu schreiben. Ich habe mir gerade mal dieses "Standardwerk" (grins) von Leo Brodie (Programmieren in FORTH) hier aus meinem Bücherregal gezogen. Wenn man dort hineinschaut und diese lustigen Karikaturen darin sieht, kommt einem spontan der Gedanke, ein Kinderbuch in den Fingern zu haben. Scheint mir doch sehr zielgruppenbezogen zu sein ;-) > Forth ist einfach. du nimmst mir das Wort aus dem Munde. Einfache Sprache für einfache Gemüter. > An die RPN-Notation muss man sich allerdings gewöhnen. Nun ja, als leidenschaftlicher Sammler alter HP Taschenrechner habe ich damit bestimmt keine Berührungsängste. > Du hast die Denkweise hinter Forth nicht verstanden. Gut, dann lasse uns Unwissende und Ungläubige doch mal etwas an deinem unermesslichen Wissen und deiner grenzenlosen Weisheit teilhaben, grosser Forth-Guru. > Da es zur Programmierung unter Forth wenig Regeln und Standards > gibt, kann man damit auch viel Unnützes und Unübersichtliches > anstellen. Naja, das kann man wohl mit jeder Programmiersprache. Gegenteilige Meinungen? > Es liegt also an jedem selbst, ob der Quelltext übersichtlich bleibt oder nicht. Wir lauschen gespannt den Ausführungen des Experten g > Auf der anderen Seite ist Forth aber höchst strukturiert, keine Möglichkeit, > Spagetti-Code zu schreiben. Boah, ich bin echt fasziniert! Erzähl uns mehr davon! > Der Erfinder von Forth ist gegen Standards, da die sich auch schwer > durchsetzen lassen. Sowas Ähnliches habe ich mir bereits gedacht ... (LOL!) Ok, genug gegrinst für heute, befassen wir uns wieder mit serösen Themen ;-) have a nice day, Notker
Hallo Notker, nein nein, wollte dich nicht mit deiner Meinung angreifen. Vielleicht liege ich ja auch halbwegs falsch, aber eine Diskussion ist es doch schon mal wert. Die Idee hinter Forth mit dem Minimalprinzip und so ist doch gar nicht so schlecht (solange der Nutzen auch nicht minimal ist). Da du die HP-Taschenrechner angesprochen hast: die neuesten Modelle können ja alternativ auch noch mit RPN-Notation umgehen, die sich für manche Sachen gut eignet. Genauso eignet sich Forth für manche Dinge ganz gut. Nicht für alles, das ist klar.. Jede Sprache für seinen bestimmten Zweck. Wenn du willst, kannst du ja deine Einstellung besser begründen, damit auch ich die Möglichkeit habe, meine Meinung zu überdenken und was dazuzulernen.. Daniel
Ich bin auch eher der Meinung von Notker. Forth ist klein, speichersparend und optimal an die Bedürfnisse von Mikrocontrollern angepasst -sozusagen computergerecht- aber nicht an die Bedürfnisse von Menschen. Ich habe mich vor Jahren auch einmal mit Forth beschäftigt, wohl auch um mich von der schnöden Masse abzusetzen und mich selbst für einen der 'letzten einsamen noch lebenden Superprogrammierer' zu halten. Spätesten als ich eine veschachtelte if-then-else-Kombination erstellen wollte, habe ich den Forth-compiler mit der stärksten Packstufe von PK-Zip komprimiert, in irgendein Verzeichnis kopiert und vergessen. Die aufkommenden Zweifel an meiner Genialität habe ich einfach ignoriert und über die Jahre verdrängt. Jetzt bin ich darüber hinweg und programmiere PC-Programme mit Delphi und Mikrocontroller in C. In beiden Sprachen bin ich immer noch ein kleines Licht, aber man kann sich viel im Internet zusammensuchen, und vielleicht kann mal irgendjemand ein Codeschnipsel von mir gebrauchen. -- Dann bin ich stolz --
Hallo an alle, das es generell viele Gegner gibt, weiß ich doch schon :) Und verschachtelte Algorithmen will ich doch auch nicht damit programmieren.. Als Script- oder Makrosprache macht sie sich jedoch gut, was mit C nicht oder zu aufwendig realisierbar ist. Die Grundfunktionen können doch in einer beliebigen Sprache (C, Asm, Basic ..) verfasst werden. Das Zusammenfassen und die Abfolge der Grundfunktionen kann zuletzt mit Forth erfolgen, so dass man flexibel ist, wenn häufige Änderungen erforderlich sind.. nur zu diesen Zweck ! ok ? Für mich würde es keinen Sinn machen, jedesmal einen PC an eine festinstallierte Steuerung anzustöpseln, nur um einen Parameter oder eine Abfolge zu ändern.. (was die Anwender ja nicht können, sondern nur die Programmierer der Steuerung).. Ein Menüsystem kann man nicht für alle Dinge einsetzen.. Wie würdet ihr also dieses Problem lösen ?? bin gespannt.. :) Daniel
> Für mich würde es keinen Sinn machen, jedesmal einen PC an eine > festinstallierte Steuerung anzustöpseln, nur um einen Parameter oder > eine Abfolge zu ändern.. (was die Anwender ja nicht können, sondern nur > die Programmierer der Steuerung).. Ein Menüsystem kann man nicht für > alle Dinge einsetzen.. > Wie würdet ihr also dieses Problem lösen ?? > bin gespannt.. :) Wenn wir schon mal bei abstrusen und total realitätsfremden Diskussionen sind, die eine uralte und bereits so gut wie ausgestorbene Programmiersprache mit high-tech Anforderungen des 21. Jahrhunderts verbinden soll, wie wäre es denn mit einer Sprachsteuerung? Dann kannst du ja deinem Compi erzählen was er machen soll und brauchst nie wieder ein Interface anzustöpseln. Mit genug Aufwand kann man sowas bestimmt auch irgendwie in Forth programmieren. Also mal im Ernst mein lieber Daniel, ich kann deinen Ausführungen nicht so ganz folgen und ich denke mal, dass ich damit in diesem Forum bestimmt nicht der Einzige bin. Ich habe ja nichts gegen theoretische Gedankenspiele, manchmal kommen ja wirklich gute Ideen dabei heraus. Aber das hier ist mir ein paar Stufen zu hoch. Was soll denn das werden wenn es fertig ist? Eine Art selbstorganisierende und morphende Codemasse in einem Computer, die wohlmöglich irgendwann anfängt zu denken und ohne das Zutun eines externen Interfaces ihr eigenes Bewußtsein entwickelt? Bist wohl ein begeisterter Perry Rhodan Leser? ;-) Wir wissen nicht, was die freundliche Hausfrau empfiehlt, aber ich empfehle stets die Mittel der Wahl (C oder Assembler) zu verwenden. Damit kann man eigentlich alles realisieren was einem so vorschwebt und man kommt damit und der Hilfe der Forumskollegen eigentlich stets zum Ziel. Oder sollte es tatsächlich etwas Exotisches sein? Kläre uns doch mal genauer auf! have a nice day Notker
> Da du die HP-Taschenrechner angesprochen hast: die neuesten Modelle > können ja alternativ auch noch mit RPN-Notation umgehen, die sich für > manche Sachen gut eignet. Nur als Hinweis, HP baut schon seit einiger Zeit keine Taschenrechner mehr. Der gemeine Mensch (homo sapiens vulgaris) ist bekanntermassen unwillig, eine gute Qualität mit der Bezahlung eines entsprechenden Preises zu würdigen und somit hat HP beschlossen, diese Sache einzustellen. Leider!
@Notker: Ich hatte nach einer Lösung gefragt, nicht wie man's am besten durch den Kakao zieht. Trotz deines langen Postings kann ich die Antwort auf meine Frage nicht finden !? Nochmal langsam: - Forth erstmal kurz beiseite lassen ! - Ein Interface ist erlaubt, aber kein PC ! - Wie kann ich ein ASM/C-Programm flexibel genug gestalten, um ganze Abläufe ändern zu können, ohne den Maschinencode neu compilieren zu müssen, da im eingebauten Zustand oder unterwegs kein PC zur Verfügung steht ? (Vorrausgesetzt, ein Menüinterface wäre zu aufwendig) Eine Möglichkeit wäre es doch, ein leicht (während des Betriebes) änderbares Ablaufscript zu interpretieren, wozu sich Forth eignet. Daniel p.s.: http://www.hp.com/calculators/ Es gibt sie noch, oder nicht ? p.s.s.: um den Thread nicht unnötig in die Länge zu ziehen und vom eigentlichen Thema abzulenken, solltest du auf Antworten mit Unterhaltungswert verzichten.
Hallo Daniel, mir scheint, Du konstruierst hier einfach einen Spezialfall: Die Änderungen sind so komplex, daß man es nicht mehr über ein Menü machen kann, aber noch nicht so komplex, daß man größere Codeteile ändern müßte. Gleichzeitig steht kein PC zur Programmierung zur Verfügung. Das ist meiner Meinung nach aber eher selten. Entweder steht der (Gesamt-)Programmablauf relativ fest, dann reicht auch ein Menü. Oder er steht eben nicht fest (Automatisierungstechnik, Roboter), dann haben die Leute aber entweder spezielle Programmiergeräte (SPS, Roboter) oder arbeiten einfach mit Notebooks. Markus P.S.: Ich hab' so ca. 100.000 Seiten an Perry-Rhodan-Romanen/Büchern im Regal.
> Ich hatte nach einer Lösung gefragt, nicht wie man's am besten durch > den Kakao zieht. Sorry Daniel, aber irgendwie fühlte ich mich durch deine Ausführungen ein wenig provoziert. Ok, mal Spass beiseite. Es soll also ein interface erlaubt sein, aber kein PC. Und es soll also ein Programmcode umcodiert werden können, ohne das Ganze mit Interface-Kabel neu zu programmieren. Nun ja, spontan fällt mir nur die Lösung in dem Link ein, den ich weiter oben gepostet habe. Es handelt sich um einen minimalistischen Basic-Interpreter für den AVR (läuft also im AVR!), der seinen Programmcode als Tokens im EEPROM speichert und dort abarbeitet (natürlich unter Zuhilfenahme des RAM). Um das Ganze zu programmieren bzw. zu ändern ist nur ein kleines TTY-Terminal notwendig. Dieses liesse sich auch wiederum mit einem AVR realisieren (kleine Tastatur, LCD-Display o.ä.), so dass man hier eine sehr kompakte, programmierbare Lösung eines Steuerungscomputers hätte. Eigentlich schon eine recht interessante und vielfältig einsetzbare Sache. Vielleicht entspricht dies ja deinen Vorstellungen. Ansonsten fällt mir so spontan keine weitere passende Lösung dazu ein. Allerdings könnte man für diesen Zweck auch einen kleinen Palmtop-Computer mit angepflanztem I/O-Interface verwenden, z.B. so einen Pocket-PC oder einen Palm Pilot. Die Möglichkeiten wären vielfältig. Vielleicht kannst Du aber auch deine Wünsche noch etwas präzisieren bzw. jemand anders in diesem Forum hat dazu noch einen guten Einfall. have a nice day Notker > p.s.: http://www.hp.com/calculators/ > Es gibt sie noch, oder nicht ? Hmm, interessant. HP hatte dies damals selbst verkündet. Z.B. hier noch zu lesen: http://de.wikipedia.org/wiki/Hewlett-Packard Scheinbar hat es sich HP doch wieder anders überlegt. Aber am interessantesten sind sowieso nur die ganz ollen Dinger mit der roten Anzeige g
HP baut übrigens lebende Fossilien ;-) schaut mal hier http://www.hp.com/calculators/financial/12c/ und hier: http://www.hpmuseum.org/hp12c.htm Schon über 20 Jahre alt und immer noch voll im Trend! Das soll mal ein anderes Unternehmen nachmachen (wenn es bis dahin nicht längst pleite ist!). have a nice day Notker (der auch einen 12C sein eigen nennt)
(Habe diesen Thread vorhin als einzigen mit Suchwort "Forth" gefunden und belebe ihn deshalb trotz seines Alters wieder) Forth ist kein "Fossil", Forth wird benutzt. Wer einmal den Bootloader einer Sun oder eines Mac abgebrochen hat, ist einem Forth begegnet. Für PCs gibt es u.a. FPC, ein hardwarenahes Forth, ideal für Erstimplementierung von Steuerungsaufgaben. Gerade im Microcontrollerbereich ist Forth nach wie vor eine feste Größe. Warum? 1. Forth ist klein. Ein Forthprogramm wird in der Regel kleiner sein als ein Assemblerprogramm, weil Forth Codewiederverwertung auf die Spitze treibt. Nur wird Forth dadurch übersichtlicher, während ein entsprechend kompakt geschriebenes Assemblerprogramm praktisch nicht mehr zu warten wäre. 2. Forth ist interaktiv. Das ist unschätzbar bei Diagnoseaufgaben (daher die Verwendung in OpenFirmware usw). Hat jemand schon einmal seinen DOS-PC mit "debug" bearbeitet? Was für ein Krampf! Ein winziges Forth-System nimmt einem da unendlich Arbeit ab. 3. Forth ist schnell. Faktor 4? Gemeint sind eher 25 %, vermute ich. Der eingebaute Compiler übersetzt jeden neuen Befehl in Maschinencode; bestehende komplexere Befehle tauchen dort als Subroutine-Aufruf auf. Durch die Arbeit mit dem Stack bedeuten Subroutinen aber verschwindenden Performanceverlust (keine umständliche Parameterübergabe), im Gegensatz zu C usw. 4. Forth taugt von kleinen bis zu großen Projekten. Ein alter Forth-Programmierer hat einmal gesagt, man könnte in Forth zwar keine großen Programme schreiben, aber man könne darin die perfekte Sprache für ein beliebig komplexes Problem schreiben. Das ist es: man schafft sich Ebene für Ebene immer komplexere Befehle und kann diese sogar unterwegs testen, ganz ohne Debugcode (den man nachher vergißt). 5. Forth ist anders. Zugegeben, Forth führt ein Nischendasein. Grund dafür ist wohl, das Forth völlig anders aufgebaut ist als andere Sprachen. C, Assembler, Basic, Pascal, Java ... die funktionieren alle nach irgendwo ähnlichen Prinzipien. Forth nicht. Wenn man also mit etwas anderem angefangen hat, ist es eine gewaltige Umstellung, ansonsten wird man mit der Sprache nicht glücklich (Beispiele im Thread). Dabei kommt Forth eigentlich dem menschlichen Denken sehr entgegen; nur ist dieses Denken bei Programmierern gerne schon umgekrempelt. Der Weg zurück ist hart, aber er lohnt sich. Im kommerziellen Umfeld ist die Entscheidung natürlich gewagt, denn einen Forth-Programmierer kann man nicht so leicht ersetzen wie einen C-Programmierer. Wer einmal "forth" und "avr" bei Google eingibt, findet, daß außerhalb dieses Forums die Kombination durchaus üblich ist und geschätzt wird. Ich fange gerade ein Projekt an und habe mich für einen Atmega als Basis entschieden. Eine Abschätzung des Resourcenbedarfs ergab, daß ich mit C nicht hinkommen werde, also werde ich wohl wieder auf Forth zurückgreifen (obwohl ich ansonsten einen Haufen C-Code von anderen Projekten übernehmen könnte). Ich würde mich gerne auch hier austauschen; die Erfahrungen von Henk interessieren mich auch. Wenn Interesse besteht, kann ich dann gerne auch eine Einführung dazu verfassen. Wenn aber nur Interesse am üblichen Forth-Bashing besteht, nur zu. Die durchschlagende Unkenntnis der Lästerer macht ihre Kritik nur zu einer Demonstration ihres beschränkten Horizontes. (-: Gruß, Philipp.
Hallo Ich bin immer für neue Dinge offen. Kannst du uns mal das prinzipielle Grundgerüst von Forth etwas näher bringen? Ich habe bis jetzt nur C, Basic, Power-Builder, Cobol und Assembler programmiert. Deine Schilderung über die Näherbringung zum menschlichen Denken interessiert mich sehr. Wenn man schon so lange wie ich C programmiert, kann mann sich kaum mehr andere Konzepte vorstellen. Noch dazu dann, wenn alle anderen Programmiersprachen so ähnlich sind. Ich bin gespannt, was du uns über Forth erzählst. Tschüss Martin
Die Idee ist leider nicht so gut. Forth wird ja normalerweise auf einem System interpretiert. Das hat so seine Vorteile, naemlich das man direkt auf seiner Zielhardware entwickelt, aber auch den Nachteil das ein Minimum an Nutzerinterface vorhanden sein muss. Bei den meisten Anwendungen die man nun aber mit kleinen AVRs, MCS51 usw macht, wird man dieses Nutzerinterface aber fuer die eigentlich arbeiten nicht mehr brauchen. Das ganze ist daher IMHO etwas ineffizient. Man kann aber auch richtige Forthcompiler nehmen. Wie der Zufall so will habe ich vor Jahren soetwas mal programmiert. Sucht mal nach st6forth. Ist aber natuerlich fuer einen ST6 und nicht AVR. Allerdings kann man das natuerlich auch aendern, ich hab das z.B spaeter mal fuer den MCS51 angepasst. Eine Anpassung an den AVR sollte keine grosse Sache sein. Das ganze hat schon eine gewisse Faszination. Insbesondere fuer sehr kleine Prozessoren auf denen man den gewissen Luxus einer ich sag mal hoeheren Sprache haben moechte, sich aber andererseits dicke Compiler kaum leisten kann, ist das dann eine schoene Sache. Ich muss aber gestehen das ich mittlerweile ueberwiegend C benutze weil auch kleine Microcontroller mittlerweile viele Resourcen mitbringen. Wer noch nie etwas von Forth gehoert hat fuer den wird die Sprache zunaechst ein Schock sein. Es lohnt sich aber sich damit zu beschaeftigen. Aehnlich wie Schach spielen oder das Kreuzwortraetzel in der Times. :-) Olaf
In den späten 80er Jahren hatte ich auch mal drüber nachgedacht, mich mit FORTH zu beschäftigen. Nach dem Anlesen des Artikels "FORTH - ein Softwarekonzept für Mikro-und Minicomputer" von Claus Kühnel im Heft 10 der "Kleinstrechner-Tips" war ich damals neugierig geworden. Zumal es für den KC85/2 bzw. KC85/3 (den ich damals hatte) FORTH als ROM-Erweiterungs-Modul M026 gab. Aber wie das so ist, das Teil war seinerzeit nicht zu beschaffen und zu teuer, und damit war die Sache erledigt. Schade. Aber die knapp 20 Seiten in dem Heft werde ich jetzt mal lesen... Gruß Ingo
erstmal vorneweg: ich hab keine ahnung von forth aber mir sind ein paar fragen gekommen "1. Forth ist klein. Ein Forthprogramm wird in der Regel kleiner sein als ein Assemblerprogramm, weil Forth Codewiederverwertung auf die Spitze treibt. Nur wird Forth dadurch übersichtlicher, während ein entsprechend kompakt geschriebenes Assemblerprogramm praktisch nicht mehr zu warten wäre." das kann man seitdem es funktionen gibt doch bei jeder sprache machen, von assembler angefangen. wo ist der unter von forth? 2. Forth ist interaktiv. Das ist unschätzbar bei Diagnoseaufgaben (daher die Verwendung in OpenFirmware usw). Hat jemand schon einmal seinen DOS-PC mit "debug" bearbeitet? Was für ein Krampf! Ein winziges Forth-System nimmt einem da unendlich Arbeit ab. dass hiesse, man müsste auf einem avr ein komplettes interface für ein und ausgabe aufbauen (ausreichendes display, keyboard) oder wie willst du sonst einen uC (ja, um die geht es hier, nicht um pc's) debuggen. ich denk mal da sind hardwarenahe diagnosesysteme ala jtag überlegen, die ein externes gerät als interface benutzen. oder was meintest du mit interaktiv (z.b debuggen) 3. Forth ist schnell. Faktor 4? Gemeint sind eher 25 %, vermute ich. Der eingebaute Compiler übersetzt jeden neuen Befehl in Maschinencode; bestehende komplexere Befehle tauchen dort als Subroutine-Aufruf auf. Durch die Arbeit mit dem Stack bedeuten Subroutinen aber verschwindenden Performanceverlust (keine umständliche Parameterübergabe), im Gegensatz zu C usw. ist forth nun ein compiler oder interpreter. da gibt es widersprüchliche angaben. oder gibts dafür beides wobei bei einem compiler die interaktive entwicklung wieder ein problem wäre. so weit ich weiss übergibt auch c parameter auf dem stack (so wie die meisten hochsprachen) was für arbeiten mit dem stack macht denn forth, dass die parameterübergaeb so viel schneller ist obwohl du ja schreibst,d ass auch der stack benutzt wird? viele subroutinenaufrufe sind zwar ideal zur codewiederverwertung aber blähen die stack unnötig auf und brauchen auch bei entsprechender menge einiges an ausführungszeit. was ist in zeiten von grossen speichern selbst auch kleinsten controllern der vorteil? so, genug gefragt. bin neugierig auf die antworten, vielleicht versteh ich das konzept der sprache dann mal ;)
Coole Sache, so ein KC-Emulator :-) Falls es jemanden interssiert, einen KC-Emulator nebst FORTH-Modul M026 gibt es hier: http://kcemu.sourceforge.net Da scheint seit einem Jahr aber die Entwicklung zu ruhen. Zumindest konnte ich damit kurz das FORTH auf einem KC85/4 starten. Dazu als Emulation "KC85 - 4" starten, unter "Module..." unten links in Schacht C das Modul "M026: Forth" reintun. Anschließend mit SWITCH 0C C1 das Modul einschalten und das Menü mit MENU neu anzeigen. Es sollten nun oben zwei neue Menüeinträge "FORTH" und "REFORTH" vorhanden sein. Jetzt kann man FORTH einfach durch Eingabe von FORTH starten und zum Spaß mal 321 + 456 ausrechnen: 321 456 + . [ENTER] Viel Spaß :-)
Wow! Tolles System. Sieht aus als wäre es aus dem vorhergehendem Jahr hunterttausend. Also bis jetzt habe ich nicht wirklich ein Argument gehört, warum Forth angeglich so super ist. Jedesmal wenn man genauer nachfragt kommt keine Antwort. Mit diesen oberflächlichen Angeblich-Argumenten kann ich nichts anfangen. Wo bleiben endlich die Beispiele, um diese Argumente zu untermauern? Warum soll ich hier einen riesen Hardwareaufwand begreiben nur damit man mal den Forth-Interpreter (oder was auch immer) laufen lassen kann, wenn man mit fast null Hardware und C den Prozessor super laufen lassen kann? Noch dazu bremst der Forth-Interpreter. Tschüss. Martin
hab mal was gesucht und das hier gefunden: http://claymore.engineer.gvsu.edu/~steriana/Python/pfavr/ mal ein paar features: - PFAVR fits into less than 13Kwords of FLASH and less than 32Kbytes of RAM - They were designed for the ATmega128 processor with at least 32K of external RAM with one wait-state. Other AVR's may work too if they have at least 13Kwords of FLASH and 32Kbytes of external RAM. kann ja sein, dass ich gerad eine schlechte implementierung gefunden hab aber das versth ich nicht unter geringer codegrösse und sparsamkeit. mal einmkleiner codeschnippsel den ich gefunden habe: LOG1W TEMPSENS VAR N : CELSIUS CRC1W DROP { DROP deletes old CRC value from Stack } TEMPSENS WR1W($BE) RD1W ->CRC / 2 . EMIT($20) FOR N(0,5) DO RD1W ->CRC NEXT IF (RD1W = CRC1W) ." Grad C" ELSE ." ERROR" ENDIF RET sieht aus wie wenn man basiccode sinnlos probier in eine zeile zu quetschen :) das dingen hat nicht mehr mit dem menschlichen denken zu tun als c-code. da liegt z.b pascal wesentlich mehr am normalen sprachgebrauch. da bleib ich lieber bei c, sieht für mich genauso unübersichtlich aus und man kriegt keinen krampf auf der shift taste ;)
@ Martin:
Eine Vorstellung von Forth im Rahmen eines Forenbeitrags? Oje,
hoffentlich verwirrt das nicht mehr als es klärt! Das Herz von Forth
ist ein zweiter Stack, auf den praktisch alle Operationen ausgeführt
werden. Ein '+' ersetzt z.B. die beiden obersten Werte vom Stack
durch ihre Summe. Das ersetzt fast alle (lokalen) Variablen und
Unterprogramme brauchen keine extra Parameterübergabe. Das macht der
Stack "automatisch". Dadurch kann man ohne großen Overhead auch
winzige Unterprogramme nutzen.
Dadurch ergibt sich automatisch die gefürchtete "umgekehrt polnische"
Notation, die aber letzlich unserem Denken entspricht: ich gebe Mehl und
Eier in die Schüssel, dann verrühre ich. Gebe Butter dazu und knete das
ganze usw. Erst die Zutaten, dann verarbeiten. Also "3 4 + 6 *". Das
"(3 + 4) * 6" wurde uns nur halt von Kleinauf antrainiert.
Forth hat ein Wörterbuch von Befehlen, das man selbst mit dem
eingebauten Compiler erweitert. Dabei werden frühere Befehle entweder
direkt eingefügt oder als Subroutinenaufruf. Dabei sind alle
Sprachelemente normale Befehle, auch "if", "for", "until" usw.
Auch der Compiler selbst (der Doppelpunkt) ist nur ein Befehl unter
vielen. Und das Schreiben von eigenen Compilern gehört zu einem
größeren Projekt fast immer dazu. Hier werden auch die meisten
Neugierigen abgeschreckt, denn man muß in Compilezeit und
Ausführungszeit denken.
Ein Kernwörterbuch für ein 8-bit-Forth wird unter einem kB groß sein,
der Rest ist dann in Forth geschrieben. Ein brauchbares, interakives
Forth kommt mit wenigen kB aus.
@ Tobi:
zu 1. In keiner anderen Sprache wirst du etwas wie
char Mittelwert(char a, char b) { return (a + b) >> 1); }
definieren. Das sieht zwar nachher übersichtlich aus, wird aber fett
und langsam; a und b müssen auf den Stack gelegt werden, das Ergebnis
nachher vom Stack geholt werden -- viel Overhead. In Forth macht man
alles ohnehin auf dem Stack (weil er nicht gleichzeitig Return Stack
ist) und es gibt keinen Overhead bis auf zwei Befehle zum
Unterprogrammaufruf und zum Rücksprung.
zu 2. Als Debuginterface für einen µC nimmt man z.B. eine UART, an die
man ein VT100 anschließt. Alles andere frißt natürlich zuviel
Resourcen. Aber dann kannst Du interaktiv Programmteile testen, z.B. um
einen timingkritischen Buszugriff auszufeilen. Ganz ohne
Ändern-Compilieren-Übertragen-Testen. Stell Dir vor, Du könntest eine
unwillige Zugriffsroutine einfach unabhängig vom Restprogramm von Hand
mit verschiedenen Parametern starten, um die Übertragung auf dem Oszi
zu verfolgen. In C müßte man erst wieder einen Haufen Debugcode
schreiben und hin und her.
zu 3. Forth ist Compiler und Interpreter. Was Du tippst, wird
interpretiert. Neue Befehle werden compiliert. Mit
: Mittelwert + /2 ;
läßt man den Befehl von oben dem Wörterbuch hinzufügen und kann in
Zukunft "4 6 Mittelwert" nutzen.
zu PFAVR: Das ist ein ANSI-Forth. Das wurde um allerlei mehr oder
weniger Nützliches erweitert. Wer ohne 32-Bit-Befehle und manchen
Programmierkomfort leben kann, braucht das nicht. Der Autor selbst
schreibt, daß es groß gerade ist, weil es in C geschrieben ist. Alleine
durch den Befehl "WORDS" muß jeder Befehl im Volltext im Dict stehen,
während für einen µC ein 2-Byte-Hashwert angemessen wäre.
Forth ist grauenerregend. Ich habe einen Jupiter ACE - erinnert sich noch wer an das Teil? Zur gleichen Zeit habe ich auf einem Apple II mit einem Forth-Derivat namens GraForth herumgespielt - schön, daß das so lange her ist.
@philip:
"In keiner anderen Sprache wirst du etwas wie
char Mittelwert(char a, char b) { return (a + b) >> 1); }
definieren. Das sieht zwar nachher übersichtlich aus, wird aber fett
und langsam; a und b müssen auf den Stack gelegt werden, das Ergebnis
nachher vom Stack geholt werden -- viel Overhead."
das sehe ich genau anders herum. bei vielen systemarchitekturen ist der
stack im hauptspeicher abgelegt und der zugriff darauf ist systembedingt
um einiges langsamer als der auf interne register. durch die vielen
zugriffe auf diesen 'rechen'-stack entstehen dann doch nicht gerade
wenige waitstates die die programmausführung ausbremsen. bei dem
prinzip, dass andere sprachen (ala c) benutzen werden die rechnungen
mit den internen registern durchgeführt die keine längere zugriffszeit
haben. bei deinem minimalbeispiel oben könnte man noch von einer
minimalen zeitersparniss ausgehen, aber bei auch nur wenig komplexeren
operationen dürfte der overhead durch den speicherzugriff grösser sein,
als der durch das einmal in register kopieren und zurück
gegen meine behauptung der unübersichtlichkeit in meinem letzten post
darf jeder forth verfechter auch gerne noch was sagen :)
Bei dem Beispiel:
char Mittelwert(char a, char b) { return (a + b) >> 1); }
wird gcc z.B. den Funktionsaufruf -je nach gewählter
Optimierungsoption- komplett weglassen und durch wenige
Assemblerbefehle ersetzen.
Stefan
Man wird i.d.R. als TopOfStack ein Register benutzen, ein weiteres als Stack-pointer. Eine Addition würde also eine indirekt adressierte Speicherzelle zum ToS-Register addieren und den Stack-Pointer decrementieren. Nenne mir mal einen Controller, der dafür länger braucht als für die zwei Push, zwei Pull, Registeraddition, noch ein Push, noch ein Pull. Natürlich ist es weniger effektiv als eine Forth-Maschine, wo die CPU den zweiten Stack verwaltet, aber immer noch effektiv genug. Je nach Controller mag es sich lohnen, auch die Nummer 2 des Stack (NOS) als Register zu führen, das führt aber automatisch zu mehr Swapperei zwischen ToS und NoS (beide Register addieren, NoS nachladen und Register decrementieren). Hängt von den Taktzyklen für die entsprechenden Befehle ab, ob das besser ist. Übersichtlichkeit? Du bist nicht der erste, der Forth als "Write-Only-Language" belästert. Die Versuchung ist tatsächlich groß. Der Autor Deines Codeschnipsels verschärft das Problem nicht nur durch gruselige Namen (es besteht die Ahnung, daß ein DS1820 ausgelesen werden soll), sondern auch durch offenbar willkürlich umdefinierte Sprachelemente. Ein FOR mit dieser Klammernotation ist ebenso "unforthisch" wie das kaputte IF. Ja, man kann sich in Forth schnell ein wirres Basic schreiben. Aber nützlich ist das wohl weniger. In einem Forth-Tuturial findest Du glücklichere Beispiele. Wenn man zu Beginn eines Programmierprojektes in Stichworten die Programmfunktion aufschreibt, gibt das meist schon einen guten Programmcode für die oberste Ebene ab. (-:
Es ist übrigens völlig egal, wie alt ein Thread ist - es ist überhaupt kein Problem, ein Diskussion über Jahre zu führen, mit großen Zeitlücken dazwischen. Der Zeitfaktor schmälert doch nicht den Inhalt. Die ursprüngliche Frage lautet, ob Forth ein sinnvolles Betriebssystem für den AVR-Mikrocomputer ist, um im Bedarfsfall mit minimaler Interface-Hardware (UART + VT100-Terminal) in den laufenden Betrieb mit Änderungen eingreifen zu können. Und ich kann bestätigen: Forth ist von Natur aus Betriebssystem, Interpreter und Compiler in einem. Dabei liegt der Speicherverbrauch samt Programm vielleicht bei 4 kB, und die Geschwindigkeit nah am Maschinencode. Forth besteht im Kern aus wenigen Bytes Maschinencode, der Rest besteht aus Forth selbst. Forth ist nicht vergleichbar mit anderen Konzepten. Es ist eleganter, denn es besteht nicht aus einem großen Programmieraufwand, sondern aus einer selbsterzeugenden, intelligenten Codeidee. Trotz seiner atemberaubenden Geschwindigkeit und seiner unglaublichen Winzigkeit ist Forth dennoch interaktiv - außerdem steht der Lösung von Aufgaben beliebiger Komplexität schlichtweg gar nichts im Wege. Forth ist nur deshalb bei der Masse der Programmierer in Vergessenheit geraten, weil es zum einen der heute rasend schnellen Prozessoren wegen nicht mehr auf Geschwindigkeit ankommt, weil es zum weiteren bei den heute riesigen Arbeitsspeichern nicht mehr auf sparsame Kleinheit ankommt, und weil zum anderen Programmierer in den meisten Fällen sozialisiert wurden durch Basic, C, Pascal oder PHP. Forth ist ein mühsames Geschäft, wenn man es gewohnt ist, in anderen Hochsprachen beliebig komplexe Anweisungen mit einer Zeile Code abzuhaken. Das geht in Forth zunächst eben nicht. Die erwähnte komplexe Anweisung muss man sich erst mal bauen - dann geht es genauso, wie in ... sagen wir C. Für den heutigen Programmierer gilt es aber als unzumutbarer Aufwand, sich seine Sprache jedesmal neu zu schreiben - durchaus verständlich. Im Grunde ist Forth damit ein Kit, um sich für seine ganz speziellen Zwecke eine eigene Sprache zu bauen - die dann allerding unvergleichlich mächtig ist. Dieser Mühe setzt sich heute keiner mehr aus - darum kann Forth niemals populär werden. Für Mikrocomputer jedoch gibt es nichts besseres! Die Interaktivität ist ein Feature, das man mit dem geringstem Hardwareaufwand realisiert werden kann - aber wen interessiert das, wo alles vorgefertigt mit Notebooks oder Handhelds möglich wird. Programmierer verstehen heute weniger denn je, was sie da benutzen - Hard- und Software sind zu komplex, zu riesig dafür. Aber bequem. Meine Antwort: Ja - für den AVR-Mikrocomputer unbedingt Forth nehmen. Wenn man es nicht hasst, weil man nichts versteht oder weil man bequem ist.
Forth ist sicher für Microcontroller nicht grundsätzlich falsch, weil es ja eigentlich genau für diesen Zweck entwickelt wurde: Die Programmierung von Steuerungen. Den Nachteil sehe ich darin, dass man nach meinem Verständnis immer Bottom-Up programmieren muss. Man fängt also mit kleinen Bausteinen an, setzt sie zu größeren zusammen, dann zu noch größeren und am Ende steht die Applikation. Das setzt aber voraus, dass man sein Projekt von Anfang an komplett durchschaut, man also schon am Anfang weiß, welche kleinen Bausteine man braucht. Viele werden hier eher Top-Down programmieren. Also erst einmal eine Art Template erstellen, bei dem der Compiler nicht mehr meckert, und das dann mit Funktion füllen. Da passt Forth halt nicht ins Konzept.
huhu, ich wecke auch mal diesen alten thread auf :) ich hatte mir vor ein paar tagen amForth angeschaut. meine fortherfahrungen davor: einmal wikipedia seite dazu durchgelesen, mehr nicht. amForth ausprobieren ging viel einfacher als ich erwartet hatte, denn es sind gleich hexfiles für arduino dabei, und zufälligerweise lag hier einer rum. flashen und voila! man hat über minicom eine art shell und kann den atmega rechnen lassen. "1 2 + ." liefert tatsächlich "3 ok" ein paar helferfunktionen um mittels forth direkt auf alle atmega-funktionalitäten sind dabei, nur fehlte dann noch passende doku - ich schaffte es nicht die led auf dem arduino-board zum blinken zu kriegen, statt dessen hab ich irgendwie das forth system geschossen: erst nach neueinspielen des eeprom hexfiles gingen einfache funktionen wieder. mein urteil: amforth ist ein funktionierendes, ausbaubares system, aber derzeit noch recht frickelig, speziell und unzureichend dokumentiert. danke an den entwickler :D
das war mal ca 1980 aktuell ;) Ich kann mich noch daran erinnern dass das mal bei einem Kunden in einem kleineren Projekt eingesetzt wurde und hinterher das komplette Entwicklerteam überzeugt war "Nie wieder !"
https://sites.google.com/site/libby8dev/fignition Hier ist ein AVR Forth computer.. hab den thread leider etwas spät entdeckt :O sonst hät ich nicht extra einen geöffnet. Gruss Matze
Mathias Trute hat ein AVR-Forth geschrieben, es ist auch irgendwo verfügbar. Forth hat einen grossen nachteil: Das System braucht enorm viel Speicher.Daher taugt das alles nur zum Systemtest. Anwendungen erstellt man damit besser nicht. Gruss Robert
> Das System braucht enorm viel Speicher.
"brauchen" ist so nicht richtig. Forth Systeme "brauchen" sogar
erstaunlich wenig Speicher. Bei Forth Systemen kann man aber durchaus
sagen: Je mehr Bytes, desto mehr Forth-Wörter hat man im System
integriert. Man kann aber letztendes alle Forth Worte, die nicht
gebraucht werden, auch aus dem System entfernen und so das System wieder
abspecken.
Forth ist halt gewöhnungsbedürftig. Das ist der größte Nachteil.
Ich möchte kurz anmerken, dass ich dieses Argument "RPN machen wir doch jeden Tag" zum kotzen finde ;-) Ich sterbe bei RPN Taschenrechnern und brauche welche mit Infix Notation. Ist einfach eine Geschmacksfrage. Frage mich auch was das in einer Programmiersprache zu suchen hat. Aber da bin ich möglicherweise zu konservativ.
Simon K. schrieb: > Ich möchte kurz anmerken, dass ich dieses Argument "RPN machen wir doch > jeden Tag" zum kotzen finde ;-) Ich sterbe bei RPN Taschenrechnern und > brauche welche mit Infix Notation. :-) Ist alles eine Frage der Gewohnheit. Den Bogen hatte ich bei meinem HP-Taschenrechner aber schnell raus. RPN ist einfach nur konsequent: Zuerst die Operatoren und dann die Operation. Bei den älteren Taschenrechnern war das ja auch nicht ander: erst tippte man den Winkel ein und dann drückte man die Taste für Sinus. Nur bei + * - / war alles ganz anders. > Frage mich auch was das in einer Programmiersprache zu suchen hat. Das ist einfach das Forth Konzept. RPN und die dafür aber konsequent durchgezogen. Das macht den "Compiler" einfach und schlank. LISP ist genau anders rum: Zuerst die Operation und dann die Operanden.
Hallo! Wir standen vor wenigen Jahren, d.h. 2009, vor der Entscheidung, ein skriptfähige Ausführungsumgebung für einen STM32 zu finden. Nach wirklich umfangreichen Voruntersuchungen sind wir immer wieder bei Forth gelandet und haben uns für pForth entschieden. Die Gründe hierfür waren die folgenden: 1. kompakte Laufzeitumgebung 2. deterministisches Ablaufverhalten ohne Garbage Collector o.ä. 3. Forth-Codegenerator sehr einfach als PC-Anwendung implementierbar 4. Laufzeitumgebung nicht mit GPL/LGPL, sondern BSD-artig Bei dem Projekt ist jedoch nicht die komplette Firmware bzw. der Anwendungsteil in Forth geschrieben, sondern nur die eigentlichen Berechnungsfunktionen. Das Produkt, das dabei herausgekommen ist, ist unsere Funkfernsteuerung iVol blu bzw. iVol 2G16: http://www.baltic-seagull.de/
Ein minimalistisches Forth, daß wenige Ressourcen des Controllers belegt u. trotzdem erweiterbar ist : http://www.wulfden.org/downloads/Forth_Resources/3-INSTRUCTION-FORTH.pdf
> Ein minimalistisches Forth, daß wenige Ressourcen des Controllers belegt
u. trotzdem erweiterbar ist :
Ist zwar schon ein paar Jahre her (18, um genau zu sein), aber damals
hatte ich ein genau auf den Zweck angepasstes Minimalforth auf einem
68HC11 programmiert, mit dem ich eine drehbare Antenne gesteuert (und
geregelt) habe. Dabei war das Betriebssystem in C geschrieben und der
Interpreter arbeitete nach Forth-Manier. Wenn man einen simplen aber
flexiblen Interpreter braucht, dann ist die gute alte Forth-Methode IMHO
ideal.
matze schrieb: > https://sites.google.com/site/libby8dev/fignition > > Hier ist ein AVR Forth computer.. hab den thread leider etwas spät > entdeckt :O sonst hät ich nicht extra einen geöffnet. > > Gruss Matze Hi! Finde den Link Spitze! Musste mir den "FIGnition" sofort ordern ! ;-) Gerhard
Daniel Roth schrieb: > vielleicht ist schon jemand von euch auf die Programmiersprache Forth > gestoßen und hat sich etwas damit befasst. Die Sprache könnte man gut > auf dem AVR umsetzen Nein, der AVR ist sogar denkbar ungeeignet für Forth. Seine Harvard-Architektur ist gerade nicht dafür gedacht, "interaktiv" zu sein, sondern sieht statischen Code vor. Dementsprechend ist der Programmspeicher für eben diesen statischen Code immer "groß", jedenfalls groß im Verhältnis zum verfügbaren RAM, auf den Forth einerseits wegen seines dynamisch generierten Codes und andererseits wegen seiner stackorientierten Arbeitsweise angewiesen ist. Also ich kann ja vielleicht noch akzeptieren, daß jemand Spaß an Forth als Sprache hat. Auch wenn ich das nicht wirklich nachvollziehen kann, ich fand die Sprache schon beschissen, als ich das erste Mal 1986 auf einem Atari 800XL damit rumgespielt habe. Und der war von der Architektur her immerhin weitaus besser für Forth geeignet als ein AVR. Forth auf einem AVR ist ungefähr so sinnvoll wie ein Ferrari F40 als Vorspannfahrzeug für eine Betonfräse oder ein Montainbike als Startstufe für einen bemannten Marsflug. Das paßt einfach nicht zusammen. Wenn du unbedingt mit Forth auf einem µC rumspielen willst, dann nimm einen mit VonNeumann-Architektur. Auch noch nicht ideal für Forth, aber immerhin schon wesentlich geeigneter als Harvard.
Vielleicht sollte man mal einige alte Fragen aus dem Thread beantworten: 1. Standardprozessoren, die sich für Forth eignen: z.B. der 68K hat quasi 8 Stacks 2. Weltraum bzw. hohe Zuverlässigkeit: IPS ist eigentlich fast vollständig standard Forth. Hat seine extrem hohe Zuverlässigkeit in Amateurfunk-Satelliten bewiesen. Ich sehe eher in der heutigen Zeit das Problem, daß mitgelieferte Libs immer für C sind. Ein Forth-Programmierer müßte die alle nachschreiben oder irgendwie in einem Mischcode aus C und Forth integrieren, damit er die Prozessor-Libs dann in Forth benutzen kann. Aus meiner Sicht sind DLLs und Forth halbwegs vergleichbar. Man kann ein laufendes System durch Austausch von Modulen umprogrammieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.