Problème avec TIGCC/a68k - Page 3

Martial Demolins (./58) :
Bon, pour faire un petit récapitulatif d'une boucle infinie de jeu synchronisée pour le double buffering, doit-on bien faire :

Ready:     tst.l   genlib::timer
        beq.s   Ready
        rts

Ca, c'est pour être sûr que sur HW1, on a bien attendu que la première frame du nouveau dscreen aie bien été affichée (?)

pourquoi ne pas afire autre chose en attedant d'ailleurs?

ensuite, on peut dessiner, lire le clavier, calculer, etc.....

on continue en finissant d'attendre le temps que l'on désire pour régler le fps:

     Wait15:
        cmp.w   #1,genlib::frame_timer
        bls.s   Wait15
        clr.w   genlib::frame_timer
        rts

puis on swappe les dscreen une fois qu'on a fini:

et on recommence.
C'est bien ça? J'ai toujours eu trop de mal avec les synchro :'(

Oui

Martial Demolins (./59) :
Encore un problème :
J'ai des fichiers (main.asm et screen.asm) qui contiennent tous les deux des exports main@xxxx (différents bien entendu ^^)
Ca ne devrait pas poser de problèmùe normalement?

Je compile comme ça :
tigcc main.asm screen.asm -o main

Non

Dans main.asm, je fais un kernel::LibsBegin sur un autre programme (rbmod1.asm) qui fait référence à des main@xxxx contenus dans screen.asm.
Et là, j'ai un comportement étrange de PreOS :
Si j'écris :

		jsr	kernel::LibsBegin
;		suba.l	a0,a0

Ca me renvoie 0, et j'ai un crash intercepted en sortie (PpHd, je pense que ça venait de là le précédent Crash Intercepted).

Si maintenant je fais l'inverse :

;		jsr	kernel::LibsBegin
		suba.l	a0,a0 

J'ai le même résultat évidemment (a0==0), mais mon programme quitte proprement et sans crasher...

Des idées?

Non.

Je rajoute l'adresse de l'archive tant qu'à faire :

Dés que j'ai le temps.

Martial Demolins (./61) :
A part les nop de padding, j'ai aucune optimisation à faire faire au linker. Codage par modules powa

Au contraire, c'est quand on code par modules que l'optimisation linker est importante!
L'assembleur (quel qu'il soit) ne peut pas optimiser les références d'un fichier à un autre, seul le linker peut le faire!

C'est des modules chargées dynamiquement à l'éxécution. Pas résolus lors du linkage par ld-tigcc.

Pas pour main.asm et screen.asm qui sont bel et bien linkés ensemble dans sa ligne de commande.

Et sinon, AMHA c'est dingue d'avoir des modules compilés séparément et liés en temps d'exécution pour un seul et même logiciel, ça crée un overhead immense en exportations et importations, il serait beaucoup plus efficace de linker tout en un seul exécutable, d'autant plus que les libs font aussi référence au programme principal, donc ne sont pas de vraies librairies dynamiques (car pas réutilisables dans un autre programme)!

Martial Demolins (./70) :
Ouep, sauf que screen ne contient que des fonctions de moins de 30 octets chacune, je vois pas ce que le linker pourrait m'optimiser là-dedans :

Les appels à ces fonctions depuis le programme principal.

Kevin Kofler (./69) :
Et sinon, AMHA c'est dingue d'avoir des modules compilés séparément et liés en temps d'exécution pour un seul et même logiciel, ça crée un overhead immense en exportations et importations, il serait beaucoup plus efficace de linker tout en un seul exécutable, d'autant plus que les libs font aussi référence au programme principal, donc ne sont pas de vraies librairies dynamiques (car pas réutilisables dans un autre programme)!

Il souhaite peut être simplement s'amuser, ou apprendre.
Ou bien la totalité du programme ferait plus de 64 ko.
Ou bien il a besoin de beaucoup de RAM à certains moments, auquel cas il décharge les modules.

Si tu as besoin d'un beta testeur I'm here

Martial Demolins (./72) :
En RAM, ça fera donc dans les ~1.5ko utilisés au lieux de 10 permanents.

Mais en archive, ça va faire dans les 3 KO d'overhead! Or, l'archive est la place occupée tout le temps par ton programme, même quand il n'est pas exécuté. Donc mauvais tradeoff. D'autant plus que 10 KO de RAM sont très peu par rapport à la RAM disponible totalement, donc cette mesure n'est absolument pas nécessaire.

Martial Demolins (./73) :
En effet. C'est bien la seule chose, jepense avoir beaucoup plus à gagner en admettant ça et en découpant mon code, en le chargeant/déchargeant à la volée (c'est ça, utiliser à fond le format du kernel).

Mais ça ne t'empêche pas du tout d'utiliser les optimisations du linker! Je ne vois pas pourquoi tu ne veux pas les mettre, ça ne coûte rien.

Kevin> C'est le concept qui est sympa à manier, c'est tout
Le but n'étant pas d'optimiser son programme dans le sens où toi tu l'entends.

Kevin Kofler (./77) :
Mais en archive, ça va faire dans les 3 KO d'overhead! Or, l'archive est la place occupée tout le temps par ton programme, même quand il n'est pas exécuté. Donc mauvais tradeoff. D'autant plus que 10 KO de RAM sont très peu par rapport à la RAM disponible totalement, donc cette mesure n'est absolument pas nécessaire.

Je relance pas le troll, mais c'est très tentant.

chhhhht

J'arrive pas à faire crasher sous pedrom : Error (Wrong Lib main)
Mais le problème provient du fait que main n'exporte que 4 symboles et pas 6. Bug du linkeur de tigcc je dirais donc

Oui.
Essaye de reformuler tes xdef dans screen.asm (1 par ligne).
Sinon essaye d'inclure screen.asm dans main.asm.

Ca marche mieux ?