Discussion sur le langage Forth

[yo_fr]

Pour faire une réponse simple, fneck :
=> Du code source : oui, à condition d'utiliser le même standard de Forth et aucune instruction dédié à la machine (*)
=> Des mots compilé : surement pas : rien ne correspondra au niveau des @...


(*) : Sur chaque machine (le Jupiter ace ne déroge pas à la règle) il y a des instructions particulière pour autoriser l'utilisation complète des capacités de la machine : par exemple sur le Jupiter Ace on a droit à plot, beep, inkey... pour ne citer qu'eux. Alors le Forth ne peux plus être considéré comme standard

Il existe plusieurs versions du standard Forth : Le 79, le 83 puis le FIG ... et donc pleins de variantes avec des mots supplémentaires pour exploiter au mieux les machines pour lesquels chacun ont été dédiés.

Pour rejoindre __sam__ , je tiens à préciser que le problème est exactement le même que sur toutes les autres machines qui bootent en basic
=> Existe-t-il un "stand-alone" des programmes basic
=> Tous les basic sont-ils compatibles entre eux
=> Sur une machine ne possédant pas le basic dans les rom et ou il faut le charger (via des cassettes ou des cartouches), comment lancer un programme utilisateur Basic sans le langage préalablement chargé
=> L'utilisateur doit-il connaitre la syntaxe de chargement (<load>, <cload>, <load # >, <load ,0> ou encore <load #"nom du programme" > ...)
=> Dans le cas d'une machine avec le Basic en Rom (MSX, par exemple) : Le Basic est-il à considérer comme un système d'exploitation

On vois bien que la problématique est exactement la même et les réponses ne différent pas, que l'on parle du Forth ou du Basic

[Markerror]

Vu que ça cause dur Forth ici, je me suis dit que cela pourrait intéresser peut-être quelqu'un .

Sur LBC, une personne vend entre autre des bouquins sur le Forth à un prix raisonnable (5 euros) :

http://www.leboncoin.fr/livres/480715952.htm?ca=4_s

et

http://www.leboncoin.fr/livres/480707040.htm?ca=7_s

Voili voulou...

[Dominique]

Pour répondre à la question de @fneck : non il ne peut pas.

D'abord ceux qui ont conçu le Forth du Jupiter Ace ont pris quelques libertées avec le Forth et ont oublié certains mots (je pense à <BUILDS DOES> par exemple) et puis comme on le dit ici dans ce fil l'architecture de la machine - adresse écran, ports de lecture clavier etc... - ainsi que le langage machine font qu'un code compilation d'une machine ne sera jamais compatible avec un autre.


Moore avait très certainement compris ça avant tout le monde. C'est pour cette raison que la portabilité se fait au niveau du langage.
DUP sera une procédure FORTH qui doublera le sommet de la pile sur Jupiter Ace, sur le MO5 le Z81 ou le plus gros des ordinateurs, pour autant qu'il ait traduit la primitive DUP dans son langage machine d'origine.

[__sam__]

Au fait, saviez-vous qu'il y a un interpréteur FORTH planqué dans le jeu MINECRAFT? (regarder à partir de la minute 6)

@Xavier: ca ne te dit pas de diffuser tes programmes FORTH dans la communauté MINECRAFT

Si vous regardez jusqu'à la minute 14, vous verrez que l'ordi virtuel a un port d'entrées/sorties programmable et qu'on peut faire clignoter les blocs qui lui sont connectés.

Franchement, je trouve ca très cool.

[Xavier31]

Ce que cette discussion m'inspire (et que j'avais essayé de faire passer le long de ce fil, mais je suis peut-être allé trop vite) est qu'un exécutable 100% autonome n'existe pas. Il s'appuie toujours sur un environnement d'exécution. L'exemple du turbo pascal utilise implicitement le fait que l'environnement d'exécution est CP/M. Sur une même machine sans le CP/M de démarré, l’exécutable ne marche pas. Il n'est d'ailleurs pas vu comme quelque chose d'executable.

Quand on parle d'exécutable autonome, on veut simplement dire qu'il peut s'exécuter sur l'ordinateur sans que le langage qui l'a crée soit présent. Afin de le faire tourner sur n'importe quel ordinateur dont l'utilisateur n'a pas acheté le langage.

Si on veut aller dans ton sens, plus rien n'est autonome : L'OS CP/M n'est pas autonome si on ne branche pas le lecteur de disquette, et l'ordinateur n'est pas autonome sans electricité. Le programmeur non plus n'est pas autonome sans air à respirer.
Bref, on fonctionne tous dans un environnement évidement et rien dans l'univers n'est 100% autonome. Notre planète n'est pas autonome, puisqu'elle dépend du soleil, qui lui dépend de la galaxie, qui à son tour dépend de l'Univers,etc. etc...

L'outil FORTH de loriciel? OUI L'outil de loriciel n'est rien d'autre que système capable d'exploiter les programmes FORTH. Lidée que j'essaye de faire apparaitre est qu'outre le fait d'être un langage, FORTH est aussi un système d'exploitation. Il tient le rôle du CP/M faisant tourner les programmes compilés pour lui. FORTH est un OS génial.

Oh oh oh!! je ne peux pas te laisser dire ça!
NON FORTH n'est pas un système d'exploitation. C'est un simple langage de programmation. Qui fait tourner des programmes point.
Il ne gère en aucun cas le hardware de la machine, le processeur, l'écran, les interruptions, le bios, la cassette ou la disquette,
bref, TOUT ce que fait un système d'exploitation. FORTH n'est qu'un langage qui tourne dans un système d'exploitation.

Plein d'autres langages sont géniaux, mais ne sont pas des OS pour autant. Turbo-Pascal est un IDE/compilateur,
certes le premier vrai IDE de l'histoire, mais un IDE rien de plus. Pas un OS non plus.

Je te signale pour info que tout langage de programmation, QUEL QU'IL SOIT, doit à un moment TRADUIRE
ses instructions en Langage Machine pour que le processeur les exécute.

A CE MOMENT LA, le langage qu'il est N'EXISTE PLUS : tout est réduit est transformé en langage machine exécuté par le processeur, au sein de l'OS. Voilà ce qu'est un système d'exploitation. Et voilà pourquoi FORTH ne sera JAMAIS un OS :
A un moment, il doit lui aussi lâcher sa purée : à ce moment là, il n'existe plus. Le processeur exécute ses codes-machine
et communique alors avec l'OS, pas avec FORTH.

... alors il n'y a plus de problème avec la notion d’exécutable natif manquant en FORTH... Cela explique probablement pourquoi le concepteur n'a pas eu besoin de créer une fonction d'export vers un autre système. FORTH se suffit à lui même.

Eh bien non, car il y a en bout de chaine ce que l'on appelle des Utilisateurs, dont je fais partie,
et qui sont bien embêtés que leur programme source ne puisse pas être sauvegardé en binaire exécutable,
qu'ils auraient pu distribuer facilement. Sans avoir à demander à leur amis de charger FORTH pour y faire tourner
leur programme, à l'aide de commandes Forth dont ils n'ont jamais entendu parler pour compiler/exécuter le source.

Alors qu'un simple RUN "" (sur une machine avec BASIC en ROM) ou taper le nom du programme sous CP/M aurait suffi.

[Xavier31]

Vu que ça cause dur Forth ici, je me suis dit que cela pourrait intéresser peut-être quelqu'un ..

Merci Markerror,
il n'y a pas beaucoup de livres sur FORTH de disponibles, donc c'est toujours bien à se "mettre sous la dent",
si j'ose dire.

[__sam__]

NON FORTH n'est pas un système d'exploitation. C'est un simple langage de programmation. Qui fait tourner des programmes point.

Un système d'exploitation (de programmes) est justement fait pour faire tourner.....des programmes.

Il ne gère en aucun cas le hardware de la machine, le processeur, l'écran, les interruptions, le bios, la cassette ou la disquette,
bref, TOUT ce que fait un système d'exploitation.

FORTH fait tout cela. Regarde le FORTH dans le jeu minecraft pour voir un exemple amusant d'interaction avec le matériel.

FORTH n'est qu'un langage qui tourne dans un système d'exploitation.

Pourtant FORTH est plus qu'un langage (une syntaxe). C'est un système (on parle de système forth) qui a sa propre ABI, sa propre notion de logiciel/tache exécutable, sa propre façon de lui passer des paramètres, et qui naturellement fournit les services dont les programmes FORTH ont besoin (lecture/écriture écran, accès aux K7, D7, port série, imprimantes, etc).

Quel serait donc le système d'exploitation sur lequel s'appuie le FORTH-79 de S.E.F.I sur TO7? La rom moniteur ? Non ca c'est un BIOS. Le moniteur n'a pas de notion de logiciel exécutable. Il n'est pas utilisable en l'état. Il faut lui adjoindre une cartouche supplémentaire, cartouche qui structure les primitives du BIOS en opérations de plus haut niveau: saisir du texte au clavier (et pas lire un seul caractère), structurer des octets en blocs physiques pour lire/écrire des fichiers sur K7, structurer des zones mémoire pour y loger des programmes, leur pile et leurs données. Cette cartouche supplémentaire peut être une cartouche basic, logo, ou même FORTH par exemple:

Tu avouera que l'apparence même du forth fait fichtrement penser à ce à quoi un OS typique ressemble du point de vue utilisateur: un écran avec un prompt pour que l'utilisateur saisisse des commandes.

Tu pourrais me dire que sur le MO5 le FORTH n'est pas une cartouche mais un programme lancé depuis le basic. Oui, mais le basic n'est utilisé que transitoirement. Il sert au chargement et par la suite il disparait. Ainsi, une fois complètement chargé en mémoire, FORTH fonctionne tout seul n'utilise plus le basic. Il aurait certainement pu être livré sous forme de cartouche MEMO5 si le producteur l'avait voulu mais ca na pas le même cout.

Oui je sais, c'est pas évident de réaliser que le langage peut être aussi un OS, mais je crois que le FORTH Thomson entre dans cette catégorie.

[Daniel]

Je ne comprends pas bien cette incompréhension entre Xavier et Sam.
Si l'objectif est de créer, sur MO5, un programme binaire exécutable sur un autre MO5, ce n'est pas difficile.
Si l'objectif est de créer, sur MO5, un programme binaire exécutable sur n'importe quelle machine inconnue, c'est impossible.
Je ne vois pas de motif de désaccord sur ces points.

Après, on peut pinailler sur la licence : faut-il ou pas la licence Loriciels pour exécuter le programme binaire ?
Ce problème n'est pas particulièrement préoccupant pour l'instant. Si un jour les auteurs du Forth MO5 se manifestent, on pourra en discuter, et nous trouverons certainement un accord pour sa diffusion sur le site dcmoto et la production de binaires compilés.

[Dominique]

je pense que _sam_ a parfaitement raison : Forth a toujours été considéré un Operating System comme disent les Américains.
L'interface parfaite entre l'utilisateur (le Prompt pour executer), le Hard (il gère les ports d'entrée et de sortie ) et le Soft (il permet d'écrire et de gérer des propres programmes.)

@Daniel je serais surpris que Loriciel puisse faire valoir des droits de licence sur le Forth qui a été cédé à la communauté comme open source par son propre créateur.

D'ailleurs ils reprennent beaucoup de l'implémentation FIG-FORTH du 6809 (Noter l'expression : This public domain publication)

http://www.forth.org/fig-forth/fig-forth_6809.pdf

"ASSEMBLY SOURCE LISTING RELEASE 1 WITH COMPLLER SECURITY AND VARIABLE LENGTH NAMES JUNE 1980
This public domain publication is provided through the courtesy of the FORTH Interest Group. Furthest distribution rnust include this notice. "

[Dominique]

Je profite du fil de message pour demander l'adresse d'un bon assembler pour le 6809 semblable au TASM que j'utilise habituellement pour le Z80.
Ce que j'ai pu trouver ( as6809 - ASM6809) ou ne marche pas ou c'est moi qui commet une erreur.
Ayant la source sur le bloc note, j'aimerai qu'il assemble les fichier .asm
Merci

[Daniel]

J'utilise A09 : http://www.hermannseib.com/english/opensource.htm
Il crée un fichier binaire importable directement dans dcmoto.

[__sam__]

[PUB] Sinon il y a le c6809 de Préhisto. Je l'utilise tout le temps pour mes productions.

C'est un macro-assembleur qui produit:

• un fichier "BIN" compatible avec le basic.
• des fichiers ASM recompilables sur vrai thomson
• un fichier *.lst contenant le listing + les codes hexa et le comptage de cycles.

Le gros truc sympa est qu'il en existe une version avec la même syntaxe sous forme de cartouche MEMO7/MEMO5 pour thomson: http://dcmoto.free.fr/programmes/assemb ... index.html.

[Dominique]

Merci à vous deux.

@Daniel : j'ai téléchargé, je teste demain.
.

[Dominique]

Le a09 est tout à fait ce qu'il me fallait.
Mais j'ai eu beau regarder, je n'arrive pas à faire codifier les
JMP /$B6
STB /$4C
CMPA /$4C

La réponse doit se trouver quelque part, mais où ?

[__sam__]

JMP /$B6
STB /$4C
CMPA /$4C

Ces instruction ont toutes la particularité d'être en mode direct, c'est à dire que la partie haute de l'adresse se trouve dans le registre DP.

Dans les assembleurs que je pratique (et cela doit être général) cela marche ainsi: il faut d'abord dire à l'assembleur quelle est la valeur de DP présumée dans le code. Cela se fait avec l'instruction SETDP, par exemple SETDP $45 donnera l'indication à l'assembleur que DP vaut $45 dans les lignes qui suivent (jusqu'au prochain SETDP). Ensuite dans le code l'assembleur optimisera directement les accès étendus (i.e. avec l'adresse complète) en accès direct: JMP $45B6 sera compilé en JMP /$B6.

Cette optimisation est souvent la bienvenue, mais parfois on ne souhaite pas l'avoir car cela décale les adresses. Alors, pour s'assurer que c'est bien le mode étendu qui sera produit, il faut écrire JMP >$45B6 (avec un ">") auquel cas l'assembleur n'optimisera pas et produira une instruction en mode étendu avec une adresse sur 2 octets.

On peut aussi forcer le passage en mode direct sans utiliser de SETDP non pas en écrivant /$B6, mais en écrivant <$B6 (avec un "<"). Tu devrais essayer de voir ce que donne le compilateur avec JMP <$B6 au lieu de JMP /$B6.