Encore quelques progrès intéressants sur cette librairie avec seulement des inlines, c'est à dire avec des insertions de très petites sous-routines directement dans leurs routines respectives.
Le résultat dépasse toutes mes espérances, regardez :
Le résultat dépasse toutes mes espérances, regardez :
Avec en plus une superbe cerise, la librairie a rétrécie maintenant de 4692 octets.
J'ai aussi rajouté l'intégration du patch Mult64Patch : de cette façon, les utilisateurs pourront l'ôter de leur user-startup, il est inutile maintenant. D'ailleurs, ce patch est l'oeuvre du français Didier Levet (alias Kakace) qui ne donne plus signe de vie : quelqu'un sait ce qu'il devient ?
Ce patch intégré est très important parce qu'il est un premier pas permettant l'unification des programmes .020, .030, .040 et .060. En effet, nous avons vu au cours des années arriver plusieurs déclinaisons d'un même programme suivant le CPU installé sur les différentes machines des utilisateurs, avec donc des extensions .0x0 au bout de chaque nom !
Ces multiples versions étaient la cause de certaines instructions manquantes comme nous l'avons vu dans les précédents articles : par exemple, les 020 et 030 ont les "muls64" et "mulu64" intégrés dans leur coeur, alors que le 060 en est dépourvu. Puisque la majorité des programmes sont devenus codés en C/C++ à partir de la mise sur le marché des 1200 et 4000, les compilateurs correspondants pondaient des exécutables en fonction de l'option CPU indiquée par les codeurs.
Un source C/C++ utilisant des "mulu64" donnait donc un binaire différent suivant l'option -m68020 ou -m68060 précisée. Dans le premier cas, le programme obtenu utilisait directement le "mulu64" et dans l'autre une routine équivalente faite d'instructions bien présentes dans le 68060.
Les concepteurs de ces compilateurs ont utilisé cette méthode parce qu'ils savaient que les instructions manquantes émulées par la 68060.library (et par la 68040.library aussi d'ailleurs) étaient très lentes.
J'ai essayé d'expliqué simplement... Enfin bref, pour résumer c'était le bordel le plus complet...
Avec ce patch intégré, les choses changent enfin : les compilateurs n'ont maintenant qu'a appeler la fonction R_Mult64 de l'utility.library lorsqu'ils rencontrent un "mulu64" dans les sources, et ainsi les différents CPUs utiliseront automatiquement soit l'instruction en elle-même (R_Mult64 utilise un "mulu64" avec des 020 ou 030), soit la routine équivalente (le patch que je viens d'ajouter pour le 060).
De cette façon, un seul exécutable sera nécessaire quelque soit le CPU installé, ce qui simplifiera la vie des utilisateurs et permettra de bonnes performances, le tout sans bien sûr utiliser la lenteur des instructions émulées par la 68040.library ou la 68060.library.
La nouvelle version de la 68060.library v66.10 est disponible ici.
Avec ce patch intégré, les choses changent enfin : les compilateurs n'ont maintenant qu'a appeler la fonction R_Mult64 de l'utility.library lorsqu'ils rencontrent un "mulu64" dans les sources, et ainsi les différents CPUs utiliseront automatiquement soit l'instruction en elle-même (R_Mult64 utilise un "mulu64" avec des 020 ou 030), soit la routine équivalente (le patch que je viens d'ajouter pour le 060).
De cette façon, un seul exécutable sera nécessaire quelque soit le CPU installé, ce qui simplifiera la vie des utilisateurs et permettra de bonnes performances, le tout sans bien sûr utiliser la lenteur des instructions émulées par la 68040.library ou la 68060.library.
La nouvelle version de la 68060.library v66.10 est disponible ici.
