Liebe Leute,

Forth bietet Wortlisten (Vokabulare). Mir fällt aber nur
ein einziger Anwendungsfall ein: eine reduzierte Wortliste
für den Anwender ohne super-cow-powers.

Wo/wie setzt ihr Wortlisten ein?
Was erreicht ihr damit?
Wie entscheidet ihr, wann Wortlisten gut sind,
und wie entscheidet ihr, was in welche Liste kommt?


Bin gespannt auf Eure Antworten,

Erich

> Forth bietet Wortlisten (Vokabulare). Mir fällt aber nur
> ein einziger Anwendungsfall ein
Nicht jedes kleine FORTH muß das haben. Genau wie
state-smart Verhalten von Compilern ist es für den
Benutzer wenig transparent und oft frustierend.

> Wie entscheidet ihr, wann Wortlisten gut sind,
Es gab mal eine Implementierung des PALASM für PALs
d.h. ein simpler Compiler für Logikgleichungen.
Da wurde es wegen der Verwendung von
Namen wie + für XOR statt Addition verwendet.
Die Syntax die für XOR "+" als Symbol hat war von MMI
mehr oder weniger vorgegeben.
Innerhalb dieser Anwendung wurde Addition nicht
benötigt.

In nanoFORTH GP32 wird für den 68HC08 Assembler
die Assembler-Wortliste bei Bedarf zugeschaltet.
Da ist der Grund bessere Compiliergeschwindigkeit.
Gabs irgenwann mal Artikel in der VD dazu.

MfG JRD

Erich Wälde wrote:

> Liebe Leute,
>
> Forth bietet Wortlisten (Vokabulare). Mir fällt aber nur
> ein einziger Anwendungsfall ein: eine reduzierte Wortliste
> für den Anwender ohne super-cow-powers.

In größeren Forth-Systemen sind sie definitiv sinnvoller als in kleinen.

> Wo/wie setzt ihr Wortlisten ein?

Na, der Assembler z.B. ist bei mir immer in einem eigenen Vokabular.
bigFORTH hat auch ein Modul-Feature, das Modul ist ein Vokabular, und
exportiert nur die Wörter, die der Benutzer des Moduls auch sehen muss. Und
bei OOP verwende ich Vokabulare, um die Methoden der einzelnen Klassen
voneinander zu trennen. Ebenso die C-Strukturen, da in C jede Struktur einen
eigenen Namensraum hat, und dann oft die gleichen Variablennamen
wiederverwendet werden (x und y z.B. kommen bei Xlib.h mehrmals an
verschiedenen Positionen vor).

Mein HTTP-Server verwendet ein eigenes Vokabular für die HTTP-Variablen. Und
der Cross-Compiler verwendet gleich mehrere Vokabulare.

> Was erreicht ihr damit?

Namensräume trennen.

> Wie entscheidet ihr, wann Wortlisten gut sind,
> und wie entscheidet ihr, was in welche Liste kommt?

Wordlisten sind gut, wenn dasselbe Wort in unterschiedlichen Kontexten
unterschiedliche Bedeutungen hat - z.B. AND in Forth führt das AND direkt
aus, AND im Assembler erzeugt einen entsprechenden AND-Befehl im Code.
Ebenso beim Cross-Compiler: Da gibt es ein AND vom Host, das direkt
ausgeführt wird, ein AND im Target, das allenfalls compiliert werden kann
und so weiter.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Bernd Paysan <bernd.paysan*gmx.de> writes:
>Wordlisten sind gut, wenn dasselbe Wort in unterschiedlichen Kontexten
>unterschiedliche Bedeutungen hat - z.B. AND in Forth führt das AND direkt
>aus, AND im Assembler erzeugt einen entsprechenden AND-Befehl im Code.

Das ist aber ein gutes Beispiel, warum die Loesung mit wordlists nicht
so toll ist: Oft will man im Assembler-Code auch ein Forth-AND
ausfuehren, z.B. um eine Bitmaske zu berechnen, dann muss man
muehselig zwischen den wordlists hin- und her-schalten, und das ganze
wird schwierig zu lesen. Was ich stattdessen lieber mache, ist, den
Assembler-Befehl "AND," zu nennen. Das loest nicht nur das
Namenskollisionsproblem, sondern hilft auch beim Lesen von mehreren
Assembler-Befehlen in einer Zeile, zumindest wenn man einen
Postfix-Assembler verwendet. Die Assembler-Befehle sind trotzdem in
einer eigenen Wordlist.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton*mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

On 30 Okt., 10:04, Bernd Paysan <bernd.pay...*gmx.de> wrote:
...
> Wordlisten sind gut, wenn dasselbe Wort in unterschiedlichen Kontexten
> unterschiedliche Bedeutungen hat - z.B. AND in Forth führt das AND direkt
> aus, AND im Assembler erzeugt einen entsprechenden AND-Befehl im Code.
> Ebenso beim Cross-Compiler: Da gibt es ein AND vom Host, das direkt
> ausgeführt wird, ein AND im Target, das allenfalls compiliert werden kann
> und so weiter.

Hm. Könnte ich damit so etwas machen?:

vocabulary amforth-asm ...
: cr cr ." .dw XT_CR " ;
...
: drop cr ." .dw XT_DROP " ;
: over cr ." .dw XT_OVER " ;
: swap cr ." .dw XT_SWAP " ;

Also Worte die zB amforth-assembler Instruktionen ergeben sollen in
ein eigenes Vocabular hinein compilieren. Aber so das bei dieser
Compilation die neuen Definitionen NICHT gefunden werden. Im Beispiel
soll ja das CR im neuen DROP als Forthwort ausgeführt werden, und eben
nicht den String " .dw XT_CR " ausgeben. Erst wenn das Vocabular
amforth-asm an gemacht wird, sollen die neuen Worte wirksam werden.

Bisher mache ich das mit einer Hilfskonstruktion.
: _cr cr ;
...
_: drop _cr _." .dw XT_DROP " _;
...

Michael

Michael Kalus wrote:
> Hm. Könnte ich damit so etwas machen?:
>
> vocabulary amforth-asm ...
> : cr cr ." .dw XT_CR " ;
> ..
> : drop cr ." .dw XT_DROP " ;
> : over cr ." .dw XT_OVER " ;
> : swap cr ." .dw XT_SWAP " ;
>
> Also Worte die zB amforth-assembler Instruktionen ergeben sollen in
> ein eigenes Vocabular hinein compilieren. Aber so das bei dieser
> Compilation die neuen Definitionen NICHT gefunden werden. Im Beispiel
> soll ja das CR im neuen DROP als Forthwort ausgeführt werden, und eben
> nicht den String " .dw XT_CR " ausgeben. Erst wenn das Vocabular
> amforth-asm an gemacht wird, sollen die neuen Worte wirksam werden.

Ja klar, kann man. Da sagt man

vocabulary amforth-asm
amforth-asm definitions forth
: cr cr ." .dw XT_CR " ;
: drop cr ." .dw XT_DROP " ;

Ausprobiert:

amforth-asm drop
.dw XT_DROP ok

Jupp, alles richtig.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On 30 Okt., 18:24, Bernd Paysan <bernd.pay...*gmx.de> wrote:

Klasse, danke. Michael

On 29 Okt., 20:14, Erich Wälde <ew.ng116...*online.de> wrote:
> Liebe Leute,
>
> Forth bietet Wortlisten (Vokabulare). Mir fällt aber nur
> ein einziger Anwendungsfall ein: eine reduzierte Wortliste
> für den Anwender ohne super-cow-powers.
>
> Wo/wie setzt ihr Wortlisten ein?
> Was erreicht ihr damit?
> Wie entscheidet ihr, wann Wortlisten gut sind,
> und wie entscheidet ihr, was in welche Liste kommt?
>
> Bin gespannt auf Eure Antworten,
>
> Erich

Wie wärs mit einer "Forth Talk" API? Ginge das in etwa so:

decimal
: .. bye ;
: ... ; \ dummy

: talk ... ; \ enable output, turn on numbers, etc.
: silent ... ; \ disabel output, turn off numbers, etc.

\ Rechner-A
vocabulary ich
ich definitions
: A-AN ich also forth talk ;
: A-AUS only ich silent ;

.... und ein weiterer Rechner hat:

\ Rechner-B
vocabulary ich
ich definitions
: B-AN ich also forth talk ;
: B-AUS only ich silent ;


dann Rechner-C, Rechner-D...

Es gibt eine Terminal Verbindung aller untereinander. Ein Master
schickt zB A-AN an alle. Nur der Rechner-A kann das verarbeiten und
schaltet sein Forth (oder die Applikationsvokablen) ein, die anderen
schweigen weiter und lauschen. Master und Rechner-A können nun
miteinander in Forth kommunizieren - Daten abrufen, neue Worte
compilieren... bis nach B-AUS ein neuer Rechner aufgerufen werden
kann.

(Wüsste ich wie man gforth "stumm" macht könnte ich das Beispiel
komplettieren. So nimmt es weiterhin Zahlen an, gibt Fehlermeldungen
aus und das cr und ok auch. Aber das Konzept wird deutlich? Immerhin
kann man schon mal was vom Terminal aus simulieren: Nach a-aus geht
nicht mehr viel, nach a-an wieder alles.)

Auf einem micro geht das so: Wenn silent geschaltet ist wird halt der
inputbuffer verworfen falls dort kein gültiges Wort war, und weiter
gelauscht. INTERPRET ist da glaube ich die passende Stelle die
angepasst werden muss.

Gern wüsste ich ja auch wie man mehrere gforths auf einem Rechner
laufen lassen und sich unterhalten lassen kann.

Michael

Hallo,

Michael Kalus wrote:
> On 29 Okt., 20:14, Erich Wälde <ew.ng116...*online.de> wrote:
>> Liebe Leute,
>>
>> Forth bietet Wortlisten (Vokabulare). Mir fällt aber nur
>> ein einziger Anwendungsfall ein: eine reduzierte Wortliste
>> für den Anwender ohne super-cow-powers.
>>
>> Wo/wie setzt ihr Wortlisten ein?
>> Was erreicht ihr damit?
>> Wie entscheidet ihr, wann Wortlisten gut sind,
>> und wie entscheidet ihr, was in welche Liste kommt?
>>
>> Bin gespannt auf Eure Antworten,
>>
>> Erich
>
> Wie wärs mit einer "Forth Talk" API? Ginge das in etwa so:
>
> decimal
> : .. bye ;
> : ... ; \ dummy
>
> : talk ... ; \ enable output, turn on numbers, etc.
> : silent ... ; \ disabel output, turn off numbers, etc.
>
> \ Rechner-A
> vocabulary ich
> ich definitions
> : A-AN ich also forth talk ;
> : A-AUS only ich silent ;
>
> ... und ein weiterer Rechner hat:
>
> \ Rechner-B
> vocabulary ich
> ich definitions
> : B-AN ich also forth talk ;
> : B-AUS only ich silent ;
>
>
> dann Rechner-C, Rechner-D...
>
> Es gibt eine Terminal Verbindung aller untereinander. Ein Master
> schickt zB A-AN an alle. Nur der Rechner-A kann das verarbeiten und
> schaltet sein Forth (oder die Applikationsvokablen) ein, die anderen
> schweigen weiter und lauschen. Master und Rechner-A können nun
> miteinander in Forth kommunizieren - Daten abrufen, neue Worte
> compilieren... bis nach B-AUS ein neuer Rechner aufgerufen werden
> kann.
>
> (Wüsste ich wie man gforth "stumm" macht könnte ich das Beispiel
> komplettieren. So nimmt es weiterhin Zahlen an, gibt Fehlermeldungen
> aus und das cr und ok auch. Aber das Konzept wird deutlich? Immerhin
> kann man schon mal was vom Terminal aus simulieren: Nach a-aus geht
> nicht mehr viel, nach a-an wieder alles.)
>
> Auf einem micro geht das so: Wenn silent geschaltet ist wird halt der
> inputbuffer verworfen falls dort kein gültiges Wort war, und weiter
> gelauscht. INTERPRET ist da glaube ich die passende Stelle die
> angepasst werden muss.
>
> Gern wüsste ich ja auch wie man mehrere gforths auf einem Rechner
> laufen lassen und sich unterhalten lassen kann.

Die Idee ist interessant.

Ich beacker grad ein ähnliches Problem: mehrere AVR controller lauschen am
Bus, ich will aber nur mit einem reden. Bei AVR gibt's ein Bit namens
MPCM --- multi processor communication mode. Wenn man den eingeschaltet
hat, dann verwirft die usart hw alle empfangenen Bytes, bei denen das
höchste bit nicht gesetzt ist. Wenn ein Byte empfangen wird, bei dem das
höchste Bit gesetzt ist, dann wird geprüft, ob die restlichen 7 Bit der
Busadresse des contollers entspricht. Wenn ja, dann schaltet dieser
controller in den normalen mode um, und die anderen ignorieren den
Datenverkehr.

Das hab ich gelernt, indem ich mir die Quellen von Lubos Pekny's
mFC Projekt angeschaut habe.
http://www.forth.cz

Das ist eine ganz andere Lösung, aber vielleicht auch von Interesse.

Ciao,
Erich

Anton Ertl schrieb:
> Bernd Paysan <bernd.paysan*gmx.de> writes:
>> Wordlisten sind gut, wenn dasselbe Wort in unterschiedlichen Kontexten
>> unterschiedliche Bedeutungen hat - z.B. AND in Forth führt das AND direkt
>> aus, AND im Assembler erzeugt einen entsprechenden AND-Befehl im Code.
>
> Das ist aber ein gutes Beispiel, warum die Loesung mit wordlists nicht
> so toll ist: Oft will man im Assembler-Code auch ein Forth-AND
> ausfuehren, z.B. um eine Bitmaske zu berechnen, dann muss man
> muehselig zwischen den wordlists hin- und her-schalten, und das ganze
> wird schwierig zu lesen. Was ich stattdessen lieber mache, ist, den
> Assembler-Befehl "AND," zu nennen. Das loest nicht nur das
> Namenskollisionsproblem, sondern hilft auch beim Lesen von mehreren
> Assembler-Befehlen in einer Zeile, zumindest wenn man einen
> Postfix-Assembler verwendet. Die Assembler-Befehle sind trotzdem in
> einer eigenen Wordlist.
>
> - anton

Eine simple, aber wirksame Anwendung von wordlists:

In ONF Open Network Forth kommunizieren über 100 Knoten in Forth
miteinander.
Dort verwende ich eine wordlist NET. In diese Liste werden alle Worte
eingetragen, die über das Netz aufgerufen werden. Die Suchreihenfolge
ist so manipuliert, dass grundsätzlich immer zuerst NET durchsucht wird.

Man erreicht so, dass diese Worte schnell gefunden und ausgeführt werden
und das ohne große Programmierarbeit.

- Heinz