programmation en C - Page 2

oui

Comment ça GTC complètement compatible avec TIGCC? Déjà:
- Produit-il aussi des exécutables _nostub? Ou seulement du kernel à 2 FF?
- Le jour où il compilera cela:
void _main(void) {
volatile unsigned long long x=({((void (*) (unsigned long long *))(unsigned short []){0x4e75})((unsigned long long []){12345678ull+98765432ull,98765432ull-12345678ull});-1234l;})+10ull;
}
qui est parfaitement accepté par TIGCC, on en reparlera. (Non franchement, il réagit comment devant ça?) Et encore j'étais gentil, j'aurais aussi pu rajouter des __complex__ ou d'autres extensions GNU bizarres (il suffit de regarder la liste).
[edit]Edité par Kevin Kofler le 13-12-2001 à 06:56:15[/edit]

Ouuf Liquid m'avais fait peur.

t'enflammes pas, kevin a raison

Je sais mais dans la pratique, je n'utiliserai jamais de code aussi barbares et j'en resterai au C ANSI

Kevin
- Les kernels valent 2 FF pour toi, ok ?? Ne vient pas encore déclencher un débat ici !
- Ce que j'explique pour l'Azur est parfaitement valable pour GTC : le mode dépend de la librarie et de l'assembleur. PAS DU COMPILO.
- Parceque tu en compiles souvent des choses come ça ???????

Kevin> si tu écrit souvent tu code comme ça, ben, félicitations...
En plus d'un an de programmation C, je n'ai JAMAIS eu à programmer quelque chose qui utilises ce type d'écritures...
Et j'espère que GTC sera à même de produire aussi bine du code nostub que du code Kernel.

Tu est aveugle squale92 ?
Lit le second point du trente-sixième post de ce topic.

arf...
un jsr doorsos::ngetchx
et in move.l $C8,a5
move.l ngetchx*4(a5),a0
jsr (a0)
ne sont pas pour moi la même chose !
Et je ne crois pas que ce soit l'assembleur qui doive faire la différence !

Sinon, je penses que c'est au copilo de dire si on a ou non le droit d'utiliser des libs, par ex...

cela dit, je reconnais que si l'assembleur ne fait pas le mode Kernel, ou si les libs ne sont pas là, on ira pas loin

C'est bien ça, tu as quelques problèmes de vue. Je réécris peut-être verras-tu mieux : le mode dépend de la librairie et de l'assembleur

Ce qui génère jsr doorsos::ngetchx ou move.l ngetchx*4(a5),a0 / jsr (a0) c'est la librairie (y'a librairie et librairie, tu sembles ne pas faire la différence), pas le compilo.

arf
dsl...

je m'y connais po trop en compilation, je le reconnais

Bien. Voici les deux définitions de "librairie" (dont la vraie traduction est "bibliothèque") :
1) binaire externe contenant des fonctions appelées par les exécutables, à l'exécution : sens employé pour les kernels
2) ensemble de fichiers, déclarant et parfois (cas de la lib Azur) contenant le code de fonctions qui seront incluses dans l'exécutable : c'est ce qui est employé à la compilation.

moué
j'avais pensé qu'à un seul des sens que tu donne.
dsl

Déjà, 2FF, c'est une manière de dire. Je ne payerais même pas 1 centime pour un kernel sur TI-89/92+.

Et puis, ceux qui testent GTC, vous avez essayé mes 3 lignes pour voir le nombre d'erreurs que ça donne?
Et je pense que comme ça au moins, vous arrêterez de prétendre que GTC est 100% compatible avec TIGCC.
D'ailleurs, j'aurais aussi dû rajouter des 0b10010101000100101010111010110000100101000ull.

arf...
Dans ce cas, il doit être possible de dire qu'il est à 100% compatible avec une utilisation "standard" de TIGCC...

Je pense que le seul truc qui devrait poser problème c'est long long.
Je vais tester.

on attend le verdict...
s'il arrive à comprendre ça, c qu'il est vraiment pas mauvais...
Même moi, qui suis normalement pas programmé => qui suis CENSE pouvoir m'adapter, j'ai du mal
(ironie)

Si tu vires ces long long qui ne servent à mon avis à rien (ou alors trouve moi un seul programme qui utilise cette extension ), ton exemple compile parfaitement.

Et GTC est compatible 95% avec TI-GCC, mais pas tout à fait 100% effectivement (pas besoin de rajouter des trucs qu'aucun prog n'utilisera jamais et qui rajoutera 10 ko au prog)

Il y en aura plus qu'avant depuis qu'il y a ma routine de multiplication des long longs dans TIGCCLIB. Et on avait aussi trouvé des routines de division et de modulo, mais elles sont en LGPL, ce qui n'est pas pratique du tout pour une librairie sur calculatrice (il faut distribuer les fichiers objet de son programme et les sources des routines avec tout programme qui utilise les routines), et l'auteur des routines a apparemment disparu, donc on n'a pas pu lui demander de changer la license. Je pense que je vais finir par écrire moi-même les routines de division et de modulo.

Et puis, GTC compile-t-il cela?
__complex__ int var=0b1000+0b1010i;
Ce n'est pas long comme ligne, ça...
[edit]Edité par Kevin Kofler le 04-01-2002 à 23:38:59[/edit]

Azur le compile

non je déconne.

Et puis Kevin, franchement, qui se sert des nombres complexes avec TIGCC... personne ! sauf vous, les bêta-testeurs...

Et les nombres binaires? Il y en a beaucoup qui s'en servent.

Ha ça, Azur les reconnais
Comme en ASM, on précède d'un pourcent les nombres binaires, et d'un dollar les nombres hexadécimaux => l'opérateur de modulo est du coup l'antislash.

eh les gars,eo est dans la partie basic ici,imaginez si un pauvre newbie qui se paume ici,il repart cash,dégouté à vie de la programmation.

Ça m'énerve cette manie de faire remonter des épaves !!!!!

erf.......

meuh non, c tranquille l'AZUR.
(et le C aussi !!!)

erf, je me suis remis au C moi (j'étais qu'un nioubi avant d'arrêter ...).

merci encore pour ton tuto squale92 !

de rien.

bon je demande ca mais je pense que la reponse est non
est-il possible de transformer un prog fait en java2 pour un compatible TI ou de programmer on-calc java2 ??

merci