TiGcc: éviter de tout recompiler - Page 1

J'aimerais savoir comment éviter de tout recompiler à chaque fois, comme par exemple le fichier asm GNU, ou un fichier asm dans mon prog.
Mais je m'y perd dans la doc de tigcc. Et j'ai pas envie de faire des batchers compliqués. Je veux juste une méthode simple sous tigcc.
J'espère ne pas trop en demander.

C'est tout simple

Ouvre la boîte des préférences accessible par File|Preferences.... Sur l'onglet General, la case "Delete object files after successful linking" doit être décochée.

Quand c'est fait, il ne te reste plus qu'à compiler avec le premier bouton de compilation de la barre d'outils : Make CTRL+F9, et pas avec le 2ème (Build ALT+F9)

OK c'est nickel. Meme F9 fonctionne

Je pense que tu as compris pourquoi les *.o ne doivent pas être effacés : si le .asm n'a pas la même date/heure de modification que le .o associé, TIGCC relance la compilation.

PaXaL a écrit :
OK c'est nickel. Meme F9 fonctionne

F9, c'est "Run". Ça doit aussi fonctionner en effet.

Makefile

Makefile rulez

Bof, c'est lourd les makefiles.

Et attention, les makefiles, c'est bien à condition de n'utiliser que des tigcc -c pour compiler et des tigcc pour éditer les liens (linker). N'essayez pas d'appeler GCC, AS, LD, Obj2TI, ... directement.

Kevin Kofler a écrit :
Bof, c'est lourd les makefiles.

Mouais, mais ça fait *presque* portable

Je vais (pour la Xeme fois) tenter me le lancer en prog, mais autant
commencer en asm, vu qu'on commence à l'apprendre au lycée.
pour un processeur 68K motorola, les instructions (au lycée) sont
tres differentes, c'est normal ? ya pas de tuto en asm sur ti-fr !
(squale !!!)

meowcat a écrit :
pour un processeur 68K motorola, les instructions (au lycée) sont tres differentes, c'est normal ?

La syntaxe varie selon l'assembleur (le programme) utilisé pour assembler.
Tu peux essayer GNU as (avec TIGCC), peut-être que ça te convient mieux.

meowcat> j'ai commencé un tuto ASM
orienté A68, et mode nostub, bien que j'ai l'intention de faire un peu de mode kernel au milieu, vu l'importance du kernel (que ce soit pr certaines fonctionnalités offertes, ou pour son role historique)

mais vu que je ne peux passer que très peu de temps dessus, il n'avance que très très très lentement
(et depuis la rentrée, j'ai rien eu le temps de coder pr TI )

squale92
a écrit : et mode nostub,

Mais:

bien que j'ai l'intention de faire un peu de mode kernel au milieu,

Beurk!

vu l'importance du kernel

Re-beurk!

(que ce soit pr certaines fonctionnalités offertes,

Fonctionnalités qui sont très loin d'être nécessaires et dont l'implémentation ne fait que gaspiller de la mémoire (la preuve: tout kernel a une taille non-négligeable).

ou pour son role historique)

Ce n'est pas une raison d'encourager son utilisation pour des programmes récents. Je veux bien qu'on parle de kernels dans un texte sur l'histoire de la programmation en assembleur sur TI-89/92+/V200, mais pas dans un tutorial censé apprendre à programmer.

arf !
c dingue d'etre ôssi accroc du nostub qd meme !!

Accro au _nostub, peut-être. Il n'empêche qu'il ne dit, à mon avis, que la vérité...
"Fonctionnalités qui sont très loin d'être nécessaires et dont l'implémentation ne fait que gaspiller de la mémoire (la preuve: tout kernel a une taille non-négligeable)." est indiscutable.

même si vous êtes totalement contre le mode kernel, je ne changerai pas d'avis, et écrirai quelques trucs à ce sujet.
notament, les librairies dynamiques !

je ne considère pas le mode kernel comme dépassé, et je sais que je ne suis pas le seul.


je commence par le nostub, parce que c'est ce qui est le plus utilisé actuellement (et parce que bcp de tutos commencent par le kernel, qui est moins à la mode aujourd'hui), mais je ne peux faire un tuto sur l'ASM sans parler du mode kernel !

squale92
a écrit : notament, les librairies dynamiques !

Beurk! Un fichier supplémentaire sur la calculatrice pour rien, des fonctions qui traînent sur la calculatrice totalement inutilisées, ...

je ne considère pas le mode kernel comme dépassé, et je sais que je ne suis pas le seul.

Tu te trompes alors, et je sais que tu n'es pas le seul à te tromper. Le mode kernel est dépassé!

squale92
a écrit : je commence par le nostub, parce que c'est ce qui est le plus utilisé actuellement (et parce que bcp de tutos commencent par le kernel, qui est moins à la mode aujourd'hui), mais je ne peux faire un tuto sur l'ASM sans parler du mode kernel !

Comme tu le dis toi-même, il y a déjà assez de tutoriaux sur le mode kernel. Si les programmeurs s'intéressent à ce vieux style de programmation, ils n'ont qu'à utiliser un vieux tutorial. Les tutoriaux récents ne doivent pas présenter les styles de programmation dépassés!

Tu te trompes alors, et je sais que tu n'es pas le seul à te tromper. Le mode kernel est dépassé!

Tu penses comme tu veux
Et j'agis de même.

il y a déjà assez de tutoriaux sur le mode kernel

Ma fois, c'est ce que tu penses

[cite]Comme tu le dis toi-même, il y a déjà assez de tutoriaux sur le mode kernel/[cite]
Je ne me rapelle pas avoir dit ça !!!
J'ai dit : "bcp de tutos commencent par le kernel".
Et ceci ne signifie pas qu'il y en a assez. juste qu'il y en a bcp (beaucoup)

ils n'ont qu'à utiliser un vieux tutorial

sauf que les vieux tutoriaux parlent pas mal de fargo...
ou alors des ROM1.0x
ou alors de DoorsOS...
en bref, la majorité des vieux tutoriaux sont dépassé...
moi, j'ai l'intention de rédiger en orientant vers PreOS... qui est tout neuf (et même encore en développement !!!)
=> ce tutorial ne sera pas autant dépassé que pas mal d'autres.

Kevin Kofler a écrit :
Tu te trompes alors, et je sais que tu n'es pas le seul à te tromper. Le mode kernel est dépassé!

Le problème c'est que beaucoup d'anciens jeux fonctionnent en kernel,
et donc les noobs (moi je prendrais selon mes connaissances) suivent.
Au fait dans ce cas, pkoi CF était en kernel (juste une question) ?

parce que PpHd, au cas où tu ne l'ai pas remarqué, fait parti des amateurs du kernels.
parce que, à l'époque où CF a été commencé, le nostub n'était pas à la mode, voir quasi-inexistant.
parce que CF utilise Genlib, qui n'est accessible en nostub que depuis très peu de temps
parce que CF utilise pas mal de trucs qui ne sont possibles qu'en mode kernel... et que avec PreOS, d'ailleurs

Il faut regarder les choses en face: les seuls programmes nécessitant/étant des kernels qui sortent actuellement, sont en gros ceux de la T3...
Combien de _nostubs pour un kernel actuellement ? Et on ne peut pas dire que tous les _nostubs soient de mauvaise qualité...
Le mode kernel est surtout orienté jeux (ça ne semblait pas intéresser les programmeurs de faire autre chose).

>parce que CF utilise pas mal de trucs qui ne sont possibles qu'en mode kernel... et que avec PreOS, d'ailleurs
Il n'y a rien de faisable en mode kernel qui ne soit infaisable en mode _nostub. Le mode kernel a des trucs que le mode _nostub n'a pas, parce que leur utilité est discutable (les BSS par exemple: les fonctions d'allocation dynamique système suffisent dans tous les cas, mais les utiliser est plus contraignant, c'est sûr). Les librairies dynamiques sont un autre prétendu avantage du mode kernel. Mais elles ne sont que rarement nécessaires. Que dire des librairies de 100 octets environ pour sauvegarder les parties des jeux, par exemple...

Et il y a des trucs parfaitement faisables en mode _nostub qui sont infaisables en mode kernel, à cause de la suppression automatique des handles...
Cette suppression automatique est désactivable, certes, mais ce n'est pas un comportement standard. AMS, lui, se moque du fait que l'utilisateur alloue et ne libère pas; cette façon de faire a des désavantages si le programmeur n'est pas soigneux, mais elle rend possible les TSRs, le stockage d'informations dans la home screen history...

mode kernel surtout orienté jeu> ben, ma fois, je voie aucun mal à ça

le reste, ça a déjà été discuté 36 fois ; je ne reviendrai pas dessus.
je n'ai aucune envie de me lancer dans le débat kernel vs nostub : ça ne changerai rien à rien (pas plus que les autres fois).

XDanger a écrit :
>parce que CF utilise pas mal de trucs qui ne sont possibles qu'en mode kernel... et que avec PreOS, d'ailleurs Il n'y a rien de faisable en mode kernel qui ne soit infaisable en mode _nostub.

Pour CF, PpHd semblait dire que ça aurait été très très difficile à réaliser en nostub.

XDanger
a écrit : Le mode kernel a des trucs que le mode _nostub n'a pas, parce que leur utilité est discutable (les BSS par exemple: les fonctions d'allocation dynamique système suffisent dans tous les cas, mais les utiliser est plus contraignant, c'est sûr.

Mais les routines d'allocation sont toutes centralisées dans le kernel, et tout le boulot et fait par le kernel. On économise du temps et de la mémoire

XDanger a écrit :
Et il y a des trucs parfaitement faisables en mode _nostub qui sont infaisables en mode kernel, à cause de la suppression automatique des handles... Cette suppression automatique est désactivable, certes, mais ce n'est pas un comportement standard.

Un peu quand même, c'est un standard pour le mode kernel

ExtendeD
a écrit : Pour CF, PpHd semblait dire que ça aurait été très très difficile à réaliser en nostub.

"très difficile" != "impossible"
Et puis le point de vue de PpHd face au _nostub n'est pas très objectif.

Mais les routines d'allocation sont toutes centralisées dans le kernel, et tout le boulot et fait par le kernel. On économise du temps et de la mémoire

Désolé, mais c'est faux.
Les accès au BSS ne sont que là pour faciliter la paresse des programmeurs. On peut faire exactement la même chose en utilisant un seul bloc alloué avec HeapAllocPtr pour tout. (C'est d'ailleurs ce que fait le kernel en interne pour les BSS.) Le segment BSS n'économise strictement rien en temps. Et en ce qui concerne la mémoire:
* allouer et libérer un bloc de mémoire prend seulement une vingtaine d'octets de code - le header et le stub du mode kernel consomment plus que ça!
* si on utilise un seul bloc alloué pour tout, on consomme exactement la même quantité de RAM qu'avec un BSS
* les BSS encouragent l'utilisation d'adresses automatiquement relogées plutôt que de l'adressage x(an) pour accéder aux variables allouées, ce qui est très inefficace à la fois en taille du code et en vitesse!

Un peu quand même, c'est un standard pour le mode kernel

Mais le standard sur TI-89/92+/V200 est ce que définit AMS. Tout le reste n'est pas un comportement standard. Si on suit ce que tu dis, n'importe qui peut définir son comportement "standard"!

Pascal : vas y, met y du kernel plein pot !!!!!!!! et je confirme que CF aurait été très difficile à faire en _nostub pour des raisons que je n'ai pas le temps de citer .

(ps : je ne connais pas ces raisons évidemment )

Kevin Kofler a écrit :
Mais le standard sur TI-89/92+/V200 est ce que définit AMS. Tout le reste n'est pas un comportement standard. Si on suit ce que tu dis, n'importe qui peut définir son comportement "standard"!

C'est pathetique
Un programme qui demande un kernel considere comme standard d'avoir un kernel (sinon, il n'y a pas de question a se poser, le programme ne se lance pas ...)

Je comprend que tu defende le kernel, mais utilise au moins des arguments convainquants ...

Dark Angel
a écrit : Un programme qui demande un kernel considere comme standard d'avoir un kernel (sinon, il n'y a pas de question a se poser, le programme ne se lance pas ...)

Tout le problème est là...

Je comprend que tu defende le kernel, mais utilise au moins des arguments convainquants ...

Euh... je pense qu'il y a une erreur là, parce que je ne défends pas du tout le kernel.