Discussion :

[Forthman]

Bonjour,

Comme mon pseudo le laisse entendre, je programme en Forth.

J'ai débuté en informatique avec ce Langage sur Hecto HRX,
et 10 ans plus tard, j'ai enfin trouvé une distribution sur PC
Ce Forth est le "Turbo FORTH" de la société MP7, avec qui j'avais de bons
contacts, et qui lors de l'abandon de Turbo FORTH, m'en a généreusement
donné les droits

Donc... cela fait plus de 16 ans que je programme avec Turbo FORTH sous DOS,
ce langage me donne totale satisfaction (j'ai bien essayé d'autres langages mais
ça passe pas ), pour faire des petites applications "embarquées"
(dernièrement pilotage d'une table d'oxycoupage ).
J'ai aussi fait quelques petits programmes de gestion commerciale, qui
pouvaient encore fonctionner sous XP grâce a des utilitaires comme
PRINTFIL (qui permet d'imprimer automatiquement un fichier texte),
mais je devais/dois faire attention aux machines que j'utilise car toutes
les cartes graphiques ne permettent pas l'utilisation du SVGA sous XP

(merci à ceux qui continuent de lire, car c'est super long )

Enfin, le but de mon appel...
Je ne connais rien a la programmation sous Win$ mais j'aimerai pouvoir
réécrire un Turbo FORTH pour windows
Ce dont j'ai besoin :
- afficher mes applications en plein écran dans une résolution SVGA (directX ?)
- et un affichage sous forme de fenêtre ultra leger (genre bloc-notes)
- Pouvoir imprimer du texte et des graphiques
- a la limite emmètre des avertissements sonores

Je connais le fonctionnement de l'interpréteur Forth sur le bout des doigts,
donc pas de problème de ce coté, mais c'est l'environnement Win$ qui me gène.

Il existe bien un Forth pour environnement Windows : WIN32FORTH
Mais ce dernier est un monstre

En résumé, je recherche de l'aide pour la partie périphérique (en fait, le noyau
Forth ne fait que quelques Ko )

merci a ceux qui ont tout lu

a+ Francois

[Rémi Coquet]

Désolé de ne pas bien saisir le fond du problème que tu exprimes dans ton post, surtout sur cette partie du site. Vu que personne ne t'a encore répondu, j'imagine que je ne suis donc pas seul dans ce cas

Donc, pour sortir des propos abscons : Tu veux utiliser l'assembleur pour te fabriquer un automate de compilation qui utilise un langage que tu connais/maîtrise bien, y inclure la gestion des API et des mécanismes modernes utilisés sous Xp, Vista, Seven..? J'ai faux ou j'ai bon m'sieur?

[Forthman]

Bonsoir Rémi,

En fait le Forth ressemble sur certains points à Java (machine virtuelle)

Le Langage Turbo Forth de la société MP7 n'a en fait rien de "Turbo" si
ce n'est que c'était l'époque du "Turbo Pascal" , "Turbo Basic" ...etc...
et que pour faire bien (et essayer de ventre) il a été nommé ainsi

Le Forth est en majorité écrit ... en Forth, et il n'y a qu'un tout petit noyau
écrit en assembleur.

par exemple, le mot qui sert à afficher du texte est : ." (point + guillemet)
Si je veux écrire un programme qui affiche Bonjour je peux le créer ainsi

: MOT1 ." Bonjour" ;

le mot : (deux points) créé un mot portant le nom de la chaine de caractères qui le suit (ici MOT1)
le mot ; (point virgule) termine la définition du mot et repasser en mode interprété
Il faut bien respecter les espaces qui sont les seuls séparateurs des mots Forth

Pour exécuter MOT1, il suffit d'être en mode interprété et de taper le nom et de valider par la touche Entrée.

On peut se servir d'un mot créé dans une autre définition, par exemple :

: 2xMOT1 MOT1 MOT1 ;

l'execution de 2xMOT1 affichera 2 fois le mot Bonjour

Pour en revenir à ce que je disais (que Forth est écrit en majorité en Forth):

le mot ." est écrit avec un autre mot : TYPE qui affiche une chaine de caractère à partir de son adresse et de sa longueur

le mot TYPE est écrit avec un autre mot : EMIT qui affiche un caractère
dont le code ASCII et placé sur la pile

(en parlant de pile, le Forth passe tous ses arguments par une pile, et utilise la notation post fixée : 1 1 + pour faire 1+1 )

Euh... où je voulais en venir déjà ??

A oui, donc effectivement, je veux utiliser l'assembleur pour écrire non pas un compilateur mais un nouveau langage Forth ressemblant à celui que je connais
mais :

y inclure la gestion des API et des mécanismes modernes utilisés sous Xp, Vista, Seven..?

Yess !!

edit : et au passage le passer en full 32 bits

J'ai commencé avec FASM mais je ne suis pas encore allé bien loin (j'ai un peu mis de coté car j'ai plein de projets en cours)

a+ François

PS: C'est pas ton nom que j'aurai vu du coté de Rosasm ?

[Rémi Coquet]

... je veux utiliser l'assembleur pour écrire non pas un compilateur mais un nouveau langage Forth ressemblant à celui que je connais

Ecrire un nouveau langage, au sens où tu l'entends, ne présente pas un niveau de complexité très élevé. C'est un module interpréteur qui remplace des blocs logiques par du code machine approprié. C'est pour cette raison que je parle de compilateur.
La notion de langage interprété est nettement plus lourde dans sa mise en place ainsi que dans son utilisation.
Sur un Pentium II 200 à MHz, un langage compilé est généré, même si ton source pèse plusieurs mégas, en quelques ms. Alourdir, voir se priver, de plusieurs technologies COM par exemple (DirectX, DirectShow et pas mal de modes coopératifs avec le noyau) c'est très regrettable pour ton projet et surtout pour tes intentions avouées: Gérer du graphisme en mode avancé, faire de la commande numérique et produire des automates programmables.

mais :
Citation:
y inclure la gestion des API et des mécanismes modernes utilisés sous Xp, Vista, Seven..?
Yess !!
edit : et au passage le passer en full 32 bits

Inclure la gestion des diverses API et COM, comme je commençais à l'exprimer plus haut, risque de devenir rapidement pénalisant si tu désires absolument conserver le mode interprété.
Donc, et à moins que tu aies des raisons profondément fondées sur une démarche fonctionnelle très précise, je te conseille de renoncer à ce mode: Les API de Microsoft n'apprécient guère d'être interrompues, y compris à un niveau très élevé de privilèges. Le fait de sauvegarder tous les contextes, les restaurer, dans le bon ordre et sans perturber les tâches cycliques du kernel, risque d'être un sujet d'étude que tu ne pourras ni contourner ni confier à quelqu'un d'autre.

De manière générale, tu vas devoir changer tellement de choses dans ta syntaxe Forth, que conserver une toute petite part d'habitudes risque de devenir rédhibitoire face à l'investissement chronovore que cela va entraîner pour mener à bien ton projet initial.

Si tu désires ré-utiliser les droits acquis "à pas cher" pour éditer une nouvelle version du Forth pour une surface cliente qui arriverait à faire pleurer une peau de chagrin… Je comprendrais bien l'intention mais je serais obligé de te rappeler que malgré les C, C+, C++, D, C#, Java … l'Assembleur demeure car il possède une propension à la stabilité liée au fait qu'il est le but et la fin ultime de tous.
Windows embbeded existe sous de nombreuses formes qui lui permette de s'adapter du téléphone au serveur multi-µP en passant par la X-Box. L'intérêt étant de disposer d'un ensemble d'API unifiées et donc pourvoir bénéficier d'un "portabilité" et d'une accessibilité bas-niveau: Le meilleur des deux mondes pour l'Assembleur. Le prix des licences générées étant quand-même très raisonnable, le fait qu'il soit possible aujourd'hui de protéger très sérieusement du code assembleur contre le RE, d'autoriser par clés RSA certaine partie du code… devraient finir de te convaincre de la qualité des produits que tu pourrais fournir à tes clients.

Tes réflexions ?

[Forthman]

Hello,

Inclure la gestion des diverses API et COM, comme je commençais à l'exprimer plus haut, risque de devenir rapidement pénalisant si tu désires absolument conserver le mode interprété.

pénalisant à quel niveau ?
Le mode interprété n'est là que pour faire quelques manips sur la pile, changer de répertoire, lancer l'exécution d'un mot, ou saisir la définition d'un nouveau mot.

Donc, et à moins que tu aies des raisons profondément fondées sur une démarche fonctionnelle très précise, je te conseille de renoncer à ce mode

en un seul mot : Souplesse quand on y a gouté, on ne peut plus s'en passer
Par exemple, le mot EMIT est un mot vectorisé.
(j'ai simplifié le principe des mots vectorisés dans mon Forth)
Le mot EMIT est défini ainsi :
: EMIT NOOP ; (NOOP est comme nop en ASM)
à partir de là, il suffit de remplacer dans le mot EMIT l'adresse de NOOP par
une adresse d'une définition qui sert à afficher un code ASCII à l'écran
et tous les mots qui utilisent EMIT (comme TYPE ou ." ) vont afficher sur l'écran.
Si je veux envoyer le texte dans un fichier, sur un port RS232 ...etc...
il me suffit de créer un nouveau mot, et de remplacer l'adresse de NOOP du
mot EMIT pour que cela redirige la sortie affichage

Les API de Microsoft n'apprécient guère d'être interrompues, y compris à un niveau très élevé de privilèges. Le fait de sauvegarder tous les contextes, les restaurer, dans le bon ordre et sans perturber les tâches cycliques du kernel, risque d'être un sujet d'étude que tu ne pourras ni contourner ni confier à quelqu'un d'autre.

Je n'ai pas compris pourquoi il fallait interrompre les API
en fait, l'interpréteur n'est rien qu'un programme comme les autres

Pour moi, le principal problème vient du fait qu'en Forth, données et code
sont mélangés. En fait, un mot écrit en Forth n'est même pas du code
(Par contre, il est possible de créer des mots en Assembleur )

La mémoire est "gérée" de manière linéaire, il n'est pas possible d'effacer
un mot sauf si on efface tous ceux qui ont été définis après.
Et s'il faut définir la quantité de RAM allouée (donc pas d'allocation dynamique) ce n'est pas un problème

Il existe bien quelques Forth pour Win$ Win32Forth étant le plus connu.
Mais ils sont très lourds à programmer à cause de l'interface Windows.

Mon but n'est pas d'utiliser toutes les possibilités des API, juste le minimum
pour pouvoir :
- afficher du graphique en plein écran (directx ?)
- accéder aux fichiers (comme je ferai sous DOS)
- pouvoir imprimer quelques chose (logiciels bureautiques)

Oui, je sais... c'est pas gagné

a+ François

[Rémi Coquet]

...Le mot EMIT est défini ainsi :
: EMIT NOOP ; (NOOP est comme nop en ASM)
à partir de là, il suffit de remplacer dans le mot EMIT l'adresse de NOOP par
une adresse d'une définition qui sert à afficher un code ASCII à l'écran
et tous les mots qui utilisent EMIT (comme TYPE ou ." ) vont afficher sur l'écran.
Si je veux envoyer le texte dans un fichier, sur un port RS232 ...etc...
il me suffit de créer un nouveau mot, et de remplacer l'adresse de NOOP du
mot EMIT pour que cela redirige la sortie affichage

Je comprends mieux. En fait, une des solutions consistera à transmettre (substituer) le Lp de ta chaîne saisie(dans un edit possédant des options de sortie(s): Routing RS232, écran, handle fichier...) à l'API idoine.

Il faudra, n'importe comment, de fabriquer au moins une dll (ou carrément un intégré) qui gère ton interface d'éditeur et qui pratique les substitutions et le routing du mode directe. Pour le reste c'est un Assembleur classique (?).

Pour le gestionnaire dynamique de mémoire, pas de problème, c'est réalisable de N+1 manières (+ Undo/Redo cyclique, destructif, listes chaînées, arbre d'insertion... comme d'habitude).

Pour ta partie graphique, que veux-tu utiliser comme ressources à part du plein écran en mode texte (RVBA 24bits + 1 byte alpha, tracés de lignes, rotations 3D, bitmap png etc.) ?