Jump to content

MadMac me les gonfles !!!


GT Turbo

Recommended Posts

Avant de me couché, j'avais un doute et j'ai vérifié Madmac a une sale tendance a faire gonflé les codes assemblés avec, j'ai fait un essais, un nop assemblé fait 44 octets !!! Théoriquement il ne devrait prendre que 2 octets ! Apparement des infos de débugguage et d'autres conneries sont sauvés avec (Je crois bien que l'entete du fichier assemblé est au format Gemdos (Taille Data ,Bss, et d'autres trucs))

 

 

 

J'ai essayé les différents formats de fichier de Madmac en sortie, certains codes assemblés sont plus gros que les sources !!! ARGHHH :wacko:

 

 

 

Je vais essayé de comprendre ce qu'il y a en trop et coupé a la serpette dans le code, si encore on avait 20 kilos de ram Gpu d'accord mais on en a que 4, donc si on s'amuse a faire gonflé nos codes avec des trucs souvent superflus, la bataille n'est pas prete d'ètre gagné !!!!

 

 

 

J'étudies cela en détails et vait cherché une solution a cet épineux problème...

 

 

 

 

 

GT En train de cherché :blink:

Link to comment
Share on other sites

Azrael :


Ca parait étonnant qu'un asm assemble plus que tu as écrit dans tes sources... Ecris en C :D au moins tu sauras pourquoi ton code est un poil plus gros :P







Ah ca c'est sur !!





Ce qui métonnes c'est que le code fonctionne directement, car au début d'un fichier Gemdos il y a une instruction 68000 qui fait un saut pour évité les données, est ce que le code correspondrait a un saut en Gpu ? Motorola Inside ? La est la question !!





GT Mulder car la 'vérité est ailleurs !' :wacko:
Link to comment
Share on other sites

  • 3 months later...

J'ai enfin les explications a mes questions, hier j'ai vite écrit un déssassembleur Dsp / Gpu, et profiter pour regarder la structure du fichier résultant d'un assemblage proc.

 

 

 

Le fichier est un fichier au format Gemdos avec entete et tout le toutim.

 

A la base le fichier fait 538 octets, si on garde que le code celui ci ne fait plus que 248 octets (90 lignes de code dsp, routine de lecture des pads).

 

 

 

Je penses qu'en utilisant le linker celui ci dégage les infos supplémentaires, vu que je ne l'utilises pas, faut que je coupes les fichiers a la main !! :wacko:

 

 

 

Pour info, j'ai vite fait un essais, ces 90 lignes de code Dsp en équivalance 68000 cela fait 3 instructions, ca calme hein !! Oui vous avez bien lu, le temps que le 68000 execute 3 instructions, le Dsp en a aligné 90 !!! :yes:

 

 

 

Et encore les instructions 68000 utilisés sont pas des instructions lentes.

 

 

 

GT Turbo :P

Link to comment
Share on other sites

frost :


Et Devpac ne va pas bien pour coder sur Jag ?? Je me souviens que ça marchait plutôt bien.





Devpac cela marche du feu de dieu, et dans le pire des cas, je peux juste utiliser l'éditeur de Devpac et utiliser Mad Mac en tant que Tools, c'est aussi pour cela que je préfères Devpac.



Voila a quoi ressemble mon menu de Devpac :







Le truc ultra top, c'est que je peux écrire le code Gpu par exemple dans la seconde fénètre, je lances Mad Mac depuis le menu tools, je repasses fenetre un et je réassemble mon code qui 'include le fichier résultant' de Mad Mac pour mes codes Gpu / Dsp. Plus de détails ici en rubrique Articles.



Ce que je voulais dire c'est que Mad Mac génère des fichiers au format Gemdos avec un entete dont on se bat les c....., cela fait surtout perdre des octets très cheres quand on a que 4 Kilos (Gpu) ou 12 Kilos (Dsp), pour l'instant j'ai trouvé un truc con, ma routine qui recopie les codes procs, recopie le code a partir du début du fichier plus $1a (Entete de 28)+2 (Taille du bra du début du fichier) et recopie le nombre d'octets inscrit dans l'entete, cela m'évite pour l'instant de devoir couper les fichiers a la main. Je penses que pour ceux qui utilisent le linker (Sur Atari il y a un shell apparement bidon (Gulam) qui a l'air de me hair, donc pour l'instant je connais pas las version Atari du linker et je m'en f... Mon environnement de devellopement est telle qu'a part l'Evo II de SCPCD je ne changerais pour rien au monde !!



GT Bien installé !! ;)
Link to comment
Share on other sites

J'utilise les compilateurs ATARI

 

je sais pas pkoi je n'ai pas indiqué avant la procedure que j'utilise...:wacko:

 

 

 

pour compiler :

 

mac.ttp -fb -u -iincludes/ main.s -s

 

-fb je sais plus il faut que je relise la doc

 

-u permet la globalisation automatique des symboles non definis

 

-s c'est pour qu'il t'indique les branchs 68000 que tu peux optimiser (en faisant bra.s ce genre de truc)

 

-i suivi du nom de dossier a inclure si tu utilise des includes sans l'adresse complet (ex : .include "jaguar.inc" et que 'jaguar.inc' est dans le dossier 'includes') (le nom du dossier doit être collé au '-i')

 

tu dois optenir un 'main.o'

 

 

 

pour linker :

 

aln.ttp -o test.bin -n -w -rq -a 4000 x x main.o

 

 

 

-n pas de file header

 

-w activation des warnings

 

-rq c pour aligner chaque segment (text, data, bss) sur une quad phrase (32octets)

 

tu peux ou bien metre :

 

-rw -> word

 

-rl -> long

 

-rp -> phrase

 

-rd -> double phrase

 

-a text data bss : c pour choisir l'adresse de l'organisation des différentes sections :

 

ex:

 

4000 -> adresse de debut du segment TEXT : le code 68000

 

x -> adresse des datas, si ce n'est pas une valeur mais 'x', c'est automatiquement mis a la suite du segment TEXT

 

x -> adresse de la section BSS idem que precedement sauf que ce sera mis a la suite des DATAS

Link to comment
Share on other sites

C'est bon a savoir, merci pour tout, j'en prends note.

 

 

 

Par contre question SCPCD, tu trouves pas cela un peu lourd ? Devoir a chaque modif lancé tout cela pour vérifier ton code ? J'utiliserais peut ètre les trucs officiels pour les versions finales, si on excepte juste le petit soucis concernant les entetes sur les fichiers Gpu ou Dsp, perso je changes plus rien, excepté peut ètre l'utilisation de MadMac pour le code 68000, pour éviter de devoir aligné certaines adresse a la main :wacko:

 

 

 

GT Documenté :yes:

Link to comment
Share on other sites

GT Turbo :


Par contre question SCPCD, tu trouves pas cela un peu lourd ? Devoir a chaque modif lancé tout cela pour vérifier ton code ?





Ben en fait, :unsure:, j'utilise aussi make.ttp.

du coup je fais un 'makefile' qui contient les 2 lignes precedentes et il suffit juste ensuite de lancer make.ttp sans parametre et il fait tout tout seul. (bien sur, il faut que make.ttp soit a coté du makefile)

sinon, pour lancer un makefile qui n'est pas dans le dossier ou il y a make.ttp, il faut lui donner comme parametre -f addr/nom_file



bien sur, le makefile est structuré d'une certaine facon :

ex: (il faut metre une tabulation devant aln et mac)

Link to comment
Share on other sites

SCPCD :


ensuite tu envoi le fichier .bin dans la jag a l'adresse 4000 et tu peux l'executer





A chacun sa technique, cela permettra aux futurs devellopeurs (Qui vont devenir nombreux !....) de choisir la leur !!



GT Turbo ;)
Link to comment
Share on other sites

Moi j'utilise un PC ... plop ! tiens chui déjà mort...

 

 

 

Donc j'ai Madmac , ALN et Make aussi et des lignes dans mon autoexec.bat

 

pis donc sinon je tape par exemple "make clean" pour virer mes fichiers temporaires ( les *.o ) et je retape "make" tout court pour compiler et "make ins" pour lancer la demo

 

tout ceci en config BJL

 

 

 

Avec l'alpine bah c'est encore plus simple pasque avec WDB ( le frère de RDB ) on est en mode fenetré , mais comme chui pas très malin , je compile comme avec le BJL , et j'ai pas mis de bouton reset alors je perds pas mal de temps avec ça

 

 

 

mais vu que je passe en moyenne une journée sur 5 lignes de code , j'essaye de pas trop coder :wacko:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...