TIGCC 0.95 Beta 2 pour Windows - Page 2

Uther
: Sinon j'ai un warning du genre: Startup code added into library c'est du a quoi ca?

Tu es en train d'essayer de mettre du code de démarrage prévu pour un programme dans une librairie. Une librairie ne peut pas définir des options nécessitant du code de démarrage.

NiPuteNiSoumise :
Génère-t-elle enfin l'instruction mulx pour multiplier des nombres sur 16 bits ?

C'est fait depuis le 5 juillet! (En -Os seulement.)

Et pour le topic "Fork de TIGCCLIB", c'est lamentable... On s'amuse à poster des mensonges à mon sujet ("avec la bénédiction de Kevin") et on me kicke du sujet pour m'empêcher de répondre, et en plus on édite le message pour que je ne voie pas qui est le c*nnard qui m'a kické. "Et si par hasard Kevin trouvait quelque chose à y redire, il peut s'exprimer " mon c*l... Et vu que je ne peux pas savoir qui d'entre-eux m'a kické, je les kicke tous d'ici, ça leur apprendra à tous de ne pas se f**tre de ma gueule:











Et voici ma réponse:

C'est bientôt fini la déconnade??? On est dans "Prog C TI" ici, vous devriez déménager dans "Humour et Blagues"...
Et évidemment que vous n'avez pas mon support, mais je pense que ça va de soi.

Doucement Kevin faut pas t'énerver

lol Kevin. Petit comme réponse. Au moins autant que leur topic.

Bon, on va dékicker les bouffons de l'autre topic, sauf pour Pollux qui est assez clairement le c*nnard qui m'a kické (vu que c'est lui le seul qui a les privilèges nécessaires). J'espère qu'ils auront appris leur leçon.











Et puis bon:

Kevin Kofler
:

NiPuteNiSoumise :
Génère-t-elle enfin l'instruction mulx pour multiplier des nombres sur 16 bits ?

C'est fait depuis le 5 juillet! (En -Os seulement.)

Pourquoi en -Os seulement ?

Sasume
:

Kevin Kofler
:

NiPuteNiSoumise :
Génère-t-elle enfin l'instruction mulx pour multiplier des nombres sur 16 bits ?

C'est fait depuis le 5 juillet! (En -Os seulement.)

Pourquoi en -Os seulement ?

Parce que c'est lent.
Dans les cas où c'est ce qu'il y a de plus rapide, c'est utilisé même en -O2 ou -O3, mais souvent, une suite de décalages et d'additions est plus rapide, donc c'est ce qui est utilisé si on optimise en vitesse.

Ah d'accord.
J'avais mal compris, je croyais qu'en -O2 et -O3 on utilisait encore un jsr _muls32_ (je ne me souviens plus du nom exact) au lieu du mulx.

Bah, normalement, il n'y a pas de raison que mulsi3 soit appelé. Mais je vais vérifier.

Ah, attends, on s'est peut-être mal compris. Je pensais à la multiplication 16-16-16. Vous parlez probablement de la 16-16-32. Je n'ai pas touché à celle-là.

Mais, que je sois en -Os ou -O2, pour ça:

long f(int x,int y)
{
 return (long)x*(long)y;
}

j'ai muls qui est généré, pas un appel à __mulsi3.

Je ne me souviens plus des détails, mais je me souviens grossièrement que lorsqu'on faisait une multiplication entre deux facteurs de 16 bits tous les deux, le code généré faisait appel à mulsi3.

Et j'ai un mulu pour ça:

unsigned long f(unsigned int x,unsigned int y)
{
 return (unsigned long)x*(unsigned long)y;
}

Hier, j'ai remarqué un bug avec EXECUTE_IN_GHOST_SPACE sur ma V200 (en utilisant une DLL nostub). ça ressemble fort à ça:

AMS 2.04 and AMS 2.05 introduce yet another level of protection (which existed before, but caused problems very seldomly): on these AMS versions, even jumping to the "ghost address space" (above 256K) is not possible if the program counter is out of a certain area. (This caused the so-called "second launch crash"
; if you have AMS 2.05 with any longer program like TI-Chess, you probably know what I am talking about.)[...]

Je n'ai pas encore réellement besoin de EXECUTE_IN_GHOST_SPACE pour le moment, mais si c'était corrigé ça serait parfait

As-tu bien mis EXECUTE_IN_GHOST_SPACE dans le programme principal et pas dans la DLL?

Oui, sinon la dll ne pourrait pas se charger

Es-tu sûr que le plantage est un déclenchement de la protection anti-exécution? (Tu as quoi quand la calculatrice plante? Une barre noire sans texte? Ou autre chose?)
Ton programme et/ou ta DLL appelle(nt)-il(s) du code dans des fichiers externes (ni le programme, ni la DLL)?

Es-tu sûr que le plantage est un déclenchement de la protection anti-exécution?

Après réflexion, c'est peut-être dû à LoadDLL, puisqu'en répondant à ton message, je viens de me rappeler que les niveaux de gris sont actifs quand ça plante.

Ton programme et/ou ta DLL appelle(nt)-il(s) du code dans des fichiers externes (ni le programme, ni la DLL)?

Non, tout le code nécéssaire est dans le programme ou dans la DLL.

GoldenCrystal
:

Es-tu sûr que le plantage est un déclenchement de la protection anti-exécution?

Après réflexion, c'est peut-être dû à LoadDLL, puisqu'en répondant à ton message, je viens de me rappeler que les niveaux de gris sont actifs quand ça plante.

Tu n'as pas répondu à ma question: comment ça plante???

Si j'ai aps précisé, c'est parce qu'en fair, rien de spécial n'apparaît, c'est juste que le programme s'arrête, rien n'apparaît à l'écran. (D'ailleurs, peu importe que la dll soit présente ou non)

Pas de barre noire en haut?
Dans ce cas, ça m'a plutôt l'air d'être une boucle infinie quelque part qu'une violation de la protection anti-exécution...
[2nd]+[HAND]+[ON] réagissent-ils (à condition que tu n'ais pas touché à l'AI6 dans ton programme)?

[2nd]+[HAND]+[ON] réagissent-ils (à condition que tu n'ais pas touché à l'AI6 dans ton programme)?

ça ne réagit pas. Je ne touche qu'aux interruptions 1 et 2.

Hmmm... Bizarre ça.
Autres trucs:
* Sur VTI, ça te fait la même chose?
* Pourrais-tu m'envoyer ton projet avec les sources complètes et compilables pour que je puisse déboguer le problème, s'il te plaît?

Euh, attends, là y'a un truc que je comprends pas... Sans EXECUTE_IN_GHOST_SPACE, la DLL se lance et il n'y a pas de plantage
Sinon, avec VTI, il n'y a pas de plantage (comme d'habitude, VTI reste insensible à ce genre de chose)
EDIT: a non, en fait, ça plante plus, c'est tout
EDIT2: maintenant ça plante quand il n'y a pas EXECUTE_IN_GHOST_SPACE

Bon, si ça ne plante plus, c'est bon.
Si ça recommence à planter, dis-le moi.

Je vais vérifier s'il n'y a pas de bug dans mon programme parce que ça devient très étrange

C'est carrément bizarre là, en effet.

Sinon, un petit truc que j'avais remarqué, c'est qu'on doît inclure DLL_INTERFACE...DLL_IMPLEMENTATION dans chaque fichier c du projet si on veut que ça compile une DLL nostub, et ce n'est pas très pratique. Une seule fois devrait suffire, non ?

Ça devrait suffire en effet... Es-tu sûr que ce soit nécessaire dans la bêta 2? Es as-tu bien mis le fichier principal en premier dans la liste? Si oui (aux 2 questions), ça mérite un "bug report" à part entière (en utilisant le formulaire s'il te plaît, pour que Sebastian le lise aussi et pour qu'on ait les informations qu'il nous faut).
Et c'est peut-être justement le fait que tu as ces macros dans plusieurs fichiers qui fait tout boguer. Normalement, DLL_* devraient être dans le fichier principal seulement.