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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
## forwarded copy of: EruqxzAUQoB@allinger-307049.user.uni-berlin
## date             : 15.08.19
## newsgroup/archive: de.sci.electronics
## user             : snipped-for-privacy@spambog.com  (Wolfgang Allinger)



wiederfindet :)


On 15 Aug 19 at group /de/sci/electronics in article snipped-for-privacy@mid.individual.net

Quoted text here. Click to load it







z.B. startup_4712.src, das System hab ich so eingerichtet, dass es beim  
Start in einem bestimmten Verzeichnis (START :) nach ner neuen Datei  
gesucht hat, wenn es die gefunden hat wurde die einfach interpretiert/  
compiliert und die Anlage war wieder auf dem neuesten Stand.

So konnte man Patches oder Versuche einspielen, so dass der Kunde die  

hatte konnte er damit arbeiten, wenn er wollte, dann einfach  



Wenns nix war, dann per Editor, zB. dem im benutzten FORTH eingebauten  
oder einen externen nehmen und startup_xxxx.src verbasteln.

Und warten, bis der eingewiesene Programmierer oder der Allinger ne  
angepasste exe lieferte.

FORTH ist halt ein Interpiler und Compreter :) gleichzeitig.


verfummeln oder probieren konnten.

kurzes langatmiges  Gesabbel von mir:

Justierung justiert werden sollen, wie geht das? Ich hab denen dann eine  
datei geschickt, wo die HLL Definitionen drinstanden. Konnte er dann beim  


das als letztes Wort in die update_Typ999 reinfrickeln, oder wenns  
dauerhaft bleiben sollte, dann eben \ (Backslash) START einflicken und  

dann eben das Kommentarwort "\ " vor Start weg und gut wars.
Alles was FORTH im Eingabestrom (prompt OK ) liest, wird bei einem <SP>  


verwursten, wenn ja, dann wurde die Zahl auf den STACK gelegt und weiter  
geparst, wenn nicht, weil BlaFasel nicht gefunden wurde, kommt ein  





Der Outer Interpreter ist einfach die Endlosschleife, die auf Keys wartet.
Mit dem einfachen Wort ":" name bla blu blubber ; wird der Compiler  
eingeschaltet und versucht eine neue Definition 'name' zusammenzubringen,  
falls der Eingabestrom nur definierte Sachen finden, passiert  
of(f)ensichtlich nix, bis das Wort ';' den Compiler wieder ausschaltet und  
die Endlosschleife (Outer Interpreter) wieder einschaltet und auf neue  
Worte wartet. Sonst kommt halt "blubber" is undefined.  Das ist die Colon-  
Definition, also der HLL Compiler.





eintippern und das Problem ist hoffentlich behoben.

Dann blubber eintippen und beobachten Was passiert? War nix? Doch lieber



blubber is redifined OK


FORGET blubber<CR>

OK

und alles ist wieder sauber.

Ahh ja, und wie ist das kompiliert? Der Compiler setzt ins RAM an die  


feddich is die Laube.


gefunden wurde, hampelt der Inner Interpreter eifach die aktuelle Liste  
ab. Also eine Liste mit Verweisen auf Listen von Listen... Es wird also  
solange die Aufgabe vor sich hergeschoben, bis irgendwann in diesem  



Kannste Dir also etwa so vorstellen, wie eine Liste mit CALL 1234  CALL  
4567 CALL 8134 ... vobei der CALL niht drinsteht, sondern nur die  
Verweisadresse und der Inner Interpreter macht dann die CALLs.

Zack, so einfach ist FORTH.


Ein weiteres wichtiges Wortpaar ist CODE ... END-CODE das macht im Prinzip  



Der Anwender wird CODE END-CODE kaum brauchen, das mach dann ggf. ich oder  
ein anderer Kenner.

Der Kunde schickt mir nur seine Latte von neuen :- Definitionen und sagt,  
funzt alles, aber zu langsam, muss 3x schneller ablaufen. Ich frickel dann  
interaktiv raus, wo wie die Zeit verplempert wird und verbessere das oder  
schreib das Wort als CODE-Definition. Ist nur ein simples umkodieren, um  

schon als gut befunden. Macht die Sache unglaublich einfach. Meist sind  

wird halt eine oder mehrere Testschleifen definiert, wo die :- und die  
CODE- Definition beide mit den gleichen Parametern aufgerufen und die  
Ergebnisse verglichen werden, wenn abweicht, Schleifenabbruch und  


Wer bisher durchgehalten hat: BRAVO nun kommt das ENDE bald :)




Auch sonstige Parameter standen in der Startup Datei

zB. Hubweg  wurde mit der syntax

12,3 inch als Hubweg

festgelegt. Oh heute cm? kein Problem, dann eben

17,3 cm als Hubweg

eintippern, wg. mir erst mal zur Probe interaktiv, dann per editor in die  
Start. Ja alle meine Projekte wurden als META Sprache in den jeweiligen  
Anwender eigenen Fachsprache geschrieben, wegen mir auch in seiner  
Landesprache. Ist praktisch Bestandteil von (Vollausbau) FORTH. Genauso  
wie METAkompiler. Wenn ich die Fachsprache des Kunden kapiert habe, bin

ihm zu seinem Nutzen gelernt und wir reden weniger aneinander vorbei.
WIN-WIN



So nun zum Schluss:




Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht  



May the FORTH be with you!





Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 15.08.2019 um 23:45 schrieb Wolfgang Allinger:

Quoted text here. Click to load it


Quoted text here. Click to load it




es um Echtzeit auf einem Mikrocontroller geht, bei dem selbst die  





reinrassigen Maschinencode laufen lassen. Bis dahin unterscheidet sich  
FORTH kaum von BASIC, was die Laufzeit betrifft.

DoDi

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

On 16 Aug 19 at group /de/sci/electronics in article snipped-for-privacy@mid.individual.net

Quoted text here. Click to load it



Quoted text here. Click to load it




Quoted text here. Click to load it





Quoted text here. Click to load it







nicht.

Die Anlage wurde dann nochmal in 3facher Ausfertigung gebaut, also 768  

Jeder Kanal kam mit 20kHz IFF rein, jeweils 16bit Laufzeit und 8bit  

IRs irgendwann asynchron in dem bis 20kHz Grundtakt.

Und nicht ein einziger IR durfte verschlabbert werden.








unterschiedlichen Tiefen, Richtungen und wehe man hat eine Bohrung am Ende  
der Anlage nicht mit Farbpistolen angespritzt und markiert.

Der Kunde fands auch nicht lustig, wenn die Compuster mal son ganzes Rohr  
komplett lackiert haben. Fehlersuche war etwas stressig :)

Die Rohre wurden gerne an Rheinmetall geliefert und die mochten absolut  
keine Farbe auf den Rohren, nur ihr Testrohr musste in der Farbe des Tages  








Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 15.08.19 23:45, Wolfgang Allinger wrote:

Quoted text here. Click to load it



Also vermutlich auch eines der am besten optimiertesten.

Deine Argumente sind, zusammenfassend, etwa:


2. Forth ist einfach zu schreiben, weil skriptbar

Das sind beides subjektive und qualitative Argumente. Auf meine Frage im


das nicht testen.

Ich habe vorher noch nie Forth geschrieben aber innerhalb von einer
Stunde konnte ich ein Benchmark zusammenstellen. Und ich habe auch den

implementiert und zwar komplett naiv, dem Pseudeocode von Wikipedia
folgende.

Dann Gforth, dass du oben empfohlen hast, als Benchmarking verwendet.
Resultate hier: https://github.com/johndoe31415/forthvsc


Datenstrom Faktor 655. Also im Mittel, sagen wir, Faktor 500 lansgsamer.

MHz clocke und auf dem System B denselben Code von 32 kHz Uhrenquarz
laufen lasse. Es sind WELTEN.



nur unbenutzbar. Ich kann das Argument ja gut verstehen, dass du die




Das ist mir schon immer sehr suspekt, wenn jemand nur Vorteile von
irgendwas anpreist. Nichts, was mir bekannt ist, hat nur Vorteile. Dann
muss man aber halt auch so ehrlich sein und die Nachteile (totale
Gurkenperformance) zugeben, sonst ist es einfach nur Unehrlich.


Johannes

Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 16.08.2019 um 20:55 schrieb Johannes Bauer:

Quoted text here. Click to load it

Quoted text here. Click to load it






darauf habe ich ja bereits hingewiesen. Schau mal in eine (embedded)  





sowas sicher nicht zu schaffen, nicht nur mangels Dokumentation der  
Hardware, sondern auch mangels direktem Zugriff darauf. Da hilft sogar  
ein RT-OS wenig, wenn es um interaktive Programme und ihre Entwicklung geht.





Kommt drauf an, welche Geschwindigkeit die Anwendung erfordert. Typische  
Controller Programme verbringen ihre Zeit fast nur mit Warten auf  
Ereignisse, und reagieren dann mit dem Setzen von ein paar Bits der  

einem langsamen 8-Bit Mikrocontroller betreiben, da geht auch mit  
500000-facher Rechengeschwindigkeit nicht mehr (Takt:100-1000 +  
Maschinencode:5-500).


Aber wenn wir schon bei der Kritik sind: FORTH Programme sind weitgehend  
write-only. Wenn ein Entwickler nicht eine saubere Trennlinie zwischen  



wurde, dann ist ein Crash vorprogrammiert :-(

Oft liegt es aber einfach in der Natur der Controller. Was verdammt  
nochmal bedeutet es, wenn das Programm dieses oder jenes Bitmuster in  



eines anderen Controllers anders funktioniert.

DoDi

Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 16.08.19 22:26, Hans-Peter Diettrich wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it


Naja, ich kann halt kein Forth. Und das Wikipedia-Beispielprogramm ist
das einzige das ich hatte und es ist auch echt Embedded-tauglich. RC4
ist so klein, dass man ihn einfach runterimplementieren kann.


machen, Testprogramme zu liefern, die weniger Overhead haben (damit man


ich halt wenigstens harte Zahlen, wo vorher nur rumgewiesel war. Jeder
ist herzlich eingeladen neue Zahlen zu liefern, aber diese qualitativen
Aussagen gehen mir auf den Keks.






digitale Signalverarbeitung gemacht, Multiply/Accumulate,
Fixpointarithmetik. Da ist RC4 eigentlich gar nicht weit davon entfernt.
Und Krypto mach heutzutage jeder IoT-Controller (das sind allerdings





Quoted text here. Click to load it



Hm aber Wolfgang behauptete doch immer, dass das angelich den Compiler
schon drin hat, d.h. das wird nicht zur Laufzeit einmal compiliert,
sondern immer interpretiert? Das hatte ich anders verstanden.



Quoted text here. Click to load it


sagen wir im letzten Jahr wirklich Kopfzerbrechen gemacht haben, das
waren allesamt welche bei denen kein Debugger, kein
Interpreter-Commandline oder irgendwas mehr hilft, weil das in der

rausgekriegt hab, was das Problem war. Ich glaube Frank Buss hat mir
damals geholfen und mich auf den richtigen Trichter gebracht.



Quoted text here. Click to load it

Naja, kommt drauf an. Bei einem HMI will ich halt nicht 100ms Warten,




Stimmt.

Quoted text here. Click to load it

Neeeh, im Leben nicht. Schrittgenaue Schrittmotorsteuerung, die dann
auch noch durch ordertliches (x16) Microstepping schwieriger gemacht
wird und bei der die Speed-Ramps ordentlich (Sinus) aussehen ist auf

schnellen (16 MHz AVR) eventuell gerade so, wenn du nicht viel anderes
machen musst.

Quoted text here. Click to load it



Quoted text here. Click to load it

Huh, hartcodierte Memory-Layouts? Lolwut? Wolfgang lobte ja, dass es
keinen Linker gibt bei Forth, aber wenn der Programmierer dann von Hand
linken muss, ne, das muss echt nicht sein.

Quoted text here. Click to load it



Quoted text here. Click to load it




Johannes

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

On 16 Aug 19 at group /de/sci/electronics in article qj74pm$8ki$ snipped-for-privacy@news2.open-news-network.org

Quoted text here. Click to load it

Quoted text here. Click to load it





[...]




[...]

Quoted text here. Click to load it





siehst, ist das Programm kompiliert.

Ist nicht wie bei Basic!


Quoted text here. Click to load it



Quoted text here. Click to load it





Ja auch in FORTH kann man schlechte Programme schreiben, geht sogar viel  
schneller.




Quoted text here. Click to load it


Schuld. Und wer keine klare Trennung zwischen HW und Anwendung hinkriegt,  

Motherboard ausgewechselt, ohne dass die 2 anderen Programmierer irgendwas  

oder gar Probleme hatten. Ausser dass das ganze dann viel schneller lief.

Ich hab den Kern und die IR angepasst und gut wars.




Quoted text here. Click to load it

Forth hat keinen Linker und braucht auch keinen. Ein Riesen Vorteil.


Quoted text here. Click to load it



Quoted text here. Click to load it






Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 17.08.19 05:34, Wolfgang Allinger wrote:





vielleicht 5 Minuten, ein "hello world" in C braucht 10. Go waren auch

ist.

Auch wenn du die RPN gut findest, mir stellen sich die Nackenhaare auf



Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it

Okay, dann hat sogar "kompiliertes" Forth eine Performance-Penalty


Quoted text here. Click to load it

Ja sehr einsteigerfreundlich, wenn man erstmal den Compiler/Interpreter
auf das Target portieren muss.

Quoted text here. Click to load it

Ohne Linker ist offenbar 500 Mal besser als mit.


Johannes

Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 17.08.2019 um 08:27 schrieb Johannes Bauer:

Quoted text here. Click to load it


immer gleiche FORTH Code. Ich habe heute noch den Karteikasten mit den  
Implementierungen der Worte zu meinem Lieblingsforth.


Quoted text here. Click to load it




ist schon passiert.

DoDi

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

On 17 Aug 19 at group /de/sci/electronics in article qj86oe$4o0$ snipped-for-privacy@news2.open-news-network.org

Quoted text here. Click to load it





Quoted text here. Click to load it

Quoted text here. Click to load it

Hello World dauert in FORTH nur solange, wie man tippen muss :p

OK> : Hello ." Hello World, hello Johannes" ; Hello <CR>


Quoted text here. Click to load it








Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it



Quoted text here. Click to load it


Quatsch mit Sosse, auf neuen Kern anpassen (1-3d Manntage) muss man nur,
wenn man FORTH auf einen neuen Processor bringen will und man im Netz



FORTH Programme laufen lassen, die mit Standard I/O auskommen. Mach das  
mal in einer anderen Sprache oder versuch mal andere Interpreter auf eine  

es kein FORTH gibt, die eine waren die Ur-PICs, und dann war da noch  

mit der Art des Speicherzugriffs (Harvard Ecke?).

Quoted text here. Click to load it




Als grobe Faustformeln:

1. Eine FORTH Anwendung oberhalb des Kernels braucht nur 1/10 des Platzes  

passte in 2kB.




2. FORTH Geschwindigkeit liegt auf der Scala ASM = 1 und Basic = 100, etwa  
bei 10. Mit Gewalt auch weit niedriger, bis an <2, aber dann ist alles in  


durchaus in HLL benutzen, wenn Du eine schnelle CPU oder nicht  
hyperventilierende IRs hast.

Einer meiner Kunden hat seine Z80 und 8051 Systeme in der 100DM Klasse  
durch 1000DM+ RTX2000 boards ersetzt. Ich hatte Kammerflimmern, als ich  
das mitbekam... Ruhig Blut, Herr Allinger, mit FORTH auf einem RTX2000  

und unoptimiert schreiben, dass er die Aufgabe nicht in 1-3 Tagen fertig  

Maschinen, kein PillePalle.

Und wegen Positionierung, Rechenzeit, Komplexheit und Deiner hochgeliebten  
Schrittmotorsteuerungen: zu meiner Zeit hat KUKA die Roboter mit FORTH  
gesteuert. Der Greifarm des Space-Shuttle war auch in FORTH programmiert.

Shooting Ranges USMC werden auch mit FORTH betrieben. 99% aller FORTH  
anwendenden Firmen benutzen es als Betriebsgeheimnis, manchmal auch nicht  

Analysatoren.






Anpassung. Mission acomplished.


kotzen: Forth-ev.de




Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 17.08.19 12:17, Wolfgang Allinger wrote:


Quoted text here. Click to load it

Quoted text here. Click to load it


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

Quoted text here. Click to load it

Quoted text here. Click to load it


Quoted text here. Click to load it





Quoted text here. Click to load it




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



Quoted text here. Click to load it


Standard-Sprachumfang verwendest. Ziemlich unglaublich, dass du das

kann.


Quoted text here. Click to load it

Quoted text here. Click to load it









Quoted text here. Click to load it

Nein.

Deine groben zusammengelogenen Faustformeln interessiert kein Mensch.


Quoted text here. Click to load it

Quoted text here. Click to load it


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

Quoted text here. Click to load it


Quoted text here. Click to load it

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

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

On 17 Aug 19 at group /de/sci/electronics in article qj9hf6$9a8$ snipped-for-privacy@news2.open-news-network.org


Quoted text here. Click to load it


Quoted text here. Click to load it





Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 17.08.2019 um 05:34 schrieb Wolfgang Allinger:


Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it




viel bringt, wenn dort ein VARIANT Datentyp verwendet wird - siehe  
VisualBasic.

Quoted text here. Click to load it

FORTH erlaubt Compilierung bei der Eingabe, was aber nicht Compilierung  
in Maschinencode bedeutet, und auch nicht unbedingt in anderweitig  

IMMEDIATE Mode (bei der Eingabe) normal abgespeichert wird, aber direkt  
weiteren FORTH Code erzeugt, wenn es in der abgespeicherten Version  






Parser wird ja von FORTH geliefert.





Quoted text here. Click to load it


Schau Dir mal die Stack-Beschreibung an, die zu jedem Wort angegeben  



so ein Mechanismus nicht bekannt.

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Ich habe mir seinerzeit etliche Bibliotheken angeschaut, die ohne  

es so eine Dokumentation, aber wenn die nicht auf den Disketten  
mitgeliefert wurde, war man in der Zeit vor dem Internet mit dem  
Quelltext alleine einfach nur aufgeschmissen :-(

DoDi

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

On 17 Aug 19 at group /de/sci/electronics in article snipped-for-privacy@mid.individual.net

Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it



Nein, BASIC interpretiert immer wieder, erst ein BASCOM setzt das als (p-  





Bei FORTH die sog. META Compiler.

Quoted text here. Click to load it



Das eine sind die COLON (HLL) Definitionen, das andere die CODE (ASM)  
Teile.

Quoted text here. Click to load it

Quoted text here. Click to load it






Quoted text here. Click to load it

So isset, ein Beispiel, u.a. mit IMMEDIATE unten dran gepappt.

Und wem das nicht reicht, es gibt auch noch CREATE DOES> , was  
Unterschiede zur Compile und zur Laufzeit macht. Hab ich u.a. gerne  


sind elegant mit CREATE DOES> .




Quoted text here. Click to load it


Quoted text here. Click to load it



Quoted text here. Click to load it


Kann mir auch keinen Reim drauf machen.

Wenn irgendwer halt ne andere Reihenfolge oder Menge braucht, soll er hat  
ein neues Wort definieren, dann crasht nix.

Doof ist allerdings, wer die Warnung "... is redifined" in den Wind  



sofort sichtbar.


Quoted text here. Click to load it

Quoted text here. Click to load it

Ich hab nie behauptet, dass alle FORTH Programme oder Programmierer gut  





Das Dicke Ende, also das interessanteste ist der Abschluss
mit "Feueralarm_bearbeiten", siehe ziemlich letzter Abschnitt.


----x8---

\ FEUER     Demo FEUERMELDER Anwendung         ALL 11:26 14MAY93
\ Last changed screen # 000                    ALL 11:26 14MAY93

\ (C) 1993 by Dipl.-Ing. Wolfgang Allinger 'ALL0593'
\           c/o Ingenieurbuero Allinger
\               Brander Weg 6         Tel/FAX: (+49)+212/66811
\               D-42699 Solingen   Germany
\ noncommercial use granted !!!


\ selbstdokumentierende Sprache am Beispiel eines FEUERMELDER
\ aussieht. Hinweis: alles in "( )" und nach "\" ist Kommentar.
\ ":" ... ";" sind neue Definitionen.
\ "Feueralarm?" und "Feueralarm_bearbeiten" sind 2!! Programme.
\ Diese Demo belegt weniger als 700 byte Programmspeicher und

\ HISTORY    MASTER LOAD SCREEN                ALL 11:19 14MAY93

DECIMAL \ default base

 000 CONSTANT $VFEUER       \ Version Kontrolle

: -FEUER  FORGET $VFEUER ;  \ entfernt dieses Programm wieder

   2 ?SCREENS THRU  \ 1 LOAD l"dt dann die Anwendungsbl"cke
                    \ bei SEQ file system auskommentieren !

\ ALL0593   v0.00 first release




\ .VFEUER ... constants ... USER Interface     ALL 10:16 14MAY93

: .VFEUER   $VFEUER CR . ;   \ zeige Versionsnr.

-1 CONSTANT ja



VARIABLE Meldung    \ bits gesetzt wenns qualmt, n. Zeile setzt
 5 Meldung !                \ zB: bit0 = Melder1, bit2 = Melder3
: Melder@  ( a -- u ) @ ;   \ liefert Datum aus Adresse
Meldung CONSTANT Melder0    \ liefert Adresse der 1. Meldung

16 CONSTANT bits/Meldung    \ zB 16bit oder was auch immer
16 CONSTANT alle            \ Anzahl Melder



VARIABLE Rauchmelder    \ 1 ... n



: abfragen  ( a -- uMASKE uDATA )

    @ 1- bits/Meldung /MOD  ( -- rem qot )
    Melder0 + Melder@       ( -- rem uDATA )
    1 ROT                   ( -- uDATA 1 rem )
    SHIFT                   ( -- uDATA uMASKE ) \ rem -> MASKE
    SWAP  ;                 ( -- uMASKE uDATA )

: entdeckt? ( uMASKE uDATA -- t=RAUCH)   AND 0> ;



: Feueralarm    ( -- ^string nMelder )

    " Rauch an Melder Nr.: "    ( -- ^string )
    Rauchmelder @ ;

: melden    ( ^string n -- )    CR SWAP COUNT TYPE .   7 EMIT ;



: abgefragt?    ( n a -- ? )    @ 1- <= ;




\ Feueralarm?                                  ALL 11:02 14MAY93


    BEGIN
        Rauchmelder abfragen
        Rauch entdeckt? IF   Feueralarm melden   THEN

        alle Rauchmelder abgefragt?
    ja = UNTIL ;


\ Programm aussieht und nicht gleich von jedem verstanden wird!

\ Das ist gemein, aber es kommt noch besser!
\ Der GROSSEN Worte ist genug gewechselt, es folgen Taten!



\ Ein paar harmlose(?) Definitionen.. Vorsichtig anschleichen..

    : Falls ;                   : melden.   melden ;
    : dann      ja = ;
    : beginne   [COMPILE] BEGIN ; IMMEDIATE

    : ja,       [COMPILE] IF    ; IMMEDIATE
    : Den       [COMPILE] THEN  ; IMMEDIATE






\ Feueralarm_bearbeiten ist nun total einfach  ALL 11:16 14MAY93


    beginne
        Rauchmelder abfragen.
        Rauch entdeckt? Falls ja, Feueralarm melden.

        alle Rauchmelder abgefragt?


\ Das soll ein Programm sein? Das versteht kein Programmierer!
\ Lieber (*(void(*)())0)()  das ist doch wenigstens KERNIGhan.


Feueralarm_bearbeiten   \ und so einfach noch sofort zu starten!


---x8---


Zum Abschluss:


zusammengestellt, leider hat der sich das dann wohl nicht angeguckt.


kurze email und ich schicke den Kram.



Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 17.08.2019 um 13:53 schrieb Wolfgang Allinger:
Quoted text here. Click to load it

Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it



diskutieren :-(

DoDi

Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 16.08.2019 um 22:47 schrieb Johannes Bauer:
Quoted text here. Click to load it




Quoted text here. Click to load it

Quoted text here. Click to load it

Da war die Arithmetik aber sicher nicht mit den FORTH Primitives  







Quoted text here. Click to load it


HMI?

Schlechtes Beispiel, wenn das Entprellen eines Knopfes schon 10-20ms  
kostet, egal wie schnell der Prozessor oder die Programmiersprache ist.  
Und auf Interrupts kann man auch in FORTH direkt reagieren, wieso nicht?


Quoted text here. Click to load it

Quoted text here. Click to load it







man das so machen? Motortreiber braucht man sowieso, und die gibt es  
passend mit Microstepping, Strombegrenzung etc.


DoDi

Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 17.08.19 09:44, Hans-Peter Diettrich wrote:

Quoted text here. Click to load it

Quoted text here. Click to load it

Ist eben genau ein gutes Beispiel: Das Entprellen dauert schon die

auch schon eher 50-75ms ansetzen. Und dann willst du dem Benutzer
*sofort* signalisieren, was passiert ist.

Wenn du da ein LCD oder sowas dran hast, das bissl mehr braucht als nur
GPIO LED an/aus, dann merkst du das sehrwohl. Und es gibt genug



Quoted text here. Click to load it

Quoted text here. Click to load it



langsam, 16 MHz als schnell und 48 MHz als superschnell bezeichnen.


Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Motortreiber mit Microstepping machen aber halt nur das, was der Name


dieselbe Geschwindigkeit.






angeflanscht direkt an den Stepper und der nimmt z.B. via RS232
Kommandos entgegen, die ihn wie einen Servo aussehen lassen).


Johannes

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

Quoted text here. Click to load it




entgegennimmt, im Fehlerfall ein Standard-THROW exekutiert, als ABORT, womit
alle Schachtelungen aufgehoben werden und der Text-Interpreter wieder neu
beginnt.

INCLUDED nimmt Text aus einer zeilenorientierten Datei entgegen. THRU macht




mit einer Zeile, die als String-Parameter gegeben wird.



Eine Schicht darunter wird man eher von Code reden, da nicht mehr Textfolgen
abgearbeitet werden, sondern kompilierte Folgen im Speicher. Dass dennoch
das Wort Interpreter ins Spiel kommt, liegt daran, dass die Modelle, wie

zu der Zeit etwa bis MItte der 1990er, dem kundigen Nutzer das mitzuteilen,
wie die Schacthelung von Code im Speicher organisiert ist.

Nunmehr ist der kundige Nutzer auch nurmehr ein braver Konsument und fragt
nicht mehr nach so etwas, bzw. ist eher irritiert.


die das korrespondiert, dass der Code aus einer Abfolge von Tokens besteht.
Und die Tokens, wenn sie zur Abarbeitung angesprungen werden, sind dann
wiederum Abfolgen von Tokens.

Erst die unterste Schicht von Tokens sind dann in Assembler kodiert.

Noch in den Forth-79 und -83 wurde das fein kultiviert, mitzuteilen, auf
welche Art die Tokens angesprungen wurden. Im kompaktesten Fall besteht
selbst noch der Beginn eines Tokens aus einem Verweis auf ein Token, dem die
Kette der folgenden Tokens mitgeteilt wird, und startet den Mechanismus des
Schachtelns und Weiterschaltens (typischerweise ein kleines Code-Schnipsel,
mit dem Namen NEXT).

Das ist die kompakteste und dann auch zugleich langsamste Form, wie der Code

Hardware-Architektur vor sich hat, wo der letztliche Assmember strikt


implementieren. Die kann dann, mit ein wenig Forth-Assembler-Code im ROM,
rein vom RAM laufen.



minimale Forth-Assembler im ROM als Maschinen-Monitor dient, mittels dem per
ad hoc dazukompilierten Routinen die Maschine auf ihr Befinden hin abfragt

Stadium weg am Objekt selbst modellieren kann, ohne dass man eine Emulation


Wenn der Zeittakt der Umgebung aber eher in Sekunden misst, ohne Milli oder
Mikro, dann braucht es keinen weiteren Luxus zur Beschleunigung.



die kleinen Prozessoren dann im emulierten ROM per Assembler-kompiliertem
Forth.

Letzteres ist dan schon die dritte Variante des Interpretierens von
Assembler-Code auf Maschinenebene, indem eben der Compiler alles, was im



schlau mit dem Code zuvor und danach verkettet. Es muss ja weiterhin die

Verschachtelung erreicht werden.



Tokens nicht selbst wiederum einen Zeiger auf das Token verweist, mit dem
Verschachtelung und Weiterschalten im Code organisiert ist, sondern diese
kleine Standard-Routine steht dann in Assembler zu Beginn von jedem Token.





wird. Oder auch nicht. Aus letzterem wird zwar auch eine lustige Maschine,
aber viel machen kann man damit nicht wirklich, oder nur bei ausnehmend


***

Quoted text here. Click to load it



wird angenommen dass jemand der mit dieser Maschine arbeitet, genug


Routinen auf, und deren Schnittstellen sollten dann doch wohl auch weiterhin
stabil bleiben. Wer dann nachher an den Schnittstellen herumdreht, bzw. das
dann nicht im Griff hat, wenn er es trotzden macht, dem ist dann wohl nicht
zu helfen. Es gibt da keinen reichen Onkel, als wie ein solcher sich die


locker dahin.



kompiliertem Code nicht entwickelt. Das ist keine Frage des Systems sondern
der Historie. Man kann das auch in Fortg einbauen, dass es kompilierten Code


Das Modell des Open-Boot-Systems hat dann die Tokens normiert ... was ebenso

mit dem Handling von APDUs im Mittelpunkt, wie mit der ISO 7816 begonnen,



Wenn dann Folgen von Tokens ausgetauscht werden, ist man bereits auf



Und das ist dann schon die Schicht, wie Libraries gestrickt sind.


abklopfen, was denn gemeint ist, wenn Libraries ausgetauscht werden. Die
Architekturen sind weniger technisch als auch historisch bedingt.

Wenn es darum ginge, sich des Mainstreams zu bedienen, wo massenweise die

in Forth eine harte Klippe, das ist die Konstruktion des Aufbaus mit



Auch das ist wohl nur historisch bedingt - wahrscheinlich auf die

das Personal zu seiner Zeit etwas stringenter in analytischen Dimensionen

bedingten Erfordernisse viel naheliegender.

Der Vorteil, den Forth in dieser Hinsicht hat, ist immens, als da
Verschachtelungen viel bililiger zu haben sind, wenn nicht bei jedem Sprung
im Code zugleich der Zusanmenhang der Daten zwuschengesichert werden muss.
Das erspart man sich, wenn die Parameter transparent auf einem gemeinsamen
Stack durchgereicht werden. Von daher wurde typischerweise in Forth stets
mit kleinen Routinen kodiert, mit den anonymen Parametern auf dem Stack.




parallel dazu, dass Unix-Maschinen sich verbreiteten. C verbreitete sich
erst einmal ganz spezifisch mit letzteren - aber auch ist hier die Tradition
aufrecht geblieben, dass, auch in C, Quelltexte korrespondiert werden, es


Das Interesse, dass nur kompilierte Libraries im Umlauf sind, ist eher

uneinsehbaren kryptischen Datenhaufen in Plastik zu verpacken und teuer





Normierung auskungelte, von allzu konkreten Implementierungsdetails Abschied
zu nehmen und abstraktere Prinzipien stattdessen aufzunehmen, sodass unter


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

On 17 Aug 19 at group /de/sci/electronics in article snipped-for-privacy@mid.individual.net


Quoted text here. Click to load it

[...]






Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 08/16/2019 22:47, Johannes Bauer wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it


Quoted text here. Click to load it

Harte Fakten werden nicht gemocht, weil sie alle 'Optionen' ersticken.

Ich habe auch mal einen Test gemacht, auf ein und derselben Plattform,
mit gleichen Mitteln und Aufgaben auf Software-Ebene.

Ergebnisse des jeweiligen Zeitbedarfs (1996):
C           1
Pascal      5
COBOL      80

C ist nicht zu toppen!
Das bewahrheitet sich immer wieder.


--  

Helmut Schellong   snipped-for-privacy@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline