AS, il en est où ? - Page 3

>Thibaut:
>Kevin & TIGCC, c'est une histoire d'amour
>

Non, c'est juste que je suis membre de l'équipe.

>Nitro:
>Au fait pour les libs statiques, l'idéal serait d'avoir un convertisseur qui prenne les archives .a et fasse un fichier qui donne d'une façon claire et facile à parser : le nom des fonctions, le code assemblé de ces fonctions, avec les éventuels relogements, et les dépendances vers d'autres fonctions s'il y en a. Apres l'intégration avec AS est facile.
>
>Mais j'ai pas tellement envie de faire ça moi meme... alors si ça interesse quelqu'un, qu'il n'hesite pas à se manifester.

Moi, ça m'intéresserait, mais le format des fichiers .a est tellement compliqué que je ne pense pas y arriver.

>>Nitro : le support des caractères accentués dans les labels, tu feras ?
>
>Non, desolé
>Je ne trouve pas ça tellement interessant,

Moi non plus. Vous n'avez qu'à faire comme moi et mettre des labels en anglais. Au moins tout le monde les comprendra.

>d'ailleurs SIDE ne sait meme pas afficher les caracteres accentués si je me souviens bien...

C'est parce que la petite fonte n'affiche pas les accents.

>et pour les conversions PC<->TI il doit y avoir des problemes aussi puisque ce n'est pas standard.

Pas vraiment. Le jeu de caractères des TI-89/92+, celui des PCs Windows et celui de beaucoup des programmes pour Linux sont tous les 3 des supersets de ISO-8859-1. En particulier, les caractères accentués sont les mêmes. En revanche, DOS utilise un jeu de caractères différent (IBM-extended ASCII alias CP 437, ou alors CP 850 ou d'autres CPs du genre, selon la configuration).

Et Thibaut, je pense que la meilleure solution est de supprimer le support des labels accentués. Ça ne sert absolument à rien.

Ha Nitro le dernier paragraphe de Kevin me donne une lueur d'espoir

Kevin : C'est parce que la petite fonte n'affiche pas les accents.
Nitro n'utilise pas la petite fonte du TIOS.
Pour ton dernier post : ne recommence pas à vouloir faire ta loi. Il y a plein de langues qui ont des lettres accentuées, alors je vois pas pourquoi on n'en profiterait pas. American Power SUUXXX
[edit]Edité par Thibaut le 30-12-2001 à 15:43:03[/edit]

>Moi, ça m'intéresserait, mais le format des fichiers .a est tellement compliqué que je ne pense pas y arriver.

C'est ce que je me suis dit aussi, c'est pour ça que je n'ai pas envie de le faire moi-meme...

>Vous n'avez qu'à faire comme moi et mettre des labels en anglais. Au moins tout le monde les comprendra.

On est bien d'accord
D'ailleurs je n'ai jamais programmé autrement qu'en anglais, et de toute façon sur mon ordinateur tout est en anglais, comme à l'école

>ça m'oblige à monopoliser un registre tout le long du programme pour pouvoir adresser les vars globales

C'est ce que fait tout bon compilateur 68k (sauf TIGCC )
C'est pour ça que je n'ai pas été surpris quand j'ai vu que tu faisais ça et que je n'ai pas fait le rapprochement avec les accents. Sur les premiers OS Mac, ils utilisaient A5 pour acceder aux vars globales, et ils appelaient ça le A5-world
Sous PalmOS c'est au choix A5 ou A4 (PalmOS est tres similaire aux premiers OS des Mac car ils utilisaient les compilateurs 68K Mac optimisés pour ce genre de fonctionnement)
Win (LiteOS) utilise également cette méthode, avec le gcc patché de PalmOS que j'ai indiqué à JM à l'époque.
Quel est le grand avantage ? Faire du multitasking sans avoir à dupliquer le segment de code qui est read-only et qui peut rester dans la FLASH
[edit]Edité par Nitro le 30-12-2001 à 15:48:19[/edit]

Ca m'arrive alors d'avoir une bonne idée de temps en temps

Et je trouve vraiment idiot d'écrire des noms de labels et des commentaires qui ne seront pas compris par une partie de la communauté. (Je vais d'ailleurs traduire tous les labels et commentaires de db92 en anglais quand j'aurai le temps.)

Comme il y a des francophones qui comprennent mal les sources en anglais, il y a des anglophones qui comprendront mal le français.
Je ne vois pas pourquoi on devrait toujours privilégier les américains

Bon j'ai réfléchi pour les libs statiques, et on va proceder autrement... pas besoin de gerer les .a puisqu'on a les .o (qui sont plus abordables), il nous faut juste un archiveur qui s'occupe de prendre tous les .o et faire le fichier lib dans un format simple, destiné à etre envoyé à la calculatrice
Qu'en penses-tu Kevin ?

>Je ne vois pas pourquoi on devrait toujours privilégier les américains

Parce que l'anglais n'est pas seulement la langue des américains, c'est la langue internationale. Comment se fait-il qu'il y ai soit des sources en anglais, soit des sources en français, mais tres tres rarement dans d'autres langues ?

Cela dit, je peux modifier SIDE pour afficher les caracteres accentués comme leurs équivalents non-accentués... comme ça tout le monde est content

Le format des .o n'est pas tellement différent de celui des .a. Et le format COFF est généralement compliqué.

>Nitro:
>>[Thibaut:] Je ne vois pas pourquoi on devrait toujours privilégier les américains
>
>Parce que l'anglais n'est pas seulement la langue des américains, c'est la langue internationale. >Comment se fait-il qu'il y ai soit des sources en anglais, soit des sources en français, mais tres tres rarement dans d'autres langues ?

Entièrement d'accord. Il n'y a que certains français qui ne veulent pas s'adapter au fait que l'anglais soit la langue internationale.

Nitro : ok, mais modifie aussi AS
Remrque je sais pas...
a ton avis, il vaut mieux
- perdre un registre et donc de ralentir l'exécution des grandes expréssions manipulant des pointeurs
- adresser en absolu et accélérer les expressions complexes manipulant des pointeurs.

??

Le format COFF c'est quand meme pas la mort... et tu as les sources de obj2ti il me semble ?
Cet été j'ai du faire un linker m68k-COFF pour remplacer le "post-linker" du SDK de TI qui est vraiment tres buggé... et il eest vrai que le format est compliqué, mais pas impossible à exploiter
Si tu ne peux pas le faire je le ferais à partir de mon linker, mais je ne peux pas promettre que ce soit fait rapidement

Ah tiens, les problèmes qu'ils ont chez TI me rappellent quelque chose. Nous aussi on a dû revoir tout notre système de linking dans TIGCC 0.92...

Thibaut: je ne suis pas encore spécialiste en ASM 68k, mais il me semble que (je peux me tromper) l'acces aux variables globales relativement à un reg d'adresse est plus rapide et prend moins de place qu'en absolu... et je ne pense pas qu'en on-calc on fasse beaucoup d'expressions complexes avec des pointeurs... privilégier la simplicité pour diminuer les chances d'avoir des bugs c'est important
Enfin bref, si j'etais toi je garderais l'adressage relatif à un registre.

Et il y a eu pas mal de duplication d'efforts. (obj2ti ressemble beaucoup à ce que tu décris.) Le tout par la faute de TI.
[edit]Edité par Kevin Kofler le 30-12-2001 à 16:38:56[/edit]

Oui justement je me suis fait ce linker (qui ne me sert plus à rien puisque j'utilise TI-GCC) parce que obj2ti ne marchait pas avec les fichiers objets du compilateur SIERRA, et que je n'avais pas les sources pour corriger ça, et que JM n'etait plus joignable.

Nitro : OK, tu as raison

ExtendeD: oups je crois que tu as raison pour le enter qui vient tout seul... je crois que je l'ai corrigé maintenant, download et dis moi si ça te le fait encore.

Tu as oublié de virer l'"optimisation" sub.w/l #x,an -> subq.w/l #x,an lorsque x est supérieur à 8

Oui tu as raison, voila c'est corrigé

J'en ai profité pour corriger un petit bug du "Find" de SIDE.
[edit]Edité par Nitro le 30-12-2001 à 17:46:57[/edit]

Merci t'es génial

> Nitro :
Quelques suggestions concernant AS et Side (après le beta test des vacances ) :
1) Dans Side, il faudrait réactiver les paramètres "d'accélération" du clavier à l'allumage lorsque l'on éteind la TI à l'intérieur du programme (soit par l'APD soit par [<>]+[ON] ou [2nd]+[ON]).

2) (Side) : Afficher la liste des fichiers texte lorsque l'on ne spécifie pas de nom, pour sélectionner plus facilement (plutôt que de devoir taper le nom).

3) Quand il y a des erreurs de compilation avec AS ou SC, aller à la ligne de la première erreur dans Side (en lisant le fichier as_error.TEXT je pense )

4) Ajout de touches de raccourcis dans le menu char (Side) notamment pour les caractères les plus utilisés (#, $ ...) (touches numériques ?)

5) Sinon, une question ...
AS, optimise-t-il les valeurs immédiates comme les AND.L #n,<registre> -> ANDI.L #n,<registre> ?

Bonne continuation pour ces deux projets
[edit]Edité par ZdRUbAl le 02-01-2002 à 11:50:06[/edit]

je fais remonter le topic

Ok, je m'y mets

Merci
Sinon, un autre truc : dans SIDE je pense que par défaut tu devrais mettre des valeurs optimisées pour les paramètres clavier. C'est rien mais bon, ca aide souvent

Bon j'ai mis la restauration des key_rate et key_repeat apres l'APD / [<>]+ON / [2nd]+ON... par contre le reste c'est un peu chiant, j'ai trop la flemme
Et pour les optimisations, oui AS le faisait pour pas mal d'instructions, mais j'ai du en virer (ou modifier) la plupart quand j'ai implementé la table de relogement parce que ça faisait tout bugger...
[edit]Edité par Nitro le 04-01-2002 à 01:59:48[/edit]

Une autre suggestion
Tu peux permettre également la confirmation par F3 pour l'option Find.
(ca permettrait de faire un Find Next simple).

Idée pour AS : rechercher les includes dans cet ordre (enfin, ceux dont on ne précise pas le chemin d'accès bien sûr ) : répertoire de la source qui inclus, répertoire actif de la calto.

>Il n'y a que certains français qui ne veulent pas s'adapter au fait que l'anglais soit la langue internationale.
Hum. Mon petit, le Francais est la langue diplomatique internationale par exellence.