Mini concours ASM 68k - Page 2

GT Turbo>
oui oui mais kochise savait pas que c'était du 68000 à ce moment-là, j'allais pas lui reprocher ça

enfin sinon c'est pas passionnant le calcul de la factorielle parce que ça overflowe super vite, pourquoi ne pas prendre un truc un peu plus intéressant du style :

unsigned int gcd(unsigned int u,unsigned int v) {
  if (u%2>v%2 || u%2==v%2 && u>v)
    swap(u,v);
  if (!u)
    return v;
  else if (v%2==0)
    return gcd(u/2,v/2)*2;
  else if (u%2==0)
    return gcd(u/2,v);
  else
    return gcd(v-u,v);
}

(avec par exemple des entiers 16 bits, c'est suffisant)

-

Pollux :
GT Turbo>
oui oui mais kochise savait pas que c'était du 68000 à ce moment-là, j'allais pas lui reprocher ça

enfin sinon c'est pas passionnant le calcul de la factorielle parce que ça overflowe super vite, pourquoi ne pas prendre un truc un peu plus intéressant du style :

unsigned int gcd(unsigned int u,unsigned int v) {
  if (u%2>v%2 || u%2==v%2 && u>v)
    swap(u,v);
  if (!u)
    return v;
  else if (v%2==0)
    return gcd(u/2,v/2)*2;
  else if (u%2==0)
    return gcd(u/2,v);
  else
    return gcd(v-u,v);
}

(avec par exemple des entiers 16 bits, c'est suffisant)

oui, tout à fait d'accord
la factorielle n'est pas un bon exemple

c'est quoi swap ?

Orion> (par contre tu t'es planté dans les priorités, & a une priorité hyper basse donc faut rajouter des parenthèses ^^)

SebRmv :
c'est quoi swap ?

échanger u et v ^^

Pollux
:

SebRmv :
c'est quoi swap ?

échanger u et v ^^

c'est à dire
tu aurais pas oublié quelque chose ?

#define swap(u,v) { unsigned int temp = u; u = v; v = temp; }
#points_sur_les_i#

Pollux :
#define swap(u,v) { unsigned int temp = u; u = v; v = temp; }
#points_sur_les_i#

désolé, j'avais pas vu le ; après le swap(u,v)

c'est quoi cet algo au fait?

algorithme d'euclide binaire pour calculer le pgcd ^^

(et euh je me suis planté pour la dernière ligne, c'est gcd(v-u,u), pas gcd(v-u,v) :

unsigned int gcd(unsigned int u,unsigned int v) { 
  if (u%2>v%2 || u%2==v%2 && u>v) 
    swap(u,v); 
  if (!u) 
    return v; 
  else if (v%2==0) 
    return gcd(u/2,v/2)*2; 
  else if (u%2==0) 
    return gcd(u/2,v); 
  else 
    return gcd(v-u,u); 
}

)

Ooooooooooooooohhh !! Vous arretez d'écrire des trucs que je comprends pas

En plus vous trollez, regardez le titre :

Mini concours ASM 68k



GT

Pollux :
algorithme d'euclide binaire pour calculer le pgcd ^^

(et euh je me suis planté pour la dernière ligne, c'est gcd(v-u,u), pas gcd(v-u,v) :

unsigned int gcd(unsigned int u,unsigned int v) { 
  if (u%2>v%2 || u%2==v%2 && u>v) 
    swap(u,v); 
  if (!u) 
    return v; 
  else if (v%2==0) 
    return gcd(u/2,v/2)*2; 
  else if (u%2==0) 
    return gcd(u/2,v); 
  else 
    return gcd(v-u,u); 
}

)

ouais, t'as pas pris la version la plus sympa pour gcc
j'imagine qu'en ASM on écrit une jolie version optimisée très facilement
alors que gcc ne fera pas les optim

si on veut jouer à ça, je propose aussi de comparer l'implémentation des arbres AVL en ASM et en C (et on comptera le nombre de bogues surtout!)

je crois donc qu'il vaut mieux arreter là
le but de ce thread n'était pas de troller sur le C vs l'ASM

Pollux
:

Orion_ :

Bah oui, forcément :

	lea	p(PC),A0
	move.l	(4,SP),D0
	move.l	(0,A0,D0.w*4),D0
	RTS
p:	dc.l	1,1,2,6,24,120,720,5040,40320,362880,3628800,39916800,479001600

Euh, tu fais le malin mais c'est encore loin d'être optimal -- tu pourrais utiliser un adressage pc-relatif, et ne charger que 16 bits dans d0

dc.L <- un L comme L donc on charge un LONG dans D0

Pollux :

Kochise
:

SebRmv :
[...]en fait, j'ai été plutôt étonné par le code produit par gcc[...]

Positivement ou négativement ? Depuis 1998 et la nouvelle norme ISO, les compilos sont dotés d'un nouveau cerveau et pondent en général un code proche d'un assemblage alamano Gcc est pas trop mal foutu dans le domaine !

Mais n'importe quoi, quel est le rapport avec C99 ? Et j'aurais plutôt tendance à penser que pour les "vieilles" plateformes style 68k qui sont plus trop maintenues, un compilo comme Gcc ne s'améliore pas avec le temps, bien au contraire, il "pourrit" :/

Je suis entienrement d'accord avec toi, mais il doit y avoir une cible 68k qui doit tjrs être plus ou moins activement maintenue dans GCC, c'est celle poru les Coldfire, qui sont apres tout des 680x0... Il me semble pas que ce µC soit trop en perte de vitesse...

Le rapport avec C99 ? Une base commune normalisée par l'ISO pour tous les concepteurs de compilateur C, avant les directives et les standarts étants plus ou moins respectés...

Kochise

ce qu'il veux dire c'est que le C99 ne fait pas faire des compilo qui optimisent mieux...

Qui compilent mieux (éviter les exe d'1 MiB pour un "Hello World!", oui). Pour l'optimisation, c'est aussi l'expérience acquise des codeurs de copilo, mais aussi les nouvelles règles qui permettent de mieux organiser le code généré, et donc de l'optimiser plus efficacement. Enfin je dit ça, moi c'est surtout l'expérience dans les VM que j'en tire, et vu qu'à peu de choses près c'est la même chose...

Kochise

je n'ai jamais eu un seul executable de 1Mo en C (pas en C++ !!) pour afficher "Hello World" et ce quelque soit le compilo (et se depuis plusieurs années)

J'ai l'impression que bcp confondent C et C++...

Et les "codeurs de compilo" ils font leur backend pour certain proco, pas tous, et les target tel le 68000 font partit des target qui sotn de plus en plus désuettes, et de moins en moins supportée, donc je vois mal des gens se faire chier a améliorer le support de ses cibles.

Et par VM tu pense a quoi ?

.NET framework ? Java ?

Ce sont des cibles qui sont activement utilisé, donc bcp d'effort sont fait dessus..

Et pour information si je fait un backend pour un proc exotique, je bénéficierais pas "automatiquemtn" de ce qu'on fait les autres sur les backend pour d'autre proco.. Le code asm, et les optims faisables sont trop spécifique a un proco/génération (une optime pour un 68000 peut tres bien etre plus lente sur un 68030 et vice-versa)

Kochise>
- quel est le rapport avec la taille d'hello world ? C99 ne change rien là-dessus, ou alors pas dans le bon sens ^^ et je pense aussi que de nos jours, les compilos se préoccupent plutôt moins de gagner 100 ko sur un hello world qu'à l'époque des ordinateurs avec 4 Mo de RAM et des disquettes comme seul support amovible...
- quelles nouvelles règles ? à part "restrict" qui doit pas être utilisé souvent, je vois pas de quoi tu parles...

SebRmv :
ouais, t'as pas pris la version la plus sympa pour gcc
j'imagine qu'en ASM on écrit une jolie version optimisée très facilement alors que gcc ne fera pas les optim

rien compris, de quelle optim tu parles ?

Kochise :
dc.L <- un L comme L donc on charge un LONG dans D0

je parle du premier move.l : tu n'as pas besoin de la partie haute du nombre dont tu calcules la factorielle ^^

Godzil :
Je suis entienrement d'accord avec toi, mais il doit y avoir une cible 68k qui doit tjrs être plus ou moins activement maintenue dans GCC, c'est celle poru les Coldfire, qui sont apres tout des 680x0... Il me semble pas que ce µC soit trop en perte de vitesse...

Ben, c'est encore utilisé donc ça marche encore bien et ça régresse pas au point de faire du code 2x plus lent que les versions précédentes, mais c'est pas suffisamment critique pour que les algos de gcc en tiennent compte : si tu regardes tous les algos de propagation de constantes et tout et tout, tu vois que c'est bien plus adapté à un processeur style x86 où on a un gros cache et où add #valeur_compliquée,d0 ne coûte pas plus cher que add d1,d0... (et à vrai dire y a pas que les algos qui posent problèment : y a plein d'optimisations qui seraient vraiment triviales à faire [transformer une instruction en une autre] qui ne sont pas faites, preuve que pas grand monde ne s'est penché dessus)

Pollux
:

SebRmv :
ouais, t'as pas pris la version la plus sympa pour gcc
j'imagine qu'en ASM on écrit une jolie version optimisée très facilement alors que gcc ne fera pas les optim

rien compris, de quelle optim tu parles ?

l'intuition... à coup de décalage et de bit C du CCR, on doit pouvoir faire une belle version en ASM et ça m'étonnerait beaucoup que gcc approche de cette version

mais bref

Ouais mais c'est un peu normal, bien que la cible 68k (aka 68332) est très utilisée dans le milieu industriel, c'est pas GCC qu'ils utilisent mais plutôt GreenHill et consorts. Et ces compilos industriels, je peut vous dire qu'ils sont au poil coté optimisation (genre orienté "3 ko dans le GPU et 16 ko dans le DSP") ! Mais comme dit, du à la désuétude de la plateforme 68k dans les ordinateurs de bureau (le Mac l'ayant abandonné depuis longtemps, seul CodeWarrior s'y interresse encore), c'est un peu normal qu'on se traine une vieille 2.95 pour 68k depuis des lustres

Kochise

PS : Machine virtuelle genre NekoVM, LUA, EEL, ...

-

SebRmv
: l'intuition... à coup de décalage et de bit C du CCR, on doit pouvoir faire une belle version en ASM et ça m'étonnerait beaucoup que gcc approche de cette version

ah ok, mais en fait je sais pas si ça a tant d'influence que ça sur la vitesse : avec 2*8 cycles gcc peut calculer u%2 et v%2 pour tout la fonction, ça peut même lui gagner du temps parce qu'il n'a pas à faire de shift [= 12 cycles] qd ça n'est pas nécessaire

cela dit je vois pas vraiment quelle serait la version "sympa pour gcc" qui éviterait ce problème ?

Kochise :
Ouais mais c'est un peu normal, bien que la cible 68k (aka 68332) est très utilisée dans le milieu industriel, c'est pas GCC qu'ils utilisent mais plutôt GreenHill et consorts. Et ces compilos industriels, je peut vous dire qu'ils sont au poil coté optimisation (genre orienté "3 ko dans le GPU et 16 ko dans le DSP") ! Mais comme dit, du à la désuétude de la plateforme 68k dans les ordinateurs de bureau (le Mac l'ayant abandonné depuis longtemps, seul CodeWarrior s'y interresse encore), c'est un peu normal qu'on se traine une vieille 2.95 pour 68k depuis des lustres

Orion_ :
pourquoi faut il que ça parte toujours en troll des que certaine personne debarque :/

un troll ? à part avec kochise qui disait un peu n'importe quoi et avec lequel j'étais pas vraiment d'accord jusqu'à ./51, je vois pas ^^ (et puis franchement je pense que c'est plus intéressant/constructif d'en discuter que de ne surtout pas contredire qqun d'autre parce que sinon on est un vilain troll)

Kochise :
GreenHill

GreenHill ? arf j'espere qu'il y a mieux pasque bon dans la boite ou je suis on a bossé avec et si ce n'est les pbms de licences (hyper restrictives) c'est un compilo qui a posé bcp de soucis alors que le portage du code du VisualStudio vers GCC (et vice-versa) n'avais posé strictement aucun pbm...

Kochise :
une vieille 2.95 pour 68k

Arf, tu sais il existe des version de GCC qui compilent pour 68000 et qui sont des GCC 3 et 4 hein ^^

(demande a Kevin K. il pourrat t'aider ^^)

-

SebRmv :
alors, vos impressions?

Oui, les voici

voyons voir maintenant ce que donne l'option -O2

Là je commente :

_fact:
        movel d2,sp@-
        movel sp@(8),d2	; oui, on pourrait s'autoriser à faire "move.w 10(sp),d2"
        moveq #1,d0
        tstl d2		; dommage, le test était gratuit si on ramenait le move.l ici!
        jeq L1		; bien vu! le plus souvent, ce test sera négatif.
        movel d2,a0
        pea a0@(-1)	; ok, mais ça c'est "pea -1(a0)" ou "pea -(a0)" ?
        jbsr _fact
        mulsl d2,d0	; ok, mais on pouvait pas faire du récursif terminal?? ;-)
        addql #4,sp
        .even
L1:
        movel sp@+,d2
        rts

Maintenant que j'y réfléchis, "pea -(a0)" ça n'existe peut-être pas. En tout cas, ça rajoute un mot (le -1) à l'instruction, qui pourrait nous servir à caser un "subq.l #1,dx". On s'extasie à juste titre de l'astuce, mais chrono en main, y gagne-t-on vraiment?

en fait, c'est là que j'ai été un peu surpris par l'utilisation de pea pour calculer (n-1) et en même temps empiler le paramètre
(je n'aurais jamais pensé à ça en fait !)
je suis content d'avoir appris cette optim en tout cas

Oui, tiens j'en reparlerai dans mon article à venir sur des optims 68k.

enfin, voici ce que donne gcc quand on donne comme processeur m68000 au lieu de m680x0 (par défaut), avec -fomit-frame-pointer et -O2

Pas mal du tout!

_fact:
        movel a2,sp@-
        movel sp@(8),a2
        moveq #1,d0
        cmpw #0,a2	; sublime, le cmp.w !!
        jeq L1
        pea a2@(-1)
        jbsr _fact
        movel d0,sp@-
        movel a2,sp@-
        jbsr ___mulsi3
        lea sp@(12),sp	; pas mal d'avoir regroupé les 2 corrections de pile!
        .even
L1:
        movel sp@+,a2
        rts

Bref, pour conclure c'est génial de pouvoir code la Jaguar en C, c'est quand même bien ça l'essentiel!!

on remarque que là ce n'est plus mulsl qui est utilisé mais une fonction auxiliaire qui émule cette multiplication longue (modulo 2^32)

Oui elles sont malines ces fonctions, c'est marrant à déssassembler

stabylo :
Bref, pour conclure c'est génial de pouvoir code la Jaguar en C, c'est quand même bien ça l'essentiel!!

et encore, on dirait que tu n'as pas vu ce thread topics/88824-du-c-kinenveu

stabylo :
cmpw #0,a2 ; sublime, le cmp.w !!

Du bon code de compilo rien de tel pour rigoler un coup


GT

GT Turbo :
Du bon code de compilo rien de tel pour rigoler un coup

En fait, il me semble que c'est plus malin qu'il n'y paraît. Certes il n'est pas possible de faire un "tst.l a2", c'est un "cmp" qui est utilisé. ok. Mais il aurait pu faire "cmp.L", mais non, il fait un "cmp.W" car l'extention du #0 de 16 à 32 bits permet de gagner 2 octets dans le code produit. C'est ça que je trouve joli (et sans ironie!).

(Bon, mais en fait il aurait pu faire un "move.l a2,d0" pour faire le test, quitte à passer le "moveq" deux fois après le test, une fois dans chaque branche du code. Mais c'est un compilo, il faut être indulgent quoi. )