Programmation BASIC

Ah ok, ça parait logique effectivement.

Après le problème par rapport aux adresses mémoires c'est qu'on a des tableaux de chaines de caractères et là c'est le bazar. Dans le tableau tu as les adresses des chaines qui elles sont stockées dans une autre zone.

Bonsoir,

Tu peux connaitre facilement l'adresse du descripteur de la variable en faisant un DEEK(#B6) juste après avoir utiliser la variable.
#B6-B7 contient l'adresse de la dernière variable utilisée
Exemple

Code:


10 DIM A(100):PRINT HEX$(DEEK(#B6))
20 A=10:PRINT HEX$(DEEK(#B6))
30 B$="TEST":PRINT HEX$(DEEK(#B6))


Le problème est qu'il faut récupérer le contenu de #B6-B7 et le stocker en mémoire et pas dans une variable, sinon c'est l'adresse de cette dernière que tu récupères à chaque fois.

Code:


10 A$="TEST":DOKE 0,DEEK(#B6)
20 PRINT "Adresse du descripteur de A$:";HEX$(DEEK(0))


Il est également possible de faire l'équivalent d'une commande VARPTR présente dans certains BASIC:

Code:


5 REM Version Oric-1
10 DATA #20,#D9,#CF,#20,#FC,#D0,#85,#00,#84,#01,#60
20 DATA -1
30 AD=#400
40 READ V:IF V<>-1 THEN POKE AD,V:AD=AD+1:GOTO 40
50 CALL #400,V
60 PRINT "Adresse du descripteur de V:";HEX$(DEEK(0))


Pour un ATMOS, il faut remplacer la ligne 10 par

Code:


10 DATA #20,#65,#D0,#20,#88,#D1,#85,#00,#84,#01,#60


Après tout dépend du type de données que tu stockes dans tes tableaux.
Pour des chaines, par exemple, l'adresse réelle de la chaine sera DEEK(DEEK(0)+1)
Pour des entiers, la valeur est de la variable est directement obtenue par DEEK(DEEK(0)+1)
Pour des réels, c'est un peu plus compliqué.

Merci pour l'info.

Si la sauvegarde est trop lente avec la boucle de put je regarderai ça.

J'ai aussi regardé le code machine de la rom pour les opérations STORE et RECALL mais c'est un peu chaud car ça utilise des flags utilisés un peu partout de ce que j'ai pu comprendre.

Je ne connais pas très bien le Sedoric, mais il n'y a pas de commande de sauvegarde d'un tableau comme sous FT-DOS? (!MSAVE et !MLOAD)

J'en ai pas trouvé dans la doc mais je l'ai pas lue du début jusqu'à la fin donc j'ai peut-être loupé ça.

Ok, sinon, au besoin, j'ai désassemblé la totalité du FT-Dos, je pourrais regarder les sources des commandes MLOAD et MSAVE et voir si on peut les adapter au Sedoric.

Ah oui ça c'est une super idée

Tu as besoin de sauvegarder quels types de tableaux?

On a des tableaux contenant des valeurs numériques et des tableaux contenant des chaînes de caractères (ce sont eux qui sont les plus compliqués à sauver mais il n'y en a pas des tonnes donc je pense qu'avec la sauvegarde séquentielle ça devrait aller très bien).

 

Bonsoir,

Pour revenir sur les variables et la place occupée par ces dernières, je viens de relire un passage du Manuel de référence Tome1  d'André Chenière.
Il précise que si toutefois les variables entières indicées occupent bien moins de place que les réelles, il n'en est pas de même pour les variables entières simples.
Elles occupent 7 octets, comme les réelles 2 octets d'identification, 2 octets pour la valeur et les 3 derniers octets toujours à zéro , ce qui fait bien nos 7 octets.
De plus, l'éxecution du programme s'en trouve ralenti du fait, que l'interpréteur doit transformer ces dernières en virgule flottante avant de les utiliser.
Pour nous qui cherchons toujours plus de vitesse et d'économie de place en basic, j'avoue que j'ai été un peu surpris; je pensais que les variables entières indicées ou non ne consommaient que 2 octets pour leurs valeurs. Bien que je prenne en référence  les dires de Mr Chenière, j'ai été fouiller dans la mémoire à l'adresse des variables simples et c'est bien vrai, en plus de ça il faut ajouter un octet consommé en plus dans le code avec le signe %.
A+

Oui j'ai vu ça dans le bouquin de Geoff Phillips.

Maximus n'utilise quasiment que des tableaux d'entiers donc pas de pb pour Tyrann 3 mais c'est vrai que ça m'a bien erroné moi aussi ce truc.

Par contre je pense pas qu'il passe en virgule flottante pour les calculs et donc c'est le seul intérêt des variables entières scalaires.

Bonjour à tous,

@Hialmar: Comme toi, cette affaire m'a intrigué et suite à ta réponse, j'ai tout de même voulu vérifier la véracité des dires de Mr Chenière. Pour mémoire, ce dernier précisait dans son ouvrage, que l'interpréteur Basic de l'Oric transforme en virgule flottante les variables entières non indicées avant de les utiliser. Après verification sur une boucle avec 2000 itérations effectuant le cumul de trois variables du style A=A+1, B=B+1, C=C+1 et respectivement A%=A%+1, B%=B%+1, C%=C%+1; sauf erreur de ma part, l'ecart obtenu est de 5 secondes en faveur des variables réelles.

Bonne journée,
A+

:( bon ben elles sont complètements inutiles alors.

Tous les calculs sont effectivement faits en virgule flottante, ce qui fait qu'une instruction A%=B%+C% nécessite la conversion des 2 variables B% et C% en virgule flottante pour calculer l'addition puis une conversion en entier pour l'affectation.
Ce qui n'est pas le cas pour A=B+C puisque déjà dans le bon format.

En revanche, les tableaux d'entiers prennent moins de place que le même tableau de réels, contrairement aux variables simples qui utilisent toutes au moins 7 octets.

Dans le même ordre d'idée, on perd également de la place avec les variables "chaine de caractères" (3 octets par chaine!)

Dans tous les cas, les tableaux sont mieux gérés, en terme d'espace occupé, que les variables simples.
Après tout dépend de l'utilisation des variables et sin on cherche à optimiser la vitesse d'exécution ou l'espace mémoire utilisé.

J'ai relu le passage du bouquin de Geoff et, bien sur, tu as tout à fait raison.

Le seul avantage à utiliser des variables non tableau entières est si on a besoin de faire des INT pour avoir la partie entière puisque c'est directement ce qui est stocké.
Bref c'est pas très intéressant.

Pour les tableaux évidemment il n'y a pas photo, sur un gros tableau on peut diviser l'espace de stockage par plus de deux (5 octet par réel contre 2 par entier).

Oui c'est effectivement une particularité de notre Oric.
Contre toute attente (et en totale contradiction avec la majorité de ses contemporains), il est préférable d'utiliser les variables en notation réelles.
Alors que sur Amstrad par contre, la "logique" est respectée et il est préférable d'utiliser (a%=a%+1 en lieu et place de a=a+1)
Mais on l'aime comme il est !!