Boucle For transformé en asm - Page 2

+ ++

(Anti C++)

A + ++ Powered !!!!



GT

Folco (./29) :
Que mon code soit assemblé au micron près, ou qu'il ne le soit pas du tout. Mais on ne devine pas mon code, on ne le triture pas, on ne le modofie pas : on assemble.

A ce moment là il faut coder en hexa, un assembleur est tout à fait supposé changer ton code, parce qu'il est symbolique.
Typiquement rien que la gestion des liens est une énorme aide, et nécessite en fonction des processeurs de générer du code différent selon que le lien est à portée ou loin (saut relatif si encodable dans les 12 bits de l'opérande signée par exemple, ou référence absolue sinon).
L'assembleur va gérer ça, car tu ne veux pas avoir tout à coup à modifier d'anciennes parties de ton programme car tu as inséré du code au milieu qui rend certains sauts trop larges pour être possibles. Inversément si des références relatives redeviennes possibles, on peut être content qu'elles soient utilisées.
Seul le code binaire te garantit que ce que tu vas faire tourner correspond à ce que tu as écrit, au prix d'une maintenance rendant quasi impossible le codage d'un jeu d'un niveau supérieur à Super Mario Land ^^

Folco (./29) :
on ne le modofie pas

syntax error

C'est pourtant clair : pas d'intervention de modo pour éditer le source à la compile

aaaaaaaaaahhh, ok ok ok

GT Turbo -> C'est mieux comme ça ? (merci Zerosquare \o/)
Et sinon, si, tu peux lire mon code, où est le problème ?


Brunni -> je sais, je sais. Je connais bien ça. Tout ton poste tourne autour d'une seule instruction : bsr. Sauf que là, il ne s'agit pas d'une question d'assemblage mais de linking. L'assembleur est là pour créer un fichier objet, pas un binaire. Que le linker résolve les sauts ne me pose aucun problème, c'est d'ailleurs étudié pour comme dirait Fernand Reynaud. Sauf que si j'ai impérativement besoin d'un bsr.s, je lui dirai. Et si ça ne peut plus linker, il me le fera savoir. Si à l'inverse je veux un bsr.w, je lui dirai également, et ma volonté sera exécutée. Si enfin je m'en fous, je lui laisse faire au mieux.
Mais l'assembleur, lui, n'a à toucher à strictement rien.
Si j'écris un clr.l dn, c'est pas pour avoir un moveq #0,dn. Si j'écris un adda.l #x,an, c'est pas pour avoir un lea x(an),an. Etc... Et j'entends que l'assembleur respecte ça à la lettre.

A noter d'ailleurs que le code de ld-tigcc n'est pas optimal au niveau des bsr, et ne produira pas toujours des références courtes, même si c'est possible, par exemple dans le cas de références croisées. Une solution pour linker au mieux est de tenter de tout coder en références courtes, et d'étendre au fur et à mesure les références impossibles.

Folco (./37) :
Et si ça ne peut plus linker, il me le fera savoir. Si à l'inverse je veux un bsr.w, je lui dirai également, et ma volonté sera exécutée. Si enfin je m'en fous, je lui laisse faire au mieux.

Ouaip, mais je vois mal pourquoi tu voudrais explicitement choisir le type de saut car ça ne peut apporter que des désavantages si tu te trompes, rien si tu fais juste. (et si tu veux faire du code auto-modifiant, il existe d'autres moyens, mais c'est une mauvaise pratique question sécurité de toute façon).

Perso j'ai pas mal fait de l'assembleur MIPS par exemple, où un grand nombre d'opérations sont symboliques. Exemple:
- Si tu veux faire un branch "b Label" tu fais en réalité un branch if greater than zero, avec le registre $0 (câblé à la valeur zéro) comme opérande.
- Un "move $dest, $source" fait "add $dest, $source, $0"
- Un "not $dest, $source" fait un "nor $dest, $source, $zero"
- etc.
Techniquement l'overhead ne coûte rien (ça prend un cycle, c'est encodé dans les 32 bits de l'instruction comme tout le reste, et ça économise la complexité d'avoir plus d'instructions). Tu as également des instructions qui peuvent se subdiviser en plusieurs. Par exemple, load immediate (32 bits) "li $dst 0x12345678" fera:
lui $dst, 0x1234 # (load 16 upper bits)
add $dst, $dst, 0x5678 # (add lower bits)
Enfin, il y a même un registre réservé à l'assembleur pour stocker le résultat temporaire de certaines instructions. Evidemment, tu connais la liste des instructions "réelles" et "symboliques", mais ces dernières sont bien pratiques en fin de compte

Bon t'as raison. Sauf que dans le cadre qui nous intéresse on parle de 68k et pas de sécurité, et surtout optimisation vitesse (cf sujet du thread). Et le smc est parfois la plus rapide des solutions, surtout dans le graphisme. Cf Extgraph et Genlib. Et c'est là que t'as besoin d'être sûr à 300% de ce que te pond l'assembleur.

Et le fait d'avoir des macros pour ton mips ne change rien au fait que tu attends une génération précise derrière ce que tu as écris. Que tu te rajoutes une couche par facilité est ton choix, c'est légitime, mais ça ne change rien au problème de la fidélité de la génération.

GT Turbo (./30) :
What else ? Je suis tout a fait d'accord, et je regarderais pas ton code, j'en ai assez en 'attente' Ca serait pas 'règlo' de regardé ton code alors que dans le mien il y a du nettoyage a faire

Ah, je comprends pourquoi tu disais que tu voulais pas lire mon code
Quand je disais "on ne triture pas, on ne [...]", je parlais de l'assembleur qui le lit, pas de quiconque veut le lire, le modifier, et le redistribuer (il est sous GPL). Toi évidemment, tu en fais ce que tu veux

Je disais ça aussi parce que vu le déclin de la communauté, j'ai rarement vu de critiques sur mon code, et vu ce que je lis, t'as l'air de toucher ta bille en 68k, donc ton avis sera toujours très bienvenu sur mon code, movea/adda/suba/cmpa ou pas

Folco (./39) :
Bon t'as raison. Sauf que dans le cadre qui nous intéresse on parle de 68k et pas de sécurité, et surtout optimisation vitesse (cf sujet du thread). Et le smc est parfois la plus rapide des solutions, surtout dans le graphisme. Cf Extgraph et Genlib. Et c'est là que t'as besoin d'être sûr à 300% de ce que te pond l'assembleur.

Oui, sauf que la question d'origine ne portait pas sur le 68000. Je dis juste que ton raisonnement est spécifique au 68k, qui est très particulier comme proço (il est abominablement lent lorsqu'il s'agit de faire des "if" ou à calculer et exécuter une table de saut et retourner d'une sous routine comparé à des opérations basiques comme move.b, mais sur la plupart des autres proços, surtout RISC, c'est totalement différent).

Folco (./40) :
Je disais ça aussi parce que vu le déclin de la communauté, j'ai rarement vu de critiques sur mon code, et vu ce que je lis, t'as l'air de toucher ta bille en 68k, donc ton avis sera toujours très bienvenu sur mon code, movea/adda/suba/cmpa ou pas

J'ai trop de respect pour ceux qui dev en assembleur (et encore plus pour de l'asm Moto ) pour aller critiquer ces personnes mais dès que j'ai 5 minutes je regarde.

On va dire que je suis issue de la scène demomaker, très très bonne école pour l'optimisation et le comptage des cycles O_o !!

Et pour ceux qui veulent regardé mes codes, je les distribue sans aucun soucis, il y en a un d'ailleurs que je dois releasé très vite (qui traine sur le dur de mon Falcon dont est d'ailleurs extrait les exemples donnés plus haut).


Brunni tu compare le 68000 a des procs de sa génération j'espère ? Car le 68000 est née en 1979 et est encore utilisé de nos jours, trouve moi un seul autre proc encore utilisé après 33 ans !!!! Donc comparé a des procs actuels c'est pas règlo

Sinon compare a un 68060 et prépare tes mouchoirs


GT Folco

P.S. : Suite a ton changement d'avatar, je ne dire plus qu'une chose : PERFECT !!

Le 68000 est très bien hein, mais je crains que ceux qui sont trop habitués à raisonner pour ce processeur auraient* énormément de peine à travailler avec d'autres. Il n'y a qu'à voir la peine que les gens ont eu à quitter le 68k au milieu des années 90, alors qu'on avait des alternatives bien meilleures si elles avaient étaient exploitées aussi bien que le 68k (désolé). D'où ma petite pique

* Subjectif + conditionnel après = quel temps ? "N'eussent" plutôt ?

GT Turbo (./42) :
Brunni tu compare le 68000 a des procs de sa génération j'espère ? Car le 68000 est née en 1979 et est encore utilisé de nos jours, trouve moi un seul autre proc encore utilisé après 33 ans !!!! Donc comparé a des procs actuels c'est pas règlo

Hum:

Le 80(0|1)86 est encore utilisé dans certains microcontrolleurs (1978),
Le 8051 l'est aussi (1980)
Le 6502 l'est aussi (1975)
Le Z80 est toujours utilisé (1976)

Et j'en passe

y'a le 74LS273 qui est encore plus vieux !

Et que dire du 7401 !

(ouais enfin le mien, il a un registre )
ouais, c'était prémédité

GT Turbo (./42) :
J'ai trop de respect pour ceux qui dev en assembleur (et encore plus pour de l'asm Moto ) pour aller critiquer ces personnes mais dès que j'ai 5 minutes je regarde.

Cool merci. Quand je parle de critiques, c'est bien évidemment constructives, le but étant de progresser. Je connais pas du tout ta manière de coder, du coup l'approche d'un problème par un autre oeil peut faire sortir des habitudes prises et faire découvrir des trucs sympas.

OCaml powa </utile>

Bovido tu sors !!!

On parle de vrai langage içi !!! Pas de ramassis de C compilé avec les pieds ou même leur propres auteurs arrivent pas a se dépatouiller !!


GT du groupe de libération de l'ASM !!! ( Asm ++ !! )

C’est pas du C, qu’est-ce que tu me racontes ? C’est blessant de comparer le plus bas avec le plus haut.

Je veux bien t’accorder que l’ASM est indispensable à côté, mais le C, on peut s’en passer, on sera d’accord.

Fais un kernel en OCaml toi...

C’est tout autant impossible que d’en faire un avec que du C, et comme j’ai dit :

Bovido (./51) :
Je veux bien t’accorder que l’ASM est indispensable

Linux, le code et 99.99999999999% en C je crois même que certaines archi il n'y as pas de code asm...

Ce n'est pas la première fois que j'arrive à la limite du système:
Warning("CSusie:PaintSprites(): Single draw sprite limit exceeded (>4096). The SCB is most likely looped back on itself. Reset/Exit is recommended

Je ne vois pas à quoi correspond très exactement ce nombre, 4096. C'est la quantité de vram ?

A premiere vue je dirais le nb de sprites maxi affichables mais on va attendre les experts pour éclaircir la situation.


GT Limite

Avec une liste chainée de sprites ?
Tu es sur de ne pas boucler ?

Il n'y a théoriquement pas de limite au nombre se sprites affichables, mais peut-être dans une même liste chainée ou une limitation Handy ?

Fadest (./57) :
Avec une liste chainée de sprites ?
Tu es sur de ne pas boucler ?

Il n'y a théoriquement pas de limite au nombre se sprites affichables, mais peut-être dans une même liste chainée ou une limitation Handy ?

oui une liste chaînée. Il y a d'abord une image de 200x102 puis le titre et un personnage de bonnes tailles aussi. Puis j'ai lié une déclaration multiple de sprites, la console affiche bravements 9 sprites de 24x16 mais au delà le message d'erreur apparaît. Je pense que la console ne peut afficher/gérer d'avantage de pixels.

Mais il ne peut s'agir de 4096 pixels.

Je ne vois pas le rapport avec les pixels...

Le message est plutôt clair, il dit que l'ordre d'affichage DrawSprite) veut afficher trop de sprites d'un coup, et que la limite (Suzie ou Handy) est de 4096. Est tu sur de ta liste chainée, en particulier, est elle bien terminée ?
Combien de sprites entends tu par une "déclaration multiple de sprites" ?

J'ai identifié le problème. Dans la déclaration multiples de sprites il y a le nombre 16320, probablement la position en mémoire, j'ai mis des valeurs de plus en plus importante, et à partir de 33000, la console aime bien. C'est la première fois que je lie des sprites multiples à d'autres sprites déjà présent, ceci expliquant cela.

Problème résolu.