Re: Sgdk - Sega Megadrive / Genesis Development Kit

[chrilith]

Ah c'est cool ça, mais ce sont des builds cygwin ou mingw ? il me semble que les builds cygwin ont besoin d'un environnement cygwin pour fonctionner non ?
Sinon je suis preneur d'un GDB qui marche bien, j'ai l'impression que la version que je livre avec SGDK n'est pas géniale (du moins je n'ai jamais réussi à la faire fonctionner correctement avec  les émulateurs qui sont censés supporter GDB).

....

Il faudrait peut être que je fasse un peu de nettoyage mais normalement j'essaie de conserver que le nécessaire.
A peu près tout les outils que tu as cité sont nécessaires pour le compilateur de ressource (rescomp) ou le makefile.
Quelques notes sur les outils suivants :
- mac68k --> en fait il s'agit de l'outil maccer qui transforme un fichier source assembleur 68000 format AT&T (GCC) en format Intel
- nm2wch --> un outil pour générer une table de symboles pour GensKMod.
- uftcpack --> compresseur UFTC de Sik mais qui n'a plus lieu d'être (je l'enlèverai sur la prochaine version je pense), le format LZ4W lui étant préférable.
- z80dasm --> probablement un desassembleur Z80, franchement je ne sais pas ce qu'il fout ici ^^
- xgmRomBuilder --> un outil pour construire un ROM player XGM à partir d'une compilation de fichier VGM, je ne savais pas où le mettre :p

Non, il y a juste besoin des DLL comme c'est déjà le cas dans le SGDK puisque ce qui faisait planté c'est la vieille DLL Cygwin
Voici donc les exe : http://chrilith.com/temp/sgdk.zip

Tu verras que certains EXE son beaucoup plus gros, je ne sais pas pourquoi, surement un changement dans les dernières version de GCC qui produit du plus gros.

EDIT/ ne pas copier le sh.exe, pas le bon fichier il semble...
EDIT2/ Bon je viens de tester le debugger, ca marche mieux que l'autre sauf que : 1. les chemins sont en mode cgywin, donc il ne trouve pas le fichier, il faut lui dire ou est le source, je vais donc regarder ca... 2. les breakpoints fonctions mais le continue revient étrangement à la même ligne en boucle, une fois le bp enlevé ca continue correctement. Je ne sais pas si ca vient de GDB ou bien de KMod.
EDIT3/ Je vais recommencer avec MSYS2 plutôt que Cygwin....

Le GDB est bien dedans amis je ne suis pas sur que ca marche mieux car KMod ne permet pas l'ajout de breakpoint de ce que j'avais pu lire, ensuite je lis ca : http://gendev.spritesmind.net/page-gdb.html et il semble que si... il faudrait que je réessaie. J'attends un retour de BlastEm! pour le bug de connexion a debugger sous Windows 10.

Pour le problème de inline, si c'est confirmé on pourra facilement compiler une version plus récente de GCC. Ce serait bien de confirmer aussi que cc1.exe et cpp.exe ne servent plus (pour moi c'est bien le cas) histoire de faire le ménage. 

Pour tous les projets "locaux" se serait bien aussi d'avoir un MAKEFILE, ca simplifierai aussi le portage multiplateforme car la, le même script de build pourrait servir pour l'ensemble des plateforme. Surtout que tes petits utilitaires sont semble-t-il facilement compilable sans modification.

Peut-être qu'il faudrait aussi ajouter les outils de Kaneda:
- maccer X pourrait remplacer mac68k ? Le code est en plus dispo. SI oui je l'ajoute au build script.
  http://gendev.spritesmind.net/page-macX.html
- Ajout de l'export pour le debug avec watchers
  http://gendev.spritesmind.net/page-nm2wch.html

What you think?

[Tryphon]

Juste pour dire que celui qui trouve comment inliner des fonctions de façon cohérente avec GCC et SGDK, je lui fais des poutous

[Stef]

Non, il y a juste besoin des DLL comme c'est déjà le cas dans le SGDK puisque ce qui faisait planté c'est la vieille DLL Cygwin
Voici donc les exe : http://chrilith.com/temp/sgdk.zip

Tu verras que certains EXE son beaucoup plus gros, je ne sais pas pourquoi, surement un changement dans les dernières version de GCC qui produit du plus gros.

EDIT/ ne pas copier le sh.exe, pas le bon fichier il semble...
EDIT2/ Bon je viens de tester le debugger, ca marche mieux que l'autre sauf que : 1. les chemins sont en mode cgywin, donc il ne trouve pas le fichier, il faut lui dire ou est le source, je vais donc regarder ca... 2. les breakpoints fonctions mais le continue revient étrangement à la même ligne en boucle, une fois le bp enlevé ca continue correctement. Je ne sais pas si ca vient de GDB ou bien de KMod.
EDIT3/ Je vais recommencer avec MSYS2 plutôt que Cygwin....

Le GDB est bien dedans amis je ne suis pas sur que ca marche mieux car KMod ne permet pas l'ajout de breakpoint de ce que j'avais pu lire, ensuite je lis ca : http://gendev.spritesmind.net/page-gdb.html et il semble que si... il faudrait que je réessaie. J'attends un retour de BlastEm! pour le bug de connexion a debugger sous Windows 10.

Pour le problème de inline, si c'est confirmé on pourra facilement compiler une version plus récente de GCC. Ce serait bien de confirmer aussi que cc1.exe et cpp.exe ne servent plus (pour moi c'est bien le cas) histoire de faire le ménage. 

Pour tous les projets "locaux" se serait bien aussi d'avoir un MAKEFILE, ca simplifierai aussi le portage multiplateforme car la, le même script de build pourrait servir pour l'ensemble des plateforme. Surtout que tes petits utilitaires sont semble-t-il facilement compilable sans modification.

Peut-être qu'il faudrait aussi ajouter les outils de Kaneda:
- maccer X pourrait remplacer mac68k ? Le code est en plus dispo. SI oui je l'ajoute au build script.
  http://gendev.spritesmind.net/page-macX.html
- Ajout de l'export pour le debug avec watchers
  http://gendev.spritesmind.net/page-nm2wch.html

What you think?

Bon visiblement pour le debugger tu rencontres les mêmes soucis que moi...
Pour les exe type sh.exe / rm.exe, j'étais passé par MSYS, pour GCC il me semble avoir tout compilé via du mingw.
Et dans  mon cas si je vire cc1 ou cpp je sais que je peux avoir des erreurs à certaines endroits (genre linkage). Peut être que tes exe plus gros inclus tout en statique.
Pour le problème du inline, effectivement les version plus récentes corrigent ce problème mais en contrepartie elles sont beaucoup moins performante sur la partie optimisation de code pour le target m68k du coup au final tu te retrouves avec du meilleur code avec le vieux GCC 3.4.6. Pour être plus précis les derniers GCC 2.x sont même encore meilleurs en terme de code générés pour m68k mais ils sont vraiment trop obsolètes, GCC 3.4.6 est un bon compromis on va dire.
Comme tu dis, ça serait pas mal d'avoir un makefile generique qui compile les différents petits outils. Mais à dire vrai, je réfléchis sérieusement à passer tout ces petits outils en java. Le java est executable quelque soit la plate forme (sitôt qu'on a installé une JVM quand même) et surtout en terme de développement c'est infini plus simple que de se taper du vieux C :-/
Pour maccer X, s'il fait exactement la même chose oui c'est bien mieux, je vais rajouter ces 2 projets (maccer X et nm2wch) merci :)

[chrilith]

C'est sur... à l'époque pour PalmOS c'était du 2.95, perso j'utilisais CodeWarrior, vraiment top. Je me demande si je ne peux pas récupérer quelques executables histoire de me faire une toolchain perso. Genre je dev avec du GCC et ensuite je recompile avec CodeWarrior...

Pourquoi il ne passe pas les vieux soft en gratos...

Sinon j'ai essayé MSYS2 mais rien ne compile, des erreurs partout. Pas envie de trop chercher pourquoi. Déjà je en comprends pourquoi mes exe sont aussi gros, surtout le GDB !!!

EDIT: OK, il suffit de stripper les exe.... reste juste le probleme du sh, pour les chemin d'accès sur GDB ca peut etre facilement remappé dans Eclipse, pas de problème donc

[Stef]

Tu as activé les optimisations sur la taille lors de la compile (-Os) ? En général c'est un bon compromis en terme de performance et de taille des exe. Pas besoin de passer en -O3 sur la compilation de GCC, mais -Os c'est plutot bien pour limiter un peu la taille des exe. Peut être aussi as tu une option qui fait des liens statiques là où moi j'ai utilisé plus de liens dynamiques (et donc la nécessité d'avoir plus de fichier exe pour que le toolchain fonctionne correctement).

[chrilith]

Bon, j'arrive pas à trouver le problème avec GDB. Après chaque breakpoint, on boucle systématiquement sur _VINT. Je me demande si le problème ne vient finalement pas d'ailleurs, peut-être la lib SGDK ou bien Gens KMod...

En supprimant le breakpoint en cours on peut passer au suivant, pas bien pratique mais ca peut aider. Un "nexti" ne passe pas à la suite et boucle aussi.

Sinon j'ai trouvé ca, si ca parle à quelqu'un :
https://sourceware.org/ml/gdb/2011-01/msg00008.html
https://www.cygwin.com/ml/crossgcc/1997/msg00346.html

j'ignore si c'est en rapport.

Sinon pour Atari, ici on utilise le GDB 5.1, le dernier que j'ai essayé est 6.6a. Peut-être qu'une compilation avec GCC 2.95 pourrait aussi mieux marcher...
http://vincent.riviere.free.fr/soft/m68k-atari-mint/

Peut-être les deux derniers tests que je ferais si le temps. J'attends un retour de BlastEm pour faire des tests aussi.

A+

[Stef]

J'avais *exactement* le même problème... et franchement pour moi ça rendait le debugging impossible. Surtout qu'à force d'enlever et ajouter les breakpoints ça finissait par tout planter GDB.

En fait j'avais trouvé un bug dans Gens KMod à propos du support GDB. Il me semble que les opérations d'accès à la mémoire ont un bug quand tu sors de la plage 24 bits (car l'adressage du 68000 se fait sur 24 bits) avec GDB. Par exemple si GDB demande à lire la valeur à l'adresse 0xFFFFFF00 (provenant du registre A7 par ex) plutot que 0x00FFFF00 (ce qui en théorie revient au même) alors Gens KMod lui retourne une valeur incorrecte. J'en avais parlé avec Kaneda mais visiblement ce n'était pas simple à corriger... je crois que ça expliquait la confusion de GDB qu s'arrêtait alors systématiquement dans Vint (problème de stack pointer). Avec BlastEm il me semble que j'ai même pas été aussi loin

GCC 2.95 m'interesse pas mal car il produit un meilleur code pour le m68k

[chrilith]

Bon j'ai un GCC 2.95.3 mais bien sur rien ne compile à cause des directives de préprocesseur qui ont largement changées depuis 2001... donc soit tu revois tous tes headers, soit c'est pas la peine d'essayer :)

Ca m'a pris au moins 3j pour corriger tout les problèmes de compilation du vieux GCC.

[Stef]

Outch, c'est à ce point ?? Pourtant dans SGDK je n'abuse pas des directives de compilation :-/
Tu as un exemple tout bête ?

[chrilith]

Code:

#define SWAP_u8(x, y)       \
{                           \
    u8 swp;                 \
                            \
    swp = x;                \
    x = y;                  \
    y = swp;                \
}

Ca pas être possible sous cette forme. Pas de retour à la ligne et des parenthèses pour encadrer les accolades.

[Stef]

Ha ouais ça craint... des define de ce genre j'en ai partout. Je ne savais pas que GCC < 3 avait une syntaxe aussi foireuse. Je comprends pourquoi on recommande au moins la version 3 du coup.

[chrilith]

Il est aussi possible d'utilise un préprocesseur plus récent (cpp.exe à renommer en cpp0.exe), mais le cc1 passe aussi par là, je ne sais pas qui compile quoi précisément.

Voici l'archive si tu veux essayer. Normalement j'ai mis tout ce qui est nécessaire (cc1.exe cpp0.exe inclus !)

http://chrilith.com/temp/sgdk-gcc2.95.3.7z

ATTENTION les autres, je déconseille si vous ne savez pas précisément ce que vous faites

[Stef]

Merci ! J'essai ça dés que j'ai un peu de temps ! J'aimerai surtout comparé le code généré :) et puis je vais tenté le inline, ça trouve il fonctionne dans GCC 2.95 (ça serait trop beau ^^)

[Orion_]

tant qu'a changer de version de compilateur, autant prendre une version carrément plus récente non ?
gcc 6.2 à été compilé pour Atari 68k
http://d-bug.mooo.com/beyondbrown/post/gcc-6/
et apparemment on peut même voir le code généré en live ici:
http://brownbot.hopto.org/

[Tryphon]

Mais est-ce que le code est bien optimisé ?

Edit : de là où je suis (hot-spot Mac do) je ne peux pas consulter tes liens.

[Hpman]

Code:

#define SWAP_u8(x, y)       \
{                           \
    u8 swp;                 \
                            \
    swp = x;                \
    x = y;                  \
    y = swp;                \
}

Ca pas être possible sous cette forme. Pas de retour à la ligne et des parenthèses pour encadrer les accolades.

Pourtant j'utilise ce genre de choses avec un 2.95.2 et ça fonctionne correctement 

[chrilith]

Zarb ouais... ca dépend du préprocesseur, c'est bien un 2.95.3 le cpp ?

Sinon voici une préversion du 6.2.0:
http://chrilith.com/temp/sgdk-gcc-6.2.0.7z

[Hpman]

2.95.2 comme le gcc.

C'est pas ton utilisation de la macro dans ton code qui pose problème?

[Stef]

Le problème avec les version récente de GCC :
- la taille des exe (des tonnes de features dont on se fout royal en target m68k) !
- le génération du code complètement farfelue.

Maintenant peut être qu'avec GCC 6 le code est de nouveau correct mais en GCC 4 et 5 c'est vraiment pas terrible :-/

Génial ton lien Orion ! C'est super de pouvoir tester en live comme ça :)

[chrilith]

2.95.2 comme le gcc.

C'est pas ton utilisation de la macro dans ton code qui pose problème?

Non les erreurs son dans les headers du SGDK à commencer par memory.h, le premier inclus (ligne 73). Si je change le format, ça passe (l'erreur disparaît sur cette ligne et il reste toutes les autres :))

Et je fais le test avec un "Hello World" donc pas de macro.

[Stef]

Bon j'ai fait des tests et les résultats sont assez... peu convaincants :-/

Code source C original :

Code:

void VDP_setTileMapData(u16 plan, const u16 *data, u16 ind, u16 num)
{
        vu16 *pwdata;
        vu32 *pldata;
        const u16 *src;
        const u32 *src32;
        u32 addr;
        u16 i;

        addr = plan + (ind * 2);
        src32 = (u32*) data;
        pldata = (u32 *) 0xC00004;

        i = num >> 3;
        while (i--)
        {
            *pldata = *src32++;
            *pldata = *src32++;
            *pldata = *src32++;
            *pldata = *src32++;
        }

        src = (u16*) src32;
        pwdata = (u16 *) 0xC00004;

        i = num & 7;
        while (i--) *pwdata = *src++;   
}

J'ai simplifié le code, c'était juste pour tester ce genre de code critique (upload en mémoire vidéo) qui est quand même relativement simple.

Résultats avec m68k-atari-mint-gcc ou g++ 4.6.4 (MiNT 20130415) et
m68k-ataripeylow-mint-gcc ou g++ 4.6.4 (MiNT 20130415) puisqu'ils produisent un code identique (si ce n'est l'instruction link qui disparait d'un coté).


Optimization -O1:

Code:

        link.w %fp,#0
        movem.l #8240,-(%sp)
        move.l 12(%fp),%a3
        move.w 22(%fp),%d1
        moveq #0,%d0
        move.w %d1,%d0
        lsr.l #3,%d0
        tst.w %d0
        jeq .L6
        subq.w #1,%d0
        moveq #0,%d2
        move.w %d0,%d2
        move.l %d2,%d0
        lsl.l #4,%d0
        lea 16(%a3,%d0.l),%a2
        move.l %a3,%a0
.L3:
        move.l (%a0),%d0
        move.l #12582916,%a1
        move.l %d0,(%a1)
        move.l 4(%a0),%d0
        move.l %d0,(%a1)
        move.l 8(%a0),%d0
        move.l %d0,(%a1)
        move.l 12(%a0),%d0
        move.l %d0,(%a1)
        lea (16,%a0),%a0
        cmp.l %a2,%a0
        jne .L3
        addq.l #1,%d2
        lsl.l #4,%d2
        lea (%a3,%d2.l),%a0
        jra .L2
.L6:
        move.l %a3,%a0
.L2:
        and.w #7,%d1
        jeq .L1
        subq.w #1,%d1
        and.l #65535,%d1
        move.l %d1,%a2
        lea 2(%a2,%d1.l),%a1
        move.l %a0,%d1
        add.l %a1,%d1
.L5:
        move.w (%a0)+,%d0
        move.w %d0,12582916
        cmp.l %a0,%d1
        jne .L5
.L1:
        movem.l (%sp)+,#3076
        unlk %fp
        rts

Init: correcte (pas optimale mais correcte)
Boucle principale: naze... 2 move.l avec du displacement à la place d'un move avec post increment logiquement...
La comparaison sur les registres d'adresses pour sortir est une catastrophe
Conclusion: poubelle

Optimisation -O3:

Code:

        link.w %fp,#0
        move.l %a2,-(%sp)
        move.l %d2,-(%sp)
        move.l 12(%fp),%a2
        move.w 22(%fp),%d1
        moveq #0,%d0
        move.w %d1,%d0
        lsr.l #3,%d0
        tst.w %d0
        jeq .L6
        subq.w #1,%d0
        moveq #0,%d2
        move.w %d0,%d2
        move.l %d2,%d0
        lsl.l #4,%d0
        lea 16(%a2,%d0.l),%a1
        move.l %a2,%a0
.L3:
        move.l (%a0),%d0
        move.l %d0,12582916
        move.l 4(%a0),%d0
        move.l %d0,12582916
        move.l 8(%a0),%d0
        move.l %d0,12582916
        move.l 12(%a0),%d0
        move.l %d0,12582916
        lea (16,%a0),%a0
        cmp.l %a1,%a0
        jne .L3
        move.l %d2,%d0
        addq.l #1,%d0
        lsl.l #4,%d0
        lea (%a2,%d0.l),%a0
.L2:
        and.w #7,%d1
        jeq .L1
        subq.w #1,%d1
        and.l #65535,%d1
        move.l %d1,%a2
        lea 2(%a2,%d1.l),%a1
        lea (%a0,%a1.l),%a1
.L5:
        move.w (%a0)+,%d0
        move.w %d0,12582916
        cmp.l %a0,%a1
        jne .L5
.L1:
        move.l (%sp)+,%d2
        move.l (%sp)+,%a2
        unlk %fp
        rts
.L6:
        move.l %a2,%a0
        jra .L2

Init: on sauvegarde un registre de plus qu'avec -O1 :-(
Boucle principale: foutage de gueule, on adresse le port en immédiate long, une catastrophe que ça soit en cycle ou taille de code. Toujours le test de sortie sur la comparaison des registres d'adresse.
Conclusion: Pire que -O1 (et hélas c'est assez fréquent avec GCC) !!

Optimisation -Os:

Code:

      link.w %fp,#0
        move.l %d3,-(%sp)
        move.l %d2,-(%sp)
        move.l 12(%fp),%a1
        move.w 22(%fp),%d1
        move.l %d1,%d0
        add.l %d0,%d0
        and.l #131056,%d0
        move.l %a1,%d2
        add.l %d0,%d2
        move.l %a1,%a0
        jra .L2
.L3:
        move.l (%a0),%d3
        move.l %d3,12582916
        move.l 4(%a0),%d3
        move.l %d3,12582916
        move.l 8(%a0),%d3
        move.l %d3,12582916
        move.l 12(%a0),%d3
        move.l %d3,12582916
        lea (16,%a0),%a0
.L2:
        cmp.l %a0,%d2
        jne .L3
        and.w #7,%d1
        add.l %d0,%a1
        jra .L4
.L5:
        move.w (%a1)+,%d0
        move.w %d0,12582916
        subq.w #1,%d1
.L4:
        tst.w %d1
        jne .L5
        move.l (%sp)+,%d2
        move.l (%sp)+,%d3
        unlk %fp
        rts

Init: pas mal, quelques copies inutiles mais mieux que O1 et O3
Boucle principale: hélas on adresse le port en immédiate long ce qui est une hérésie mais il faut admettre que le code est tout de même bien plus propre et court qu'avec -O3 et -O1.
Conclusion: Le plus lisible des codes, beaucoup mieux que O1 et surtout O3 sur ce point, en terme de performance il fait mieux que O3 mais est derrière O1.

Globalement c'est quand même la version -Os que je préfère pour la propreté du code généré même si c'est vraiment mauvais en terme de perf. -Os (size optimization) donne souvent de bons compromis.

[Orion_]

Code:

_VDP_setTileMapData
 movem.l l17,-(a7)
 move.l (8+l19,a7),a0
 move.l #12582916,a1
 moveq #0,d2
 move.w (18+l19,a7),d2
 move.l d2,d0
 asr.l #3,d0
 move.w d0,d1
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 beq l15
l13
 move.l (a0),(a1)
 addq.l #4,a0
 move.l (a0),(a1)
 addq.l #4,a0
 move.l (a0),(a1)
 addq.l #4,a0
 move.l (a0),(a1)
 addq.l #4,a0
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 bne l13
l15
 move.l a0,a2
 move.l #12582916,a3
 moveq #7,d0
 and.l d2,d0
 move.w d0,d1
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 beq l16
l14
 move.w (a2),(a3)
 addq.l #2,a2
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 bne l14
l16
l17 reg a3
 movem.l (a7)+,a3
l19 equ 4
 rts

Voila ce que ça donne avec le compilateur VBCC.
c'est pour ça que tout ce qui est acces au hardware ou routine critique, je le fait en asm, parceque la, ne pas utiliser (a0)+ pour sortir un addq.l #4,a0 c'est lamentable ...
pourtant, parfois, le compilo sort des optims auquel on aurais jamais pensé, alors que sur des choses élémentaire il fait n'importe quoi, c'est étrange..

[Stef]

On continue et termine avec m68k-ataribrown-elf-gcc ou g++++ (GCC) 6.2.0

Optimisation -O1 :

Code:

        link.w %fp,#0
        move.l %d2,-(%sp)
        move.l 20(%fp),%d2
        moveq #0,%d0
        move.w %d2,%d0
        asr.l #3,%d0
        move.w %d0,%d1
        subq.w #1,%d1
        tst.l %d0
        jeq .L6
        move.w %d1,%d0
        move.l 12(%fp),%a0
.L3:
        move.l #12582916,%a1
        move.l (%a0),(%a1)
        move.l 4(%a0),(%a1)
        move.l 8(%a0),(%a1)
        lea (16,%a0),%a0
        move.l -4(%a0),(%a1)
        dbra %d0,.L3
        and.l #65535,%d1
        addq.l #1,%d1
        lsl.l #4,%d1
        move.l 12(%fp),%a0
        add.l %d1,%a0
.L2:
        and.w #7,%d2
        move.w %d2,%d0
        subq.w #1,%d0
        tst.w %d2
        jeq .L1
.L5:
        move.w (%a0)+,%d1
        move.w %d1,12582916
        dbra %d0,.L5
.L1:
        move.l (%sp)+,%d2
        unlk %fp
        rts
.L6:
        move.l 12(%fp),%a0
        jra .L2


Init: L'init est pas mal, encore une fois pas optimale mais ça va.

Boucle principale: c'est pas mal ! Pour la première boucle au moins, dommage pour l'init du port et le displacement, mais au moins on a plus qu'un seul move. La 2me boucle par contre, pas terrible avec le port mis en immediate :-/ Ils ont enfin corrigé ce bug d'opti qui faisait toujours apparaitre 2 move quand un seul était possible :)


Optimisation -O3:

Code:

        link.w %fp,#0
        move.l %d2,-(%sp)
        move.l 20(%fp),%d1
        moveq #0,%d0
        move.w %d1,%d0
        asr.l #3,%d0
        move.w %d0,%d2
        subq.w #1,%d2
        tst.l %d0
        jeq .L6
        move.w %d2,%d0
        move.l 12(%fp),%a0
.L3:
        move.l #12582916,%a1
        move.l (%a0),(%a1)
        move.l 4(%a0),(%a1)
        move.l 8(%a0),(%a1)
        lea (16,%a0),%a0
        move.l -4(%a0),(%a1)
        dbra %d0,.L3
        and.l #65535,%d2
        addq.l #1,%d2
        lsl.l #4,%d2
        move.l 12(%fp),%a0
        add.l %d2,%a0
.L2:
        and.w #7,%d1
        jeq .L1
        move.l #12582916,%a1
        move.w (%a0),(%a1)
        cmp.w #1,%d1
        jeq .L1
        move.w 2(%a0),(%a1)
        cmp.w #2,%d1
        jeq .L1
        move.w 4(%a0),(%a1)
        cmp.w #3,%d1
        jeq .L1
        move.w 6(%a0),(%a1)
        cmp.w #4,%d1
        jeq .L1
        move.w 8(%a0),(%a1)
        cmp.w #5,%d1
        jeq .L1
        move.w 10(%a0),(%a1)
        cmp.w #6,%d1
        jeq .L1
        move.w 12(%a0),%d0
        move.w %d0,(%a1)
.L1:
        move.l (%sp)+,%d2
        unlk %fp
        rts
.L6:
        move.l 12(%fp),%a0
        jra .L2

Init: Identique à -O1

Boucle principale: Le première boucle est identique à -O1, la 2eme boucle est... abracadabrantesque ! Il détecte que 8 itérations max sont possible du coup il unrolle mais n'importe comment, aucun intérêt, le code est juste plus gros et en terme de cycle je pense que tu y perds par rapport à un dbra   Decidément -O3 c'est toujours n'importe que sur 68000, le code est plus gros et plus foullis et souvent avec aucun gain notoire en performance (quand ce n'est pas pire).

Optimisation -Os:

Code:

   link.w %fp,#0
        move.l %a2,-(%sp)
        move.l %d2,-(%sp)
        move.l 12(%fp),%a1
        move.l 20(%fp),%d0
        moveq #0,%d1
        move.w %d0,%d1
        asr.l #3,%d1
        move.w %d1,%d2
        move.l %a1,%a0
.L3:
        subq.w #1,%d2
        cmp.w #-1,%d2
        jeq .L2
        move.l #12582916,%a2
        move.l (%a0),(%a2)
        move.l 4(%a0),(%a2)
        move.l 8(%a0),(%a2)
        lea (16,%a0),%a0
        move.l -4(%a0),(%a2)
        jra .L3
.L2:
        and.w #7,%d0
        lsl.l #4,%d1
        add.l %d1,%a1
.L5:
        subq.w #1,%d0
        cmp.w #-1,%d0
        jeq .L1
        move.w (%a1)+,%d1
        move.w %d1,12582916
        jra .L5
.L1:
        move.l (%sp)+,%d2
        move.l (%sp)+,%a2
        unlk %fp
        rts

Init: Une belle init quasi optimale qui favorise effectivement la taille du code un peu au détriment de la vitesse.

Boucle principale: Le première boucle est identique à -O1 et -O3 si ce n'est le test de sortie moins optimisé juste pour réutiliser plusieurs fois le même code et ainsi réduire la taille du code, même remarque pour la 2me boucle, ce qui est plus pénalisant en terme de performance... dommage.


Encore un fois, le switch -Os produit le code le plus propre et le plus lisible, mais le manque d'instruction Dbra pénalise un peu en terme de perf. Globalement on est quand même mieux, mais ça reste améliorable... surtout avec un code C qui aide, on devrait voir un move.l (a0),(a1)+ mais non rien à faire :-/
Ici je conseille le -O1, le code ressemble pas mal à ce que GCC 3.4.6 produit en -O1.

Au final, je pense qu'on pourrait effectivement remplacer le vieux GCC 3.4.6 avec le nouveau GCC 6.2 car ils ont enfin corrigé quelques soucis sur les optimisations. Cela dit, le code ne semble pas meilleur que le GCC 3.4.6, peut être même un poil moins bon. Mais si l'inline fonctionne alors ça vaut carrément le coup ! J'aimerai bien voir la taille des exe aussi :)

[Invité]

Moralité dans tout ce charabia ??
Bon je quitte Sgdk et je retourne sur Bex et son optimisation aux petits oignons.

Non sérieux, la version actuelle est géniale !!
J'ai réalisé des tests avec mon projet avec une foule d'objets, ça ne ralentit pas d'un poil.
Faut juste bien optimiser son code d'origine ... 
Après je ne suis qu'un codeur du Dimanche dont l'avis importe peu.

[chrilith]

Au final, je pense qu'on pourrait effectivement remplacer le vieux GCC 3.4.6 avec le nouveau GCC 6.2 car ils ont enfin corrigé quelques soucis sur les optimisations. Cela dit, le code ne semble pas meilleur que le GCC 3.4.6, peut être même un poil moins bon. Mais si l'inline fonctionne alors ça vaut carrément le coup ! J'aimerai bien voir la taille des exe aussi :)

Je t'ai mis ca plus haut. Faut que je recompile avec isl pour l'optimisation.

[Stef]

Code:

_VDP_setTileMapData
 movem.l l17,-(a7)
 move.l (8+l19,a7),a0
 move.l #12582916,a1
 moveq #0,d2
 move.w (18+l19,a7),d2
 move.l d2,d0
 asr.l #3,d0
 move.w d0,d1
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 beq l15
l13
 move.l (a0),(a1)
 addq.l #4,a0
 move.l (a0),(a1)
 addq.l #4,a0
 move.l (a0),(a1)
 addq.l #4,a0
 move.l (a0),(a1)
 addq.l #4,a0
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 bne l13
l15
 move.l a0,a2
 move.l #12582916,a3
 moveq #7,d0
 and.l d2,d0
 move.w d0,d1
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 beq l16
l14
 move.w (a2),(a3)
 addq.l #2,a2
 move.w d1,d0
 subq.w #1,d1
 tst.w d0
 bne l14
l16
l17 reg a3
 movem.l (a7)+,a3
l19 equ 4
 rts

Voila ce que ça donne avec le compilateur VBCC.
c'est pour ça que tout ce qui est acces au hardware ou routine critique, je le fait en asm, parceque la, ne pas utiliser (a0)+ pour sortir un addq.l #4,a0 c'est lamentable ...
pourtant, parfois, le compilo sort des optims auquel on aurais jamais pensé, alors que sur des choses élémentaire il fait n'importe quoi, c'est étrange..

Bon au moins ça montre que VBCC n'est hélas pas très bon non plus sur l'opti, cela dit son code est loin d'être le plus pourri, GCC 4 et 5 font pire, et GCC 6 fait un peu mieux mais pas beaucoup...
C'est vrai que c'est incompréhensible, surtout en aidant le compilo avec un code type *d = *s++, mince quoi :-/

Puis ce genre de séquence de code :

Code:

 move.w d0,d1
 move.w d1,d0

 
Et c'est vrai qu'à côté de ça, parfois il peut faire des optis (mais plutot type sémantique) assez balaises...

[Hpman]

C'est vrai que c'est incompréhensible, surtout en aidant le compilo avec un code type *d = *s++, mince quoi :-/

T'as tenté le coup en déclarant avec le mot clef register?
Je sais que le register est pas garanti (tout comme le inline) mais je suis curieux maintenant 

[Stef]

Moralité dans tout ce charabia ??
Bon je quitte Sgdk et je retourne sur Bex et son optimisation aux petits oignons.

Non sérieux, la version actuelle est géniale !!
J'ai réalisé des tests avec mon projet avec une foule d'objets, ça ne ralentit pas d'un poil.
Faut juste bien optimiser son code d'origine ... 
Après je ne suis qu'un codeur du Dimanche dont l'avis importe peu.

Haha c'est parce-qu'on est tatillon Vetea, mais c'est vrai que le code généré par GCC n'est pas optimale, loin d elà, et parfois ça en est un peu rageant... mais je me doute que le code généré par BEX est loin d'être optimal aussi
Après en optimisant un peu le code C, on arrive à des résultats corrects quand même et c'est ce qui compte =)

[Stef]

C'est vrai que c'est incompréhensible, surtout en aidant le compilo avec un code type *d = *s++, mince quoi :-/

T'as tenté le coup en déclarant avec le mot clef register?
Je sais que le register est pas garanti (tout comme le inline) mais je suis curieux maintenant 

Non ça bien sur il s'en contre fout, c'est l'un des premiers trucs que j'ai essayé, tout comme forcer une convention d'appel type "register". Mais sur m68k ça n'existe pas (ou plutot y'a pas de standard.. ce qui est bien dommage, avec la tripoté de registres du CPU).

[Stef]

Au final, je pense qu'on pourrait effectivement remplacer le vieux GCC 3.4.6 avec le nouveau GCC 6.2 car ils ont enfin corrigé quelques soucis sur les optimisations. Cela dit, le code ne semble pas meilleur que le GCC 3.4.6, peut être même un poil moins bon. Mais si l'inline fonctionne alors ça vaut carrément le coup ! J'aimerai bien voir la taille des exe aussi :)

Je t'ai mis ca plus haut. Faut que je recompile avec isl pour l'optimisation.

Oui j'ai vu :) le lien pour la version 6.2 est le mauvais (il pointe sur le 2.95) mais en faisant un copier / coller de l'adresse c'est bon
J'ai décompressé le compilo 6.2, la taille de l'exe cc1, gros foutage de gueule    132 Mo !
Sur GCC 2.95 il fait 1.4 Mo... C'est ça que je n'aime pas non plus sur les GCC récents... on se fout de 95% des fonctionnalités qu'il intègre (il doit pouvoir faire les crèpes mais je m'en contre fous)

[chrilith]

Oui c'est la folie... m'enfin. Bref, j'ai fait plein de versions, reste plus qu'à savoir quoi faire... ou pas :)

Je passe au dev cette fois-ci !