Re: 8 reichen auch

11 views
Skip to first unread message

Torsten Kildal

unread,
Jun 21, 2005, 5:37:37 AM6/21/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Torsten Kildal (kil...@gmx.de) schreibt:
>
>> [...] Und überhaupt, 16 Zeilen pro Screen reichen doch vollauf :-)
>
>8 reichen auch. :))
>
><http://www.retroforth.org>
>
>Eines der schärfsten Minimal-Forth(s), das ich kenne, 32 Bit,
>Linux/Windows/standalone.

Was, gar kein DOS? :-) Sind IMHO aber ziemlich viele Core-Words für
"minimal". Was ist denn daran so "scharf"?

>fup2 de.comp.lang.forth

geht klar...

Gruss Torsten.

--
OJ: Bück dich Fee, Wunsch ist Wunsch.

Joachim Merkel

unread,
Jun 21, 2005, 6:56:00 AM6/21/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

>> Eines der schärfsten Minimal-Forth(s), das ich kenne, 32 Bit,
>> Linux/Windows/standalone.

> Was, gar kein DOS? :-) Sind IMHO aber ziemlich viele Core-Words für
> "minimal". Was ist denn daran so "scharf"?

DOS und 16-Bit standalone wurde Oktober letzten Jahres mal für
demnächst angekündigt, hätte ich auch gern.
Ist schon irgendwie komplett , also nicht das Forth mit den
allerwenigsten Befehlen. Bei RF ist alles sehr sorgfältig gemacht,
der Ausstieg aus Worten gefällt mir auch. Oder hast Du das binary
mal in einem Lister betrachtet? Die gesamten Hochsprache-Routinen
sind alle übersichtlich im Programm zu lesen, weils subroutine-
threaded ist.
Schlicht, elegant, weckt den Spieltrieb, einfach und motivierend.
Erspart einem sicher nicht das nötige Verständnis aufzubringen,
aber ist derzeit noch mehr ein Textadventure für mich ;)

--
Salut
_)oachim

Torsten Kildal

unread,
Jun 23, 2005, 12:16:39 AM6/23/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Torsten Kildal (kil...@gmx.de) schreibt:

>der Ausstieg aus Worten gefällt mir auch. Oder hast Du das binary


>mal in einem Lister betrachtet? Die gesamten Hochsprache-Routinen

Nee, hab mir nur mal kurz die WEB-Seite angesehen aber nix gedownloadet.
Ist das Generic-Paket in C oder Assembler?

>sind alle übersichtlich im Programm zu lesen, weils subroutine-
>threaded ist.

indirect threaded finde ich eigentlich cooler. Ist zwar langsamer aber
man kann die fertig "compilierten" Module theor. auch mit anderen CPUs
abarbeiten lassen und muß außerhalb des Nucleus nicht mal wissen, wie
breit Zeiger auf der Plattform sind. Bei meinem eigenen Versuchen (so
um 1997), von den ich letztens schrieb, hatte ich versucht, auch noch
die Speicher-Adressen als solche loszuwerden (plattformabhängig) also
war die CFA nur noch ein Index in eine Tabelle aller Wörter des
jeweiligen Moduls. Primitive gingen an der Modul-Tabelle vorbei und
addressierten stattdessen direkt ein (Pascal-) array[] of procedure.
Die beiden Stacks waren auch außerhalb des für Forth-Module sichtbaren
Adressraums. D.h. sie waren als Pascal-Array compiliert und konnten nur
über fest eingebaute Kernwort angesprochen werden. Wie nennt man so was?
Doppelt indirect threaded ist das ja nur in Bezug auf die Primitive. Bei
den Secondäries stehen in der Tabelle ja keine Adressen sondern ein
Offset innerhalb des jeweiligen Moduls. Naja, hatte zu der Zeit viele
Ideen, aber es fehlt die Zeit...

>Schlicht, elegant, weckt den Spieltrieb, einfach und motivierend.

Apropos Spieltrieb, wie wäre es denn mit einem portablen Pascal auf
dem Rücken eines Forth's. Gibts da schon was? Hab vor Jahren mal ein
Basic gesehn, welches in Forth geschrieben war.

>Erspart einem sicher nicht das nötige Verständnis aufzubringen,
>aber ist derzeit noch mehr ein Textadventure für mich ;)

Da wünsche ich Dir viel Spaß mit dem Drachen :-)


Gruß Torsten

--
A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take
away. (Antoine de Saint-Exupery)

Joachim Merkel

unread,
Jun 23, 2005, 4:41:00 AM6/23/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

> Nee, hab mir nur mal kurz die WEB-Seite angesehen aber nix
> gedownloadet. Ist das Generic-Paket in C oder Assembler?

Bisher in FASM, einem 386er/Pentium Assembler und die Macros
genannten Hochsprachenroutinen sind in Forth. Es gab aber einen
Vorschlag retroForth nach einer Art Reengineering mit dem
Disassembler von Albert v.d. Horst rf mit einem eigenen,
integrierten Assembler zu bauen.
Die Idee kam beim Entwickler wohl auch gut an, aber der
Assemblerteil ist derzeit wohl noch nicht ganz dafür
ausgelegt worden, aber der aktuellen Betaversion 8.0
liegt ein eigener Assembler von A.v.d.H. bei.

[...]
> indirect threaded finde ich eigentlich cooler. [...] Bei meinem


> eigenen Versuchen (so um 1997), von den ich letztens schrieb, hatte
> ich versucht, auch noch die Speicher-Adressen als solche loszuwerden
> (plattformabhängig) also war die CFA nur noch ein Index in eine
> Tabelle aller Wörter des jeweiligen Moduls. Primitive gingen an der
> Modul-Tabelle vorbei und addressierten stattdessen direkt ein
> (Pascal-) array[] of procedure. Die beiden Stacks waren auch
> außerhalb des für Forth-Module sichtbaren Adressraums. D.h. sie
> waren als Pascal-Array compiliert und konnten nur über fest
> eingebaute Kernwort angesprochen werden. Wie nennt man so was?

Die Frage muß ich weiterreichen , da muß ich passen.
Aber ist dennoch eine interessante Anregung, werde ich mal
drüber nachdenken. Es ging da ja um den embedded Interpreter.

[...]


> Apropos Spieltrieb, wie wäre es denn mit einem portablen Pascal auf
> dem Rücken eines Forth's. Gibts da schon was? Hab vor Jahren mal ein
> Basic gesehn, welches in Forth geschrieben war.

Es gibt wohl ein Pascal im TCOM Teil des F-PC-Pakets (nur f. real mode)
aber es hat sich anscheinend niemand mehr damit befaßt.

Charles Moore in einem slashdot-Interview 2001:
--------------------------------zip-----------------------------------
Forth would make a fine intermediate language. But why have an
intermediate language? It introduces another layer of confusion and
inefficiency between the programmer and her computer.
--------------------------------zap-----------------------------------

Ich gehe aber auch davon aus, daß sich niemand wirklich für Pascal
interessiert, ich habe von ein oder zwei Oberon-Fans unter Forthern
gelesen, aber wohl eher als OS.

[...]


> Da wünsche ich Dir viel Spaß mit dem Drachen :-)

Tnx. Der steckt da im Detail, keine Definition im Editor darf
derzeit länger als eine Zeile sein.

--
Salut
_)oachim

Message has been deleted

Anton Ertl

unread,
Jun 24, 2005, 4:09:19 AM6/24/05
to
kil...@gmx.de (Torsten Kildal) writes:
>Apropos Spieltrieb, wie wäre es denn mit einem portablen Pascal auf
>dem Rücken eines Forth's. Gibts da schon was?

Paul Kleinrubatscher hat sowas einmal in einer Diplomarbeit teilweise
gemacht (aber nicht so toll).

Schwierigkeiten dabei sind vor allem das goto (vor allem ueber
Prozedurgrenzen hinweg) und, zu einem geringerem Grad, das statische
Scoping.

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

Torsten Kildal

unread,
Jun 25, 2005, 2:41:34 AM6/25/05
to
all...@gmx.de (Wolfgang Allinger) schrieb:
>
> On 23 Jun 05 at group /de/comp/lang/forth in article

> <kil...@gmx.de> (Torsten Kildal) wrote:
>
>>Apropos Spieltrieb, wie wäre es denn mit einem portablen Pascal auf
>>dem Rücken eines Forth's. Gibts da schon was? Hab vor Jahren mal ein
>>Basic gesehn, welches in Forth geschrieben war.
>
>BASIC auf/in Forth gibbet immer noch. Sieh mal bei
>
>http://www.amresearch.com/

Danke, werde ich mir mal ansehen. Es ging mir aber eigentlich nicht
darum, irgendeine "einfachere" Sprache als Forth zu finden, sondern
einen kleinen Pascal-"Compiler" zu haben, den man überallhin mitnehmen
kann, z.B. auch für Microcontroller. Und schon wieder bin ich OT :-)

Derzeit wird Pascal dummerweise immer Delphi-ähnlicher und damit auch
C-äher. Hinzu kommt, daß z.Z. auch noch die Weiterentwicklung von FreePascal
für mein heiß geliebtes DOS in der Luft hängt. Also ich mache mir ersthaft
Sorgen, ob ich mal später im Alter immer noch ein Pascal finden werde, was
noch nicht vollständig verkorks wurde. Irgendwann werden wir ja alle mal
alt. :-/
Und wenn dann der letzte bei Opa noch laufende Rechner kaputt geht,
der noch nicht durch DRM und anderen Mist geknebelt wurde, spätestens dann
wäre man gezwungen, mit aller Software auf eine andere Plattform umzuziehen.
Zur Not kann man sich ja dann von einem netten Enkel einen kleinen "freien"
Rechner basteln lassen. Sicher haben die Mikrocontroller bis dahin soviel
Power, wie heute die Desktops. Wenn ich mir nun aber vorstelle, einen
komplettes Pascal darüber zu portieren... :-(
Da ich früher mal in Forth (Fig, F83) programmiert hatte, ist mir in etwa
klar, wie der Unterbau des Forth-"Compilers" aussieht. Jetzt kam noch eine
Diskussion in der Pascalgruppe zum Multithreading dazu und ich erinnerte
mich daran, wie Forth Multithreading macht. So kam mir die Idee, man könnte
sowas wie den Fadencodeinterpreter von Forth als eine VM unter sowas wie
einen P-Code-Compiler legen. Forth selbst (als Sprache) wäre da nicht mehr
drin, aber man könnte es natürlich genauso darübersetzen, wie das Pascal.
Wenn man den Code später mal "recompiliert", soll man nicht mehr sehen,
in welcher Sprache er erzeugt wurde.
Der Vorteil wäre IMHO, daß dieses Teil viel leichter portierbar wäre,
außerdem bin ich mir sicher, daß sich auch in 100 Jahren noch Forth-fähige
Hardware finden lassen wird. Bei der Gelegenheit würde ich auch gleich
versuchen, Pascal an zwei Stacks zu gewöhnen und ihm ein VM-internes
Multithreading spendieren. Naja, alles erstmal nur so geträumt... :-)

>Ich benutze den BASIC Kram nicht und bin bei der Version 6 geblieben, da
hab BASIC das letzte Mal auf dem ZX81 benutzt :^)

>die Version 7 mir zu trocken ist :-) Funzt hervorragend mit den Cygnla
>Prozessoren, ich hab einiges für den F310 gemacht.

Sind das Microcontoller? Kenne da nur Atmel und davor UB8820 :-)
Andererseits F310 klingt fast so, als wäre das eine Forth-CPU?

>
>Tschüß Wolfgang
>

Gruss Torsten

--
Das Thema Softwarepatente ist immer noch nicht in den Massenmedien.
Muss es erst zur Selbstverbrennung von Programmieren vor den Toren
des Patentamtes kommen? (Harald Seffers in de.org.ccc)

Torsten Kildal

unread,
Jun 25, 2005, 3:34:32 AM6/25/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Torsten Kildal (kil...@gmx.de) schreibt:

>> gedownloadet. Ist das Generic-Paket in C oder Assembler?


>
>Bisher in FASM, einem 386er/Pentium Assembler und die Macros
>genannten Hochsprachenroutinen sind in Forth. Es gab aber einen
>Vorschlag retroForth nach einer Art Reengineering mit dem
>Disassembler von Albert v.d. Horst rf mit einem eigenen,

wieso muß er es diassemblieren, hat er seinen Source verlegt? :-)

>[...]


>> eigenen Versuchen (so um 1997), von den ich letztens schrieb, hatte

...


>Aber ist dennoch eine interessante Anregung, werde ich mal
>drüber nachdenken. Es ging da ja um den embedded Interpreter.

Will Du den dann zu Public Domain machen? Vielleicht laß ich Dich bei
Interesse ja mal in mein Code reinsehen? Es sind zwei separate
Pascal-Programme, eines interpretiert die Forth-Source und erzeugt die
Module (16bit-Fadencode) das andere kann man als eigene Exe zum Ausführen
dieser Module benutzen oder als Unit in ein Pascal-Prog. einbauen, und
von dort aus den Interpreter ein Modulname übergeben. Also richtig fertig
ist es nicht, deshalb hab ich es auch nirgends veröffentlicht, aber ein
kleines "Hallo Welt" geht schon und in ein eigenes Programm hatte ich es
auch schon mal eingebaut.

Das Kernel kennt bisher nur diese 63 Primitive:

(:) ; (BRANCH) (0BRANCH) R BYE CMOVE >R R> DUP DROP OVER SWAP -DUP 2DUP
SP@ (LIT) @ ! 1- 1+ 2* . (.") EMIT WAIT XOR (SETFILE) LOADBYTES + - C@
C! = 0= 0< < > (DO) (LOOP) (+LOOP) OR AND (DoCon) (DoVar) PS@ GETMEM
FREEMEM FSEEK

die sind aber in TurboPascal geschrieben. Der Rest ist in Highlevel.

>Es gibt wohl ein Pascal im TCOM Teil des F-PC-Pakets (nur f. real mode)
>aber es hat sich anscheinend niemand mehr damit befaßt.

Muß ich mal meine Hd durchsuchen. Irgendwann hatte ich mir F-PC doch
schon mal besorgt.

>Charles Moore in einem slashdot-Interview 2001:
>--------------------------------zip-----------------------------------
>Forth would make a fine intermediate language. But why have an
>intermediate language? It introduces another layer of confusion and
>inefficiency between the programmer and her computer.
>--------------------------------zap-----------------------------------

Ich will für diese Anwendung ja nicht ein Forth als Zwischenschicht,
sondern nur die genialen Konzepte der Forth-VM übernehmen. (siehe dazu
mein anderes Posting)

>Ich gehe aber auch davon aus, daß sich niemand wirklich für Pascal
>interessiert, ich habe von ein oder zwei Oberon-Fans unter Forthern
>gelesen, aber wohl eher als OS.

Es könnte damit mal wieder die Leistungsfähigkeit von Forth vorgeführt
werden.


Gruss Torsten

--
Es ist nicht Deine Schuld, dass die Welt ist, wie sie ist.
Es wär nur Deine Schuld, wenn sie so bleibt.
(die Ärzte aus Berlin)

Torsten Kildal

unread,
Jun 25, 2005, 3:26:48 AM6/25/05
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) schrieb:

>kil...@gmx.de (Torsten Kildal) writes:
>>Apropos Spieltrieb, wie wäre es denn mit einem portablen Pascal auf
>>dem Rücken eines Forth's. Gibts da schon was?
>
>Paul Kleinrubatscher hat sowas einmal in einer Diplomarbeit teilweise
>gemacht (aber nicht so toll).

Kann man die downloaden?

>
>Schwierigkeiten dabei sind vor allem das goto (vor allem ueber
>Prozedurgrenzen hinweg) und, zu einem geringerem Grad, das statische

Braucht man das denn überhaupt? Goto innerhalb einer Prozedure sehe ich
ja unter gewissen Umständen noch ein, aber über Prozedurgrenzen hinweg?

das statische
>Scoping.

Das interessiert mich, erklär mal bitte, was ist da das Problem? Liegt
es an der Bufferverwaltung von Forth?

Gruss Torsten

--
(Hier entsteht in Kuerze eine Signaturzeile.)

Marcel Hendrix

unread,
Jun 25, 2005, 7:39:50 AM6/25/05
to
[..]

>> Es gibt wohl ein Pascal im TCOM Teil des F-PC-Pakets (nur f. real mode)
>> aber es hat sich anscheinend niemand mehr damit befaßt.

> Muß ich mal meine Hd durchsuchen. Irgendwann hatte ich mir F-PC doch
> schon mal besorgt.

[..]

Habe Ich mal zur ANS uebersetzt, fuer iForth.
Jetzt kan er dies:

===

DOC
(*
PASCAL.FRT Tiny Pascal Copyright 1987-91 Tom Zimmer

Here is the latest version of my Tiny Pascal implementation in Forth.

It doesn't do all that much, but it does translate the simple examples
included with the compiler (PASX.TPS) and SIEVEP.TPS from PASCAL to Forth.

Once TPASCAL has been loaded, you can use it to translate the pascal
example file PASX.TPS into Forth with the following command:

INCLUDE TPASX.TPS <enter>

The Pascal translator will output Forth source to the console.

Limitations
-----------
Arrays : the .. operator is not supported, and type must be INTEGER
example: foo: array[100] of integer;

Comments : Non standard syntax. '{' '(*' '}' and '*)' do not work. Use
'\*' combined with '*\'
example: \* This is a comment *\

Strings : no string constants, no string operators. The write() procedure
supports quoted strings. Single char strings are ok.
example : const foo = '.'
write('hello, world',foo);

Output : No writeln(x). Use newline; write(x);
If a number must be printed, use the # prefix.
example: const foo = 1; write(#foo) \* prints "1"

Input : No readln(). Use the # prefix to pass the variable address to
read's runtime (#input).
example: var ii: integer; read(#ii);

Functions: These do not work. This is probably an oversight as code is present
to support them.
*)
ENDDOC

=== input

(* A sample pascal program to compile with tPascal, the pascal translator *)

PROGRAM primes; \* The Sieve of Erastothenes, 10.3 seconds/100 in tForth *\
const \* about 7 seconds in iForth on '386; 3.080 on '486 *\
size = 8190;
var
flags: array[8190] of integer;
ii, prime, kk, count, iter : integer;
BEGIN
newline; write('1000 iterations ...');
FOR iter := 1 to 1000 DO BEGIN
count := 0;
FOR ii := 0 TO size DO flags[ii] := 1;
FOR ii := 0 TO size DO
IF flags[ii] THEN BEGIN
prime := ii+ii+3;
kk := ii+prime;
WHILE kk <= size DO
BEGIN
flags[kk] := 0;
kk := kk+prime
END;
count := count+1
END;
END;
newline; write(#count,'primes found.')
END.

=== output (text)

FORTH> in sievep.tps
\ The Sieve of Erastothenes, 10.3 seconds/100 in tForth
\ about 7 seconds in iForth on '386; 3.080 on '486

8190 CONSTANT size
VARIABLE flags 32756 allot
VARIABLE ii
VARIABLE prime
VARIABLE kk
VARIABLE count
VARIABLE iter
: primes
cr ." 1000 iterations ... "
1 1000 1 + swap
DO
I iter ! 0 count !
0 size 1 + swap DO I ii ! ii @ flags []CELL 1 swap ! 1 +LOOP
0 size 1 + swap
DO I ii ! ii @ flags []CELL @
IF ii @ ii @ 3 + + prime ! ii @ prime @ + kk !
BEGIN kk @ size <=
WHILE kk @ flags []CELL 0 swap ! kk @ prime @ + kk !
REPEAT count @ 1 + count !
ENDIF
1 +LOOP
1 +LOOP
cr count @ . ." primes found. " ;

Gibt also Forth text aus.

-marcel

Anton Ertl

unread,
Jun 25, 2005, 7:38:56 AM6/25/05
to
kil...@gmx.de (Torsten Kildal) writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) schrieb:
>>kil...@gmx.de (Torsten Kildal) writes:
>>>Apropos Spieltrieb, wie wäre es denn mit einem portablen Pascal auf
>>>dem Rücken eines Forth's. Gibts da schon was?
>>
>>Paul Kleinrubatscher hat sowas einmal in einer Diplomarbeit teilweise
>>gemacht (aber nicht so toll).
>
>Kann man die downloaden?

Nein, das war kurz vor der Web-Zeit. Vielleicht habe ich die Diskette
noch irgendwo, und kann sie ins Web stellen, aber wie gesagt, sie war
nicht so toll.

>>Schwierigkeiten dabei sind vor allem das goto (vor allem ueber
>>Prozedurgrenzen hinweg) und, zu einem geringerem Grad, das statische
>
>Braucht man das denn überhaupt? Goto innerhalb einer Prozedure sehe ich
>ja unter gewissen Umständen noch ein, aber über Prozedurgrenzen hinweg?

Scheint fuer mich eine misslungene Art von Exceptions zu sein. Aber
wenn man ISO Pascal implementieren will, braucht man es.

>das statische
>>Scoping.
>
>Das interessiert mich, erklär mal bitte, was ist da das Problem?

Wie implementiert man es, sodass es schnell ist? Mit stack frames und
statischen links etc., und Zugriff auf die Variablen darueber (wie im
Lehrbuch) kann man es natuerlich implementieren, aber das wird dann
ueblicherweise nicht Register verwenden. Sonst sehe ich da eigentlich
kein Problem.

Message has been deleted

Joachim Merkel

unread,
Jun 25, 2005, 3:02:00 PM6/25/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

> Joachim Merkel <jm...@gmx.de> schrieb:
>> Torsten Kildal (kil...@gmx.de) schreibt:

>>> gedownloadet. Ist das Generic-Paket in C oder Assembler?
>>
>> Bisher in FASM, einem 386er/Pentium Assembler und die Macros
>> genannten Hochsprachenroutinen sind in Forth. Es gab aber einen
>> Vorschlag retroForth nach einer Art Reengineering mit dem
>> Disassembler von Albert v.d. Horst rf mit einem eigenen,

> wieso muß er es diassemblieren, hat er seinen Source verlegt? :-)

Es gibt den Source für den FASM, aber die Ziele hier waren
per Disassemblierung den Source für einen weiteren Assembler
in Forth zu bekommen, der in etwas abgespeckter Form in RF
eingebaut wird und damit ein "Meta-Assembling" von RF gestattet
oder die Assemblierung mit voller Fehlererkennung -behandlung
auf dem anderen Forth (ciforth). Ich habe es noch nicht genau
angeschaut, aber der Sinn oder Vorteil ist ja, daß Du den
Source bis aufs letzte Byte identisch wie das Original
hinbekommst.


>> [...]
>>> eigenen Versuchen (so um 1997), von den ich letztens schrieb,
>>> hatte

> ....


>> Aber ist dennoch eine interessante Anregung, werde ich mal
>> drüber nachdenken. Es ging da ja um den embedded Interpreter.

> Will Du den dann zu Public Domain machen?

Soweit habe ich nicht gedacht. Pygmy-Forth ist Shareware, kann zwar
umsonst benutzt werden, nur für die Shadow-Files will Frank Sergeant
etwas Geld sehen.
Ich bin erst mal weiter, wenn es so als Subroutine in Pascal läuft,
wie es unter C läuft und Teile des Pascal-Programms für Skript-
gesteuerte Abläufe taugen oder tauglich gemacht werden können.
Neben einfacherer Programmierung erwarte ich mir Ideen zur besseren
Modularisierung des Pascal-Programms und für interne Schnittstellen.
Meine Überlegung ist, manche Funktionen sozusagen zu verdoppeln,
um einfacher Varianten oder sonstwas auszuprobieren ohne zugleich
die alte Funktion abzuschalten oder mehr oder weniger Erweiterungen
zu probieren und zu testen.

> Vielleicht laß ich Dich bei Interesse ja mal in mein Code reinsehen? Es
> sind zwei separate Pascal-Programme, eines interpretiert die
> Forth-Source und erzeugt die Module (16bit-Fadencode) das andere kann
> man als eigene Exe zum Ausführen dieser Module benutzen oder als Unit
> in ein Pascal-Prog. einbauen, und von dort aus den Interpreter ein
> Modulname übergeben.

Danke, mich würde mal das letztere interessieren. Ich schätze ich sollte
mir vorher von den Sachen selbst gründlicher ein Bild gemacht habe, was
hier geht oder nicht. Die Probleme werden vermutlich nicht beim
Aufruf des Interpreters und die Übergabe einfacher Funktionsaufrufe
liegen, sondern bei den Versuchen, auf wesentliche Teile der
.Exe/.Ovr auf eigene Faust am runtimesystem vorbei zuzugreifen.

> Also richtig fertig ist es nicht, deshalb hab ich es auch nirgends

> veröffentlicht [...]

> Das Kernel kennt bisher nur diese 63 Primitive:

[...]


> die sind aber in TurboPascal geschrieben. Der Rest ist in Highlevel.

Ist wohl auch portabel geplant, aber soweit gehen meine Überlegungen
derzeit nicht.

[...]


> Ich will für diese Anwendung ja nicht ein Forth als Zwischenschicht,
> sondern nur die genialen Konzepte der Forth-VM übernehmen. (siehe
> dazu mein anderes Posting)

4tH könnte Dich als Vorlage auch interessieren, das ist ein Forth-
Interpreter in C der Tokens interpretiert, soll crash-frei sein,
gibts auch für DOS - auch mit DMPI-Extender - und die VM ist in
der neuesten Version doppelt so schnell schreibt Hans Bezzemer
(demnächst als pre-Release).
Der entspricht der Hälfte Deiner Beschreibung, denke ich mal.
--------------------------------zip-----------------------------------
[read.me]
4tH is basic framework for creating application specific scripting
languages. It is a library of functions centered around a virtual
machine, which guarantees high performance, ease of use and low overhead.
--------------------------------zap-----------------------------------
Der Code läuft ohne neuzukompilieren unter DOS und Linux. Soweit
keine Systembesonderheiten wie Pipes unter Linux eingebaut wurden.
Steht unter GPL.

<http://www.xs4all.nl/~thebeez/4tH>

Ist auch als Forth-Lernsystem konzipiert.
Ich spiele damit gerne rum und bastel Filter für meine Emails.

>> Ich gehe aber auch davon aus, daß sich niemand wirklich für Pascal
>> interessiert, ich habe von ein oder zwei Oberon-Fans unter Forthern
>> gelesen, aber wohl eher als OS.

> Es könnte damit mal wieder die Leistungsfähigkeit von Forth
> vorgeführt werden.

Dauert nur immer alles seine Zeit, bis es mehr als PD-Schrott [tm] ist.
Man könnte mal eine deutsche Dokumentation für 4tH schreiben,
Forth ist schon leistungsfähig, aber unzureichend dokumentiert.

--
Salut
_)oachim

Torsten Kildal

unread,
Jun 26, 2005, 3:37:10 AM6/26/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Torsten Kildal (kil...@gmx.de) schreibt:
>> Joachim Merkel <jm...@gmx.de> schrieb:
>>> Torsten Kildal (kil...@gmx.de) schreibt:

>> wieso muß er es diassemblieren, hat er seinen Source verlegt? :-)
...


>angeschaut, aber der Sinn oder Vorteil ist ja, daß Du den
>Source bis aufs letzte Byte identisch wie das Original
>hinbekommst.

Verstehe.

[embedded Interpreter]

>Neben einfacherer Programmierung erwarte ich mir Ideen zur besseren
>Modularisierung des Pascal-Programms und für interne Schnittstellen.

In dieser Hinsicht hat mich FORTH eigentlich über die Jahre immer
beeinflußt. Wer *einmal* FORTH gelernt hat, programmiert IMHO sein
Leben lang in jeder Sprache etwas FORTH. Das gilt wahrscheinlich aber
auch für alle andere Sprachen u. Programmierer. Ich erkenne z.B. auch
oft, ob ein Pascal-Text von einem C-Programmierer oder einem Müsli-Fan
geschrieben wurde.

>Meine Überlegung ist, manche Funktionen sozusagen zu verdoppeln,
>um einfacher Varianten oder sonstwas auszuprobieren ohne zugleich
>die alte Funktion abzuschalten oder mehr oder weniger Erweiterungen
>zu probieren und zu testen.

? Du sprichst mir in Rätseln, aber ich ahne, worauf Du hinaus willst. Es
scheint, Du wünscht Dir, daß das fertige Pascal-Programm noch ein
bisschen Interpreter bleibt, so daß Du auch bei fertiger EXE immer noch
dranrum fummeln kannst, richtig? Oder soll der Fadencode, den Dein
embedded Interpreter interpretiert, nach Erstellung der PAS-EXE dann
festbleiben?

>> Vielleicht laß ich Dich bei Interesse ja mal in mein Code reinsehen? Es
>> sind zwei separate Pascal-Programme, eines interpretiert die

...


>Danke, mich würde mal das letztere interessieren. Ich schätze ich sollte
>mir vorher von den Sachen selbst gründlicher ein Bild gemacht habe, was

...
OK, ich pack Dir mal was zusammen. Ist Deine Adresse replyfähig?

>> Das Kernel kennt bisher nur diese 63 Primitive:
>[...]
>> die sind aber in TurboPascal geschrieben. Der Rest ist in Highlevel.
>
>Ist wohl auch portabel geplant, aber soweit gehen meine Überlegungen
>derzeit nicht.

Ja, für mich war die Portabilität mit das Wichtigste. Aber auch eine hohe
Skalierbarkeit wäre nach meinem Wunsch. Es macht ja keinen Spaß aller paar
Jahre wegen der Bitbreite oder der Größe des max. adressierbaren
Adressraums alle Software umzuschreiben.

>4tH könnte Dich als Vorlage auch interessieren, das ist ein Forth-

...


>Der entspricht der Hälfte Deiner Beschreibung, denke ich mal.

Klingt interessant, werd ich mir mal ansehen. Und sei es nur, um mir
was abzukucken. :-)

>Der Code läuft ohne neuzukompilieren unter DOS und Linux. Soweit

Cool, *so* sollte es sein!

>Forth ist schon leistungsfähig, aber unzureichend dokumentiert.

Daran liegt es wohl eher nicht, daß FORTH nicht *die* Weltsprache ist.
Ein Grund ist IMHO, daß wir immer wieder zulassen, daß sich falsche
Sprechweisen und Vorstellungen über diese Sprache verbreiten und in
den Köpfen festsetzen. Z.B. "eine Sprache für kleine Computer", "wurde
früher mal für ... benutzt".
Außerdem werden Besonderheiten der Sprache oft in negativer Form
beschrieben, statt sie als Feature zu kennzeichnen. Also statt zu
sagen "in Forth gibt es keine Klammern" wäre besser "in Forth *braucht*
man keine Klammern". Oder statt "in Forth *muß man immer* mit zwei Stacks
arbeiten" klingt es viel besser "Forth *bietet* Daten und Adressen
einen eigenen Stack, so müssen sich diese nicht wie bei anderen Sprachen
auf *nur einem* Stack drängeln". Überhaupt darf man bei dem Vergleichen
mit anderen Sprachen nie so viel Bescheidenheit zeigen, daß man die
jeweils andere als Maßstab zuläßt "XY kann Forth *auch*" oder "Forth macht
XY so ähnlich, wie Z++". Besser ist: "XY ist bei FORTH selbstverständlich"
und "was Sie vielleicht erst von Z++ kennen, ist bei Forth schon von Haus
aus dabei." Das ist dann zwar oft etwas provozierend, aber dann wird
wenigstens diskutiert. :-) Man kann ja mal mit verschiedenen Formulierungen
Leuten FORTH erklären, die noch nie davon gehört haben und sie anschließend
befragen, was sie über F. denken. Vielleicht wäre dann so eine Art
"FORTH-Knigge" möglich, der den Fans dieser Sprache einen Leitfaden zur
Argumentation bietet. Wenn man die Leute erstmal neugierig gemacht hat,
finden sie auch genug deutschsprachiges Material. Sie müssen nur wollen.
Darüber hinaus gibt es natürlich noch andere Gründe, z.B. mangelndes
Librarykonzept, leichte Rekompilierbarkeit, usw...

Gruß Torsten

Torsten Kildal

unread,
Jun 26, 2005, 4:52:53 AM6/26/05
to
all...@gmx.de (Wolfgang Allinger) schrieb:
> <kil...@gmx.de> (Torsten Kildal) wrote:
>>all...@gmx.de (Wolfgang Allinger) schrieb:
>>> <kil...@gmx.de> (Torsten Kildal) wrote:

...
>Nö, kuck Dir einfach mal an, wie die das BASIC auf Forth aufgesetzt
>haben, das sollte so ähnlich auch in Platzcal gehen :-)

OK, werd ich machen. Obwohl, das BASIC dürfte IHMO kaum formale Parameter
lokale Variablen, lokale Prozeduren, Varianten-Records und all den
anderen Compilerkram kennen...

>>mache mir ersthaft Sorgen, ob ich mal später im Alter immer noch ein
>>Pascal finden werde, was noch nicht vollständig verkorks wurde.
>>Irgendwann werden wir ja alle mal alt. :-/
>

>Hihi, so geht's mir schon seit Jahren.

Was denn, liefert Dein Schreibwarenhandel etwa keine Papierrollen mehr
für Deinen Lochstreifendrucker? :-)

...


>>Sind das Microcontoller? Kenne da nur Atmel und davor UB8820 :-)
>

>Ja, hab mich vertippert, heisst CYGNAL :-\

Gut, kenn ich trotzdem nicht, schlimm? :^)

>>Andererseits F310 klingt fast so, als wäre das eine Forth-CPU?
>

>Nö, ist ein sehr schneller 8051 (25MHz Coretakt, optimierter Kern, viele

Achso, dachte nur wegen dem "F" im Namen...

>Der kleinste ist z.Zt. der F300 in einem 11(?)pol MLP Gehäuse 3x3x0,6mm!
>incl. ADC SIO und und und...
>
>Da kannste 'ne M6er Schraube ausbohren und einen Controller ins Gewinde
>unterbringen. Musst nur einen Deppen finden, der die Drähte für die
>serielle Schnittstelle anschließt :-)
>
>Hätte doch was ...M6Forth :-)

Lieber nicht, sonst denken die noch, bei uns ist'ne M6-Schraube locker. :^)

>
>Tschüß Wolfgang
>

--
Eine FAQ, sie zu knechten, sie alle zu finden,
ins Wissen zu treiben und ewig zu binden.

Die FAQ für de.etc.beruf.selbstaendig: www.debs-faq.de

Torsten Kildal

unread,
Jun 26, 2005, 4:37:44 AM6/26/05
to
m...@iae.nl (Marcel Hendrix) schrieb:
...

>>> Es gibt wohl ein Pascal im TCOM Teil des F-PC-Pakets (nur f. real mode)
>>> aber es hat sich anscheinend niemand mehr damit befaßt.
...

>Habe Ich mal zur ANS uebersetzt, fuer iForth.
>Jetzt kan er dies:
...
[schönes Pas-2-4th Beispiel gesnippt]

den Source-Translater schau ich mir (wenn ich ihn finde) mal an, aber das
ist eigentlich nicht *das*, was ich wollte. Da könnte ich z.B. auch gleich
einen P2C-Konverter nehmen. Was mir vorschwebt, ist ein kleiner portabler
PAS-Compiler, den ich mir selber zurechtbiegen kann, der komplett in seiner
eigenen Sprache (also meinem PAS-Dialekt) geschrieben wurde und auf dem
Rücken eine FORTHartigen VM läuft. Ich hatte schon daran gedacht, auf eine
JAVA-VM zu bauen, aber seien wir mal ehrlich, wer FORTH kennt, kann JAVA
doch nicht ersthaft für voll nehmen?!
Wenn ich dann eines Tages gezwungen sein werde, die Plattform zu wechseln,
würde es IMHO reichen, diese FORTHartigen VM zu portieren. Der Compiler
und alle Anwendungen sollten dann (bereits auf der alten Plattform
"compiliert") sofort auf der neuen benutzbar sein. Soweit zumindest mein
Wunschdenken ... :-)

Gruss Torsten.

--
why use windows if you have a door?

Joachim Merkel

unread,
Jun 26, 2005, 4:50:00 AM6/26/05
to
Joachim Merkel (jm...@gmx.de) schreibt:

> Torsten Kildal (kil...@gmx.de) schreibt:

>> Nee, hab mir nur mal kurz die WEB-Seite angesehen aber nix
>> gedownloadet. Ist das Generic-Paket in C oder Assembler?

> Bisher in FASM, einem 386er/Pentium Assembler und die Macros
> genannten Hochsprachenroutinen sind in Forth.

Das war nix. Die Macros gibts nur als Assembler-Macros.
Ansonst gibt es zwei Vokabulare Forth und Macro. In beiden
tauchen primitives und secondaries auf. Wie bei Pygmy,
wo es Forth und Compiler gibt, sind Worte in Macro immer
immediate und im Interpreter werden nur Worte aus Forth
aufgerufen.
Was mich anfangs leicht irritiert hat, war der fehlende Prompt
im Interpreter, so daß man nie weiß ob das System nicht in
einer Endlosschleife hängt.
--
Salut
_)oachim

Marcel Hendrix

unread,
Jun 26, 2005, 7:32:13 AM6/26/05
to
kil...@gmx.de (Torsten Kildal)wrote Re: 8 reichen auch
[..]

> Wenn ich dann eines Tages gezwungen sein werde, die Plattform zu wechseln,
> würde es IMHO reichen, diese FORTHartigen VM zu portieren. Der Compiler
> und alle Anwendungen sollten dann (bereits auf der alten Plattform
> "compiliert") sofort auf der neuen benutzbar sein. Soweit zumindest mein
> Wunschdenken ... :-)

Aber das fundamentelle Problem aendert sich nicht. Am Ende
muss man doch immer systemabhaengige Funktionen aufrufen. Ich
kan mich vorstellen das so etwas in der Zukunft 'unerwuenscht' ist
oder so gar unmoeglich gemacht wird (vom OS geblockt, oder vielleicht
gar gesetzlich verboten). Natuerlich kan man sich seine Hardware (selber)
bauen (lassen), aber man will darauf doch eigene Software lauefen
lassen (e.g. news / mail / ftp etc.). Und (software)Schnittstellen werden
dan natuerlich gesperrt sein (wie es RSN der CD, DVD, und TV-karte und die
AD-converter der Audio-Karte sein werden:-)

Verstehen ich recht dass die Forthartigen VM dazu dient ein interpretierbares
Pascal zu schaffen? Am Ende braucht man doch immer een Pascal compiler
um auf ein anderes Platform zu wechseln? Was fuer type Code auch erzeugt wird
nichts, systemnaehen Aufrufen werden immer drin sein.

-marcel

Joachim Merkel

unread,
Jun 26, 2005, 5:40:00 AM6/26/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

[...]


>> Meine Überlegung ist, manche Funktionen sozusagen zu verdoppeln,
>> um einfacher Varianten oder sonstwas auszuprobieren ohne zugleich
>> die alte Funktion abzuschalten oder mehr oder weniger Erweiterungen
>> zu probieren und zu testen.

> ? Du sprichst mir in Rätseln, aber ich ahne, worauf Du hinaus
> willst. Es scheint, Du wünscht Dir, daß das fertige Pascal-Programm
> noch ein bisschen Interpreter bleibt, so daß Du auch bei fertiger
> EXE immer noch dranrum fummeln kannst, richtig? Oder soll der
> Fadencode, den Dein embedded Interpreter interpretiert, nach
> Erstellung der PAS-EXE dann festbleiben?

Ich will erweiterte Programmiermöglichkeiten, eben skript-
programmiert. Teilweise um vorhandene Funktionen nachzubauen oder
was neues anzustellen ohne gleich alles umzukrempeln.
Das Forthprogramm wäre jederzeit erweiter- und änderbar und
die Aufrufe können natürlich auch Teil des Pascals Programms
bleiben.
Ich sollte vielleicht auch darüber nachdenken, ob nicht die
Grundfunkunktionalität ohne die Skriptgeschichte erhalten
bleiben sollte, aber da ich sowieso in erster Linie
für meinen eigenen Bedarf plane, spielt das keine Rolle.

> OK, ich pack Dir mal was zusammen. Ist Deine Adresse replyfähig?

Ja, nur ist es wirklich nicht so eilig. Aber danke schonmal.

[...]

> Außerdem werden Besonderheiten der Sprache oft in negativer Form
> beschrieben, statt sie als Feature zu kennzeichnen. Also statt zu
> sagen "in Forth gibt es keine Klammern" wäre besser "in Forth
> *braucht* man keine Klammern".

Das finde ich ist ein wichtiger Punkt.

[...]

> Vielleicht wäre dann so eine Art "FORTH-Knigge" möglich, der den
> Fans dieser Sprache einen Leitfaden zur Argumentation bietet.

In comp.lang.forth wird gerade das Buch Programming Forth
korrekturgelesen, da sind solche Vorschläge genau richtig.

--
Salut
_)oachim

Torsten Kildal

unread,
Jun 26, 2005, 8:31:22 PM6/26/05
to
m...@iae.nl (Marcel Hendrix) schrieb:

>kil...@gmx.de (Torsten Kildal)wrote Re: 8 reichen auch
...
[Wunschdenken]
...

>Aber das fundamentelle Problem aendert sich nicht. Am Ende

Soll es aber: Alle Anwendungen würden dann "in der Box" der F-VM laufen.
So sehen sie nur das, was ihnen die VM bietet. Natuerlich wäre ein Teil
der VM-Implementation plattformabhängig, aber dieser Teil wäre dank
der Eigenschaften von FORTH sehr klein im Verhältnis zu anderen VM's.

>muss man doch immer systemabhaengige Funktionen aufrufen. Ich
>kan mich vorstellen das so etwas in der Zukunft 'unerwuenscht' ist

zur Not eben wieder ein standalone FORTH ... also zurück zur Natur :-)

>oder so gar unmoeglich gemacht wird (vom OS geblockt, oder vielleicht
>gar gesetzlich verboten). Natuerlich kan man sich seine Hardware (selber)

... und dann werden alle Programme < 5 MB automatisch als Virus eingestuft
und gelöscht. Natürlich wird vorher noch eine Kopie des Schädlings an M$
gesendet... Jaja, wir freuen uns alle auf *diese* Zukunft. :-(

>bauen (lassen), aber man will darauf doch eigene Software lauefen
>lassen (e.g. news / mail / ftp etc.). Und (software)Schnittstellen werden

klar will man. Ich weiß ja nicht, ob ein TCP/IP-Stack in Highlevel schnell
genug wäre, aber wenigsten eine Möglichkeit'ne Netzkarte oder ein Modem
anzusprechen müßte die VM ihren Clienten IMHO schon bieten.

>Verstehen ich recht dass die Forthartigen VM dazu dient ein interpretierbares
>Pascal zu schaffen? Am Ende braucht man doch immer een Pascal compiler
>um auf ein anderes Platform zu wechseln? Was fuer type Code auch erzeugt wird
>nichts, systemnaehen Aufrufen werden immer drin sein.

Nein. Die F-VM soll ganz ohne Pascal geschaffen werden. Sie könnte z.B.
mit einem Forth-Assembler erzeugt werden. D.h. sie soll zu einem großen
Teil aus Highlevel-Fadencode und ganz wenigen Assembler-Primitiven bestehen.
Der interaktive Teil sowie die Dictionäries entfallen. Es ist also nur ein
portabler Fadencode-Interpreter. Alle Programme, die darauf aufsetzen,
sollen dann aus *diesem* Code bestehen. Einmal "compiliert" kann man sie
von einer VM zur anderen mitnehmen und dort sofort nutzen ohne neu zu
compilieren. Der Pascal-Compiler wäre *ein* Beispiel für so ein Programm.
Er compiliert den PAS-Source nicht zu Maschinencode sondern zu F-Code und
ist selber in Pascal geschrieben. Folglich kann er sich dann auch selber
compileren. Bis dahin müßte man ihm aber mit dem Forth-Assembler unter die
Arme greifen.
Im Prinzip läuft es darauf hinaus, ein kleines Betriebssystem in einer
Forthbox zu schaffen. In diesem F-OS gäbe es dann u.U. verschiedene
Compiler (ich bevorzuge da natürlich Pascal) und damit kann man sich
dann programmieren, was man will. Wenns mal zu langsam wird, weil
interpretiert, kann man ja immer auf den Forth-Assembler ausweichen, der
die "Muttersprache" der Box darstellt. Wenn das allerdings auch noch
zu langsam ist, müßte man dem Kern Primitive zufügen, die wären dann
wieder plattformabhängig.

Jetzt könnte man natürlich sagen "nimm doch ein Java", aber das gefällt
mir nicht. Ich finde da FORTH viel besser. Außerdem wenn JAVA wirklich
nur halb so portabel wäre, wie immer behauptet, wieso habe ich dann bis
heute noch kein anständig funktionierendes JAVA für DOS gefunden?
FORTHe dagegen hab ich hier en Masse. IMHO ein klarer Beweis, welche
Sprache leichter portierbar ist...

>
>-marcel
>

Gruß Torsten.

--
Heute kann man ja kaum noch eine AOL-CD aus dem Fenster werfen,
ohne jemanden zu treffen, der einen SuSE-Karton unter dem Arm traegt.
(Jochem Huhmann in de.comp.os.unix.discussion)

Joachim Merkel

unread,
Jun 29, 2005, 4:02:00 AM6/29/05
to
Joachim Merkel (jm...@gmx.de) schreibt:

> Torsten Kildal (kil...@gmx.de) schreibt:

[RF]
>> [...] Was ist denn daran so "scharf"?

[...]


> Bei RF ist alles sehr sorgfältig gemacht, der Ausstieg
> aus Worten gefällt mir auch.

Mal ein Beispiel:

: hi ." hi" 0; hi 1- ;
7 hi
hihihihihihihi

:)
--
Salut
_)oachim

Marc Olschok

unread,
Jun 29, 2005, 11:22:28 AM6/29/05
to

Der Ausstieg per 0; gefällt mir auch. Vormalige Versionen von >>
landeten beim Versuch 0 bits zu schieben, immer im Nirvana und
da liest sich eine Korrektur wie : rshift 0; >> ; einfach
sehr hübsch.

Mit Version 8 hat Retroforth auch eine for ... next Schleife,
bekommmen, so dass man jetzt auch einfach

: hi for ." hi" next ;

schreiben kann.

Marc
so dass ich fü

Joachim Merkel

unread,
Jun 29, 2005, 6:18:00 PM6/29/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

>> [...]
>>> Bei RF ist alles sehr sorgfältig gemacht, der Ausstieg
>>> aus Worten gefällt mir auch.
>>
>> Mal ein Beispiel:
>>
>> : hi ." hi" 0; hi 1- ;
>> 7 hi
>> hihihihihihihi

Gut zu sehen, "Recursive" ist nicht erforderlich zum sofortigen
Aufruf.

> Der Ausstieg per 0; gefällt mir auch. Vormalige Versionen von >>
> landeten beim Versuch 0 bits zu schieben, immer im Nirvana und
> da liest sich eine Korrektur wie : rshift 0; >> ; einfach
> sehr hübsch.

> Mit Version 8 hat Retroforth auch eine for ... next Schleife,
> bekommmen, so dass man jetzt auch einfach

> : hi for ." hi" next ;

> schreiben kann.

Danke. Hatte mich schon mal gewundert, daß es fehlt.

--
Salut
_)oachim

Joachim Merkel

unread,
Jun 30, 2005, 1:16:00 AM6/30/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

>>> Bei RF ist alles sehr sorgfältig gemacht, der Ausstieg
>>> aus Worten gefällt mir auch.
>>
>> Mal ein Beispiel:
>>
>> : hi ." hi" 0; hi 1- ;
>> 7 hi
>> hihihihihihihi

Sorry, das füllt leider voll den Bildschirm ;-)
War aus der Erinnerung, ich muß für RF immer Linux booten,
schreibe hier aber unter DOS. Besser wäre:

: hi ." hi" 0; 1- hi ;
7 hi
hihihihihihihihi

ergibt 8 mal "hi"; wenn ich mich nicht verzählt habe entspricht
das der lautmalerische Umsetzung der Töne des Eichhörnchens
im Bildschirmschoner einer bekannten Nuß-Nougat-Creme.

: hi ." hi" 1- 0; hi ;
7 hi

Sollte also 7 mal "hi" ergeben..

> Mit Version 8 hat Retroforth auch eine for ... next Schleife,
> bekommmen, so dass man jetzt auch einfach

> : hi for ." hi" next ;

> schreiben kann.

.. ja wirklich gut daß es das gibt. :-))

--
Salut
_)oachim

Marc Olschok

unread,
Jun 30, 2005, 11:03:01 AM6/30/05
to
Joachim Merkel <jm...@gmx.de> wrote:
> Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:
>
>>>> Bei RF ist alles sehr sorgfältig gemacht, der Ausstieg
>>>> aus Worten gefällt mir auch.
>>>
>>> Mal ein Beispiel:
>>>
>>> : hi ." hi" 0; hi 1- ;
>>> 7 hi
>>> hihihihihihihi
>
> Sorry, das füllt leider voll den Bildschirm ;-)

Da sieht man mal, wie unaufmerksam ich lese ...

> War aus der Erinnerung, ich muß für RF immer Linux booten,
> schreibe hier aber unter DOS. Besser wäre:
>
> : hi ." hi" 0; 1- hi ;
> 7 hi
> hihihihihihihihi
>
> ergibt 8 mal "hi"; wenn ich mich nicht verzählt habe entspricht
> das der lautmalerische Umsetzung der Töne des Eichhörnchens
> im Bildschirmschoner einer bekannten Nuß-Nougat-Creme.
>
> : hi ." hi" 1- 0; hi ;
> 7 hi
>
> Sollte also 7 mal "hi" ergeben..
>
>> Mit Version 8 hat Retroforth auch eine for ... next Schleife,
>> bekommmen, so dass man jetzt auch einfach
>
>> : hi for ." hi" next ;
>
>> schreiben kann.
>
> .. ja wirklich gut daß es das gibt. :-))

In vorherigen Versionen hätte man es mittels repeat ... until
machen können

: hi repeat ." hi" until ;

aber es ist nicht sehr elegant, den Laufindex auf dem Datenstack
zu halten, ohne ihn im Schleifenrumpf überhaupt zu verwenden.

Version 8 ist auf jeden Fall schon wegen loc: ... ;loc zu
empfehlen. Es wird gleich alles viel lesbarer.

Jetzt warte ich nur noch darauf, dass sich bei /mod irgendwann einmal
der "richtige" Stackeffekt ( n n' --- rem quot ) einstellt.

Marc

Sieghard Schicktanz

unread,
Jun 29, 2005, 7:17:18 PM6/29/05
to
Hallo Joachim,

Du schriebst am 29 Jun 2005 10:02:00 +0200:

> : hi ." hi" 0; hi 1- ;
> 7 hi
> hihihihihihihi

Echte Ausgabe oder nur nachgestellt?

Mir scheint, irgendwas ist da falsch...

> :)


--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
--
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
- acht zwei fuenf vier sieben Achmuehle / Eurasburg
mailto:Sieg...@Schicktanz.schs.de
-----------------------------------------------------------

Torsten Kildal

unread,
Jun 30, 2005, 5:28:32 PM6/30/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Joachim Merkel (jm...@gmx.de) schreibt:

>[...]
>> Bei RF ist alles sehr sorgfältig gemacht, der Ausstieg
>> aus Worten gefällt mir auch.
>
>Mal ein Beispiel:
>
>: hi ." hi" 0; hi 1- ;
>7 hi
>hihihihihihihi
>
>:)

Schöne Sache, hätte man IMHO aber besser 0exit oder so ähnlich
nennen sollen. Normalerweise steuern Worte wie ":" und ";" ja den
Compiler, "0;" dagegen steuert aber das Laufzeitverhalten. Wenn man
es also etwas eng sieht, könnte man es mit bedingter Compilierung
verwechseln.

Gruß Torsten.

--
Geniale Menschen sind selten ordentlich, ordentliche selten genial.
(Albert Einstein, dt.Physiker)

Joachim Merkel

unread,
Jul 1, 2005, 12:25:00 AM7/1/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

[...]


> Version 8 ist auf jeden Fall schon wegen loc: ... ;loc zu
> empfehlen. Es wird gleich alles viel lesbarer.

Da hat sich jemand was dabei gedacht, nur bin ich noch am Grübeln:

Hier mal den Source für den Viewer ``v'', der Anzeige des Datenstacks
``.s'' in einer Zeile und ``status'' mit der Anzeige der Blocknr.
und des Datenstacks (davor die Def.en von ``loc:'' und ``loc'').

--------------------------------zip-----------------------------------
variable (loc)
: loc: last @ (loc) ! ; : ;loc (loc) @ last ! ;

loc:
: row green dup 64 type 64 + cr ;
: .rows 8 repeat dup 8 - negate red . >r row r> until ;
: .block ." Block: " blk @ . ;
: x--- ." +---:---+---:---" ;
: --- white space space x--- x--- x--- x--- cr ;
: v --- blk @ block .rows drop --- ;
: .stack ." Stack: "
: .s 10 repeat dup [ $86048b 3, ] . until cr ;
: status green .block .stack ;
' status ' .s ' v
;loc alias v alias .s alias status
--------------------------------zap-----------------------------------

``last'' ist die Adresse des letzten Dictionary-Eintrags
und ``;loc'' restauriert den dann wieder nach der Sicherung in
``(loc)'' durch ``:loc''. Mit den ``alias'' werden dann die
Adressen der Definitionen den Namen zugewiesen und
diese damit an das Dictionary angehängt, aber wo
sind die Definitionen dann überhaupt geblieben? Ich dachte
immer, die werden automatisch an das Forth-Vokabular angehängt?

Was mir auch auffällt, daß zwei Colon-Definitionen hintereinander
stehen, ``.vstack'' und ``.s'' aber nur die letzte mit einem ``;''
abgeschlossen wurde. Hatte ich auch schonmal was drüber
gelesen, eine Machine-Forth-Spezialität?

> Jetzt warte ich nur noch darauf, dass sich bei /mod irgendwann
> einmal der "richtige" Stackeffekt ( n n' --- rem quot ) einstellt.

Würgaround zum Pentiumbug ?-)
--
Salut
_)oachim

Joachim Merkel

unread,
Jul 1, 2005, 12:26:00 AM7/1/05
to
Hallo Sieghard,

Sieghard Schicktanz (Sieg...@Schicktanz.SchS.de) schreibt:

[...]

> Echte Ausgabe oder nur nachgestellt?

> Mir scheint, irgendwas ist da falsch...

War ja nur ein zero terminating string ;)

--
Salut
_)oachim

Joachim Merkel

unread,
Jul 1, 2005, 1:05:00 AM7/1/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

>>> Bei RF ist alles sehr sorgfältig gemacht, der Ausstieg
>>> aus Worten gefällt mir auch.
>>
>> Mal ein Beispiel:
>>
>> : hi ." hi" 0; hi 1- ;

correction:
: hi ." hi" -1 0; hi ;
>> 7 hi
>> hihihihihihihi
>>
>> :)

> Schöne Sache, hätte man IMHO aber besser 0exit oder so ähnlich
> nennen sollen. Normalerweise steuern Worte wie ":" und ";" ja den
> Compiler, "0;" dagegen steuert aber das Laufzeitverhalten. Wenn man
> es also etwas eng sieht, könnte man es mit bedingter Compilierung
> verwechseln.

Bei RF wird in beiden Fällen nur Exit ``;;'' in ein Wort
eingebaut, bei ``;'' wird anschließend noch in den Interpreter
gewechselt. Es kommt noch besser, ein weiteres ``:'' liefert Dir
in einer Definition einen weiteren Eintrittspunkt.

--
Salut
_)oachim

Stefan Schmiedl

unread,
Jul 1, 2005, 3:34:16 AM7/1/05
to
On 01 Jul 2005 06:25:00 +0200, Joachim Merkel <jm...@gmx.de> wrote:

> --------------------------------zip-----------------------------------
> variable (loc)
> : loc: last @ (loc) ! ; : ;loc (loc) @ last ! ;
>
> loc:
> : row green dup 64 type 64 + cr ;
> : .rows 8 repeat dup 8 - negate red . >r row r> until ;
> : .block ." Block: " blk @ . ;
> : x--- ." +---:---+---:---" ;
> : --- white space space x--- x--- x--- x--- cr ;
> : v --- blk @ block .rows drop --- ;
> : .stack ." Stack: "
> : .s 10 repeat dup [ $86048b 3, ] . until cr ;
> : status green .block .stack ;
> ' status ' .s ' v
> ;loc alias v alias .s alias status
> --------------------------------zap-----------------------------------
>
> ``last'' ist die Adresse des letzten Dictionary-Eintrags
> und ``;loc'' restauriert den dann wieder nach der Sicherung in
> ``(loc)'' durch ``:loc''. Mit den ``alias'' werden dann die
> Adressen der Definitionen den Namen zugewiesen und
> diese damit an das Dictionary angehängt, aber wo
> sind die Definitionen dann überhaupt geblieben? Ich dachte
> immer, die werden automatisch an das Forth-Vokabular angehängt?

Der Code ist noch da, nur die Namen sind weg. Wenn ich mich recht
erinnere, verwendet rf getrennte Bereiche für Namen und Code.

>
> Was mir auch auffällt, daß zwei Colon-Definitionen hintereinander
> stehen, ``.vstack'' und ``.s'' aber nur die letzte mit einem ``;''
> abgeschlossen wurde. Hatte ich auch schonmal was drüber
> gelesen, eine Machine-Forth-Spezialität?

woanders würde es z.b. so aussehen:

: .s ... cr ;
: .stack ." Stack: " .s ;

Nur ist's bei rf etwas effizienter beim Schreiben und Ausführen.

rf8 ist jetzt übrigens offiziell raus :-)

s.

Marc Olschok

unread,
Jul 1, 2005, 10:05:41 AM7/1/05
to
Joachim Merkel <jm...@gmx.de> wrote:
> Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:
>[...]
>> Jetzt warte ich nur noch darauf, dass sich bei /mod irgendwann
>> einmal der "richtige" Stackeffekt ( n n' --- rem quot ) einstellt.
>
> Würgaround zum Pentiumbug ?-)

Unwahrscheinlich. Vor Version 8 war /mod eine gewöhnliche
Definition unter Verwendung von / und mod und da war die
Reihenfolge auch schon "falsch herum".

In der aktuellen Version werden / und mod auf /mod zurückgeführt.
Für meinen Hausgebrauch habe ich einfach in der /mod Definition ein
swap angefügt, weil ich zu faul zum lesen der opcodes war. Daher sehen
die geänderten Zeile in source/blocks/base jetzt bei mir so aus:

: /mod [ $c389 2, $99ad 2, $fbf7 2, ] dup [ $d089 2, ] swap ;
: mod /mod drop ; : / /mod nip ;

Marc

Joachim Merkel

unread,
Jul 1, 2005, 10:31:00 AM7/1/05
to
Stefan Schmiedl (s...@xss.de) schreibt:

> Der Code ist noch da, nur die Namen sind weg. Wenn ich mich recht
> erinnere, verwendet rf getrennte Bereiche für Namen und Code.

Verstehe, das geht anscheinend ganz einfach bei subroutine threaded
Forth.
Beim Forth mit anderem threading gibts headerlose Worte, damit sie
nicht im dictionary auftauchen.

[...]

> rf8 ist jetzt übrigens offiziell raus :-)

Ich bin beeindruckt, der Termin für die stable-Version war heute,
wie in der RF v8.0-Beta angekündigt.

Jetzt sind sogar bis zu 4-fach geschachtelte lokale Definitionen
mit loc:...;loc möglich. Was das bringt, muß ich mir mal genauer
anschauen.

--
Salut
_)oachim

Torsten Kildal

unread,
Jul 1, 2005, 1:02:44 PM7/1/05
to
Joachim Merkel <jm...@gmx.de> schrieb:

[...]


>Bei RF wird in beiden Fällen nur Exit ``;;'' in ein Wort
>eingebaut, bei ``;'' wird anschließend noch in den Interpreter
>gewechselt.

Funktioniert das denn auch aus einer DO-LOOP Schleife heraus?

>gewechselt. Es kommt noch besser, ein weiteres ``:'' liefert Dir
>in einer Definition einen weiteren Eintrittspunkt.

Das ist ok, es wirkt sich ja nur zur Compilezeit aus. Allerdings
sehe ich auch hier wieder das Risiko, in verschachtelte LOOPs
zu springen. Liegt den heutzutage der Schleifenindex nicht mehr
auf den Returnstack? (kenne nur F83 u.älter).

Gruß Torsten.

PS: ließ sich K4 bei Dir starten?

--
This message has been doubly encrypted by rot13.
Unauthorised decryption may be a violation of the DMCA.
(Brian in comp.lang.pascal.borland)

Joachim Merkel

unread,
Jul 1, 2005, 6:00:00 PM7/1/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

>> Bei RF wird in beiden Fällen nur Exit ``;;'' in ein Wort
>> eingebaut, bei ``;'' wird anschließend noch in den Interpreter
>> gewechselt.

> Funktioniert das denn auch aus einer DO-LOOP Schleife heraus?

Es gibt nur repeat...again/until und for...next bei RF v8.0
(bei einer Vorversion war mglw. do...loop testweise dabei).

>> gewechselt. Es kommt noch besser, ein weiteres ``:'' liefert Dir
>> in einer Definition einen weiteren Eintrittspunkt.

> Das ist ok, es wirkt sich ja nur zur Compilezeit aus. Allerdings
> sehe ich auch hier wieder das Risiko, in verschachtelte LOOPs
> zu springen. Liegt den heutzutage der Schleifenindex nicht mehr
> auf den Returnstack? (kenne nur F83 u.älter).

Das Risiko wird nicht ausgeschlossen, soweit ich das verstanden
habe.
Der Index bei do..loop liegt normalerweise immer auf dem Returnstack,
auch in ANS-Forth, wobei diesem Standard bisher kaum Bedeutung
für die Entwicklung von RF beigemessen wurde. Es werden aber
wohl Vorschläge zu einem Kompatibilitätslayer gesammelt.

> PS: ließ sich K4 bei Dir starten?

Compiliert auch, kein Problem mit BP7 auch mit der optimierten
RTL von Robert Prins. Die Exe ist dann etwas kleiner, die
Zeit ist dann gerinfügig kürzer, das liegt daran, daß die
Optimierungen keine Rolle bei der Erzeugung von Test.log
spielen (nur noch 386-Assembler und noch einiges anderes).
Wenn es Dich interessiert, schau mal auf Garbo nach BPL70V20.ZIP.

--
Salut
_)oachim

Torsten Kildal

unread,
Jul 2, 2005, 4:45:28 PM7/2/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Torsten Kildal (kil...@gmx.de) schreibt:

[;; mitten im Wort]


>> Funktioniert das denn auch aus einer DO-LOOP Schleife heraus?
>
>Es gibt nur repeat...again/until und for...next bei RF v8.0

Und was soll der Unterschied zw. for...next und DO...LOOP sein?

>> zu springen. Liegt den heutzutage der Schleifenindex nicht mehr
>> auf den Returnstack? (kenne nur F83 u.älter).
>
>Das Risiko wird nicht ausgeschlossen, soweit ich das verstanden
>habe.
>Der Index bei do..loop liegt normalerweise immer auf dem Returnstack,
>auch in ANS-Forth, wobei diesem Standard bisher kaum Bedeutung

Habe schon oft darüber nachgedacht, ob es nicht sinnvoller wäre den
Index woanders hin zu legen, aber wohin? Vielleicht wäre ja ein extra
LOOP-Stack sinnvoll? Dann könnte sich z.B. ein Scheduler darauf verlassen,
daß das, was oben auf dem Returnstack liegt grundsätzlich eine Adresse
sein muß...

[K4]


>> PS: ließ sich K4 bei Dir starten?
>
>Compiliert auch, kein Problem mit BP7 auch mit der optimierten
>RTL von Robert Prins. Die Exe ist dann etwas kleiner, die

Noch kleiner?! Wieviel? Bei mir hat sie unter BP7 schon nur 7808 Byte
(mit pklite 5580 Byte). Also für Pascal-Verhältnisse schon äußerst
klein. :-)

>Zeit ist dann gerinfügig kürzer, das liegt daran, daß die
>Optimierungen keine Rolle bei der Erzeugung von Test.log
>spielen (nur noch 386-Assembler und noch einiges anderes).

Ich hatte K4 aber auch schon auf XT's benutzt.

>Wenn es Dich interessiert, schau mal auf Garbo nach BPL70V20.ZIP.

Danke, werd ich mir vormerken.

Gruß Torsten

--
Excel im Informatikunterricht. Na großartig. Und in Biologie lernt
ihr dann zu husten, als praktische Anwendung der Mikro- und
Humanbiologie? (David Kastrup in de.sci.mathematik)

Joachim Merkel

unread,
Jul 3, 2005, 12:40:00 AM7/3/05
to
Torsten Kildal (kil...@gmx.de) schreibt:

> [;; mitten im Wort]
>>> Funktioniert das denn auch aus einer DO-LOOP Schleife heraus?
>>
>> Es gibt nur repeat...again/until und for...next bei RF v8.0

> Und was soll der Unterschied zw. for...next und DO...LOOP sein?

Der Return-Stack wird bei for...next nicht gebraucht, ist
einfacher zu implementieren, wurde aber nicht in den ANS-Standard
aufgenommen. Begründet wurde das meist damit, daß for...next nicht
einheitlich in vd. Forth funktionierte:
--------------------------------zip-----------------------------------
[vgl. Pygmy]
FOR ( - h) ( u -) starts a FOR ... NEXT loop. Body executes
u times, not u+1 times as in some Forths.
NEXT ( h -) ( -) ends a FOR ... NEXT loop.
--------------------------------zap-----------------------------------
Die Entscheidung wird in comp.lang.forth häufiger kritisiert.

[do...loop]


> Habe schon oft darüber nachgedacht, ob es nicht sinnvoller wäre den
> Index woanders hin zu legen, aber wohin? Vielleicht wäre ja ein
> extra LOOP-Stack sinnvoll? Dann könnte sich z.B. ein Scheduler
> darauf verlassen, daß das, was oben auf dem Returnstack liegt
> grundsätzlich eine Adresse sein muß...

Oder eben for...next nehmen.

> [K4]

> Noch kleiner?! Wieviel? Bei mir hat sie unter BP7 schon nur 7808
> Byte (mit pklite 5580 Byte). Also für Pascal-Verhältnisse schon
> äußerst klein. :-)

Mit der alten RTL bekomme ich unter BP7 für K4.Exe hier 6992 bytes
mit der neuen 6320. Mit Pklite 2.01(PKWARE) bekomme ich für
letztere 4674 bytes, mit UPX v1.24d werden aus 6320 dann 4056 bytes.

BTW der Aufruf von Pascal-Routinen mit dem embedded Interpreter
hatte mich zunächst interessiert.
Hast Du vielleicht auch ein Beispiel dafür?
--
Salut
_)oachim

Torsten Kildal

unread,
Jul 3, 2005, 4:17:58 PM7/3/05
to
Joachim Merkel <jm...@gmx.de> schrieb:
>Torsten Kildal (kil...@gmx.de) schreibt:

>> [K4]
[...]


>BTW der Aufruf von Pascal-Routinen mit dem embedded Interpreter
>hatte mich zunächst interessiert.
>Hast Du vielleicht auch ein Beispiel dafür?

ist unterweg... (--> PM)

Gruß Torsten.

--
Irren ist menschlich. Aber wenn man richtig Mist bauen will, braucht man
einen Computer. (Dan Rather, CBS-Fernsehreporter)

Marc Olschok

unread,
Jul 4, 2005, 11:13:12 AM7/4/05
to
Joachim Merkel <jm...@gmx.de> wrote:
> Torsten Kildal (kil...@gmx.de) schreibt:
>
>> [;; mitten im Wort]
>>>> Funktioniert das denn auch aus einer DO-LOOP Schleife heraus?
>>>
>>> Es gibt nur repeat...again/until und for...next bei RF v8.0
>
>> Und was soll der Unterschied zw. for...next und DO...LOOP sein?
>
> Der Return-Stack wird bei for...next nicht gebraucht [...]

Bist du sicher?

Ein kleiner Testlauf mit

: lauf for r . next ; 3 lauf

bringt mir die Ausgabe:

3 2 1

Also scheint der Laufindex auf dem Return-Stack gehalten zu werden.

Hingegen wird bei repeat...until der Laufindex auf dem Datenstack
gehalten wird und beim verlassen der Schleife entfernt wird:

: lauf repeat .s until ; 42 3 lauf .s

liefert die Ausgabe

0 0 0 0 0 0 0 0 42 3
0 0 0 0 0 0 0 0 42 2
0 0 0 0 0 0 0 0 42 1
0 0 0 0 0 0 0 0 0 42

Oder meintest du etwas anderes?

Grüße, Marc

Torsten Kildal

unread,
Jul 4, 2005, 2:05:34 PM7/4/05
to
Marc Olschok <sa7...@l1-hrz.uni-duisburg.de> schrieb:

[for...next]


>3 2 1
>
>Also scheint der Laufindex auf dem Return-Stack gehalten zu werden.
>
>Hingegen wird bei repeat...until der Laufindex auf dem Datenstack
>gehalten wird und beim verlassen der Schleife entfernt wird:

Da gibts jetzt auch einen Laufindex?! Ich seh schon, ich muß mir
diesen ANS-Standard bei Gelegenheit mal ansehen...
[miraltvorkommend] :-/

Bisher kannte ich REPEAT nur am *Ende* einer BEGIN-WHILE-REPEAT
Struktur. Die Analogie REPEAT-UNTIL bei z.B. Pascal ist ja ebenfalls
nur durch ein Flag gesteuert. Braucht es wirklich neben DO-LOOP
noch eine weitere unbedingte Schleife?

Gruß Torsten.

--
Chancengleichheit besteht nicht darin, daß jeder einen Apfel
pflücken darf, sondern daß der Zwerg eine Leiter bekommt.
(Reinhard Turre, dt. Theologe)

Joachim Merkel

unread,
Jul 4, 2005, 1:46:00 PM7/4/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

>>> Und was soll der Unterschied zw. for...next und DO...LOOP sein?
>>
>> Der Return-Stack wird bei for...next nicht gebraucht [...]

> Bist du sicher?

> Ein kleiner Testlauf mit

> : lauf for r . next ; 3 lauf

> bringt mir die Ausgabe:

> 3 2 1

> Also scheint der Laufindex auf dem Return-Stack gehalten zu werden.

Ja stimmt, man sollte alles testen, vor allem wenn man es leicht testen
kann ;-) Ich hatte mir die Implementation von For...Next im Source
angesehen und anscheinend nicht verstanden.

Der Unterschied zu do ... loop ist dann wohl nur der, daß der Index
nicht in einer Laufvariablen gehalten wird, sondern direkt auf dem
Returnstack liegt.

BTW gefällt mir ``R@'' aus dem F-83-Standard besser als ``R'', das
noch aus FIG-Zeiten stammt.

--
Salut
_)oachim

Joachim Merkel

unread,
Jul 4, 2005, 1:49:00 PM7/4/05
to
Joachim Merkel (jm...@gmx.de) schreibt:

> Torsten Kildal (kil...@gmx.de) schreibt:

>> Und was soll der Unterschied zw. for...next und DO...LOOP sein?

> Der Return-Stack wird bei for...next nicht gebraucht, ist

Sorry, das war falsch von mir erkannt.

[...]
> --------------------------------zip---------------------------------
> -- [vgl. Pygmy]


> FOR ( - h) ( u -) starts a FOR ... NEXT loop. Body executes
> u times, not u+1 times as in some Forths.
> NEXT ( h -) ( -) ends a FOR ... NEXT loop.
> --------------------------------zap---------------------------------

Da sind ja auch zwei Stackbilder, man muß ja nur hinschauen ;-)

> [do...loop]
>> Habe schon oft darüber nachgedacht, ob es nicht sinnvoller wäre den
>> Index woanders hin zu legen, aber wohin? Vielleicht wäre ja ein
>> extra LOOP-Stack sinnvoll? Dann könnte sich z.B. ein Scheduler
>> darauf verlassen, daß das, was oben auf dem Returnstack liegt
>> grundsätzlich eine Adresse sein muß...

> Oder eben for...next nehmen.

Die Überlegung war mit einer Schleifenkonstruktion auf den Datenstack
auszuweichen. Davon abgesehen ist das Einrichten eines weiteren Stacks
wohl nichts besonders schwieriges oder sehr seltenes.

--
Salut
_)oachim

Coos Haak

unread,
Jul 4, 2005, 4:00:23 PM7/4/05
to
Op Mon, 04 Jul 2005 19:05:34 +0100 schreef Torsten Kildal:

> Marc Olschok <sa7...@l1-hrz.uni-duisburg.de> schrieb:
>
> [for...next]
>>3 2 1
>>
>>Also scheint der Laufindex auf dem Return-Stack gehalten zu werden.
>>
>>Hingegen wird bei repeat...until der Laufindex auf dem Datenstack
>>gehalten wird und beim verlassen der Schleife entfernt wird:
>
> Da gibts jetzt auch einen Laufindex?! Ich seh schon, ich muß mir
> diesen ANS-Standard bei Gelegenheit mal ansehen...
> [miraltvorkommend] :-/
>
> Bisher kannte ich REPEAT nur am *Ende* einer BEGIN-WHILE-REPEAT
> Struktur. Die Analogie REPEAT-UNTIL bei z.B. Pascal ist ja ebenfalls
> nur durch ein Flag gesteuert. Braucht es wirklich neben DO-LOOP
> noch eine weitere unbedingte Schleife?
>
> Gruß Torsten.

Die Laufindex von DO-LOOP, der mit R (mit ANS ist das I) bedeutet wird,
steht auf den Return-Stack. Vielliecht ist das auch so mit FOR-NEXT.
(I habe die neueste Version davon noch nicht).
Das Unterschied zwischen beide ist das FOR-NEXT stets mit Eins zurückzählt,
weil ein DO-LOOP mit Eins nach oben lauft. Mit +LOOP ist das noch um zu
wandeln mit grossere Schritte, positiv order negativ.
Das Implementieren von DO-LOOP ist ziemlich aufwändiger als FOR-NEXT und
bei RF wird das wohl eine Rolle gespield haben.

Coos
--
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

Joachim Merkel

unread,
Jul 5, 2005, 2:32:00 AM7/5/05
to
Joachim Merkel (jm...@gmx.de) schreibt:

[for...next]


> Der Unterschied zu do ... loop ist dann wohl nur der, daß der Index
> nicht in einer Laufvariablen gehalten wird, sondern direkt auf dem
> Returnstack liegt.

Sorry again, ``I'' ist keine Variable sondern legt eine Kopie
auf den Datenstack. Zumindest ist der Unterschied, daß
do...loop der, nach dem ANS-Standard zwei verschachtelte loops
unterstützt daher gibts ``I'' und ``J''(vorher im F-83-Standard
waren es sogar drei, also noch ``K'').

--
Salut
_)oachim

Joachim Merkel

unread,
Jul 5, 2005, 2:33:00 AM7/5/05
to
Coos Haak (chf...@hccnet.nl) schreibt:

> Die Laufindex von DO-LOOP, der mit R (mit ANS ist das I) bedeutet
> wird, steht auf den Return-Stack. Vielliecht ist das auch so mit
> FOR-NEXT. (I habe die neueste Version davon noch nicht).

Du hast Recht, ``I'' ist ein Wort, das eine Kopie des TORS auf den
TOS legt.
Ich hatte ``I'' erst für eine Variable gehalten, weil ich unter
CHForth folgendes ausprobiert hatte:

FORTH> : hi 5 0 do i . loop ; ok
FORTH> hi 0 1 2 3 4 ok
FORTH> forget hi ok
FORTH> : hi 5 0 do r@ . loop ; ok
FORTH> hi 32763 32764 32765 32766 32767 ok
FORTH>
Das schienen mir erst Adressen zu sein, ist aber nur eine andere
Zahlendarstellung?

Unter RF bekommt man den Laufindex wie von Marco erwähnt
in: <3it208F...@news.dfncis.de>
--------------------------------zip-----------------------------------


: lauf for r . next ; 3 lauf

bringt mir die Ausgabe:

3 2 1
--------------------------------zap-----------------------------------

> Das Unterschied zwischen beide ist das FOR-NEXT stets mit Eins
> zurückzählt, weil ein DO-LOOP mit Eins nach oben lauft. Mit +LOOP
> ist das noch um zu wandeln mit grossere Schritte, positiv order
> negativ. Das Implementieren von DO-LOOP ist ziemlich aufwändiger als
> FOR-NEXT und bei RF wird das wohl eine Rolle gespield haben.

Bei RF kommen ``until'' und ``next'' wieder elegant aus derselben
Routine, nur bei ``next'' wird der Index vom Returnstack auf
den Datenstack geholt und bei ``for'' vom Datenstack auf den
Returnstack verschoben.
--------------------------------zip-----------------------------------
: repeat here ; : again compile ;
: next m: r> : until $48 1, $c009 2, $850f 2, here - 4 - , $ad 1, ;
: for here m: >r ;
--------------------------------zap-----------------------------------

--
Salut
_)oachim

Marc Olschok

unread,
Jul 5, 2005, 11:13:39 AM7/5/05
to
Torsten Kildal <kil...@gmx.de> wrote:
> Marc Olschok <sa7...@l1-hrz.uni-duisburg.de> schrieb:
>
> [for...next]
>>3 2 1
>>
>>Also scheint der Laufindex auf dem Return-Stack gehalten zu werden.
>>
>>Hingegen wird bei repeat...until der Laufindex auf dem Datenstack
>>gehalten wird und beim verlassen der Schleife entfernt wird:
>
> Da gibts jetzt auch einen Laufindex?! Ich seh schon, ich muß mir
> diesen ANS-Standard bei Gelegenheit mal ansehen...
> [miraltvorkommend] :-/

Nicht notwendig.
Die Bezeichungen 'repeat' und 'until' in Retroforth haben praktisch
nichts mit den gleichnamigen Bezeichungen in ANS Forth oder früheren
Standards zu tun
Das ist ein leider ein wenig verwirrend. (man gewöhnt sich daran :-)

>
> Bisher kannte ich REPEAT nur am *Ende* einer BEGIN-WHILE-REPEAT
> Struktur. Die Analogie REPEAT-UNTIL bei z.B. Pascal ist ja ebenfalls
> nur durch ein Flag gesteuert. Braucht es wirklich neben DO-LOOP
> noch eine weitere unbedingte Schleife?

In Retroforth gibt es keine do...loop Schleife. (*)

In Retroforth zählen sowohl repeat...until als auch for...next
immer nur bis 0 herunter, sie sind also nicht so allgemein wie
die do...loop.

Dahinter steckt wohl die Erkenntnis, dass man oft nur an der Anzahl
der Schleifendurchläufe interessiert ist, so dass man statt
n 0 do ... loop auch gleich n for ... next nehmen kann.

Wie Joachim früher schon bemerkte, bemühen sich die Entwickler
von Retroforth um Sparsamkeit und Einfachheit.


(*) es kann sein, dass irgendwo do...loop in optionalen Dateien
implementiert wird, in früheren Versionen habe ich das mal gesehen.

P.S.: um noch einmal das Subject einzubringen, ich habe zu Hause
gleich wieder die Blockgröße auf 1024b ungestellt und verwende 16 Zeilen.

Marc

Torsten Kildal

unread,
Jul 5, 2005, 12:46:49 AM7/5/05
to
Coos Haak <chf...@hccnet.nl> schrieb:

>Die Laufindex von DO-LOOP, der mit R (mit ANS ist das I) bedeutet wird,

Da hat man auch schon bei F83 besser I statt R genommen. Schließlich
war es ja nicht vorgeschrieben, daß der Laufindex auf dem Returnstack
liegen müßte, aber meist lag er dort.

>steht auf den Return-Stack. Vielleicht ist das auch so mit FOR-NEXT.

Also dieses FOR-NEXT bekommt nur *einen* Parameter, richtig?
Wird es denn dann unabhängig vom Wert diese Parameter mindestens
einmal ausgeführt, wie es auch bei DO-LOOP ist, oder testet es schon
bei dem FOR den Wert?

>Das Implementieren von DO-LOOP ist ziemlich aufwändiger als FOR-NEXT und

Nee, ist eigentlich relativ einfach, hab ich selber schon paar mal gemacht.

Gruß Torsten

--
Der Fehler in einem mathematischen Beweis steckt immer an der mit
"offensichtlich" markierten Stelle. (Ingrid Voigt de.sci.mathematik)

Coos Haak

unread,
Jul 5, 2005, 12:00:38 PM7/5/05
to
Op 05 Jul 2005 08:33:00 +0200 schreef Joachim Merkel:

> Coos Haak (chf...@hccnet.nl) schreibt:
>
>> Die Laufindex von DO-LOOP, der mit R (mit ANS ist das I) bedeutet
>> wird, steht auf den Return-Stack. Vielliecht ist das auch so mit
>> FOR-NEXT. (I habe die neueste Version davon noch nicht).
>
> Du hast Recht, ``I'' ist ein Wort, das eine Kopie des TORS auf den
> TOS legt.
> Ich hatte ``I'' erst für eine Variable gehalten, weil ich unter
> CHForth folgendes ausprobiert hatte:
>
> FORTH> : hi 5 0 do i . loop ; ok
> FORTH> hi 0 1 2 3 4 ok
> FORTH> forget hi ok
> FORTH> : hi 5 0 do r@ . loop ; ok
> FORTH> hi 32763 32764 32765 32766 32767 ok
> FORTH>
> Das schienen mir erst Adressen zu sein, ist aber nur eine andere
> Zahlendarstellung?

Bei viel 16 bit Forths sind da zwei Zahlen auf der Returnstack in DO-LOOP.
Versuch mal folgendes:
: hi 5 -4 do cr i . r@ . loop ;
I addiert die beiden, zumindenst bei mein CHForth. R@ tut das nicht, FOR
NEXT wird nur einen Zahler haben.

Joachim Merkel

unread,
Jul 5, 2005, 5:05:00 PM7/5/05
to
Coos Haak (chf...@hccnet.nl) schreibt:

> Bei viel 16 bit Forths sind da zwei Zahlen auf der Returnstack in
> DO-LOOP. Versuch mal folgendes:
> : hi 5 -4 do cr i . r@ . loop ;
> I addiert die beiden, zumindenst bei mein CHForth.

Aha, Danke.

--------------------------------zip-----------------------------------
: ddup dup dup ; ok
: hi cr 5 -4 do i . r> ddup . r> ddup . 2 roll + . cr >r >r loop ; ok
hi
-4 32759 -32763 -4
-3 32760 -32763 -3
-2 32761 -32763 -2
-1 32762 -32763 -1
0 32763 -32763 0
1 32764 -32763 1
2 32765 -32763 2
3 32766 -32763 3
4 32767 -32763 4
ok
--------------------------------zap-----------------------------------

Das ist auch bei TurboForth so.

> FOR NEXT wird nur einen Zahler haben.

Ja, sieht für mich so aus.

--
Salut
_)oachim

Joachim Merkel

unread,
Jul 12, 2005, 4:28:00 PM7/12/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

> P.S.: um noch einmal das Subject einzubringen, ich habe zu Hause
> gleich wieder die Blockgröße auf 1024b ungestellt und verwende 16
> Zeilen.

Compiliert der Source der 8-Zeilen-Blöcke dann noch?

Seit neuestem liegt der RF v.8.0-Developer-Version in der lib
ein Programm namens FOeRTHchen bei. Weiß jemand was das ist?
Ich bin daraus nicht schlau geworden.

--
Salut
_)oachim

Marc Olschok

unread,
Jul 13, 2005, 10:01:35 AM7/13/05
to
Joachim Merkel <jm...@gmx.de> wrote:
> Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:
>
>> P.S.: um noch einmal das Subject einzubringen, ich habe zu Hause
>> gleich wieder die Blockgröße auf 1024b ungestellt und verwende 16
>> Zeilen.
>
> Compiliert der Source der 8-Zeilen-Blöcke dann noch?

Im Prinzip ja.
Das einzige mögliche Hindernis besteht darin, dass Kommentartexte
vielleicht nicht mit | versehen sind. Dann kann man ja einfach einen
halben 16-Zeilen Block laden.

In der betreffenden Datei in source/blocks/red sind mehrere
Versionen von evaluate enthalten.

Meine modifizierte Version von eb ist

: eb (block) 1024 eval ;

aber es spricht nichts gegen zusätzliche

: eb1 (block) 512 eval ;

: eb2 (block) 512 + 512 eval ;

In source/blocks/red sind außerdem noch el und e vorhanden:

: el (line) 64 eval ;
: e 0 el 1 el 2 el 3 el 4 el 5 el 6 el 7 el ;

damit kann man sich auch noch individuell sein eval schneidern.

Meine Änderungen sind übrigens nicht besonders tiefschürfend:
es genügte

in source/blocks/red die Änderung von 512 nach 1024
in den Definitionen von (block), eb, x und new

in source/blocks/red-view die Änderung von 8 nach 16
in der Definition von .rows

Marc

Joachim Merkel

unread,
Jul 13, 2005, 11:38:00 AM7/13/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

[16-Zeilen Block in RF compilieren]

> Meine modifizierte Version von eb ist
> : eb (block) 1024 eval ;

Ist der alte, unveränderte Eintrag. Wieso ist der eigentlich
bereits auf 1024 Zeichen, waren dann doch 2 Blöcke?

[...]
Danke für Deine Erläuterungen zu Evalution.

> Meine Änderungen sind übrigens nicht besonders tiefschürfend:

[...]

Dto.
Allerdings war die status-Meldung noch 8 Zeilen tiefer zu legen.

--
Salut
_)oachim

Joachim Merkel

unread,
Jul 13, 2005, 6:41:00 PM7/13/05
to
Joachim Merkel (jm...@gmx.de) schreibt:

> Coos Haak (chf...@hccnet.nl) schreibt:

>> I addiert die beiden, zumindenst bei mein CHForth.

Eigentlich wird subtrahiert, denn ...

[...]


> : ddup dup dup ; ok
> : hi cr 5 -4 do i . r> ddup . r> ddup . 2 roll + . cr >r >r loop ;

> hi
> -4 32759 -32763 -4
> -3 32760 -32763 -3
> -2 32761 -32763 -2
> -1 32762 -32763 -1
> 0 32763 -32763 0
> 1 32764 -32763 1
> 2 32765 -32763 2
> 3 32766 -32763 3
> 4 32767 -32763 4

... durch die Zweierkomplement-Zahlendarstellung wird eine
Subtraktion auf eine Addition zurückgeführt. Der Vorteil liegt
in der maschinellen Schnelligkeit und dem Auswerten des
Overflow-Flags zur Bestimmung des Überschreitens der Indexgrenze,
sagt mein "weiper Zech". Das Overflowflag würde dann wohl bei
16-Bit-Arithmetik beim Erreichen von 32768 = 2^15 gesetzt werden?
Ich stimme C.H. aber sofort zu, daß die Implementation von
do...loop nicht so einfach ist. ;-)

Immerhin sind beliebig geschachtelte Schleifen-Konstruktionen
denkbar, was auch ein Grund war, daß for...next nicht in den
ANS-Standard aufgenommen worden sein soll, weil es keiner blickte,
ob das sicher wäre, wie ich in einem Thread in comp.lang.forth von
2003 nachgelesen habe. Da konnte sich ein Alt-Forther nicht
vorstellen, daß for...next in den gesammelten Schleifenkonstruktionen
von gforth gefahrlos aufgerufen werden kann, was aber sofort widerlegt
wurde ;-)
Aber wer kommt nur auf solche Ideen, etwa in while...repeat ein
do...loop und darin for...next aufzurufen? Möglicherweise
versucht man damit Cache-Probleme zu vermeiden, also branch
prediction zu erhalten, aber ich möchte sowas nicht testen.

--
Salut
_)oachim

Marc Olschok

unread,
Jul 14, 2005, 8:25:17 AM7/14/05
to
Joachim Merkel <jm...@gmx.de> wrote:
> Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:
>
> [16-Zeilen Block in RF compilieren]
>
>> Meine modifizierte Version von eb ist
>> : eb (block) 1024 eval ;
>
> Ist der alte, unveränderte Eintrag. Wieso ist der eigentlich
> bereits auf 1024 Zeichen, waren dann doch 2 Blöcke?

Im Ernst? Ich habe hier nur noch meine Hausversion und dacht,
es hätte vorher 512 gestanden. Dann ist wohl 'eb' ein Relikt und
es ist 'e' das aktuell Standardevaluate.

Die Versionen bis 7 hatten auch stets Blockgröße 1024.
Allerdings hatte CC für Version 8 den Blockeditor
noch einmal überarbeitet.

Könnte die Blockgröße 512 irgendeinen Vorteil für die angepeilte
DOS-Version bringen, wenn man z.B. mit Disketten arbeitet?

Marc

Joachim Merkel

unread,
Jul 14, 2005, 10:28:00 AM7/14/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

[eb]
>> [...] Wieso ist der eigentlich


>> bereits auf 1024 Zeichen, waren dann doch 2 Blöcke?

> Im Ernst? Ich habe hier nur noch meine Hausversion und dacht,
> es hätte vorher 512 gestanden. Dann ist wohl 'eb' ein Relikt und
> es ist 'e' das aktuell Standardevaluate.

``eb'' war vorher ``e'', hat man anscheinend nur kopiert und dabei
zudem ``block'' in ``(block)'' geändert.

> Die Versionen bis 7 hatten auch stets Blockgröße 1024.
> Allerdings hatte CC für Version 8 den Blockeditor
> noch einmal überarbeitet.

Mit ``edit'' habe ich mich erst ab v8.0beta befasst. Stimmt, ein
Screen hatte vorher 1024 Zeichen -- war mir bisher nicht aufgefallen,
weil der Editor nicht integriert war, hatte ich damit garnichts
angefangen.

> Könnte die Blockgröße 512 irgendeinen Vorteil für die angepeilte
> DOS-Version bringen, wenn man z.B. mit Disketten arbeitet?

Bringt vielleicht etwas schnellere Lese/Schreibzyklen, wenn
Screens einzeln nachgeladen oder gesichert werden können.
Ich vermute, es geht eigentlich nur um mehr Platz unterhalb des
Editors, weil der Editor immer präsent bleibt, an sich ja wohl
keine schlechte Idee, zusätzlich zu der (besseren) Integration.

--
Salut
_)oachim

Joachim Merkel

unread,
Sep 11, 2005, 7:54:00 PM9/11/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schrieb am 30.6.05:

> Jetzt warte ich nur noch darauf, dass sich bei /mod irgendwann
> einmal der "richtige" Stackeffekt ( n n' --- rem quot ) einstellt.

Jetzt hat's geklappt, außerdem sind die Farbspielereien wieder
aus dem core raus und vorher wurden Schleifen auch wieder
entschlackt, until gibt's nicht mehr. Libreto ist anscheinend
ein Anfang für C-Library-Aufrufe.

The spirit of retroforth :=)
--------------------------------zip-----------------------------------
* 9-11-2005 added a new word "help" to see a glossary in retro
* 9-11-2005 added new port: libretro
* 9-10-2005 initial version of colorlib
* 9-10-2005 added :: various cleanups, better performance
* 9-6-2005 internal cleanups and added 'boot'
* 9-5-2005 updated the notes in the top level
* 9-4-2005 changed "next" to use the improvements from
Alexy Abramov (bugfix on negative or 0 as the initial
counter)
* 9-4-2005 removed the colors from the core, changed /mod to
follow the standard way of doing things
--------------------------------zap-----------------------------------
aus Changes.Txt.

--
Salut
_)oachim

Marc Olschok

unread,
Sep 13, 2005, 11:40:18 AM9/13/05
to
Joachim Merkel <jm-...@gmx.de> wrote:
> Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schrieb am 30.6.05:
>
>> Jetzt warte ich nur noch darauf, dass sich bei /mod irgendwann
>> einmal der "richtige" Stackeffekt ( n n' --- rem quot ) einstellt.
>
> Jetzt hat's geklappt, außerdem sind die Farbspielereien wieder
> aus dem core raus und vorher wurden Schleifen auch wieder
> entschlackt, until gibt's nicht mehr. Libreto ist anscheinend
> ein Anfang für C-Library-Aufrufe.

Das mit /mod ist ja schon einmal sehr gut (ich hatte das in
meiner Privatversion mit einem zusätzlichen Byte gemacht).

Aber was ist denn eigentlich als Ersatz für until gedacht?
Die for...next Schleife nutze ich zwar häufiger, aber ab und
zu will man ja doch das Gegenstück mit dem Laufwert auf dem
Datenstack per repeat...until.


viele Grüße, Marc

Joachim Merkel

unread,
Sep 13, 2005, 7:47:00 PM9/13/05
to
Marc Olschok (sa7...@l1-hrz.uni-duisburg.de) schreibt:

> Aber was ist denn eigentlich als Ersatz für until gedacht?
> Die for...next Schleife nutze ich zwar häufiger, aber ab und
> zu will man ja doch das Gegenstück mit dem Laufwert auf dem
> Datenstack per repeat...until.

Muß man wieder 0; und einen Dekrement-Befehl wieder in die Schleife
einbauen. Was anderes war until ja auch nicht, nur wurde der TOS
vor dem Vergleich dekrementiert, was bei 0 auf dem Datenstack eine
Endlosschleife produzierte, darum hat man es vermutlich wieder
ausgebaut.
BTW, es gibt auch ein Wiki, ich habe mich mal angemeldet.

--
Salut
_)oachim

Reply all
Reply to author
Forward
0 new messages