AS, il en est où ? - Page 7

Aucun des trois n'est sorti officiellement, mais la concurrence est déjà acharnée

Je peux rentrer dans la danse ?

wi wi ntre dans la danse

[I]"Bon, j'arrive à assembler avec AS les sources produites par CC, le tout on-calc et ça a l'air de marcher... mais malheureusement, je me suis aperçu que ce n'est meme pas un compilateur ANSI, c'est tout juste du K&R"[/i]

C'est quoi K&R?

C'est un truc avant qu'ANSI ne debarque avec ses normes. C'est un autre sandard C quoi.

Le premier standard du C - logique, c'est les inventeurs -

Le C K&R, ça se reconnaît surtout aux déclarations de fonction:
int main (argc,argv) int argc; char *argv[];
{
(on trouve ce genre de déclarations dans A68k)
En C ANSI, ça serait:
int main (int argc,char *argv[]){
Mais la plupart des compilateurs ANSI comprend sans problèmes les déclarations K&R. (GCC les avale sans se plaindre.)
Mais il y a d'autre différences, par exemple quelques fonctionnalités en moins, et que le C K&R permet plus de liberté d'interprétation au compilateur et est donc moins fiable pour certaines choses.

Nitro :

1* Azur est plus rapide que GTC et CC : Pollux qui a bossé plus que toi sur son compilo donc j'imagine mal que CC soit plus rapide que GTC lui même plus lent qu'Azur.

2* /* Azur est plus proche du C ANSI que CC et GTC ne le sont. */ (Argument supprimé )

3* Azur est un langage un peu plus clair que le C.

4* Azur n'impose aucune limite quant au nombre d'expressions dans les fonctions, alors que GTC et CC plantent sur les fonctions "trop" longues.

5a* Azur a un parser prévu pour l'optimisation : il ne me reste plus qu'à faire quelques ajouts dans l'analyse des blocs d'instructions pour qu'il optimise.

5b* Azur optimisera probablement mieux que GTC et CC : en effet au lieu d'adresser par registres les variables les plus utilisées dans la FONCTION comme le font GTC et CC (c'est l'explication du bug décrit au 4*), Azur s'adaptera dynamiquement au fur et à mesure de l'avancée dans le code => dans la plupart des cas l'optimisation sera plus pertinente.

Conclusion :

[edit]Edité par Thibaut le 24-01-2002 à 17:22:59[/edit]

>2* Azur est plus proche du C ANSI que CC et GTC ne le sont.

LOL, le C K&R est beaucoup plus proche du C ANSI que l'Azur, dans lequel tous les opérateurs sont différents.

>3* Azur est un langage un peu plus clair que le C.

Tu te contredis. De 2 choses l'une: soit il est proche du C ANSI (même plus que le C K&R comme tu prétends), soit c'est "un langage un peu plus clair que le C". D'après ce que je sais, c'est plutôt la 2ème solution.

>5b* Azur optimisera probablement mieux que GTC et CC : en effet au lieu d'adresser par registres les variables les plus utilisées dans la FONCTION comme le font GTC et CC (c'est l'explication du bug décrit au 4*), Azur s'auto-adaptera dynamiquement => dans la plupart des cas l'optimisation sera plus pertinente.

Tu peux préciser? Je n'ai pas tout à fait compris là. "Azur s'auto-adaptera dynamiquement"? Ça ressemble à "limited only by available memory".

Tu ne connais rien de l'Azur et pourtant tu te permet de répondre...

>> l'Azur, dans lequel tous les opérateurs sont différents.
faux, tu aurais mieux fait de te taire.

>> soit il est proche du C ANSI (même plus que le C K&R comme tu prétends), soit c'est "un langage un peu plus clair que le C".
Les différences sont minimes entre le C et l'Azur, et ces petites différences font la clarté de l'Azur. Proche ne veut pas dire identique => tu aurais mieux fait de te taire.

>> "Azur s'auto-adaptera dynamiquement" Ça ressemble à "limited only by available memory".
Nitro comprendra, mais toi tu ne dois pas connaître C68k, sinon tu comprendrais.

mais tu oublie une chose sur ton magnifique compilo Thibaut !!!

c'est que je n'ai pas envie de me brouter les couilles a apprendre un nouveaux language de prog, alors que le C est rependu et partous utilisé !!!

meme si ce language est censé etre "tres proche" du C, tant que ce n'est pas du C, sa me saoul !!
je ne pense pas etre le seul....
[edit]Edité par misato le 24-01-2002 à 16:52:19[/edit]

>Tu ne connais rien de l'Azur et pourtant tu te permet de répondre...

Ah, parce que toi, tu as essayé CC avant de faire des commentaires dessus...
Et moi, je n'ai peut-être pas essayé CC, GTC et/ou l'Azur, mais je connais le C K&R et j'ai lu ta description de l'Azur quand tu l'avais postée.

>>> l'Azur, dans lequel tous les opérateurs sont différents.
>faux, tu aurais mieux fait de te taire.

Soit tu as encore changé l'Azur depuis que tu as posté ta description, soit tu mens!
Le @ pour les pointeurs, c'est du C?
Le \ pour le modulo, c'est du C?
Etc...
Alors tais-toi.

>>> soit il est proche du C ANSI (même plus que le C K&R comme tu prétends), soit c'est "un langage un peu plus clair que le C".
>Les différences sont minimes entre le C et l'Azur, et ces petites différences font la clarté de l'Azur.

LOL, parce que c'est tellement plus clair de lire int+ plutôt que unsigned int...
Et parce que les opérateurs changés sont plus clairs? Pour moi, c'est seulement une source de confusion pour ceux qui connaissent le C, et ça n'apporte absolument rien. (Ne me dis pas que tu as dû changer l'opérateur modulo pour permettre les nombre binaires - TIGCC les permet aussi, avec le préfixe 0b, qui d'ailleurs serait beaucoup plus clair sur une TI-89/92+, vu qu'elles utilisent ce même préfixe.)

>Proche ne veut pas dire identique => tu aurais mieux fait de te taire.

Mais plus proche que le C K&R veut dire qu'il y a moins de différences entre Azur et C ANSI qu'entre C K&R et C ANSI. Et c'est un mensonge pur et net. Je te signale que le C K&R:
- utilise unsigned pour désigner un entier comme non signé
- utilise & et * pour les pointeurs
- utilise % pour les modulos
...
comme le C ANSI.

>> Ah, parce que toi, tu as essayé CC avant de faire des commentaires dessus...
J'ai essayé GTC qui est identique à CC sur les grandes lignes que je compare avec l'Azur.

>> Le @ pour les pointeurs, c'est du C? Le pour le modulo, c'est du C?
Non, c'est de l'Azur. Mais ça s'utilise comme en C. Et l'habitude d'utiliser ces opérateurs vient très facilement. Ces quelques opérateurs ne sont pas TOUS les opérateurs, c'est surtout ça qui était faux dans ta première affirmation.

>> Pour moi, c'est seulement une source de confusion pour ceux qui connaissent le C, et ça n'apporte absolument rien.
Ca apporte une meilleure vitesse d'interprétation, une meilleure lisibilité (on n'a pas besoin de se demander si * va faire une multiplication ou déréférencer un pointeur, par exemple)
C'est effectivement une source de confusion au début, mais ne parle pas sans avoir essayé.

Comme dit plus haut, je m'y suis habitué très facilement et squale92 qui rédige la documentation de la bibliothèque n'a pas eu besoin d'explication mais juste d'un exemple pour comprendre la syntaxe Azur. Pourquoi ? Parceque ça s'utilise comme en C. La différence entre la syntaxe Azur et la syntaxe C est très largement inférieure à celle entre le Pascal et le C.

>> Mais plus proche que le C K&R veut dire qu'il y a moins de différences entre Azur et C ANSI qu'entre C K&R et C ANSI
Là ok, mon point de vue a peut-être été trop optimiste. Je retire l'argument.

[edit]Edité par Thibaut le 24-01-2002 à 17:26:00[/edit]

Heu azur ca se programme comme du delphi?

procedure ...

Non, comme du C !
Mais je vois pas trop l'interet de creer un autre language.
Deja que le C et le pascal, c'est kifkif la meme chose a mes yeux

ah ? J'ai tenté le delphi, et j'ai rien compris!! Pourtant, le C, je comprend

Bein le delphi, c'est vraime,nt simple, c'est comme tu c avec des if then else...
Enfin bon c'est un language plutot symat, qui permet de ffaire ds truc rapidement sous windows...

L'Azur est très très différent du Pascal. A part les structures qui s'écrivent comme des "phrases" (donc un peu comme en Pascal), y'a pas de ressemblance.

PpHd : l'intérêt c'est que ça apporte une meilleure vitesse d'interprétation, une meilleure lisibilité, et puis un compilateur plus simple à programmer (c'est bien toi qui a dit que le propre de notre communauté c'est la fénéantise ? ).

Kevin tu vas être content

Comme je refais la gestion symboles / reconnaissance de mots clés en ce moment, j'ai par la même occasion changé les types... Désormais les types de l'Azur sont char short int long

>Désormais les types de l'Azur sont char short int long

Aller, encore un ptit effort et on pourra appeller ça du C

/me dit "powa"

mais merde, il va falloir que je change les types dans la doc

Tu n'as qu'a aussi supporte les unsigned, et c'est bon

oué, c clair !

N'empeche que ca aurait ete cool un beau language oriente objet avec des asserts, de l'allocation de memoire trnasparente, etc, etc.

arf...
su TI ?
rêve toujours

Bah je vais m'y mettre.

à faire un compilateur C++ ?
On-TI, ou ON-PC ?
si tu le fais, je veux être bêt-testeur !!!

Clair que ce serait bien... j'ai d'ailleurs dit à Thibaut que c'est le seul truc qui rendrait l'Azur incontournable... enfin bon.

honnétement, ça doit être LA MORT à coder : déjà un compilateur ANSI-C, c'est grave dur !!!
(du moins, d'après els sources de compilo ON-PC que j'ai vu !)
mais alors... compilon C++... surtout avec les faibles ressources de la TI, c po gagné !