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.) ?

[Forthman]

Bonjour Rémi,

Une petite précision stp, quand tu utilise "Lp" c'est bien l'abréviation de "Long pointer" ?
Je connais (connaissais) bien la programmation système, mais étant autodidacte
je n'utilise pas forcément les bons termes
Et en plus je ne me suis jamais penché sur la programmation sous un OS
(sauf DOS mais c'est pas vraiment un OS )

Pour l'affichage, je ne comptes pas utiliser le mode texte, mais un mode graphique "basique" genre 800x600 en 256 couleurs ou un peu plus (en résolution et/ou en couleurs).
C'est ce que j'utilise actuellement pour mes programmes, et encore j'étais il y
a peu encore en 640x480.

Les fonctions utilisées seront elles aussi basiques :
- points
- lignes
- rectangles pleins (ou pas)
- sprites
- fontes de caractères en bitmap (6x8 8x16 ...etc...)

pas besoin que mes applications s'adaptent au matériel, elles ne sont pas
destinées à être diffusées

Le Forth que j'utilise ne comporte pas d'éditeur intégré, je me contente de
Edit du DOS ou de PSPad sou Windows.
J'écrirai peut-être un jour un éditeur pour Forth, mais ce n'est pas ma priorité.

merci de ton aide

a+ François

[Rémi Coquet]

Une petite précision stp, quand tu utilise "Lp" c'est bien l'abréviation de "Long pointer" ?
Je connais (connaissais) bien la programmation système, mais étant autodidacte
je n'utilise pas forcément les bons termes
Et en plus je ne me suis jamais penché sur la programmation sous un OS
(sauf DOS mais c'est pas vraiment un OS )

Lp est bien l'abréviation de Long Pointer et ce terme désigne une étiquette, un label, une adresse (réelle ou un offset virtuel) dans toute application, par opposition à son contenu: Data ou code.
Que D ne soit pas un OS, j'arrive encore à te suivre mais pour OS tu tombes sur un, justement.

Pour l'affichage, je ne comptes pas utiliser le mode texte, mais un mode graphique "basique" genre 800x600 en 256 couleurs ou un peu plus (en résolution et/ou en couleurs).
C'est ce que j'utilise actuellement pour mes programmes, et encore j'étais il y
a peu encore en 640x480.
Les fonctions utilisées seront elles aussi basiques :
- points
- lignes
- rectangles pleins (ou pas)
- sprites
- fontes de caractères en bitmap (6x8 8x16 ...etc...)

Ce que tu décris là est l'équivalent d'un mode "texte" + un mode "graphique" simultané.
Pour les fontes, le matériel se charge de te proposer des concepts de fontes "variables" et "fixes". Je pense, d'après ta description, que tu utilises les secondes pour des questions de facilités d'alignement. Les fonctions DirectX ou certains encapsulations de la GDI (par exemple) te permettent de travailler avec des fontes vectorielles sans problèmes de localisation.

Plusieurs mécanismes, situés à divers niveaux d'abstraction et de l'OS cohabitent autour ou dans le kernel Microsoft (clairement depuis SE). Cependant…

pas besoin que mes applications s'adaptent au matériel, elles ne sont pas
destinées à être diffusées

… même pour des applications personnelles (je ne vois pas bien le rapport) tu utiliseras toujours le matériel.
Ce n'est pas le CPU qui a la charge de la partie graphique (même si les velléités d'Intel, AMD, NVIDIA et consorts, pour des questions de marché, brouille les cartes) mais un hardware spécialisé qui décharge ce dernier et possède son propre jeu d'instructions.
Tous ces hardwares sont compatibles avec un format qui a évolué: WDM pour faire simple (Microsoft au départ mais vu ses parts de marchés il rend service à tous en normalisant les accès et la conception des drivers qui sont de moins en moins spécifique et de plus en plus compatibles).
L'intérêt étant de pouvoir obtenir l'accès à des interfaces identiques (COM) quel que soit ton hard. Ensuite, selon les capacités de ce dernier, le travail est fait réellement par lui ou, à défaut, par le µP (ce qui est de plus en plus rare depuis une bonne dizaine d'années).
Donc, pas d'angoisse pour l'adaptation matérielle, c'est transparent pour l'utilisateur.
[quote]Le Forth que j'utilise ne comporte pas d'éditeur intégré, je me contente de
Edit du DOS ou de PSPad sou Windows.
J'écrirai peut-être un jour un éditeur pour Forth, mais ce n'est pas ma priorité.[quote]

Je ne comprends pas bien comment tu comptes utiliser le "mode directe" cité plus haut dans tes post ?

Il faudrait que tu précises où se situent les diverses fonctions: Ton noyau, l'interface…

Hier soir, en remontant les divers posts du forum, j'ai constaté que ton projet n'est pas nouveau et à subie plusieurs évolutions (Chez toi, plutôt que dans le code). Il serait bon de fixer les choses pour avancer notablement.

[Forthman]

Bonjour,

Quand je dis que le DOS n'est pas un OS, je veux dire par là que l'on peut l'ignorer dans ses programmes.
Quand je créé un programme destiné à tourner sur une machine sans OS,
je le met au point sous DOS (ou sous console windows) et une fois qu'il est au
point, je le "transforme" pour qu'il démarre au BOOT de la machine.

pas besoin que mes applications s'adaptent au matériel, elles ne sont pas
destinées à être diffusées

… même pour des applications personnelles (je ne vois pas bien le rapport) tu utiliseras toujours le matériel.

ce que je veux dire, c'est que je pourrai recompiler le programme pour une machine spécifique

Je ne comprends pas bien comment tu comptes utiliser le "mode directe" cité plus haut dans tes post ?

Il faudrait que tu précises où se situent les diverses fonctions: Ton noyau, l'interface…

C'est un projet qui me trotte dans la tête depuis longtemps, et c'est vrai qu'il a évolué
- au début un Forth plus puissant sous DOS
- puis un Forth plus puissant autonome (l'OS serait contenu dans le Forth)
- puis un Forth pour Windows (ou Linux qui sait)
Quand je dis "plus puissant" je ne parles pas en terme de vitesse, mais de gestion de pile (32 bits au moins) et de capacité d'allocation de RAM.
Pour l'instant, le Forth que j'utilise exploite une pile 16bits ce qui commence à
être un peu pénalisant pour mes applications (je dois beaucoup jongler)
De plus, comme ce sont des applications DOS à la base, et que le Forth
prend déjà 26Ko de RAM dans mon segment de 64Ko, je suis vite obligé de
magouiller pour pouvoir gérer les donnéés.
C'est encore plus vrai quand j'utilise un mode SVGA qui "pompe" déjà 470Ko pour un écran en seulement 800x600 et 256 couleurs

a+ François

[Rémi Coquet]

ce que je veux dire, c'est que je pourrai recompiler le programme pour une machine spécifique

En utilisant les Api tu n'auras pas besoin de faire quoi que ce soit, les drivers sont là pour ça et la "portabilité" sous Windows devrait être accrue.