Discussion :

[Kannagi]

Bon je n'ai pas une longue expérience dans ce domaine, du coup je me pose des questions mais elles sont relatives à l'expérience acquise.
Je n'ai pas une question technique sur un processeur particulier mais je code en asm 65816.

Bon ma première question : privilégier MACRO ou fonction ?
Personnellement, je n'utilise que des macros, du coup l'instruction JSR (cycle 6-8) ne me sert pas.
Après j'imagine que le mieux est d'utiliser une fonction quand les macros commencent à être limitées ? Ou un probleme de la taille d'exécutable (mais il faut écrire vraiment pas mal j'imagine).
Donc quand utiliser JSR ?

Ensuite je n'utilise pas le push et pop, PHA et PLA (cycle 3 chacun), alors que LDA (cycle 2-4 (const-addr) ) et STA (cycle 4) reviennent au même et je préfère stocker en mémoire .
Sinon question 'bête' : y a-t-il un moyen de savoir quel est la capacité de la pile en stockage ?
Je n'arrive vraiment pas à trouver un moment où il serait plus avantageux.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
		lda $4219	; read joypad (cycle 4)
 
		AND #$01
		cmp #$01
		bne +
		lda 0
		inc A
		sta 0
+
 
		lda $4219	; read joypad
		AND #$02
		cmp #$02
		bne +
		lda 0
		dec A
		sta 0
+

Avec push/pop

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
		lda $4219	; read joypad (cycle 4)
                pha ( cycle 3 )
	        pha ( cycle 3 )
                pla (cycle 3)
 
		AND #$01
		cmp #$01
		bne +
		lda 0
		inc A
		sta 0
+
 
		pla (cycle 3)
		AND #$02
		cmp #$02
		bne +
		lda 0
		dec A
		sta 0
+

Voilà pour mes petites questions, enfin elle me sont importantes vu que cela déterminera comment je coderai en asm.
Bien sûr le but est d'optimiser le code .

[Forthman]

Macros ou fonctions...

c'est vrai que les Macros bouffent plus de place puisque à chaque appel le code est recompilé...
Mais comme tu le dis, tout dépend du programme...

Instinctivement je dirais qu'une fonction est plus "propre" mais ce n'est que subjectif, et quand je me suis mis à l'assembleur
(moi je suis resté 80x86), comme mes programmes ressemblaient plus à des démos (il fallait qu'il y ait toujours un truc qui bouge à l'écran )
j'avais privilégié les macros (plus rapide car pas de saut)

Pour l'utilisation de la pile, ici aussi c'est pour éviter de définir un paquet de variables (bien que l'on puisse utiliser des variables génériques comme TEMP1, 2 3 ...etc...)
donc à première vue ça fait plus propre de passer par la pile, et ça permet de faire fonctionner la cervelle quand la valeur dont on a besoin n'est pas tout en haut

J'y connais rien dans ton proc, mais j'imagine que comme pour x86 tu dois avoir un pointeur de pile, du coup la profondeur de pile dépend de la quantité de
mémoire que tu as à disposition, et de l'emplacement de ce pointeur (s'il est à 10 octets d'une zone de code, la pile sera peu profonde )

[Kannagi]

Merci de tes conseils
Oui bah je pense pareil les fonctions me semble plus propre mais j'utilise les macro au final (et puis niveau syntaxe c'est plus pratique a utiliser aussi),mais il est vrai que dans d'autre langage les macro sont guère utilisé , je pense surtout au C ou en utilise beaucoup plus les fonctions , je pense que j'utiliserais les fonction en asm plus pour ranger le code par bloc.
Ok je comprend mieux pour la pile utilisais comme variable temporaire , mmh ça me semble une bonne idée.
Je vais regarder pour la zone de pile

[Forthman]

Par contre, il faut éviter de passer des paramètres par la piles aux fonctions, car lors de l'appel
cette dernière est utilisée pour stocker l'adresse de retour et autres bricoles

[Obsidian]

Hello,

Bon je n'ai pas une longue expérience dans ce domaine du coup je me pose des question mais elle sont relative de l'expérience acquise.
Je n'ai pas une question technique sur un processeur particulier mais je code en asm 65816

Le 65816 est un dérivé du 6502, lui-même un proche cousin des 68xx. J'ai moi-même beaucoup utilisé le 6809 et je trouve que ce sont les familles les plus agréables à utiliser, tant pour faire ses premières armes en assembleur que pour prendre du plaisir à développer. C'est donc une très bonne chose mais, par curiosité, qu'est-ce qui t'amène aujourd'hui à travailler sur des plate-formes aussi anciennes ?

Bon ma premier question privilégier MACRO ou fonction ?
Personnellement j'utilise que des macro du coup instruction JSR (cycle 6-8) ne me sert pas.
Après j'imagine que le mieux est d'utiliser une fonction quand les macro commence a être limité ? ou un probleme de la taille d'exécutable (mais il faut écrire vraiment pas mal j'imagine).
Donc quand utiliser JSR ?

L'usage consiste en principe à utiliser JSR (ainsi que BSR sur 68xx). Travailler uniquement avec des macros, cela revient à utiliser exclusivement des fonctions inline en C++ à l'exclusion de toute fonction ordinaire, voire même à ne définir que des #define sans jamais déclarer une seule fonction. C'est donc un peu hardcore comme approche. Il faut dire également qu'à l'époque où on utilisait ces micro-processeurs, la mémoire vive était restreinte (quelques kilo-octets en général) et les macro-assembleurs étaient des logiciels rares et chers.

Malgré tout, cela ne se justifierait que si tu étais à la fois très limité en temps machine (au cycle près), très limité en RAM mais que tu disposerais a contrario d'une quantité incroyable de ROM ou de RAM programme.

Également, utiliser uniquement des macros t'interdit de déclarer des fonctions récursives.

Ensuite je n'utilise pas le push et pop , PHA et PLA (cycle 3 chacun) , alors que LDA (cycle 2-4 (const-addr) ) et STA(cycle 4) revient au même et je préfère stocker en mémoire .
sinon question 'bête' y 'a t il un moyen de savoir quel est la capacité de la pile en stockage ?

La pile est en mémoire. Elle utilise le registre SP comme index de pile. Quand tu écris PHA, le micro-processeur décrémente SP puis sauve A à l'endroit pointé. Quand tu écris PLA, le micro-processeur charge A d'abord puis incrémente SP.

À l'époque des huit bits, où la mémoire était limité mais où, surtout, les logiciels étaient mono-tâches et spécialement conçus pour une machine qui ne variait jamais, il était d'usage de se déclarer des variables fixes en mémoire et d'aller taper dedans à volonté, l'usage de la pile pour les données étant anecdotique mais pas inexistant. En C, par contre, pratiquement tout se fait sur la pile. Ce qui est lu ou écrit à des adresses fixes correspond soit aux variables globales, soit à des sections compilées spécifiquement pour la machine-cible.

J'arrive vraiment pas a trouver un moment ou il serait plus avantageux.

Dans le second extrait, tu peux déjà économiser deux instructions en tête de programme puisqu'il ne sert à rien d'empiler l'accumulateur si c'est pour le dépiler juste après.
Ensuite, si LDA $4219 sert à récupérer l'état du joypad, alors cet état peut varier entre deux sections du programme. Le sauver (dans la pile ou ailleurs) permet d'arrêter cet état à un moment donné et de travailler sur une donnée identique dans toutes les sections de ton code.

Et surtout, c'est dans cette même pile que va être enregistrée l'adresse de retour lors d'un JSR. Donc, en l'absence de pile, pas de fonctions récursives non plus.

Voila pour mes petite question , enfin elle me sont importante vu que cela derminera comment je coderais en asm.
Bien sur le but est optimiser le code .

Optimiser selon quels critères ? Et notamment, optimiser au profit de la vitesse ou de l'espace occupé ?

[Kannagi]

Le 65816 est un dérivé du 6502, lui-même un proche cousin des 68xx. J'ai moi-même beaucoup utilisé le 6809 et je trouve que ce sont les familles les plus agréables à utiliser, tant pour faire ses premières armes en assembleur que pour prendre du plaisir à développer. C'est donc une très bonne chose mais, par curiosité, qu'est-ce qui t'amène aujourd'hui à travailler sur des plate-formes aussi anciennes ?

J'avoue que c'est un bon assembleur , j'avais commencé avec le x86 mais j'ai pas trouvé beaucoup intérêt , ce processeur possède peu instruction , peu op-code bref très transparent et donc j’apprends bien avec ce processeur.
Bah je code dessus vu que toute les SNES en possède une , donc oui je code sur SNES , bon la SNES a une architecture assez complexe mais si on a pas peur de mettre les main dans les cambouis c'est un pur régal
Après je le conseillerais pas comme première expérience niveau jeux vidéo.

L'usage consiste en principe à utiliser JSR (ainsi que BSR sur 68xx). Travailler uniquement avec des macros, cela revient à utiliser exclusivement des fonctions inline en C++ à l'exclusion de toute fonction ordinaire, voire même à ne définir que des #define sans jamais déclarer une seule fonction. C'est donc un peu hardcore comme approche. Il faut dire également qu'à l'époque où on utilisait ces micro-processeurs, la mémoire vive était restreinte (quelques kilo-octets en général) et les macro-assembleurs étaient des logiciels rares et chers.

Malgré tout, cela ne se justifierait que si tu étais à la fois très limité en temps machine (au cycle près), très limité en RAM mais que tu disposerais a contrario d'une quantité incroyable de ROM ou de RAM programme.

Également, utiliser uniquement des macros t'interdit de déclarer des fonctions récursives.

C'est vrai mais assembleur et les langage plus haut niveau sont pas vraiment pareil et pas la même approche j'imagine (apres en C++ en a le choix en asm en est plus restreint),c'est pour ça que je me pose aussi la question.
D'un coté je possédé énormément de ROM , les cartouche SNES pouvais contenir (d’après la doc officiel) "3~4M Bit a 33~64M Bit" , ça laisse pas mal de marge.
Par contre faire un jeu 2D avec 2.68 hz ou 3.58 mhz (les fréquences sont réglable , quelqu'un aurait une idée du pourquoi ?) , donc oui je dois je pense faire un peu attention au perf , certes elle possède une accélération matériel pour la 2D mais j'ignore son potentiel , comme j'ignore ce qu'est capable un processeur de 2/3 mhz mais ça me semble faible , et j'ai pas grandi avec des ordi de ce niveau(avec une SNES oui ) donc j'ai aucune idée si je peux codé sans trop me soucier des perf ou non.
La RAM est minimal 128 ko , et la moitié pour les graphismes , et pas mal de registre sont en mémoire donc pour les donné du jeu je dois avoir 50-60ko.
Mais Forthman vient de dire que on peut pas faire passer ces argument (d'un fonction)via la pile donc je dois le faire niveau variable ?

La pile est en mémoire. Elle utilise le registre SP comme index de pile. Quand tu écris PHA, le micro-processeur décrémente SP puis sauve A à l'endroit pointé. Quand tu écris PLA, le micro-processeur charge A d'abord puis incrémente SP.


À l'époque des huit bits, où la mémoire était limité mais où, surtout, les logiciels étaient mono-tâches et spécialement conçus pour une machine qui ne variait jamais, il était d'usage de se déclarer des variables fixes en mémoire et d'aller taper dedans à volonté, l'usage de la pile pour les données étant anecdotique mais pas inexistant. En C, par contre, pratiquement tout se fait sur la pile. Ce qui est lu ou écrit à des adresses fixes correspond soit aux variables globales, soit à des sections compilées spécifiquement pour la machine-cible.

J'avais bien compris comment fonction la pile ^^
Oui bah perdre mes habitude de programmeur du 21eme siècle , et prendre les habitude de ceux du 20 eme siècle
Blague a part je note une autre façon de codé mais j'ai posté justement pour avoir ce genre de réponse , les bonnes pratique en assembleur et sur de embarqué (et j'ai pas la même approche avec des ordi récents).
J'ai impression que je vais devoir cartographier ma mémoire RAM.

Dans le second extrait, tu peux déjà économiser deux instructions en tête de programme puisqu'il ne sert à rien d'empiler l'accumulateur si c'est pour le dépiler juste après.
Ensuite, si LDA $4219 sert à récupérer l'état du joypad, alors cet état peut varier entre deux sections du programme. Le sauver (dans la pile ou ailleurs) permet d'arrêter cet état à un moment donné et de travailler sur une donnée identique dans toutes les sections de ton code.

Et surtout, c'est dans cette même pile que va être enregistrée l'adresse de retour lors d'un JSR. Donc, en l'absence de pile, pas de fonctions récursives non plus.



Optimiser selon quels critères ? Et notamment, optimiser au profit de la vitesse ou de l'espace occupé ?

Oui effectivement t'as raison pour la pile ,comme dit plus haut j'ai mis mes configurations et n'étant pas expert dans le domaine j 'ai impression d'avoir mes premier doute quand je touchais a la POO ou au procédural et je me demandais quel était la bonne approche , j'ai le même sentiment maintenant.

Merci de tes remarques ,bon content que y'a quelque vétérent en asm sur le forum et quand je m'attaque a un langage je m’intéresse toujours au bonne pratique a avoir ou quel approche est la bonne , mais disons que l'asm plus beaucoup de personne la pratique ardument

[Obsidian]

C'est vrai mais assembleur et les langage plus haut niveau sont pas vraiment pareil et pas la même approche j'imagine (apres en C++ en a le choix en asm en est plus restreint),c'est pour ça que je me pose aussi la question. D'un coté je possédé énormément de ROM , les cartouche SNES pouvais contenir (d’après la doc officiel) "3~4M Bit a 33~64M Bit" , ça laisse pas mal de marge.

C'est vrai. Il y a des chances pour qu'en outre, cet espace soit paginé et pas linéaire. Dans ce cas, les macros te simplifient la tâche (jusqu'à une certaine limite).

Par contre faire un jeu 2D avec 2.68 hz ou 3.58 mhz (les fréquences sont réglable , quelqu'un aurait une idée du pourquoi ?) ,

C'était le cas sur PC pendant un temps (le fameux bouton Turbo) pour pouvoir exploiter les fréquences accessibles par les dernières générations tout en préservant la compatibilité avec les anciens programmes s'appuyant sur une cadence fixe. Mais en l'occurence, ce doit être pour conserver les synchronisations avec les systèmes d'affichages européens, nippons et américains.

Mais Forthman vient de dire que on peut pas faire passer ces argument (d'un fonction)via la pile donc je dois le faire niveau variable ?

Si, on peut et c'est comme ça que le compilateur C procède. Mais il est vrai également que le micro-processeur s'en sert lors des JSR et des des interruptions. Il faut juste penser à laisser suffisamment de place. En outre, le manque de registres peut rendre délicat la manipulation de toutes ces données. Sans compter que les copier dans la pile a un coût non négligeable. Si la fonction est faite pour n'être appelée qu'une ou deux fois dans des contextes définis à l'avance, il peut effectivement être intéressant de faire en sorte qu'elle aille les chercher directement à la bonne place.

J'avais bien compris comment fonction la pile ^^
Oui bah perdre mes habitude de programmeur du 21eme siècle , et prendre les habitude de ceux du 20 eme siècle
Blague a part je note une autre façon de codé mais j'ai posté justement pour avoir ce genre de réponse , les bonnes pratique en assembleur et sur de embarqué (et j'ai pas la même approche avec des ordi récents).
J'ai impression que je vais devoir cartographier ma mémoire RAM.

Ce que je voulais dire, c'est que la taille de ta pile n'est virtuellement limitée que par la taille de ton plan mémoire et que, donc, elle dépend de ta machine et de son système.

[Kannagi]

Ok je note
Pour les fonctions en asm j'ai bien compris donc je réserverai une place spécifique pour les arguments.
Pour la pile pour une utilisation comme variable temporaire si j'ai bien compris.

Merci encore pour vos conseils.