Travail sur GCC 4

[ol.g...@lutece.net]

Bonsoir


GCC 3.4.6 ne donnant pas les résultats escomptés (je n'arrivais qu'a
compiler que du code 68000 qui fonctionnait sinon les autres
plantaient), j'ai fini par switcher sur un GCC 4.6.4 déjà tout prêt à
compiler et là cela marche et puis surtout c'est ce que j'utilisais
encore pour crosscompiler donc pas trop a se casser la tête avec les
librairies.


Je me suis remis à rajouter les registres étendus du 68080 à la fois
dans GCC et GAS adapté pour ce compilateur, là je me suis rendu compte
que le 68080 n'était pas du tout debuggué avec les registres étendus
pour le CPU on m'a conseillé plutôt de me contenter pour le moment des
registres étendus avec le FPU sensé être débuggué, après pas mals de
bugs à régler dans GCC et GAS, globalement cela semble fonctionner sauf
que là encore avec mes tests massifs en essayant de compiler tinygl je
suis tombé sur une instruction fpu buggué (en l’occurrence fmove.l qui
s’emmêle les pinceaux avec les registres étendus) , résultat j'arrive à
compiler 80% des sources de tinygl sans problème visible et 2 fichiers
si je les compile avec l'option 68080 qui donnent des résultats
étranges! Pour cerner le problème il m'a fallut découper en petit code
un des fichiers fautifs pour trouver le code générant le problème pour
avoir un code assembleur simple et assez petit pour être étudié par une
personne de l'équipe Apollo super compétente. Bref attente de la
correction qui va bien pour finaliser cela. Est ce qu'il y aura un gain?
A mon avis très faible! Mais l'idée n'est pas là car plus je teste plus
je pense que le principal problème de GCC 68K c'est qu'il n'a jamais été
amélioré pour gérer les pipelines et pour qu'un pipeline puisse être
efficace il me semble que si on a plus de registres le pipeline va mieux
fonctionner.

Bon vu que je suis en attente et que s'arrêter dans GCC c'est risquer de
ne jamais repartir un jours car c'est tout simplement un exercice de
torture de l'esprit! Alors pourquoi ne pas essayer de gérer au moins un
peu le pipeline du FPU et comme j'ai un principe simple que est 20% du
travail cela fait 80% du résultat alors essayons le minimum du minimum
pour ne faire que 5% et voir si cela fonctionne encore. Bah semblerait
que cela fonctionne encore et pire que cela accélère la partie FPU de
manière pas radicale mais suffisamment pour ne pas avoir de doute du
tout sur l'amélioration. En supposant que le pipeline se fait sur 6
cycles et qu'il peut sur toute instruction sortir 1 instruction par
cycle en mode pipeline on ne peut pas faire plus basique comme
schématisation! je pense que le gain sera de l'ordre de 10%. Bon c'est a
bien étudier pour le moment 2 sources sont encore en 68040 sans gestion
particulière.


Suite au prochain épisode si je n'abandonne pas définitivement la chose!


Olivier