Discussion :

[<Zer0>]

Salut !

Je débute en Forth, et après avoir implémenter des tas de structures statiques, il me faut maintenant faire de même pour les dynamiques (en commençant bien sûr par le tableau dynamique). Je n'ai jamais été confronté à un langage qui ne les propose pas dans son core, donc je suis en territoire inconnu .

Je pensais utiliser la technique de l'expansion géométrique de tableaux : lorsque le tableau (en réalité statique) devient trop petit, on en alloue un nouveau x fois plus gros. Seulement je ne suis pas capable de coder un truc pareil :

• Je ne sais pas comment libérer de la mémoire en Forth (d'ailleurs, je me demande comment ça fonctionne, puisqu'une fois que HERE a été incrémenté comment revenir en arrière ?)
• Si le tableau venait à changer d'adresse au cours de son redimensionnement, cela ne risque-t-il pas de poser des problèmes chez les codes exploitants ?
• Suis-je obliger d'implémenter d'abord les structures C-like ? PArce que sinon je ne vois pas comment associer un nom de tableau a une capacité théorique, comme dans l'exemple de Wikipédia :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  function insertEnd(dynarray a, element e)
      if (a.size = a.capacity)
          // resize a to twice its current capacity:
          a.capacity ← a.capacity * 2  
          // (copy the contents to the new memory location here)
      a[a.size] ← e
      a.size ← a.size + 1

Il serait peut-être plus simple de penser à une autre solution, du genre listes doublement chaînées ? Quel est l'usage en Forth ?

Merci d'avance !

PS : gforth propose des tas de trucs utiles, dont quelques structures de données dont peut-être les tableaux dynamiques; mais j'ai une petite envie de mettre les mains dans le camboui .

[Forthman]

Bonsoir,

Ca c'est une très bonne question !

Je n'utilise qu'un vieux Forth sous DOS (ou une adaptation sous forme d'OS)
donc je n'ai aucune idée de comment faire sous Win$ ou Linux

Par contre, je suis en train de faire une petite applie qui permettra de gerer
un fichier de plusieurs Mo (maximum 1Go)

Mais comme l'accès à ces données est continue, je lis ou modifie le fichier
par tranches de 256Ko

a+ François

[<Zer0>]

Argh. Je vais essayer de me renseigner sur Usenet (si mon anglais ne me fait pas défaut), je te tiens au courant .

[Forthman]

Oui, je veux bien

Tu utilises quel Forth ? gforth ?
Je ne sais pas comment est gérée la mémoire avec un Forth sous Win$
(limite imposée dès le début ou allocation dynamique en fonction de la hauteur du dictionnaire )

En tout cas, tu n'es pas obligé de créer un mot et de lui allouer de la RAM pour
faire ton tableau.

Tu peux simplement créer un pointeur "flottant" genre :
: TABLEAU HERE 1000 + ;
où TABLEAU @ renverra la première cellule de ton tableau.
Bien sur, ton tableau va se déplacer dans la RAM en créant de nouveaux mots,
mais une fois ton programme fini, plus de problème

a+ François

[<Zer0>]

J'utilise gforth sous GNU/Linux.

Je ne comprends pas bien ton TABLEAU. En gros, il nous envoie n CELLS plus loin que HERE. Mais je n'ai pas de garantie qu'aucun mot ne va demander un peu plus d'espace, et foutre en l'air mon tableau ! C'est pas très viable de partir de ce principe là, on ne peut pas connaître l'implémentation de tous les mots qu'on utilise... Je préfère être explicite avec des VARIABLEs; après je ne sais vraiment pas quel est l'usage en Forth.

D'ailleurs, à propos des variables, comment résoue-t-on les conflits de noms ? Il arrive souvent que j'ais à me servir d'une valeur intermédiaire dans un algorithme, que je nomme par exemple _OK . J'ai pas interêt, à ce moment là, de charger un autre programme qui définit un _OK ...

[Forthman]

si ton tableau est utilisé pendant la phase de développement, ou est destiné à
être implanté définitivement dans le forth que tu utilises, effectivement,
il faut le définir à une adresse fixe.

Mais si tu comptes créer une application, quand cette dernière sera crée,
plus aucune définition ne sera créé, et donc HERE ne sera pas modifié

Quand tu créés un mot Forth (tout est mot en Forth) qui existe déjà,
tu dois normalement avoir un message qui te prévient que ce mot existe déjà.

Les mots nouvellements définis utiliserons la dernière définition, mais les mots
définis avant continuront d'utiliser l'ancien.

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
: TEST  1 ;

: 2TESTS
  TEST TEST ;

: TEST 2 ; (message d'avertissement, mais la compilation continue)

: 3TESTS
  2TESTS TEST ;

L'execution de 3TESTS va placer sur la pile les valeurs 1, 1, et 2

a+ François

[<Zer0>]

J'imaginais plutôt un cas avec des VALUEs, toussa...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
1 VALUE TEST

: BIDULE 3 TEST ! ;

5 VALUE TEST

Dans ce cas, le prochain appel à BIDULE fait planter. Y'a-t-il moyen de séuriser tout ça ? Pour être plus concret, j'ai implémenté une version de quicksort pour mes tableaux; afin de simplifier considérablement le code, mon SORT utilise une VALUE nommée _TEMP (pour stocker des valeurs temporaires). Mais que ce passe-t'il si un programme qui requiert ces tableaux définit lui-même une VALUE _TEMP ? Le mot SORT ne risque-t-il pas de ne plus fonctionner ?

[Forthman]

Hello,

Je ne connaissais pas le mot VALUE (qui n'existe pas dans mon Forth)
Mais je viens d'aller faire un tour sur un manuel de GForth.

Visiblement les mots créés avec VALUE ne sont pas destinés à être utilisés
avec ! et @

dans ton exemple, il faut remplacer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

: BIDULE 3 TEST ! ;

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

: BIDULE 3 TO TEST ;

par contre, si tu redéfini le mot TEST, tu ne pourra plus utiliser l'ancien

a+ François

[<Zer0>]

Hmm oui, j'aurais dû prendre comme exemple des VARIABLEs .

par contre, si tu redéfini le mot TEST, tu ne pourra plus utiliser l'ancien

Et donc, aurais-tu une idée pour sécuriser mes "modules" ? Je veux dire, dans un gros projet, il y a de grandes chances que des noms de variables soient identiques...

[Forthman]

Hello,

Je ne vois pas ce que tu veux sécuriser

De toutes manières, le Forth laisse beaucoup de liberté au programmeur.
parfois beaucoup trop , et il n'y a pas réellement de "sécurité"

Tu peux très bien écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
: TEST
  12 DO
    I .
   LOOP ;

alors que DO a besoin de 2 valeurs (fin début DO )
donc à l'exécution la valeur de fin sera "récupérée" sur la pile.
Si cette dernière est vide (la pile) la valeur dépilée est indéfinie, le pointeur
de pile risque de pointer sur une partie de code, et en plus le fait d'empiler la
valeur I risque d'écraser cette même partie de code

Il y a une dixaine d'année j'avais recompilé le Kernel de mon Forth pour
éviter les erreurs de piles... mais cela devient très vite très lent
( ne pas oublier que Forth n'est qu'un langage semi-compilé )

a+ François

[<Zer0>]

Je ne vois pas ce que tu veux sécuriser

Eh bien... si un un algorithme a besoin d'une variable donnée pour fonctionner, et qu'on charge une autre source qui redéfinit cette variable, il va y avoir un conflit entre mes deux programmes... Et dans un gros projet, c'est probablement le genre d'erreur qu'est pas évidente à dénicher, non ?

PS : je n'ai pas encore pris le temps de rédiger proprement un post pour usenet, je vais essayer de faire ça mercredi après-midi...

[Forthman]

Non, il n'y aura pas de conflit.

Seulement si tu veux accéder à la valeur de l'ancienne variable, et bien...
tu ne pourras pas

Par exemple, j'utilise la variable VIRTUAL qui contient le segment où je
stocke l'écran virtuel.

J'ai plusieurs modules qui utilisent cette variable :
- gestion de l'ecran virtuel
- affichage de sprites
- afficharge de graphiques
- afficharge de caracteres en mode graphique

bien souvent je n'ai pas besoin de charger tous les modules, par exemple,
si la gestion de l'ecran virtuel n'est pas chargée, VIRTUAL = A000h

La solution que j'utilise n'est surement pas standard (car mon Forth n'est pas standard)
voici la ligne magique :

EXIST? VIRTUAL NOT ?\ VARIABLE VIRTUAL

EXIST? renvoit -1 si le mot qui suit existe sinon 0
NOT inverse la valeur
?\ exécute la suite de la ligne si la valeur au sommet de la pile = -1

donc la variable VIRTUAL n'est créée que si elle n'existe pas

a+ François

[<Zer0>]

Hmmm... je vois, c'est tout de même loin de cette constante sécurité que l'on a avec les langages hauts niveau, avec leurs namespaces et leurs namescopes ...

Sinon, par curiosité, quel Forth utilises-tu ? Genre gros g33k barbu, le Forth codé par toi-même en Assembly ?

[Forthman]

C'est clair que le Forth n'est pas sécurisé pour 2 sous
La seule chose qui est vérifiée c'est l'intégrité de la pile ... et encore

J'utilise un dérivé du Turbo Forth distribué par la société MP7 (qui a fermé
depuis un peu plus d'une dizaine d'années)
C'est un Forth que j'ai adapté au fil des ans à mes besoins/envies
Le source de Turbo Forth est livré avec, et est écrit en Forth (métacompilation)

Aujourd'hui se suis en train d'écrire un nouveau Forth en assembleur (avec
FASM) pour avoir un outil compatible Win$ ou Linux car jusqu'à présent je
l'utilisait surtout sur des machines dédiées sous DOS ou sans OS.

a+ François

[<Zer0>]

Des machines sans OS ? WTF ?

(eh ouais, la jeunesse...)