Librairie dynamique - Page 4

Folco (./90) :

p = NULL = (void* ) 0mais ca peut être différent d'un memset(p, 0, sizeof (void*));

Ah ? Et pourquoi ? oO

Voir norme C99

Oué ok, comme si j'en étais là

Je suis plutôt en train de chercher à comprendre pourqoi ça ne constitue pas une bonne vieille lib dynamique :

#include	<tigcclib.h>
#define USE_KERNEL
#define USE_TI89
#define USE_TI89TI
#define USE_TI92PLUS
#define USE_V200
int	_library;

// Map name
const char map1__0000[] = "Test";

=> /opt/gcc4ti/lib/tigcc.a: Error: Unresolved reference to `__main'.

Sans blague, j'en veux pas de main justement

=> Résoudru, fallait kernel.h et pas tigcclib.h

La définition de NULL dépend de l'archi du CPU, il se trouve qu'apriori tout les CPU sont fait plus ou moins de la meme maniere pour ça, mais ce n'est pas a excluer, sans compter que si tu utilise un debuggueur de mémoire, NULL peut tout a fait etre redéfini pour detecter certaines erreurs

Ok. J'arrive toujours pas à imaginer de cas où ça merde mais tant pis. Le truc de PpHd me semblait plus basé sur des histoires de taille. Je me suis creusé la cervelle sans trouver de quoi il pouvait s'agir.

Sinon, pour les libs kernel, ça ça suffit :

#include "kernel.h"
int	_library;

Vraiment super bien foutu kernel.h.

Folco (./81) :
Habituellement, est-ce que vous explicitez toutes les conditions, genre if(truc !=0) ou if(machin == 0) ?

Non, surtout pas, voir ça me fait l'effet de quelqu'un qui ne connaît pas bien le C. C'est inutile et redondant. Je mets toujours if (truc) ou if (!machin) et même if (!strcmp(...)).

Folco (./92) :
Je suis plutôt en train de chercher à comprendre pourqoi ça ne constitue pas une bonne vieille lib dynamique :

#include	<tigcclib.h>
#define USE_KERNEL
#define USE_TI89
#define USE_TI89TI
#define USE_TI92PLUS
#define USE_V200
int	_library;

Parce que tes #define n'ont aucun effet parce que tu les as mis après le #include, donc tigcclib.h ne les voit pas. Et du coup ton programme n'est pas kernel et ne peut donc pas être une librarie dynamique.

Ce n'est pas pour rien que l'EDI gère ça par un dialogue et que je conseille de toujours utiliser l'EDI.

L'EDI en fait 100 fois moins que mon script, c'est toujours le même problème

Il me semble que tu peux le configurer pour exécuter des scripts avant et après compilation, donc ça reviendrait au même.

Sauf quand tu veux faire plusieurs compilation à la fois, par exemple pour un pack archive. T'es obligé alors d'avoir plusieurs instances de TIGCC ouvertes, pas pratique du tout.

De toute façon, Kate overkill TIGCC IDE au niveau des features d'édition et de formattage, TIGCC IDE atteignant tout juste les features du Notepad, le problème est réglé.

Quelle est la manière optimale (au point de vue vitesse) de tester un bit en C ? Je pourrais faire un Data[index] & MASK, mais idéalement, il me faudrait un btst, non ?
Je vois bien peekbit, mais est-ce optimal ?
#define peek_bit(addr,bit) (!!(*((unsigned char*)(long)(addr))&(1<<(bit))))
Comme j'ai aucune idée de ce qu'y s'y passe, j'espère que la rotation n'est pas calculée au run-time si on donne un pixel précis ?
Ca va se traduire par un simple btst #n,x(an) une fois compilé ?

Je pourrais faire un Data[index] & MASK, mais idéalement, il me faudrait un btst, non ?

GCC est censé savoir générer des btst.b et btst.l tout seul... mais ne le fait pas toujours.
Ces définitions ont été faites avant les dernières versions de GCC, mais les macros de pixel d'ExtGraph utilisent de l'ASM inline avec opérandes C - une fois que la définition de ces macros est correcte (pas mal de bugfixes ont été nécessaires ), on est sûr d'avoir le code optimal.

Je vois bien peekbit, mais est-ce optimal ?

Pour un test de bit en mémoire, oui.

(j'ai édité).

Bon ben marchi.

Bonus : Si je fais un peekbit ( table [index] , 13)
Va-t-il savoir qu'en fait faut faire un peekbit ( table [index+1] , 5 ) ?

Ca serait beaucoup plus propre pour moi d'écrire ça comme ça.

Non, ça ne marche pas comme ça ^^
Faut que tu analyses le comportement de la chose.
En réalité peekibit est une macro sur & (enfin de mémoire) donc ça te donnerait table[index] & (1 << 13). Donc si ton table[index] est de type trop petit tu aura une extension de type automatique. En gros soit ça retournera soit toujours 0 soit le signe si ta valeur était signée. (Et le compilateur pourrait même optimiser ça mais je sais pas si gcc va si loin )

Bon, en fait, j'ai transformé mon tableau de short en tableau de char. Et je regarde à [index * 2] ou [(index *2) +1]. Les données sur les deux octets sont de toute façon distinctes, donc c'est aussi bien comme ça.

Heuu... Hmm tu dois t'être mal précisé dans ton post précédent alors
Tu as du faire un amalgame avec la notion de tableau et la représentation des données internes.

Enfin évidemment tu peux tester les bits 0-15 sur un entier 16 bits, et 0-31 sur un entier 32 bits, et ainsi de suite

Oui, et le compilateur s'en démerdera. Mais au niveau assembleur, je sais ce à quoi il faut que j'arrive, et un btst ne se fait que sur un octet, pas deux. Donc je préfère travailler sur un tableau de char, je lui donne une chance de ne pas faire de la merde.

Comment le cmopilateur va traiter ce type d'affectation :
Savez-CharX = (((CharX + 16) / 16) * 16);
Est-ce qu'il va se dire "ah ok, il veut un lsr.w #4 / lsl.w #4" ?

Est-ce qu'il va simplifier le /16*16 en se disant "putain il est con ce mec"

Le cas échéant, comment lui forcer la main ?

A moins qu'un CharX = (CharX +16) & 0xFFF0 soit mieux en terme de vitesse ?

Je ne sais pas ce que ça donne au niveau du nombre de cycles, mais en général pour faire ça en C on se sert de masques comme dans ta dernière hypothèse (ça fait une seule opération au lieu de 2, j'imagine que ça a de grandes chances d'être plus rapide, non ?)

Et il ne simplifiera en aucun cas le "... / 16) * 16", ça serait mathématiquement complètement faux.

Très bien. Tant mieux s'il ne simplifie pas, vu qu'on est en nombres entiers, ça serait faux en effet.

Je vais compter les cycles. D'un côté, on a :

lsr.w #4,dn
addq.w #1,dn
lsl.w #4,dn

De l'autre :

addi.w #16,dn
andi.w #0xFFF0,dn

Faut que je compte les cycles, le addq est vraiment très rapide.

Tiens, visiblement on a pas le droit de faire ça ?
CharX = (offset > 0 ? ((CharX - 16) & 0xFFF8) : CharX = (CharX + 16) & 0xFFF0);
Faut écrire quoi pour s'y prendre bien ? Pas envie d'écrire un if, ça prend trop de place dans le source pour ce que c'est.

Et en plus il me met "signed and unsigned in conditional expression, parce que CharX est unsigned, mais je ne fais que comparer offset à 0 (et offset est signed)

CharX = offset > 0 
      ? ((CharX - 16) & 0xFFF0) + 8 
      : (CharX + 16) & 0xFFF0 ;

pas vérifié, mais déjà il y avait une affectation de trop

Exact, fruit d'un copier coller mal réfléchi. Merci bien.

Marrant, du coup le warning du un/signed s'est barré comme par magie.

Heu sinon, le code cité par Pen^2 indique ((CharX - 16) & 0xFFF0) + 8 alors que celui que tu as mis(édité ?) indique ((CharX - 16) & 0xFFF8). C'est un changement normal ? Car les deux ne sont clairement pas équivalents.

Oui, bien vu, j'ai édité bêtement dans un moment de je ne sais quoi. Le bon code est ((CharX - 16) & 0xFFF0) + 8 en effet.

Optimisé, ça donne même (CharX &FFF0) - 8

-8 plutôt non ?

Oui corrigé, n'importe quoi

Lionel Debroux (./100) :
Ces définitions ont été faites avant les dernières versions de GCC, mais les macros de pixel d'ExtGraph utilisent de l'ASM inline avec opérandes C - une fois que la définition de ces macros est correcte (pas mal de bugfixes ont été nécessaires ), on est sûr d'avoir le code optimal.

Non, pas pour les tests! L'assembleur inline ne peut pas retourner une valeur dans un flag, donc tu es obligé de la mettre dans un registre pour rien. C'est pour ça que la macro de TIGCC n'utilise pas l'assembleur inline pour les tests!

Folco (./106) :
Comment le cmopilateur va traiter ce type d'affectation :
CharX = (((CharX + 16) / 16) * 16);

Si CharX est non-signé, ça va donner des shifts, si CharX est signé, ça va soit garder la division (optimisation taille), soit faire un shift + d'autres calculs pour avoir le même comportement (optimisation vitesse).

Si tu veux un shift, utilise les opérateurs de shift:
CharX = (((CharX + 16) >> 4) << 4);

Kevin Kofler (./116) :

Lionel Debroux (./100) :
Ces définitions ont été faites avant les dernières versions de GCC, mais les macros de pixel d'ExtGraph utilisent de l'ASM inline avec opérandes C - une fois que la définition de ces macros est correcte (pas mal de bugfixes ont été nécessaires ), on est sûr d'avoir le code optimal.

Non, pas pour les tests! L'assembleur inline ne peut pas retourner une valeur dans un flag, donc tu es obligé de la mettre dans un registre pour rien. C'est pour ça que la macro de TIGCC n'utilise pas l'assembleur inline pour les tests!

Tout à fait d'accord
Ma remarque portait sur le fait que GCC ne génère (ou du moins, à une époque, ne générait pas) pas toujours des instructions de bit, et que c'est pour ça que les macros de pixel d'ExtGraph utilisent bset, bclr, bchg et btst (en mettant le résultat dans un registre, effectivement) en ASM inline.

Mais la bonne solution dans ce cas, c'est de corriger le compilateur, pas d'utiliser de l'assembleur inline qui ne peut pas être optimal (à cause de ce problème de retour dans un flag).

Tu utilises bien trop souvent l'assembleur inline, et dans pas mal de cas, tes utilisations sont un workaround pour un bogue ou une limitation de GCC qu'il vaudrait mieux corriger dans GCC, workaround qui peut empêcher d'autres optimisations à portée plus globale plus tard.

Ben alors interdis l'assembleur inline !

Bah non, ça peut être utile dans certains cas. Mais le problème, c'est que c'est utilisé à tort et à travers.