Question existencielle sur la valeur du c sur notre ti... - Page 1

Bein voila... lorsque je compile un prog ecrit en C et que je regarde ce que cela donne en asm, j'ai de quoi prendre peur...
Alors, le c n'entrainerait il pas l'apparition de code degueulasse sur nos ti...

Domage que de plus en plus de personnes prog en C (

C'est clair. Le compilateur GCC génère un code mal optimisé et forcément énorme. L'occupation mémoire doit augmenter d'au moins 40 % lorsque le code est écrit en C. Sans compter qu'un langage comme le C favorise le copier/coller abusif, l'écriture en un clin d'oeil de fonctions énormes, et surtout la non-maîtrise de ce que le programme fait réellement, bloquant dès lors la progression des non spécialistes.
De très mauvaises habitudes liées au C peuvent également pousser les gens ç utiliser des fonctions de la stdlib, or celles ci sont totalement inadaptées à la TI. Utiliser des fonctions tel fopen, printf, et compagnie, n'aura que pour effet l'augmentation de la taille d el'exécutable. Alors que des fonctions bien plus appropriées telles findsym ou drawstr permettent de limiter ces pertes, et s'avèrent indispensables en asm : avantage certain pour lui ! L'avènement du langage C sur TI n'a pour autre but que de copier les plates formes micro, ce qui constitue un but totalement ridicule puisqu'une TI se rapproche bien davantage d'un PDA, et se prête dès lors très mal au code énorme, "overbloated", et non optimisé.
Hélas, les innovations fonctionnent toujours comme ça. Rendre une chose accessible au plus grand nombre passe obligatoirement par des consessions. Ce qui est moins normal en revanche, c'est de voir que de nombreux ex-programmeurs asm se mettent désormais au C. Peut-on y voir une forme de paresse ? Ou tout simplement le fait que ces gens là, ayant déjà tout prouvé, ne jugent plus nécessaire de se prendre la tête ? Quoiqu'il en soit, le C sur TI annonce bien la fin d'une ère. Et si de gros sites comme ticalc.org ferment juste à ce moment là, ce n'est certainement pas pour rien. Faut-il y voir un signe ?

Mal optimisé, mais très optimisé quand même !
Tu connais un compilo qui fait mieux ?


Quand à savoir pourquoi beaucoup se mettent au C, ben c'est parceque on se prend moins la tête en C. Pollux n'aurait jamais codé GTC en ASM, moi non plus pour l'Azur.

Au fait Bz, ton projet du forum des pieux.. c'est pas en C?

c kler que depuis la sortie du C sur ti , y'aura jamais plus de "grand" jeu qui ont fait autrefois honneur a la ti ...(a part CF )
Le gros probleme pour l'ASM c que c bcp plus difficile de connaitre le minimum pour pouvoir commencer a sortir qq chose de la TI!
De plus faire des routines graphiques ne sont pas des choses simple et ce n'est pas donné a tout le monde de savoir en faire des rapides.
Les mnémoniques et la syntax de l'asm est complexe et pas évident ...c'est pas un language de haut nivo, il est donc difficilement accessible au debutant en programmation.(en effet la plupart des programmeur sur ti commence la programmation sur leur TI donc par le basic , puis apres ils veulent passer a la vitesse superieur , et donc s'oriente vers le C qui est plus proche du basic que l'asm).

"c'est de voir que de nombreux ex-programmeurs asm se mettent désormais au C." , fo les comprendre , le C qd on connais l'asm ca peut etre tres optimiser et moins cass kouille ...
Moi je crois surtout que l'avenir de la programmation sur TI , c'est le C + GenLib ...en tout cas c kler que l'asm est mort!

Je ne suis pas d'accord, il ne faut pas taper sur le C comme ca. Il y a de tres bonnes choses qui n'aurait peut-etre (surement ?) pas étés faites sans C sur TI:
- Mr Nutz
- ...

Bon c'est vrai, ca fait pas des masses, mais enfin ...

Par contre, c'est vrai que les newbies (qui a dit LamerZ) qui font du C font souvent de la merde, et que les C les y incite peut-etre, mais le C bien fait peut ne pas etre beaucoup plus gros, ni plus lent, et ca m'aurait grave fait chier de faire Total en Asm ...

De plus, pour mon cas particulier, le C m'a permis d'entrer dans la programmation 68k (car je connaissait deja le C), et je fait mintenant aussi un peu d'asm ...

En fait, il y a deux facon de penser le C:
- comme un language de haut niveau: ce qu'il faut eviter sur 68k (c'est dans cette voie la que va le C++)
- comme un languaga de bas niveau, en pensant a ce que ca deviens une fois compilé, et en aller voir le code compilé de temps en temps ...

NON les bons progs seront reconnaissables à l'efficacité des routines critiques codées en ASM, donc par les bons programmeurs

MrNuz fait 55ko tu trouve pas ca un peu bcp ?

C vrai que c'est un pêu gros (Total aussi est enorme), mais je trouve pas ca tellement genant.

Et Sonic, il est pas un peu gros aussi

oui mais ds Mr nutz y'a qu'un seul scrolling lol

>Blue_Z:
>De très mauvaises habitudes liées au C peuvent également pousser les gens ç utiliser des fonctions de la stdlib, or celles ci sont totalement inadaptées à la TI. Utiliser des fonctions tel fopen, printf, et compagnie, n'aura que pour effet l'augmentation de la taille d el'exécutable. Alors que des fonctions bien plus appropriées telles findsym ou drawstr permettent de limiter ces pertes, et s'avèrent indispensables en asm : avantage certain pour lui !

Faux. Avec TIGCC 0.92, tu peux t'en sortir sans problèmes avec (par exemple):

  pea.l 1234
 pea.l format(PC)
 jsr printf
 addq.l #8,a7
 rts
format: dc.b '%lu',0

>pya:
>c kler que depuis la sortie du C sur ti , y'aura jamais plus de "grand" jeu qui ont fait autrefois honneur a la ti ...(a part CF )

Les jeux de la TICT sont tous de grands jeux (au sens de grande qualité, pas grande taille), et ils sont tous écrits en C.

>De plus faire des routines graphiques ne sont pas des choses simple et ce n'est pas donné a tout le monde de savoir en faire des rapides.

Project / Add Files... / extgraph.a / OK
jsr Sprite8_XOR

>Moi je crois surtout que l'avenir de la programmation sur TI , c'est le C + GenLib ...en tout cas c kler que l'asm est mort!

Moi, je crois que l'avenir est le C _nostub. Mais il restera de la place pour l'assembleur _nostub (même si les programmeurs en assembleur sont de plus en plus une minorité). Je ne vois pas de futur pour les kernels.

>Dark Angel:
>Je ne suis pas d'accord, il ne faut pas taper sur le C comme ca. Il y a de tres bonnes choses qui n'aurait peut-etre (surement ?) pas étés faites sans C sur TI:
>- Mr Nutz
>- ...

- TI-Chess
...
Essayez d'écrire un jeu d'échecs en assembleur. (Et non, gcc -S tichess.c ne vaut pas!)

Moi, je n'aime pas vraiment le C parce qu'il n'est pas très efficace comme optimisation, mais je n'ai rien contre les programmes ou jeux programmés en C, tant qu'ils fonctionnent bien. Et en tout cas, je préfère un programme en C qui fonctionne à un programme en assembleur qui plante toutes les 2 minutes. Et je n'aime pas les programmes pour kernel quel que soit le langage dans lequel ils ont été programmés.
[edit]Edité par Kevin Kofler le 30-10-2001 à 22:26:11[/edit]

cela me rapelle mon cours d'info il y a d'ici peu 2 semaines...
j'ai sortit un code du genre:
if (x&1) x<<=2

mon prof d'info m'a sortit:
Un ingenieur informatitien a environ 1 moins pour devellope un soft, en programmant sont but est de faire le code le plus lisible possible afin de ne pas perdre de temps...
il a ajouter... on ne perd pas de temps a optimiser en taille et en vitesse, car on sait que dans 6 moins un pc 2 fois plus puissant va sortir... ce que l'on nous demande c'est d'etre productif...

En bref j'aime pas trop sa phrase, mais neanmoins, ce n'est que la triste verite de la vie... (et la rom ti est la pour en temoigner...)
Mais si l'on reviens sur ti.. le hardware ne bouge pas, et ce n'est pas une plate forme ou l'on peut devellope des soft en C... si certains trouve cela plus pratik ok, mais tout prog en C peu tenire 25% de moins en taille minimum en asm sur ti... donc forcement ca peut faire peur...

bien que je n'ai jamais fait qqchose d'extraordinaire sur 68k;mais je suis tout a fait d'accord avec toi Kevin K.

Timad> Oui mon projet sur el forum de mes deux c'est bien du C... c'est sans doute pour ça qu'il est si énorme et qu'il bugge autant.

moi j'y crois pas du tout que ça prend plus de place en C, il fo juste trouver le bon compromis vitesse/taille et c bon, y a de nopbreux jeux ASM si je voulais les refaire en C je suis sur qu'ils prendraient bien moins de place

et pis rien n'empeche d'inclure de l'ASM ds du C
et c bien moins buggé le C que l'asm

ceci dit sans C j'aurais jamais fait de menu ou de sauvegarde des highscores dans un fichier pour Dash... et malgré le fait que GTC optimise très mal, Dash prend seulement 3 ko

on peut le dnlder ou GTC ???

Nulle part, c'est lui qui choisit les bêta-testeurs.

>Kevin:
>Moi, je n'aime pas vraiment le C parce qu'il n'est pas très efficace comme optimisation, mais je n'ai rien contre les programmes ou jeux programmés en C, tant qu'ils fonctionnent bien. Et en tout cas, je préfère un programme en C qui fonctionne à un programme en assembleur qui plante toutes les 2 minutes. Et je n'aime pas les programmes pour kernel quel que soit le langage dans lequel ils ont été programmés.

Justement, le kernel inclut une protection anti-cash ...
Tu va me dire qu'on peut en inclure une en _nostub, mais c'est completement debile de rajouter la meme chose dans chaque prog ...

D'abord, non merci, je n'ai pas besoin d'une protection anti-cash. L'argent n'est pas aussi dangereux que ça.

Mais sérieusement:
1. Les protections anti-crash sont plutôt une partie du problème qu'une solution:
- Ça pousse les programmeurs à ne pas programmer proprement ("de toute façon, il y a l'anticrash").
- Ça ne marche pas à 100%, mais seulement à 50% environ (je parle bien pour les programmes pour kernel, puisque les kernels ne sont pas suffisamment intelligents pour installer un anticrash pour les programmes en _nostub. alors que c'est possible - cf. KerNO de Greg Dietsche (http://www.geocities.com/gdietsche) qui est déjà prêt et utilisable - mais encore en développement - et cf. le projet TI-Guard de Godzil, dont des bêtas sont déjà sorties).
- Quand ça marche, il y a de grandes chances qu'il y aura un plantage irrécupérable (sauf par un reset) dans AMS par la suite parce que la mémoire système est souvent corrompue. On peut aussi avoir des bogus plus subtils dans AMS - il y a des cas connus où de la mémoire corrompue a fait échouer solve avec "Argument must be a boolean expression or integer" - un message non-sens.
Je préfère donc ne pas avoir d'anticrash et utiliser le bon vieux reset - de toute façon, AMS 2.05 me récupèrera l'archive entière dans au moins 99% des cas. Peut-être que je vais tout de même essayer KerNO à un moment.
2. Connais-tu TICT Explorer (anticrash à niveau explorateur) et KerNO (anticrash TSR à niveau système)? Les 2 fonctionnent avec les programmes en _nostub. Et personne n'est forcé d'utiliser un anticrash (et de gaspiller plusieurs KO) s'il n'en a pas besoin.
[edit]Edité par Kevin Kofler le 31-10-2001 à 19:46:36[/edit]

je dois reconnaitre qu kevin n'a pas tord

moué ...

Kevin a rarement tord, sauf lorsqu'il parle des kernels.
[edit]Edité par Thibaut le 01-11-2001 à 14:47:39[/edit]

sblurb, c completement idiot ce qui est dit, le but c'est que le jeu marche comme le voudrait l'auteur!!! en C il est possible de faire les 3/4 des jeux, en restant a l'assembleur pur, comment voulez vous que nombre de gros jeux sortent???
c'est pas realiste.
Je préfère dire, qu'a chaque projet correspond une facon de programmer différente, la seule chose, c'est que c'est vrai la ti manque un peu de puissance et de place, mais qui dira que tichess est facil a faire en asm? ...

et puis mon pang preferé est celui d' aghnar en C nostub
et je suis convaincu kil fera un bon zelda

moi je suis pas pour l'anticrash, car de toutes façons quand mes programmes plantent, l'anticrash ne voit jamais rien, et c'est normal.
par contre, j'ai des jeux sur ma calc dont je tairais le nom qui plantent systématiquement et qui sont on va dire bien récupérés par l'anticrash, alors je sais pas vraiment si je dois être pour ou contre !
ce qui est sur, c'est que je me dit jamais "l'anticrash est la pour ça au cas ou"

sinon, je suis d'accord avec toi kevin, même si tu es du clan nostub

Haaaa il ne faut pas lui dire ça !!!! Prépare toi à subire une éloge très objective du _nostub

Une victoire de plus, Kevin ...

Vive le C, mais avec de l'ASM.
J'ai commencé il y a 4 ans l'assembleur pour 68HC11, puis 68000, PIC, ATMEL et pour finir bientôt DSP. Il y a tellement de chose que l'on peut faire en ASM que ça en est délirant ! la seule chose très lourde est l'allocation dynamique, mais on peut faire un CHESS sans problème en ASM, puisque l'algo de décision n'est rien d'autre qu'un système d'arbre qui est relativement facile à réécrire - seulement ça prend du temps, plus qu'en C -. J'ai fait un algo pour une bataille navale - seule chose, c'est qu'il y avait des sauts pas normaux qui s'effectuaient, mais je ne suis pas un pro de la prog ASM -.

Il est vrai que l'ASM conduit à plus d'erreurs et c'est normal, puisqu'en C, le compilateur vérifie le code, ce qui n'est pas le cas en ASM, mais il est possible de faire un excellent code en ASM.

"Encore une victoire de canard"