Créer une librairie - Page 1

Hello tout le monde !

Je cherche à programmer une librairie en C.
Pour l'instant la seule méthode que j'ai trouvé c'est de
compiler un vrai programme executable, récupérer le code asm
généré par TIGCC et rajouter xdef _library et quelques bidouilles....

Y'a pas mieux en C ??

A+

#define USE_KERNEL
#....

int _library;

void malib__0000(short x, short y) {
return x+y;
}

Voila. C'est tout.

c'est expliqué dans mon tutorial !!!!!!!!

www.ti-fr.org
rubrique programmation


(enfin, je crois que je l'ai mis)

vivi, ça y est... Et c'est aussi dans la doc de TIGCC

J'avoue mon erreur !!!
En fait, j'avais une vieille version de TIGCC ( du temps ou c'était pas encore terrible...)
La nouvelle est bien mieux !!!

Je vais voir la doc sur Ti-fr...

Merci tout le monde
A+

#define USE_KERNEL
#include <tigcclib.h>

char _library[] = "Un commentaire quelconque...";
short _ti92plus, _ti89;

#define mylib_version mylib1__0000
long mylib1_version = 0b0000000000000001;


#define myopen mylib1__0001
void myopen()
{
}


Help !!!! I need somebody help...

microfirst
a écrit : Help !!!! I need somebody help...

Quel est ton problème maintenant?

Et short _ti92plus,_ti89 fonctionne toujours pour des raisons de compatibilité, mais c'est vieux. Maintenant, on met:
#define USE_TI89
#define USE_TI92PLUS
#define USE_V200
(N'oublie pas la Voyage 200!)

Avec l'exemple ci-dessus , quand je compile j'ai une erreur lors de la phsae de linkage :

"Exported label is not valid" !!!!

C'est ça qui est faux:
#define mylib_version mylib1__0000
long mylib1_version = 0b0000000000000001;
Il manque le "1":
#define mylib1_version mylib1__0000
long mylib1_version = 0b0000000000000001;
Et du coup, mylib1__0001 n'était pas valide, parce qu'il n'y avait pas de mylib1__0000.

D'ailleurs je ferais :

#define USE_KERNEL
#define USE_TI89
#define USE_TI92PLUS
#define USE_V200
#include <tigcclib.h>

int _library;
char _comment[] = "Un commentaire quelconque...";
int mylib__version01; // Preos version number

#define mylib_version mylib__0000
long mylib_version = 0b0000000000000001;

#define myopen mylib__0001
void myopen()
{

}

PpHd
a écrit : int mylib__version01; // Preos version number

Je précise que ça ne marche qu'avec TIGCC 0.94 bêta 1 minimum.

Sinon ca ne fait rien. Donc il peut le mettre quand meme

Et au fait: pourquoi veux-tu absolument programmer une librairie dynamique plutôt qu'une librairie statique? Les librairies statiques sont bien plus simples, plus pratiques, moins gaspilleuses en place (seules les fonctions effectivement utilisées se retrouveront sur la calculatrice) etc.!

Et chaque fois que l'on a besoin d'une fonction, elle se retrouve dans le programme, d'ou perte de place si plusieurs programmes l'utilisent

Tout à fait, mais Kevin sera toujours trop fier pour reconnaître que son argument gain de place en faveur des librairies statiques est faux.

Bon écoutez: tigcc.a fait 45954 octets! Je voudrais voir la gueule que vous feriez si c'était une librairie dynamique! Et Corridor92 ne marcherait certainement pas avec TIGCCLIB en dynamique, ça prendrait beaucoup trop de RAM. Probablement même TI-Chess ne marcherait pas.

Si tu veux je te fais tigcclib, et qui fonctionne tres bien. Paris tenu ?
Surtout que les .a prennent au moins 50% de place qu'un .o

PpHd
a écrit : Si tu veux je te fais tigcclib, et qui fonctionne tres bien. Paris tenu ?

Non, merci. On veut pouvoir changer les implémentations internes quand on veut, donc on n'en veut pas de TIGCCLIB en dynamique. La licence ne t'interdit pas d'en faire une, mais à la prochaine bêta de TIGCC, elle ne marchera très probablement plus (il y a des changements internes entre pratiquement chaque bêta).

Petit joueur

Kevin, si votre bibliothèque avait été écrite en ASM, elle pèserait aux alentours de 30 ko.

>> Corridor92 ne marcherait certainement pas avec TIGCCLIB en dynamique
Ben si puisque les 45 ko (ou 30 ko...) seraient divisés en plusieurs fichiers et qu'aucun programme n'a besoin de charger toutes les libs existantes pour fonctionner

Ben non, TIGCCLIB est et restera un seul fichier!!!
Découper TIGCCLIB en plusieurs fichiers serait une vraie insulte envers le travail de Zeljko! C'est vraiment hors de question.
Et de toute façon, TIGCCLIB en dynamique est hors de question.

Et quand je parle d'économie de place, je mesure la taille d'un programme, pour la simple raison que personne ne peut prétendre savoir quelles combinaisons de programmes l'utilisateur aura sur sa calculatrice, et si ces combinaisons de programmes utiliseraient les mêmes librairies dynamiques ou des librairies dynamiques différentes! (J'ai toujours dit ça: les exemples que PpHd donne pour montrer un apparent gain de place avec les librairies dynamiques sont toujours choisis de manière à avoir exclusivement des jeux genlib. Ce n'est pas du tout le cas général!)

Mais la licence le permet

Et avec preos 0.58 je peux faire un seul fichier tigcclib contenant plein de sous fichiers avec les fonctions necessaires

Vas-y PpHd ! tu vas voir le pauvre mode _nostub va bientôt être oublié de tous quand chacun se rendra compte du gain de place du mode kernel

Non, personne à part vous n'utilise le mode kernel même s'il prend moins de place! Quand comprendrez-vous que tout le monde à part vous déteste le mode kernel?

Et vu le nombre de fonctions qu'il y a dans TIGCCLIB, et le nombre de fonctions effectivement utilisées, le gaspillage de place est énorme si tu la mets en dynamique.

Et nos headers ne seront jamais compatibles avec une TIGCCLIB dynamique, donc tu auras un fork À mettre à jour régulièrement.

>Et quand je parle d'économie de place, je mesure la taille d'un programme, pour la simple raison que personne ne peut prétendre savoir quelles combinaisons de programmes l'utilisateur aura sur sa calculatrice,
C'est bien la ton erreur. Il faut faire une analyse plus fine

>et si ces combinaisons de programmes utiliseraient les mêmes librairies dynamiques ou des librairies dynamiques différentes!
avec la democratisation de tigcc, si on faisait une lib dynamique, ca prendrait beaucoup de programme ensemble, nan ?

>(J'ai toujours dit ça: les exemples que PpHd donne pour montrer un apparent gain de place avec les librairies dynamiques sont toujours choisis de manière à avoir exclusivement des jeux genlib. Ce n'est pas du tout le cas général!)
c'etait pour le mettre en evidence, dans un cas ou c'est clair et net.
Et c'est aussi un cas realiste (le mien).

PpHd a écrit :
>et si ces combinaisons de programmes utiliseraient les mêmes librairies dynamiques ou des librairies dynamiques différentes! avec la democratisation de tigcc, si on faisait une lib dynamique, ca prendrait beaucoup de programme ensemble, nan ?

Vu la taille de TIGCCLIB (dont seule une partie relativement petite sera effectivement utilisée dans chaque programme), ça ne vaudrait quand-même pas le coup!

Et puis, tu n'as pas compris que TIGCCLIB évolue, et qu'on peut donc difficilement maintenir la compatibilité binaire entre les versions. Avec les librairies statiques, on peut changer l'ABI quand on veut sans créer aucun problème de compatibilité (avec les programmes en C), c'est bien plus pratique.

Si j'ai compris, et je vous le reproche. Mais une fois que la convention assembleur sera cataloguee, vous ne pourrez plus y couper

C'est une bonne raison de continuer à ne pas la documenter.
Et puis, même si on la documente, ça ne sera valable que pour la version de TIGCCLIB précise qu'on documente. Ça changera à la prochaine. (Tout l'avantage des librairies statiques est qu'on n'a pas besoin de maintenir une compatibilité binaire. Tu n'as qu'à linker avec une ancienne version si ton programme dépend de l'ancienne ABI, l'utilisateur ne verra pas la différence.)