NEXT

Nous y voilà ! Après avoir mis en place un framework de tests dans l'article précédent, il est temps d'implémenter le mot NEXT.

Un petit rappel du premier article de Moving Forth : NEXT est le mot qui permet de faire avancer l'exécution d'une séquence de pointeurs vers des mots Forth. Son pseudo-code (en modèle Indirect Threaded Code) est le suivant :

    (IP) -> W   récupère la mémoire pointée par IP dans le registre "W"
                -> W contient maintenant l'adresse du Code Field
    IP+2 -> IP  avance IP, le compteur de programme
    (W) ->  X   récupère la mémoire pointée par W dans le registre "X"
                -> X contient maintenant l'adresse du code d'exécution
    JP (X)      saute à l'adresse présente dans le registre X

Implémentation

En 6502, le code est un peu long, car l'adressage indirect nécessite de passer par des registres en page zéro. Et les manipuler demande plusieurs instructions. Je …

Des tests

Depuis le dernier article, je me suis surtout concentré sur la mise en place d'un framework de tests, ainsi que sur une réflexion de « comment commencer » ?

La lecture de l'article 2 de Moving Forth m'a donné une liste de mots à implémenter en priorité : NEXT, DOCOL et ;S. Cela afin d’arriver rapidement sur une boucle écrite en Forth. J'y reviendrai plus loin dans l'article.

Côté tests, ça a été une aventure en plusieurs étapes. Dans l'idée d'augmenter le nombre de tests, je voulais m'appuyer sur un framework de tests LUA tout fait. J'en ai trouvé un, luaunit qui m'a semblé tout à fait répondre à mes attentes. Pour l'utiliser, je dois utiliser un require("luaunit") dans mon script de tests. Et là ont commencé les ennuis. Tout d'abord, require() n'est pas permis par défaut dans Mesen2, il faut aller permettre les fonction E/S dans les …

Le projet minimal

Avant de passer à la lecture de l'article 2 de la série Moving Forth, je veux mettre en place un projet « minimal ». Plus exactement, c'est initialement ce que je voulais faire, avec un petit code source pour Famicom qui affiche un texte, un Makefile et bien entendu, un framework de tests.

Mais les notes que j'avais prises sur la Famicom remontaient à un petit moment, et il y a quelques trucs à initialiser avant d'afficher un caractère à l'écran. J'ai donc cherché un squelette de projet déjà fait. Sur une machine populaire, ça doit bien exister.

Mon choix s'est porté sur Nes Template de Mike Moffitt. Le squelette n'est pas minimaliste, mais a une bonne base, avec un système de configuration flexible pour la ROM destination, et assez de quoi écrire un message à l'écran, ainsi que manipuler des banques de mémoire. C'est bien écrit, bien …

Family Forth, le projet

En m'intéressant au langage de programmation Forth, j'ai parfois croisé l'affirmation que pour bien comprendre Forth, il fallait en développer un.

C'est cohérent avec son histoire, qui débute comme une trousse à outils de son inventeur pour lui faciliter les développements qu'il fait pour ses employeurs.

J'ai lu un certain nombre de documents sur Forth, parcouru quelques implémentations et même développé un jeu dans ce langage pour Hector HRX.

Plus récemment, en m'amusant avec le BASIC pour Famicom, je me suis demandé ce qui pourrait être développé sur la console pour tirer parti du clavier. Alors, pourquoi pas un Forth interactif sur Famicom ?

Une rapide recherche m'a montré que des expériences en Forth pour Famicom avaient déjà été faites, mais pas forcément sous l'angle interactif. Et bien entendu, il existe déjà des Forth pour 6502, le processeur qui équipe cette machine (même si c'est une version …

Voici un nouvel article de la série sur la compression de données, qui fait suite à celui sur la compression RLE, la compression LZ et la compression ZX0.

À la fin de l'article sur la compression LZ, il avait été question de fréquence d'apparition des nombres pour les offsets de référence et les longueurs de motif. Cette constatation avait amené lors de l'article sur ZX0 à regarder le codage gamma, qui permet de coder des entiers avec un nombre de bits variable afin d'optimiser la taille des petits nombres (qui sont plus fréquents).

Revenons sur cette histoire de fréquence en l'étendant à tous les symboles présents dans les données à compresser. Il serait intéressant d'avoir un codage dépendant de la fréquence d'apparition des symboles : plus le symbole est fréquent, plus son code est court.

Ce codage est obtenu avec l'algorithme de Huffman.

En plus d'avoir des codes de longueurs …