Cartographie mémoire du VG5000µ

Les bouquins, les scans, les pdf ou les liens qui vont bien... ici c'est la bibliothèque.

Modérateurs : Papy.G, fneck, Carl

Avatar de l’utilisateur
Mokona
Messages : 1040
Inscription : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Cartographie mémoire du VG5000µ

Message par Mokona »

Hello,

il y a un bon moment maintenant, je me suis lancé dans une sorte de regroupement et vérification systématique des sources de documentation sur le VG5000µ, au moins d'un point de vu fonctionnement logiciel. Cela a donné la recopie au propre des schémas de principe l'année dernière entre autre.

Je compile tout ça doucement dans un document qui regroupe tout ce que je trouve, mais comme c'est long, je me suis dis que cela pouvait « émettre » des articles sur Triceraprog au fur et à mesure.

L'un de mes tous premiers questionnement était à propos de la cartographie mémoire que l'on trouve dans les différentes sources. Elle m'a toujours paru incohérente et incomplète. Du coup, j'ai fouillé là-dedans et j'explique un peu le cheminement par ici : https://www.triceraprog.fr/vg5000u-une- ... basic.html

Mais pour ne pas vous obliger à lire mon interminable prose, voici l'image qui conclut l'article. Sans lire l'article, cela peut donner le jeu des différences avec les schémas disponibles (c'est très léger).

Et n'hésitez pas si vous trouvez à votre tour une erreur sur ma cartographie, au bout d'un moment à l'avoir sous les yeux, je ne la vois plus.

Image
Avatar de l’utilisateur
Mokona
Messages : 1040
Inscription : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Mokona »

Dans la foulée, voici un programme en BASIC qui se liste lui-même, en parcourant la mémoire.

C'est bien entendu plus pour l'étude du fonctionnement que pour l'intérêt, l'instruction LIST étant plus complète.

L'article : https://www.triceraprog.fr/vg5000u-un-l ... basic.html
Avatar de l’utilisateur
Carl
Modérateur
Messages : 13254
Inscription : 08 avr. 2007 13:21
Localisation : http://www.doledujura.fr
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Carl »

Merci Mokona pour ces 2 articles très intéressants !

Carl
Markerror
Messages : 2121
Inscription : 31 oct. 2011 19:21
Localisation : Orléans
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Markerror »

Hop, je confirme, merci pour ces articles plaisants à lire et au sujet intéressant. Il y a toujours des choses à découvrir/creuser sur nos vieilles machines, et ça fait plaisir de découvrir un travail bien fait :-).
Avatar de l’utilisateur
Mokona
Messages : 1040
Inscription : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Mokona »

Merci, ça motive.

Un nouvel article sur le sujet de la recherche de lignes en BASIC. Est-ce que mettre les routines les plus souvent appelées en début de programme est une optimisation ? Et pourquoi ?

https://www.triceraprog.fr/vg5000u-le-b ... ignes.html
Avatar de l’utilisateur
Carl
Modérateur
Messages : 13254
Inscription : 08 avr. 2007 13:21
Localisation : http://www.doledujura.fr
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Carl »

Merci Mokona !

Carl
Fred_72
Messages : 1131
Inscription : 22 mai 2019 13:10
Localisation : Sarthe

Re: Cartographie mémoire du VG5000µ

Message par Fred_72 »

Merci pour ces articles très intéressants.
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: Cartographie mémoire du VG5000µ

Message par Papy.G »

C'est un sacré boulot, et je lirais probablement les articles quand j'aurais de longues heures au calme. :P

Pour ce qui est de la localisation des sous-routines, je n'ai pas programmé sérieusement sur autre chose que ma calculette, et sur celle-ci, du moins, l'interpréteur scrute tout le programme depuis le début de celui-ci jusqu'à trouver la ligne appelée, ce qui donne des possibilités d'optimisations conséquentes sur des programmes utilisant beaucoup de sous-routines et écrits en ignorant ce fait.

Tu peux voir ici un exemple, et sur cette calculette, malgré le fait que l'on déclare des labels, et qu'ils soient limités à dix, l'interpréteur ne les localise pas à l'avance ou au premier appel pour y accéder plus rapidement, j'ai donc localisé les boucles en tête, et par ordre de fréquence d'appel. On peut voir aussi que j'utilise les valeurs r et thêta pour les compteurs dans les boucles, car les variables, bien que prédéfinies, sont frappées du même défaut, plus on va loin dans l'alphabet, plus l'accès est lent! :shock: Selon mes tests, r et thêta semblent être en tête du tableau de variables. J'utilise cela comme une convention, dans le Mastermind, je ne suis pas allé jusqu'à compter si je fais appel plus de fois dans une boucle à une valeur plus lente qu'une autre, et peut-être il y a moyen d'optimiser encore de ce côté.

Il est probable que sur le BASIC du VG5000µ, les routines, variables et chaînes soient frappées de cette même particularité, il doit donc falloir, pour optimiser, mettre les boucles en tête, avec des variables servant de compteurs parmi les premières déclarées, le type de variable utilisée est important aussi pour la rapidité de traitement (selon disponibilité dans le BASIC).
On pourrait croire, à priori, que l'interpréteur va scruter depuis l'instruction en cours, mais dans ce cas, pour retourner en tête de sous-routine, on va, à chaque fois, scruter toute la mémoire pour revenir juste un peu plus tôt dans le listing. En scrutant depuis le début du listing, on gagne statistiquement du temps. Je ne sais pas si certains interpréteurs scrutent en arrière depuis la ligne en cours, mais je pense que c'est une complication inutile en vue de l'optimisation visée, garder en cache l'adresse physique des lignes appelées me semble d'un meilleur rapport complexité/optimisation, mais cela limite le nombre de branchements.

On comprend au passage pourquoi les BASIC "compilés" permettent une rapidité d'exécution conséquente par rapport à ceux "interprétés" à la volée.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Avatar de l’utilisateur
Mokona
Messages : 1040
Inscription : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Mokona »

Je confirme que les variables du BASIC VG5000 subissent le même traitement (les variables forment le sujet du prochain article que j'écris).

L'interpréteur les classes en deux grands styles : tableaux et pas tableaux. Puis cherche systématiquement depuis le début de la liste du bon espace. Il peut donc être intéressant, si on utilise une variable pour une boucle FOR, de l'initialiser en tout début de programme, pour qu'elle soit localisée dans les premières.

J'avais cru lire que le ATARI BASIC XL, dans sa version interprétée, faisait de la recherche dans les deux sens, en fonction de la ligne actuelle. Privilégiant les sauts de lignes locaux, et que cette optimisation était valide... je ne retrouve plus l'article par contre.
Avatar de l’utilisateur
Mokona
Messages : 1040
Inscription : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Mokona »

Créer des variables, ce n'est pas une mince affaire, voici une nouvelle lecture plus longue que les autres, et qui encore ne traite que des variables simples (pas des tableaux) : https://www.triceraprog.fr/vg5000u-les- ... moire.html
Avatar de l’utilisateur
Carl
Modérateur
Messages : 13254
Inscription : 08 avr. 2007 13:21
Localisation : http://www.doledujura.fr
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Carl »

Merci Mokona pour ce cours sur les variables 8)
Carl
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: Cartographie mémoire du VG5000µ

Message par Papy.G »

Mokona a écrit : 19 août 2019 15:54J'avais cru lire que le ATARI BASIC XL, dans sa version interprétée, faisait de la recherche dans les deux sens, en fonction de la ligne actuelle. Privilégiant les sauts de lignes locaux, et que cette optimisation était valide... je ne retrouve plus l'article par contre.
Oui, si la routine compare le numéro de ligne courant pour obtenir la direction, ce doit être une optimisation intéressante. 8)
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Fred_72
Messages : 1131
Inscription : 22 mai 2019 13:10
Localisation : Sarthe

Re: Cartographie mémoire du VG5000µ

Message par Fred_72 »

Merci pour ces infos.
J'étais justement surpris de voir qu'il n'y avait pas de routine de gestion des chaînes de caractères détaillées dans les différents ouvrages.
Maintenant, je sais pourquoi :)
Ce cours va m'être très utile.
Avatar de l’utilisateur
Mokona
Messages : 1040
Inscription : 17 déc. 2016 22:01
Localisation : Nord Est des Yvelines
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Mokona »

Alors... parlons des chaînes de caractères, de leur allocation (lorsque c'est nécessaire) et de leur lien avec les variables.

https://www.triceraprog.fr/vg5000u-les- ... teres.html

Je me dis que ça mériterait une animation... il se passe pas mal de choses.
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Cartographie mémoire du VG5000µ

Message par Daniel »

Quand on utilise les chaînes dans un programme BASIC, il faut programmer intelligemment pour éviter la réorganisation de l'espace chaînes (appelée "ramasse-miettes" dans l'article de Mokona). En effet, quand il y a beaucoup de chaînes, ce processus peut être très long, et quand un jeu d'action se fige pendant quelques dixièmes de secondes, voire quelques secondes, c'est très gênant. Ce n'est pas propre au VG5000, tous les BASICs doivent avoir le même problème, en particulier chez Thomson.

Le plus pénalisant est la concaténation de chaînes : à chaque caractère ajouté la chaîne est ré-allouée, et si la concaténation est dans une boucle l'espace chaînes est très vite rempli. L'astuce consiste à définir d'entrée la chaîne à sa plus grande taille possible, et ensuite utiliser uniquement des instructions qui ne modifient pas sa longueur : RIGHT$, LEFT$, MID$...
Daniel
L'obstacle augmente mon ardeur.
Répondre