Niveaux de gris - Page 4

Là je dis chapo.

Et l'avantage de ce système, c'est qu'on peut utiliser des relogements compressés sans avoir à mettre à jour le kernel.
En mode kernel, on utilisera (ce n'est pas encore implémenté pour le mode kernel) le format de PreOs prochaine version, donc il faudra mettre à jour PreOs pour utiliser les programmes pour kernel avec relogements compressés.

Le code de relogement pour relogements compressés prend actuellement 160 octets, 96 desquels sont pour le décodage des offsets, et donc partagés avec le support des BSS et d'autres fonctionnalités liées aux relogements. Et il me semble qu'il y a encore des optimisations possibles, donc d'ici la version finale, ça peut encore être réduit de quelques octets.

Quant au code de relogement pour relogements non-compressés, mais non-redondants (format style kernel), il prend encore moins de place (mais permet aussi moins de gains au niveau de la table). Le format optimal dépendra évidemment de la taille du programme (plus précisement du nombre de relogements qu'il contient).

Vivement que TIGCC 0.95 sorte parceque là c'est vraiment interessant.

Au faite, est-ce que les librairie statique vont subir une amélioration sous TIGCC 0.95? Parce que ce faire un fichier par fonctions ça devient pénible pour la mise à jours.

geogeo :
Au faite, est-ce que les librairie statique vont subir une amélioration sous TIGCC 0.95? Parce que ce faire un fichier par fonctions ça devient pénible pour la mise à jours.

Non, c'est le principe-même des librairies statiques qu'il faut séparer les fonctions pour permettre un linkage sélectif.

Donc c'est un défaut.
Et pas possible de faire un support de projets pour librairie statique? Du même style que si s'était des header? Là je parle de l'IDE.

Et je ne vois vraiment pas le problème. Dans TIGCCLIB, on a aussi un fichier par fonction, et c'est pratique, parce que si on veut éditer, à titre d'exemple, la fonction atoi, on édite atoi.s ou atoi.c et on n'a pas besoin de toucher au reste. On peut même éviter de recompiler le reste (Project/Make dans l'IDE; pour avoir la même chose en ligne de commande, tu peux utiliser un Makefile).

geogeo
: Et pas possible de faire un support de projets pour librairie statique?

C'est fait depuis longtemps. Il suffit de mettre le bon "target" (Function archive (.a)) sous Project/Options.
D'ailleurs, ta manière d'appeler ar directement est obsolète. Ça fait longtemps qu'il y a tigcc -ar pour ça.

lol, j'avais pas vu.
Merci

D'ailleurs, ton build.bat se résume à une ligne:
tigcc -ar INTERRUPT.asm variables.asm EnableSound.asm DisableSound.asm InstallSound.asm UninstallSound.asm Initialize.asm SetTempo_voice1.asm SetTempo_voice2.asm GetTempo_voice1.asm GetTempo_voice2.asm SetState.asm SetLoop.asm SetBeep_voice1.asm SetBeep_voice2.asm beep.asm PlayFX_voice1.asm PlayFX_voice2.asm PlayFX.asm GetFrequency_voice1.asm GetFrequency_voice2.asm PortStatus.asm Interrupt5.asm PlaySound_voice1.asm PlaySound_voice2.asm PlaySound.asm GetLength_voice1.asm GetLength_voice2.asm GetTime.asm GetState.asm GetMode.asm GetLoop.asm Time_voice1.asm Time_voice2.asm InitializeTime_voice1.asm InitializeTime_voice2.asm VoiceState.asm SetVoiceState.asm SetIntMask.asm -o polysnd2.a

Ouai mais ça fait fouillie, surtout que je rajoute des fonctions et que j'en efface, quoi que c'est facile dans ce cas aussi....
Je sais que ar existe or je trouve que de faire tout en détail permet vraiment de voir ce qui ce passe.

Mais rien ne dit qu'ar existera toujours dans TIGCC 0.95 et supérieures... On a maintenant notre propre archiveur capable de lire les symboles dans les fichiers objet générés par A68k sans conversion, qui sera intégré à link.dll, chargée directement par IDE.exe et tigcc.exe. Ceci dit, on a aussi une interface en ligne de commande (ar-tigcc.exe) compatible avec les options les plus importantes de GNU ar qui sera probablement livrée avec TIGCC 0.95.

Tout ceci pour dire qu'il est une très mauvaise idée d'appeler des outils autres que tigcc.exe ou tprbuilder.exe dans ses lignes de commande.

Tout ceci pour dire qu'il est une très mauvaise idée
d'appeler des outils autres que tigcc.exe ou tprbuilder.exe dans ses lignes de commande.

Aujourd'hui j'apprend plein de trucs.
J'opte pour ta méthode.

Par contre pour le hack de gris pour PolySnd, il y sera encore?

D'ailleurs, à titre d'information, la version actuelle de ar-tigcc ne comprend pas -r. Seulement -rc et -qc. (Mais on peut changer ça si c'est vraiment nécessaire.)

geogeo
: Par contre pour le hack de gris pour PolySnd, il y sera encore?

Oui, il marche toujours avec les sources actuelles, on n'a rien changé à cet endroit.
Mais évidemment, je ne peux pas garantir qu'il n'y aura aucun changement d'ici la release officielle de TIGCC 0.95.

Kevin Kofler
: Non, c'est le principe-même des librairies statiques qu'il faut séparer les fonctions pour permettre un linkage sélectif.

-ffunctionsections
-fdata-sections

Ça ne sert à rien. On linke par fichier objet, pas par section (du moins dans TIGCC 0.95). (Il y a une option pour supprimer les sections non référencées, mais je ne ferais pas confiance à ça à ta place. Et en plus, cette option peut être désactivée.)

Et pour finir, c'est du GCC. En assembleur, il faut déclarer les sections soi-mêmes pour utiliser cette méthode.

Par contre contrairement au format kernel, les DLL utilisent toujours les rables de relogement d'AMS

bah ça à l'air vachement bien tout ça, mais un point de détails:
vous entendez quoi par relogement ?

cf. ./86...

euh si je pose la question, c'est parce que j'ai pas bien compris pas parce que j'ai pas vu le post...

PpHd :
Par contre contrairement au format kernel, les DLL utilisent toujours les rables de relogement d'AMS

Solution: ne pas utiliser de DLLs.
De toute façon, elles ne sont prévues que pour des cas exceptionnels. Et vu que le nouveau linker peut mettre toutes les données du programme (même les chaînes de caractère) dans un fichier externe automatiquement (avec tables de relogement compressées dans le programme principal pour les accès au fichier externe), ces cas exceptionnels deviennent encore plus rares.

Au fait, Kevin, est-ce que maintenant (GCC 3.3 pre18), -mpcrel et -freg-relative-an fonctionnent correctement ?

Ben en gros l'exécutable contient des pointeurs vers des endroits dont l'adresse n'est pas connue au moment de la compilation (seule l'adresse relative par rapport au début du fichier l'est) ; donc au moment du lancement du programme il faut écrire les bonnes adresses aux bons endroits dans l'exécutable, et c'est à ça que sert la table de relogement.

XDanger
: Au fait, Kevin, est-ce que maintenant (GCC 3.3 pre18), -mpcrel et -freg-relative-an fonctionnent correctement ?

Pas mieux qu'avant, à mon avis. Ces switches sont et ont toujours été expérimentaux.

ah ok, merci Sally

> Pas mieux qu'avant, à mon avis. Ces switches sont et ont toujours été expérimentaux.
Je sais, mais c'est un peu dommage... Il est bien sûr possible de faire sans, mais ils pourraient être intéressants (mode pc-relatif = pas de table de relogements; une solution pour s'en passer est soit -freg-relative-an qui ne marche pas super bien, soit une global register variable).

Kevin Kofler :
L'algorithme de TIGCCLIB est le seul couramment utilisé. Universal OS utilise à l'origine le même code (ça a divergé depuis, mais l'algorithme reste le même), PreOs utilise le même algorithme avec du code différent. Tous les autres algorithmes (mis à part celui de Brunni) sont plus anciens et clignotent affreusement ou ne marchent pas du tout sur HW2.

y'a les gris de FlashZ aussi.

Ça m'étonnerait que l'algorithme soit fondamentalement différent. Mais j'avoue ne pas avoir vérifié.

je ne pense pas non plus qu'il soit different (l'algo), mais bon je precisais qu'une autre routine existait.