1


Ce matin je me suis rappellé d'une page lu dans une doc officielle Motorola, aligné son code sur un multiple de 32 bit (Un mot long) permet d'évité de perdre des cycles machines.

Donc j'en appelle a ce qui connaisse un peu le système et qui on déjà joué avec (Kochise t'est ou ?), le Pexec (La fonction gemdos qui permet de lancé un programme, fonction appellé quand vous double cliquez sur un .PRG, etc...) doit chargé les PRG a une adresse paire, mais pas obligatoirement sur un multiple de mot long. Donc la question, si on détourne le Pexec par une routine perso qui relogerait le code a une bonne adresse, on pourrait gagné un peu de vitesse et tout cela en soft, par quelques lignes d'asm. La routine de relocation j'en ai réécrite une il y a quelques mois, il faudrait juste généré la Basepage.

Ceux qui possède une CT2, CT60 ou autres cartes accélératrices ne verront surement rien, déjà le gain ne sera pas powerfull mais c'est a prendre en considération. Faut que je fasses une estimation du gain possible par cette ruse.


J'ai une petite histoire concernant la doc de Motorola, un jour RaZ m'appelle en me disant, Motorola propose de la doc gratuite juste les frais de port a payé, intérréssé ? Moi bien sur Oui, RaZ passe la commande.

15 Jours après dans ma boite aux lettres, un sac en toile de jute, je me demandais qui m'envoyait des patates !! J'ai ouvert le sac et dedans :

- MC68030 User's manual
- Dsp56300 Digital Signal Processor family manual
- Programmer's reference manual (Tout des 68xxx jusqu'au 68040, avec aussi le CPU32 et les 68881/2)
- DSp56301 User's manual.

Et en fin de compte, aucun frais de port donc un grand merci a RaZ et a Motorola !!

GT Turbo cool
avatar
Accrochez vous ca va être Cerebral !!

2

GT Turbo :
le Pexec (La fonction gemdos qui permet de lancé un programme, fonction appellé quand vous double cliquez sur un .PRG, etc...) doit chargé les PRG a une adresse paire, mais pas obligatoirement sur un multiple de mot long.


Ok, donc dans ton code tu fais un code automodifiant, qui teste la première adresse en ram, ensuite tu décale ton code pour que le début soit casé sur un multiple de mot long, un jump là où le code commence vraiment et le tour est joué, non ?

Az, codeur à deux balles.
Gare à celui qui touche a mes chips quand je code !

3

Azrael_CV
:
GT Turbo :
le Pexec (La fonction gemdos qui permet de lancé un programme, fonction appellé quand vous double cliquez sur un .PRG, etc...) doit chargé les PRG a une adresse paire, mais pas obligatoirement sur un multiple de mot long.


Ok, donc dans ton code tu fais un code automodifiant, qui teste la première adresse en ram, ensuite tu décale ton code pour que le début soit casé sur un multiple de mot long, un jump là où le code commence vraiment et le tour est joué, non ?

Az, codeur à deux balles.


Pas de cote automodifiant, sinon faudrait que je geles les caches du 68030. Donc plus simple, je fais comme la fonction, je reserve toute la mémoire, trouve la premiere adresse multiple de 32 bit, (Cela se fait en deux lignes, voire une !) et je charges le code betement a cette adresse !! Et le tour est joué, il y a encore deux ou trois trucs a généré pour etre sur que le PRG fonctionne mais sinon cela devrait allé. Tant que j'y pense quelqu'un sait si on arrive a récupéré facilement l'adresse de la ligne de commande, que le GEM a pris ?

Cerebral Pawa !!

GT Turbo (C.V.) cool
avatar
Accrochez vous ca va être Cerebral !!

4

GT Turbo :
Pas de cote automodifiant, sinon faudrait que je geles les caches du 68030. Donc plus simple, je fais comme la fonction, je reserve toute la mémoire


Tu peux pas les dégeler en cours de route ?

Euh... si tu reserves toute la mémoire ça signifie qu'il n'y a que ton code qui tourne ?

Az, br..leur de haut niveau.
Gare à celui qui touche a mes chips quand je code !

5

Tu t'en fout, puisque la basepage et ton programme sont en 'général' relogés sur des adresses multiples de 256 ! Donc forcément multiple de 4 wink Ensuite ça n'avantagerais que le début du soft puisque rapidement tes routines internes risqueraient de ne plus êtres positionnées à des adresses multiples de 4. Il faudrait alors à la fin de chaque sous routines ajouter la ligne suivantes :
EVEN

Remarque ça ne garantie qu'un alignement à 2. Il me semble qu'il existe une directive QUAD pour forcer l'alignement à 4, mais qui n'existe pas dans Devpac. A voir...

Mais si la doc te dit "Makâz, si aligné sur 4 tu es, roi du monde tu seras", oublie pas non plus que le bus du Falcon est 16 bits, donc l'alignement à 4 ne serait profitable qu'aux seuls TT (et Medusa/Hades/Milan), pour peu que ton soft soit compatible (genre prog GEM et consort)...

Bonne bourre !

Kochise

PS : Moi aussi je veux la doc Motorola, tu m'files l'adresse en minimsg ?
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

6

Kochise

PS : Moi aussi je veux la doc Motorola, tu m'files l'adresse en minimsg ?


Je voulais justement savoir, donc si effectivement les progs son chargés a un multiple de 256, je vais écrire du code pour rien !! C'est ce que je voulais savoir merci a toi Kochise.


Pour le livres cela date de l'année dernière, je ne sais pas si c'est encore valable. Je contacte RaZ et si il a encore l'adresse je lui dit de te l'envoyé. Ou mieux RaZ si tu lis ceci (Ce que tu feras !) peut tu publié l'adresse d'ou tu avais commandé ces livres ? Si elle est encore valable ? Je penses que cela peut intérréssé d'autres personnes.


GT Turbo cool
avatar
Accrochez vous ca va être Cerebral !!

7

Je n'ai pas retrouvé la dite page.
Par contre, en vadrouillant de ci de là, j'ai pu retrouver des versions de différents bouquins et manuels ainsi qu'une adresse fort intéressante :
http://www.freescale.com/
Ce site propose des docs et à l'achat et en PDF de nombreux processeurs, DSP compris.
Ne vous fier pas à l'icone du caddy, après séléction et affichage de la liste des docs voulues, un clic sur son nom vous envoie vers sa version PDF.
Autrement via Motorola japon, j'ai pu récupéré deux ou trois docs dont une ne semble pas se trouver sur Freescale et qui concerne "Implementation on Fast Fourier Transforms on Motorola's Digital Signal Processors".
Que du bonheur en perspective.

Maintenant si quelqu'un se sent motivé pour contacter Motorola et leur poser gentiment la question pour la disponibilité physique des docs, qu'il ne se gène pas.


Je tiens les docs que j'ai pu recolter à dispo de quiconque les désire en sachant que Freescale à l'air suffisamment exhaustif pour éviter de se fatiguer à organiser un échange de fichier redondant.
avatar