Forth : La méthode de Monte-Carlo

[Papy.G]

Pour les divisions (et multiplications), quand le jeux d'instructions le supporte, on peut mettre bout-à-bout des calculs sur huit bits pour faire du 16,24, 32 bits?

[Dominique]

Par ailleurs qu'entends tu par "Est il possible de corriger le bug sans déplacer les adresses ?" tu veux dire reprogrammer la zone du cf_uslash pour qu'elle fasse la même chose ? tout dépend de l'occupation mémoire. Si la 2eme version occupe moins d'octets ce sera joueable. ?

C'est à dire la nouvelle routine doit occuper au pire le même espace de mémoire afin de ne pas décaler les adresses

Code : Tout sélectionner

                    mod7             
4A04 EC42                    LDD    $02,U 
...... nouvelle routine

4A39 39                      RTS 

Bien entendu si elle occupe moins de mémoire on mettrait des NOP apres RTS

Dans cette nouvelle routine on n'aurait pas besoin de PULL du D car on a au retour mod7 l'instruction

Code : Tout sélectionner

4A60 0EAC                    JMP    PULL 

Ce qui fait que l'instruction
......

Code : Tout sélectionner

69EE 3342       LEAU   $02,U               5

dans la nouvelle routine DU/ me semble superflue et c'est elle qui doit causer les erreurs sur les grands nombres.
Je regarde vite fait

[__sam__]

Pour les divisions (et multiplications), quand le jeux d'instructions le supporte, on peut mettre bout-à-bout des calculs sur huit bits pour faire du 16,24, 32 bits?

Oui c''est ce qui est fait dans ces routines là: on fait du 32bits à base de primitives 8bits.

@Dominique: hum mod7 (division 32:16) réutilise mod5 (probablement pour une division 16:16) avec tout un tas de registres en pages-zéro. Du coup c'est pas forcément évident de remplacer tout ca par le code que tu as trouvé et qui utilise uniquement la pile U sans passer par les même entrées en page-zero. A noter: un truc m'inquiète dans mod5: l454D n'est pas initialisé. Ca veut dire qu'on utilise ce qui a été laissé là par le dernier appel à U/. C'est curieux.

Je pense à un truc: il me semble qu'en forth on peut redéfinir un mot-clef du langage. Est-ce que du coup ca ne réparerait pas ton bug facilement via cette sur-charge/re-définition de U/ ? Dans le pire des cas on pourrait même modifier la valeur en $4A5C-4A5D pour la faire pointer vers le code machine du DU/ corrigé. Mais par contre si ce dernier marche mal, il va falloir le débugger.

Je pourrais regarder ce soir comment adapter la division de logicielmoto pour faire 32:16 et peut-être la faire travailler sur les mêmes entrées page-zero que celle attendu par mod7/5/3, mais là c'est moins évident.

[Dominique]

@Sam

Comme on pouvait s'y attendre la division que tu avais donnée ici http://www.logicielsmoto.com/phpBB/view ... 9&start=60 marche très bien et donne des restes parfaitement exploitables.
Je vais bien suivre ce que tu as fait pour voir comment faire pour un 32 / 16 bits.

Code : Tout sélectionner

; SAM/ 

69C8 3716       PULU   A,B,X               9
69CA 1E01       EXG    D,X                 8
69CC 3416       PSHS   X,B,A               9
69CE 4F         CLRA                       2
69CF 5F         CLRB                       2
69D0 8E0011     LDX    #$0011              3
69D3 2008       BRA    $69DD               3
69D5 59         ROLB                       2
69D6 49         ROLA                       2
69D7 A362       SUBD   $02,S               7
69D9 2402       BCC    $69DD               3
69DB E362       ADDD   $02,S               7
69DD 6961       ROL    $01,S               7
69DF 69E4       ROL    ,S                  6
69E1 301F       LEAX   -$01,X              5
69E3 26F0       BNE    $69D5               3
69E5 ED62       STD    $02,S               6
69E7 3516       PULS   A,B,X               9
69E9 43         COMA                       2
69EA 53         COMB                       2
69EB 3616       PSHU   X,B,A               9
69ED 0EB6       JMP    /$B6                3

SAM.jpg (6.94 Kio) Consulté 3786 fois

Merci

[__sam__]

Oh merci, mais la division n'est pas de moi mais initialement de Tomix puis optimisée par Préhisto. La transformation en 32:16 est assez directe, il faut juste ne pas oublier de mette à jour le LDX avec la bonne valeur du nombre de tours (33 je pense).

Je voulais te demander: c'est l'environnement FORTH qui présente le code ASM desassemblé de cette façon ou est-ce que tu passes par le débuggeur de DCMOTO ?

[Dominique]

C'est le DCMOTO de Daniel ! Merci à lui.

Il suffit de faire un double clic sur la fenêtre du listing, elle se met dans le presse papier. Comme un copier/coller on sélectionne plusieurs lignes si on veut.

Je tape le texte du programme sur un pad, je sauvegarde en BIN, je télécharge le BIN à l'adresse 2100 (Adresse de l'éditeur Forth) grâce à la Mise au point et je n'ai qu'à compiler par 1 LOAD - C'est simple et rapide

SAM4.jpg (75.92 Kio) Consulté 3783 fois

[__sam__]

Tu tapes le texte ASM ou HEXA (je ne vois pas bien la photo) ? tu utilises quel assembleur ?

[Dominique]

Non, je tape en Hexa -

Sur la feuille du PAD je tape textuel les ascii

HEX CREATE SAM/ 3716 , 1E01 , 3416 , 4F5F , 8E C, 0011 , 2008 , 5949 , A362 , 2402 , E362 , 6961 , 69E4 , 301F , 26F0 , ED62 , 3516 , 4353 , 3616 , 0EB6 , SMUDGE

J'enregistre comme "XXX;BIN"

Je vais sur la "Mise au point" du DCMOTO - Il y a le bouton Load (où j'ai renseigné l'adresse de chargement)

L'avantage c'est que l'éditeur Forth lit l'adresse 2100 (Qui correspond à 1 LOAD ) comme si on l'avait tapée au clavier. Je ne sais pas si tu te souviens mais on en avait parlé il y a quelques années.

SAM5.jpg (53.97 Kio) Consulté 3777 fois

SAM6.jpg (210.44 Kio) Consulté 3777 fois

[__sam__]

Ah ok. J'ai l'impression que tu pourrais aussi passer par les fonctions "simuler le clavier" de DCMoto pour lire soit le presse-papier soit le fichier édité dans le pad.

[Dominique]

Oui également;

Je vais regarder quelles sont les fonctions qui utilisent les adresses genre l454D surtout pour vérifier si elles se passent les infos, ou si ce ne sont que des adresses de mémoire temporaire.

Edit :

[Dominique]

Je me trompe peut être, mais je vois toujours un "store" préalable à l'intérieur des adresses 454D a 4552

Code : Tout sélectionner

4A06 DD4D                    STD    l454D 
4A0A DD4F                    STD    l454F
4A12 DD51                    STD    l4551

Je ne me souviens pas avoir vu le noyau d'un compilateur Forth passer des valeurs entre les procédures hors des variables systèmes bien connues et qui suivent des normes. Ces variables qu'elles soient du Boot-Up (FENCE, DP, S0, R0, .....) ou des paramètres (BASE, CONTEXT, CURRENT et..) sont normalement connues et indexées par rapport à une origine; De plus ces variables l454D à l4551 seraient documentées.

Tout cela pour dire que les auteurs ont certainement réservé ces espaces de mémoires par convenance personnelle et qu'il n'y a pratiquement aucune chance pour que l'altération d'une variable de stockage temporaire dans U/ vienne interférer dans le fonctionnement d'une autre routine du Forth. On peut donc s'en passer; C'est d'ailleurs ce que font tous les FIG des différents processeurs.

Et si on se trompe on sera quitte à laisser tel que c'était.

[__sam__]

Oui je pense que tu as raison: ce sont des espaces de travail temporaires qui servent pour les routine se programmant moins facilement avec les piles.

[Dominique]

Je profite d un temps libre pour voir la routine U/ avec bug et son remplacement.
La correction serait plus courte que l'origine, donc aurait pu tenir.
sauf que .... elle donne le quotient sur 32 bits et le mot M/MOD ( ud1 u1 ... u3-reste ud4-quotient) s'en sert
Donc on ne peut la remplacer que par une qui donne un quotient sur 32 bits.