Faut-il utiliser des INT en Basic?
Modérateur : Politburo
Faut-il utiliser des INT en Basic?
Est-ce que le fait d'utiliser des INT (variables avec "%") sur les BASIC Commodore?! Je pensais que les INT prenaient moins de place en mémoire et que les opérations étaient plus rapides.
Postez ce que vous pensiez avant de regarder la vidéo
Il fait les sur un C-128 en mode C-64. Je pensais que le PET allait gérer le tout un peu mieux, mais sur l'émulateur VICE en version 3.1, c'est la même chose que le C-64!
Postez ce que vous pensiez avant de regarder la vidéo
Il fait les sur un C-128 en mode C-64. Je pensais que le PET allait gérer le tout un peu mieux, mais sur l'émulateur VICE en version 3.1, c'est la même chose que le C-64!
- gilles
- Fonctionne à 9600 bauds
- Messages : 3100
- Enregistré le : 17 avr. 2007 21:25
- Localisation : 44
- Contact :
Re: Faut-il utiliser des INT en Basic?
en interprété la performance sur des calculs très simples dépend de pas mal de choses... la longueur des noms de variables par exemple... même les commentaires ont un impact (assez faible) sur la performance... sur certains basic il y a un opérateur DEFINT qui permet de ne pas allonger les lignes en forcant globalement le type mais je ne crois pas que le C64 l'ait.
Re: Faut-il utiliser des INT en Basic?
Non, le C64 n'a pas ce genre de DEF.
La vidéo ne veut, à mon avis, que démontrer que l'utilisation des INT n'est pas ce qu'on pense.
J'avoue que j'ai été un peu surpris des résultats, surtout pour le PET
La vidéo ne veut, à mon avis, que démontrer que l'utilisation des INT n'est pas ce qu'on pense.
J'avoue que j'ai été un peu surpris des résultats, surtout pour le PET
- gilles
- Fonctionne à 9600 bauds
- Messages : 3100
- Enregistré le : 17 avr. 2007 21:25
- Localisation : 44
- Contact :
Re: Faut-il utiliser des INT en Basic?
Pour du calcul tres tres simple oui mais si il commence a y avoir de la multiplication ou de la division les resultats vont sans doute aller dans l’autre sens (je n’ai pas testé, mes commodore 8bit sont au grenier )
Re: Faut-il utiliser des INT en Basic?
Visiblement, même pour les calculs simples, il est préférable d'utiliser du virgule flottante.
Suite à la vidéo, je ne vois pas très bien l'utilité des INT sur les vic/c64/c128
Si quelqu'un a un PET sous la main, ce serait bien de faire le test.
Suite à la vidéo, je ne vois pas très bien l'utilité des INT sur les vic/c64/c128
Si quelqu'un a un PET sous la main, ce serait bien de faire le test.
- snsv6502
- Fonctionne à 300 bauds
- Messages : 114
- Enregistré le : 12 oct. 2018 21:23
- Localisation : Nantes
Re: Faut-il utiliser des INT en Basic?
INT ou pas INT ? Sur C64 le BASIC est tellement mal fichu que le plus étonnant dans l'histoire c'est qu'on puisse se poser ce genre de question.
Ce serait assez simple d'y répondre en décortiquant le code de l’interpréteur BASIC, mais bon... chacun son dada mais en asm sur c64, il me semble qu'il y a plus rigolo à faire (au hasard... déplomber Dragon's Lair ?)
Ce serait assez simple d'y répondre en décortiquant le code de l’interpréteur BASIC, mais bon... chacun son dada mais en asm sur c64, il me semble qu'il y a plus rigolo à faire (au hasard... déplomber Dragon's Lair ?)
]CALL-151
*
*
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
Re: Faut-il utiliser des INT en Basic?
Très juste.
Bon ce qui est clair, c'est que le BASIC des CBM est loin d'être optimal. Mais ça on le sait puisqu'il s'agit d'un BASIC très ancien de Microsoft plus ou moins "volé" ( euh "adapté") par Commodore à partir d'une version acquise pour le PET.
Les INT% sont des entiers signés de deux octets (16 bits 15 bits de valeur et le "premier/dernier" bit de signe): c'est loin d'optimiser le code sur un système 8 bits.
Le seul avantage est le gain mémoire qui est important surtout pour les grands tableaux/matrices. Pour une variable simple, il n'y a aucun avantage, sachant que toute l'arithmétique des CBM est en "réels à virgule flottante" sur cinq octets (IEE394) qui perdent facilement leur bit de garde et crée potentiellement des incongruités calculatoires démoniaques
Evaluer A% = B% + C% et bien plus compliqué que A = B + C car il faut de nombreuses conversions pour appliquer les opérandes < real > + < real > et < adr > = < real > ; sans compter que la recherche des variables en RAM est une opération assez curieusement menée, surtout pour les INT% qui sont en fin de zone et nécessitent de plus long parcours pour trouver A% B% ou C% (sans compter le retour du sous-programme ayant effectuer la recherche dans la première zone).
Ce qui est surprenant, c'est la relative lenteur de l'interprétateur du BASIC à "décortiquer" le contenu des lignes de code. Je n'ose pas imaginer le circuit tortueux que l'info suit au sein du système pour finalement aboutir dans l'unique accumulateur arithmétique et être mal arrondie une fois mémorisée dans la variable de destination.
Dans la vidéo, je suis surpris du temps que prend la lecture dans la boucle de la constante 3.1415692 par rapport à la constante PI. tout ce passe comme si de multiples conversions se faisaient à chaque chiffre et de façon répétitive à chaque chiffre supplémentaire.
Connaissant le caractère facétieux et le sérieux opiniâtre des concepteurs, je ne serais pas surpris d'apprendre que c'est bien la méthode utilisée.
En conclusion: je crois que les imperfections des CBM 8 bits sont voulues, c'est à des fins pédagogiques. Ces imparfaites machines ont donné des idées et ont forgé de bien meilleurs informaticiens et de bien plus nombreux passionnés que des langages et des machines infiniment plus rigoureuses et optimisées.
La preuve, nous en parlons encore plus de 30 ans après leur apparition et dans un discours qui est compréhensible de nous tous.
En 1983, qui nous comprenait lorsque nous évoquions format de donnée, bits/octets, temps d'exécution, optimisation ???
Bon ce qui est clair, c'est que le BASIC des CBM est loin d'être optimal. Mais ça on le sait puisqu'il s'agit d'un BASIC très ancien de Microsoft plus ou moins "volé" ( euh "adapté") par Commodore à partir d'une version acquise pour le PET.
Les INT% sont des entiers signés de deux octets (16 bits 15 bits de valeur et le "premier/dernier" bit de signe): c'est loin d'optimiser le code sur un système 8 bits.
Le seul avantage est le gain mémoire qui est important surtout pour les grands tableaux/matrices. Pour une variable simple, il n'y a aucun avantage, sachant que toute l'arithmétique des CBM est en "réels à virgule flottante" sur cinq octets (IEE394) qui perdent facilement leur bit de garde et crée potentiellement des incongruités calculatoires démoniaques
Evaluer A% = B% + C% et bien plus compliqué que A = B + C car il faut de nombreuses conversions pour appliquer les opérandes < real > + < real > et < adr > = < real > ; sans compter que la recherche des variables en RAM est une opération assez curieusement menée, surtout pour les INT% qui sont en fin de zone et nécessitent de plus long parcours pour trouver A% B% ou C% (sans compter le retour du sous-programme ayant effectuer la recherche dans la première zone).
Ce qui est surprenant, c'est la relative lenteur de l'interprétateur du BASIC à "décortiquer" le contenu des lignes de code. Je n'ose pas imaginer le circuit tortueux que l'info suit au sein du système pour finalement aboutir dans l'unique accumulateur arithmétique et être mal arrondie une fois mémorisée dans la variable de destination.
Dans la vidéo, je suis surpris du temps que prend la lecture dans la boucle de la constante 3.1415692 par rapport à la constante PI. tout ce passe comme si de multiples conversions se faisaient à chaque chiffre et de façon répétitive à chaque chiffre supplémentaire.
Connaissant le caractère facétieux et le sérieux opiniâtre des concepteurs, je ne serais pas surpris d'apprendre que c'est bien la méthode utilisée.
En conclusion: je crois que les imperfections des CBM 8 bits sont voulues, c'est à des fins pédagogiques. Ces imparfaites machines ont donné des idées et ont forgé de bien meilleurs informaticiens et de bien plus nombreux passionnés que des langages et des machines infiniment plus rigoureuses et optimisées.
La preuve, nous en parlons encore plus de 30 ans après leur apparition et dans un discours qui est compréhensible de nous tous.
En 1983, qui nous comprenait lorsque nous évoquions format de donnée, bits/octets, temps d'exécution, optimisation ???
Modifié en dernier par C.Ret le 29 mars 2019 19:45, modifié 1 fois.
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
-
- Fonctionne à 2400 bauds
- Messages : 1806
- Enregistré le : 03 mai 2003 02:24
- Localisation : Nonglard (Annecy)
- Contact :
Re: Faut-il utiliser des INT en Basic?
Ben simplement un truc pondu par micro$oft : what else ?
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
- snsv6502
- Fonctionne à 300 bauds
- Messages : 114
- Enregistré le : 12 oct. 2018 21:23
- Localisation : Nantes
Re: Faut-il utiliser des INT en Basic?
En conclusion: je crois que les imperfections des CBM 8 bits sont voulues, c'est à des fins pédagogiques. Ces imparfaites machines ont donné des idées et ont forgé de bien meilleurs informaticiens et de bien plus nombreux passionnés que des langages et des machines infiniment plus rigoureuses et optimisées.
C'est un point de vue rigolo, mais ceci dit, le c64 est sacrément bien pensé si l'on évite de se pencher sur le BASIC (et aussi la rom du lecteur de disquette ... quand même un peu...) . D'autre part, l'apple ][ est une machine fichtrement bien conçue (surtout pour ce qui touche à la partie lecteur de disquettes àmha) et ça ne l'a pas empêchée de propulser des pointures en programmation par paquets de 12.
Peut-être cela tient-il surtout à l'époque ?
A peu près tous mes potes en ce qui me concerne ... qui venaient tous des fameux 'clubs d'informatique'.En 1983, qui nous comprenait lorsque nous évoquions format de donnée, bits/octets, temps d'exécution, optimisation ???
Bref, désolé si ma réponse est un peu hors sujet... en tout cas, c'était vraiment chouette ce temps là
]CALL-151
*
*
- C.Ret
- Fonctionne à 9600 bauds
- Messages : 3422
- Enregistré le : 31 mai 2008 23:43
- Localisation : N 49°22 E 6°10
Re: Faut-il utiliser des INT en Basic?
Là je suis d'accord à 6502 %
Même si son BASIC est imparfait , c'est vrai que cette machine est bien pensées et que les "maigres" ressources sont bien exploitées : quand on voit tout ce qui est fait avec 64 kio (sons, couleur, sprites, manettes de jeu, E/S, modem, dataset, imprimante, lecteurs externes multiples, etc, etc...)
Le tout tient dans le boitier sous un clavier de qualité professionnelle et se branche sur la télé du salon. Voilà qui explique le succès planétaire et le nombre de ventes historique du C64.
"En 1983, à part les gas bizarres et le professeur de mathématiques que nous fréquentions au 'club d'informatique' du lycée, qui nous comprenait lorsque nous parlions micro ?" Et surtout, qui ne se moquait pas de notre hobby ? (ou de nos cassettes audio sans musique dessus) hein ?
Par contre, cela a l'avantage d'être disponible et permettre de rendre certains programme plus clair et parfois plus efficace en évitant erreurs d'arrondi, encombrement mémoire des tableaux/matrices, multiplication des noms de variable.
L'usage le plus courant des INT% que je fait est typiquement pour les graphiques: les variables flottantes réelles X et Y contenant la valeur "mathématiques" d'un point et les variables entières respective X% et Y% les coordonnées graphiques de ce point
Par exemple:
Le suffixe % indique les coordonnées graphiques, les autres variables sont réelles (dans l'espace mathématiques). L'exécution sera plus lente avec les INT%, mais le code est plus clair, plus facile lire et à maintenir.
Pour optimiser la vitesse, il faut limiter la nombre de variables, éviter les constantes numériques dans les boucles, remplir les lignes…
Par exemple:
Ou quelque chose d'approchant
Même si son BASIC est imparfait , c'est vrai que cette machine est bien pensées et que les "maigres" ressources sont bien exploitées : quand on voit tout ce qui est fait avec 64 kio (sons, couleur, sprites, manettes de jeu, E/S, modem, dataset, imprimante, lecteurs externes multiples, etc, etc...)
Le tout tient dans le boitier sous un clavier de qualité professionnelle et se branche sur la télé du salon. Voilà qui explique le succès planétaire et le nombre de ventes historique du C64.
A oui, en posant la question, j'avais oublié les membres de nos 'clubs d'informatique' ! C'est vrai qu'eux au moins nous comprenaient déjà à l'aube de l'aire numérique. Je dois donc reformuler ma question :
"En 1983, à part les gas bizarres et le professeur de mathématiques que nous fréquentions au 'club d'informatique' du lycée, qui nous comprenait lorsque nous parlions micro ?" Et surtout, qui ne se moquait pas de notre hobby ? (ou de nos cassettes audio sans musique dessus) hein ?
L'idée qu'il faut retenir et que , contrairement à d'autres machines ou des environnements de programmation, les CBM 8 bits n'ont pas une arithmétique entière sur 16bits qui rendrait l'usage des INT% plus rapide. Il faut voir les INT% comme un add-on une surcouche adaptée sur l'arithmétique 'floating real' originale IEE756
Par contre, cela a l'avantage d'être disponible et permettre de rendre certains programme plus clair et parfois plus efficace en évitant erreurs d'arrondi, encombrement mémoire des tableaux/matrices, multiplication des noms de variable.
L'usage le plus courant des INT% que je fait est typiquement pour les graphiques: les variables flottantes réelles X et Y contenant la valeur "mathématiques" d'un point et les variables entières respective X% et Y% les coordonnées graphiques de ce point
Par exemple:
Code : Tout sélectionner
100 TRAP 500
110 FOR X = XA TO XB STEP SX
120 : Y = FN FN F(X)
120 : X%=(X-XA)*320/(XB-XA)
130 : Y%=(YB-Y)*200/(YB-YA)
140 : DRAW 1,X%,Y%
150 NEXT X
160 TRAP
500: RESUME 150
Pour optimiser la vitesse, il faut limiter la nombre de variables, éviter les constantes numériques dans les boucles, remplir les lignes…
Par exemple:
Code : Tout sélectionner
1 TRAP5:H=200/(YB-YA):W=320/(XB-XA):FORX=XATOXBSTEPSX:DRAW1,(X-XA)*W,(YB-FNF(X))*H:NEXT:TRAP
5 RESUMENEXT
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.