AS et AMS < 2.04 :D - Page 3

Mais du coup, cmpstri prend 4 fois plus de temps qu'un strcmp :
1- lecture de l'octet
2- extension sur 16 bits
3- lecture de type 0(an,dn.w)
4- ceci pour les deux sources et pour chaque caractère


Bref, je continue de penser qu'AS serait sensiblement plus rapide avec strcmp !

XDanger a écrit :
Ah, dommage que personne n'ait le temps d'inclure ces trucs dans TIGCCLIB... Kevin, est-ce que le zip des pending updates est régulièrement updaté ?

Non. Et il me semble qu'il n'est même plus téléchargeable là (je ne le trouve pas sur le FTP).

Thibaut a écrit :
Bref, je continue de penser qu'AS serait sensiblement plus rapide avec strcmp !

Un assemblage prend environ dans les 1/3 de seconde, la différence tu la verras pas passer

Tu veux dire qu'AS traite en moyenne 3 lignes d'ASM par seconde ? Je crois me rappeller qu'il est beaucoup plus rapide (mais ça fait super longtemps que je ne l'ai pas utilisé).

A l'époque où je m'en servais, il traitait 64 ko de source en 17 secondes si j'ai bonne mémoire. Si on pouvait descendre ce temps à 14 secondes, par exemple, ça serait plutôt bien
On pourrait proposer 2 versions dans le ZIP : une qui est sensible à la casse, et une autre qui n'est pas sensible.

#define CASE_SENSITIVE  // mettre en commentaire pour la version insensible
#ifdef CASE_SENSITIVE
  #define compare_string(s1,s2) strcmp(s1,s2)
#else
  #define compare_string(s1,s2) cmpstri(s1,s2)
#endif

C'est pas la mer à boire

Thibaut
a écrit : Tu veux dire qu'AS traite en moyenne 3 lignes d'ASM par seconde ?

Non, je parlais de l'assemblage d'une source entière
En fait je n'avais jamais testé AS avec de grosses sources. Il fait 9s pour 32ko de sources finalement.

Thibaut> Ce n'est ptet pas la mere a boire, mais si tu veux utiliser strcmp au lieu de stricmp sachant que les sources sont dispo tu te le fait toi meme, mais je refuse d'ajouter un truc qui rendrait incopatible certaines sources (d'ailleur je suis meme pas sur que stricmp ne soit pas utilisé pour les tableau de symboles) donc c'est hors de question de faire sa en standard

Arf! Moi quand je code avec AS j'ai tout le temps des erreurs "Symbol value differs between first and second pass", ça arrive lorsque j'ai trop de label. Mais je sais pas comment vous faites pour assembler des sources de 32ko, à partir de 2 ou 3 ko moi c'est même pas la peine d'espèrer.

L'erreur que tu as, c'est quand tu utilises deux labels qui ont le même nom.

oui

faudrait que je rende aussi les erreur plus "compréhensibles"

N'hésitez pas a faire un buglist et une wishlist

jackiechan> Ca ne vient pas de là... J'ai déjà vérifié. Bien sûr que je n'ai pas 2 labels de même nom.
La seule manière qui me permet d'avoir des sources un peu plus grosses, c'est d'enlever include "ams" et de remplacer tous les Romcalls par leur offset respectifs. Et encore là au bout d'un moment je suis limité. Alors je réduis la taille des noms de mes labels et encore là je suis limité. Je pense qu'il y a trop de labels mais pourtant il n'y en a qu'un vingtaine, pas plus...

Sa doit etre alors la table de symbole qui est trop petite
(ams inclu bcp de symboles)

Donc faut aussi que je vérifie le fonctionnement de la table de symbole, oki

Mon cher godzil, t'es bouché
Je propose que tu inclues une version sensible à la casse A CÔTE de la version insensible, et non pas UNE version standard imposée !

les sources d'AS sont distribué, donc si tu veux changer des truc, rien ne t'en empeche !


Bon je suis en train de reprendre toute les sources d'AS, le partitionnement entre les fichier C a été assé bizzarement fait, et je vais tout reprendre (sa permettra l'utilisation entre autre de TIGCC-IDE) et une compilation moins brute (pasage par des .o)

Je vais surement faire pas mal de modifs sur le fonctionnement interne d'AS, et j'espere ajouter le support des macro en meme temps

Cool

Aouyayaya je plein nitro, je sais pas comment il a reussi a maintenir se code !

On sent que le code d'origine est pas jeune :/

Il y a plein de choses qui sont vraiment pas propre selon les "chartes" actuelles de codage..

J'vais avoir du boulot, mais bon c pas grave, je vais tenter d'alleger le code et le rendre plus portable (je sens que je vais en changer une grosse majorité :/)

Oui je pense que c'est vraiment une bonne idée. Parce que CC est vraiment bof, mais AS serait parfaitement fonctionnel ou presque si il n'y avait pas le problème de la table des symboles et si les macros étaient gérées.

godzil
a écrit : Il y a plein de choses qui sont vraiment pas propre selon les "chartes" actuelles de codage..

Comme quoi par exemple ?

Des fichiers C sont inclu dans le "corp principal" du programme (entre autre)
il y a une utilisation assé abusive des variables globales etc....

L'inclusion de fichiers C, c'est peut-être volontaire de la part de Nitro (optimisation vitesse & taille)

je sais pas, mais sa fait pas forcement tres propre, et sa empeche une compilation incrémentielle

Thibaut a écrit :
L'inclusion de fichiers C, c'est peut-être volontaire de la part de Nitro (optimisation vitesse & taille)

Avec le switch -Wa,-l ça ne doit pas changer grand chose.

XDanger a écrit :
Ah, dommage que personne n'ait le temps d'inclure ces trucs dans TIGCCLIB...
Kevin, est-ce que le zip des pending updates est régulièrement updaté ?

Kevin a écrit:
Non. Et il me semble qu'il n'est même plus téléchargeable là (je ne le trouve pas sur le FTP).

Rah, dommage. Je vais voir si je trouve ça sur le FTP de TICT, mais ça m'étonnerait beaucoup...

Oui effectivement je me suis bien amusé à maintenir le code d'origine qui date d'il y a 150 ans au moins (), du temps où le standard du C n'imposait pas de prototypes, et dans l'assembleur d'origine il était impossible de mettre un espace en trop pour séparer les mnemonics des instructions, impossible de mettre un espace apres une virgule, etc... le format était totalement rigide, ça a impliqué pas mal de changements mais ce programme était quand meme suffisamment bien écrit pour que ce soit pas trop pénible.

De plus, j'inclus tous les .c dans le .c principal parce que à l'époque où j'ai fait la majorité du travail sur AS (pour vous dire un peu à quel point ça ne date pas d'hier), tigcc ne gérait pas la compilation séparée.. je pense que Kevin peut confirmer que ça fait vraiment super longtemps. Et depuis ce temps là je n'ai pas trouvé la motivation de tout re-séparer en unités de compilation indépendentes.
voila.... bonne chance à tous ceux qui pourront faire des modifs pour améliorer le programme.

du temps que tu passe dans les parages, nitro, tu a deja rencontré un pbm avec les valeurs imédiates ?

godzil
a écrit : du temps que tu passe dans les parages, nitro, tu a deja rencontré un pbm avec les valeurs imédiates ?

Personnellement non...

Moi non plus. Je ne programme pas souvent avec AS, mais ça m'arrive de temps en temps.

hummm etrange

J'suis vraiment en grogne face a ses sources lol

Bon j'vais tester un truc pour savoir si je suis responsable de qq chose ou si c tigcc qui bug :/

Haaaaaaaaaaaaaaaaaa !!!
je suis content, le fautif est bien tigcc

ou alors nitro les sources distribué correspondent pas a la version compilé fournis avec :/

La version compilé dans le zip marche nickel, mais si je tente de le compiler avec TIGCC 0.94 SP4 sa foire sur les constantes numériques :/

G isolé le code C qui genere cette erreur (enfin qui dit a l'assembleur qu'il y a un pbm, reste a savoir d'ou vien se pbm, car le code C a l'air juste :/)

Le code ASM testé :

 move.b #33,d0
 rts

Kevin si tu passe par la

Quelle est la version de GCC (tigcc --version) qui fonctionne et celle qui ne fonctionne pas? As-tu essayé le prerelease de GCC 3.3 (http://tigcc.ticalc.org/gcc33/) le plus récent?

Essaye aussi d'isoler un testcase plus petit (qui ne doit pas forcément faire quelque chose d'utile. Il ne doit même pas être exécutable à condition que tu identifies l'erreur dans le code assembleur généré) si possible. AS est un programme relativement gros. Mais si tu n'arrives pas à isoler un testcase, je le ferai. Il me faudra juste les numéros de version de GCC (celle qui fonctionne et celle qui ne fonctionne pas).