Forum TI-Planet.org

kindermoumoute wrote:

• Le grammer est un langage interprété très récent qui promet d'évoluer considérablement par la suite, mais pour l'instant les possibilités ne permettent pas de tout faire. Il existe un début de tutoriel ici.
• L'Axe est un langage compilé qui existe depuis 2 ans maintenant, très complet et beaucoup plus simple que l'asm z80, il y a un tutoriel ici (la troisième partie arrive prochainement).
• L'asm z80 est un langage difficile à apprendre mais il existe un tuto ici (nécessite d'avoir un compte sur le site du zéro car le tuto n'est pas encore en ligne entièrement).

Je proteste, contrairement aux préjugés, l'assembleur n'est pas compliqué et TOUT LE MONDE y compris ceux qui n'ont jamais programmé y arrive facilement avec un bon tutoriel (lien que t'as donné).

Ensuite, tu as oublié de préciser les avantages de l'assembleur par rapport à l'Axe : possibilités beaucoup plus étendues, programmes plus rapides et plus légers (sachant que la mémoire manque sur les z80), et en plus, ce qui est le top, c'est qu'on comprend vraiment comment marche la machine, on gère tout et on peut tout faire, c'est super agréable. Et une fois que l'on commence à s'y habituer, on peut se lancer dans des projets plus ambitieux, comme la création d'un environnement de développement (Grammer), la création d'un nouveau langage (Axe), et même la création d'OS (mais ça je sais pas faire... faut demander à Benjamin Moody).

Pour le tutoriel, il existe également une version en ligne (moins complète) accessible aux non inscrits : ici. Enjoy !

Pour l'algorithmique comme celle des problèmes du projet Euler, l'ASM pur est un assez mauvais choix. Si on ne connaît pas encore l'ASM sur une plate-forme, la mise de fonds initiale est trop importante, et on passe trop de temps à se préoccuper de détails d'implémentation (surtout sur un Z80 limité à peu de registres, et des registres 8/16 bits de surcroît...)

mdr1 wrote:Je proteste, contrairement aux préjugés, l'assembleur n'est pas compliqué et TOUT LE MONDE y compris ceux qui n'ont jamais programmé y arrive facilement avec un bon tutoriel (lien que t'as donné).

Ensuite, tu as oublié de préciser les avantages de l'assembleur par rapport à l'Axe : possibilités beaucoup plus étendues, programmes plus rapides et plus légers (sachant que la mémoire manque sur les z80), et en plus, ce qui est le top, c'est qu'on comprend vraiment comment marche la machine, on gère tout et on peut tout faire, c'est super agréable. Et une fois que l'on commence à s'y habituer, on peut se lancer dans des projets plus ambitieux, comme la création d'un environnement de développement (Grammer), la création d'un nouveau langage (Axe), et même la création d'OS (mais ça je sais pas faire... faut demander à Benjamin Moody).

Pour le tutoriel, il existe également une version en ligne (moins complète) accessible aux non inscrits : ici. Enjoy !

C'est pas vraiment un préjugé. J'ai essayé l'assembleur avec 3 ou 4 tutos et il m'a fallu 2 semaines pour faire une TileMap qui ne supportait que 2 types de tiles. Pourtant, j'avais deja programmé (en TI-Basic). En Axe, il ne m'a fallu qu'une demi journée pour faire une TileMap supportant une soixantaine de tiles, en utilisant un demi tuto (j'ai lu la moitié et j'ai commencé à coder: c'est en forgeant que vous connaissez la suite).
En plus, si tu sais vraiment programmer en Axe (comme Runer112), l'assembleur n'offre pas plus de possibilités, n'est pas plus rapide ni plus léger (par contre, faut être bon ).
Sinon, c'est vrai que l'assembleur permet de mieux comprendre la machine. De plus, ce n'est pas un language specifique a la calculette, donc il y a plus de "débouchés"

De plus, ce n'est pas un language specifique a la calculette, donc il y a plus de "débouchés"

L'assembleur n'est en effet pas spécifique à la calculatrice - mais aussi bien l'ASM Z80 (qui n'a jamais été bien adapté au C) que l'ASM 68k (qui est bon pour le C, depuis le début) sont rares, de nos jours
Les plate-formes ARM sont en revanche très répandues, mais rares sont ceux qui les programment en ASM.

Je pensais avoir été plutôt objectif sur la liste des langages existant, mais je suis content de te revoir reprotester ainsi mdr1.

Lionel Debroux wrote:Pour l'algorithmique comme celle des problèmes du projet Euler, l'ASM pur est un assez mauvais choix. Si on ne connaît pas encore l'ASM sur une plate-forme, la mise de fonds initiale est trop importante, et on passe trop de temps à se préoccuper de détails d'implémentation (surtout sur un Z80 limité à peu de registres, et des registres 8/16 bits de surcroît...)

Avec un peu d'habitude, l'organisation se fait très rapidement et l'architecture se trouve en un instant. Les registres 8/16 bits sont très suffisants (pour preuve ce que vous faites en axe qui est compilé en langage machine).

Hayleia wrote:C'est pas vraiment un préjugé. J'ai essayé l'assembleur avec 3 ou 4 tutos et il m'a fallu 2 semaines pour faire une TileMap qui ne supportait que 2 types de tiles. Pourtant, j'avais deja programmé (en TI-Basic). En Axe, il ne m'a fallu qu'une demi journée pour faire une TileMap supportant une soixantaine de tiles, en utilisant un demi tuto (j'ai lu la moitié et j'ai commencé à coder: c'est en forgeant que vous connaissez la suite).
En plus, si tu sais vraiment programmer en Axe (comme Runer112), l'assembleur n'offre pas plus de possibilités, n'est pas plus rapide ni plus léger (par contre, faut être bon ).
Sinon, c'est vrai que l'assembleur permet de mieux comprendre la machine. De plus, ce n'est pas un language specifique a la calculette, donc il y a plus de "débouchés"

La programmation TI-Basic n'ayant rien à voir avec l'assembleur, cela ne te pouvait être d'aucun aide pour l'apprentissage de ce dernier, pas même pour l'algorithmique. De plus, il est largement compréhensible que tu aies eu du mal à apprendre l'assembleur z80, c'était pareil pour moi, étant donné les nullités de tutoriels sur internet. C'est quand j'ai découvert le tutoriel du site du zéro que j'ai facilement appris l'assembleur. Pour l'Axe, tu n'as pas appris avec des nullités.

Pour tes TileMap, c'est parce-que codant à travers un compilateur, tu ne te rends pas compte des trucs pas du tout optimisés que tu peux faire, alors que lorsque tu vas faire de l'asm, tu vas trop essayer d'optimiser et de n'utiliser que les registres, sans t'en rendre compte.

Si tu ne me crois pas pour l'optimisation, voici un code Axe :

Code: Select all

If getKey(1) and (B<56
   B+1→B
ElseIf getKey(4) and (B>0
   B-1→B
End


Et ce code compilé donne :

Code: Select all

variable = $86EE

org $9D93
.dw $6DBB

ld   hl,$FE01
call $9F65
push hl
ld   hl,(variable)
ld   de,56
xor a
sbc hl,de
ld    h,a
rla
ld    l,a
pop de
ld   a,l
and e
ld   l,a
ld   a,h
or   l
jp   z,ElseIf
ld   hl,(variable)
inc hl
ld   (variable),hl
jp  End

ElseIf:

ld   hl,$FE08
call $9F65
push hl
ld   hl,(variable) ;\
ld   de,0             ; > Aberrant
ex  de,hl            ;/
xor a
sbc hl,de
ld    h,a
rla
ld   l,a
pop de
ld   a,l
and e
ld   l,a
ld   a,h
or   l
jp  z,End
ld   hl,(variable)
dec hl
ld   (variable),hl

End:

ret


Ça fait pas beau à voir. Après on va me dire : avec la nouvelle version, il y a ++ et --. Ok, on gagne quoi ? 1 ou 2 octets *2. En attendant, il y a peut-être sans cesse des petites optimisations de routines à chaque nouvelle version, ou va gagner 1 octet pour tout le programme quand on l'utilise, alors qu'à côté, le compilateur utilise toujours des nombres 16 bits alourdissant le programme de centaines d'octets. Idem pour le fait que les types ne soient pas gérés (pas de déclaration de variable).
Donc je trouve franchement gonflé de dire que l'asm est pas plus optimisé, il est nettement plus optimisés (pas le même ordre de grandeur). L'Axe n'est pas du tout optimisé si c'est ce que les gens veulent savoir, il n'y a qu'à utiliser Calcsys pour décompiler ce que produit Axe.

Et il est objectif que l'assembleur offre plus de possibilités, on peut utiliser par nous-mêmes tous les trucs système, on peut faire des rom, des vrais interruptions, un compilateur Axe, un interpréteur Grammer (comme je l'ai dit plus haut, d'ailleurs).


Je ne dénigre pas du tout l'Axe, contrairement à ce que certains ici semble faire vis-à-vis de l'assembleur, mais je pense que ceux qui veulent rester sur l'axe et ne pas découvrir l'assembleur, ou essayer de mieux l'apprendre, rate beaucoup. Et je me lamente sur le désintérêt envers l'assembleur qui semble se montrer pour certains, alors que je rencontre des débutants qui y arrivent très bien et font de super programmes. Si tu regardesles projets du zcontest assembleur 2011, tu vas légèrement changer tes préjugés.

Et c'est grâce à ceux qui font de l'assembleur que vous avez le compilateur Axe, le kernel Ndless etc.

Ne nous fâchons pas

Il est un fait que le code natif permet de faire des choses qu'Axe, Grammer, NewProg ne peuvent pas faire. Ces compilateurs / interpréteurs sont du reste écrits en code natif, comme tu l'indiques.
Mais il y a d'autres faits:
* nombreux sont les gens qui ne rentrent pas dans la complexité de la programmation en code natif, pour diverses raisons qui leur sont propres, et avec lesquelles tout un chacun peut ne pas être d'accord;
* la programmation en Basic, Axe, Grammer, NewProg, GFA Basic, BBC Basic, Lua, et j'en passe des centaines, peut être jugée "suffisante" pour certaines choses. "Good enough" est un compromis entre satisfaction de l'utilisateur (parce que le programme va "assez" vite / est "assez" petit / fait "assez" de choses) et temps passé à le développer (le programme pourrait aller plus vite, être plus petit et/ou faire plus de choses, mais il coûterait donc plus cher selon une certaine métrique, en général temps passé + argent).

En logiciel, comme dans la vie, nombreux sont les compromis, et on peut se déplacer presque continûment sur des échelles entre plusieurs critères
Par exemple, sur l'échelle optimisation / temps de développement:
* sur les processeurs pas trop complexes, l'assembleur (langage d'assemblage, en français) pur écrit à la main par une personne compétente est de bonne qualité - mais ça prend un temps variable à devenir compétent, pas mal de temps à se soucier des détails d'implémentation, et aussi du temps à debugger les bêtises (car on en fait toujours);
* le C reste bas niveau, et sur les architectures dont le processeur est fait pour le C, est un bon choix pour le code natif. A code équivalent, on met habituellement trois à cinq fois moins de temps à développer en C qu'en ASM. Typiquement, seuls les hobbyistes, ou dans l'industrie, ceux qui ont de très fortes contraintes de performance / accès très bas niveau sur des morceaux de code bien ciblés, s'amusent à écrire de l'ASM;
* Axe génère du code qui donne envie de vomir aux programmeurs en code natif - mais il est à sa place sur le compromis vitesse / facilité de développement: un langage plus rapide et de plus bas niveau que le BASIC, mais qui abstrait déjà nombre de choses que le programmeur aurait à gérer lui-même en C ou pire, en ASM;
* le BASIC pur est de haut niveau et abstrait beaucoup de choses pour l'utilisateur (calculs sur des nombres longs, etc.), mais est (plus) "lent".

Tu vois ce que je veux dire ?

Lionel Debroux wrote:Il est un fait que le code natif permet de faire des choses qu'Axe, Grammer, NewProg ne peuvent pas faire. Ces compilateurs / interpréteurs sont du reste écrits en code natif, comme tu l'indiques.
Mais il y a d'autres faits:
* nombreux sont les gens qui ne rentrent pas dans la complexité de la programmation en code natif, pour diverses raisons qui leur sont propres, et avec lesquelles tout un chacun peut ne pas être d'accord;
* la programmation en Basic, Axe, Grammer, NewProg, GFA Basic, BBC Basic, Lua, et j'en passe des centaines, peut être jugée "suffisante" pour certaines choses. "Good enough" est un compromis entre satisfaction de l'utilisateur (parce que le programme va "assez" vite / est "assez" petit / fait "assez" de choses) et temps passé à le développer (le programme pourrait aller plus vite, être plus petit et/ou faire plus de choses, mais il coûterait donc plus cher selon une certaine métrique, en général temps passé + argent).

Bien sûr, mais j'insiste sur le fait que l'assembleur est BEAUCOUP plus léger comme je l'ai montré avec le code, et ce n'est pas négligeable sur des calculatrices avec si peu de mémoire.

Lionel Debroux wrote:En logiciel, comme dans la vie, nombreux sont les compromis, et on peut se déplacer presque continûment sur des échelles entre plusieurs critères
Par exemple, sur l'échelle optimisation / temps de développement:
* sur les processeurs pas trop complexes, l'assembleur (langage d'assemblage, en français) pur écrit à la main par une personne compétente est de bonne qualité - mais ça prend un temps variable à devenir compétent, pas mal de temps à se soucier des détails d'implémentation, et aussi du temps à debugger les bêtises (car on en fait toujours);

Le z80 est simples, et c'est plus optimisé que l'Axe même en tant que débutant.

Lionel Debroux wrote:* le C reste bas niveau, et sur les architectures dont le processeur est fait pour le C, est un bon choix pour le code natif. A code équivalent, on met habituellement trois à cinq fois moins de temps à développer en C qu'en ASM. Typiquement, seuls les hobbyistes, ou dans l'industrie, ceux qui ont de très fortes contraintes de performance / accès très bas niveau sur des morceaux de code bien ciblés, s'amusent à écrire de l'ASM;

Le C est beaucoup plus optimisé que l'Axe.

Lionel Debroux wrote:* Axe génère du code qui donne envie de vomir aux programmeurs en code natif - mais il est à sa place sur le compromis vitesse / facilité de développement: un langage plus rapide et de plus bas niveau que le BASIC, mais qui abstrait déjà nombre de choses que le programmeur aurait à gérer lui-même en C ou pire, en ASM;

Le C est plus haut niveau que l'Axe, il gère les types et déclarations, donne une véritable interface de pointeurs, fait de l'optimisation à la compilation, comporte le systèmes des structures (struct), a des variables locales etc.

Et attention, tu sembles placer le C et l'assembleur sur la même échelle de niveau, et c'est un erreur. L'assembleur est nettement plus bas niveau que le C car représente directement le code machine et n'est pas compilé, mais directement assemblé ; le C est compilé puis assemblé.

Lionel Debroux wrote:* le BASIC pur est de haut niveau et abstrait beaucoup de choses pour l'utilisateur (calculs sur des nombres longs, etc.), mais est (plus) "lent".

Là, je suis d'accord.

Lionel Debroux wrote:Tu vois ce que je veux dire ?

Bof. Mais sache que comme je l'ai dit, je ne dénigre pas l'Axe, pour preuve, il permet de faire rapidement de bons jeux. Mais je trouve regrettable que l'apparition de l'Axe entraine certains préjugés sur l'assembleur, car c'est toujours son extrême difficulté inexistante qui est mise en avant pour inciter à faire de l'Axe.

mdr1 wrote:Si tu ne me crois pas pour l'optimisation, voici un code Axe :

Code: Select all

If getKey(1) and (B<56
   B+1→B
ElseIf getKey(4) and (B>0
   B-1→B
End


Ce n'est pas du tout ce que voulais dire hayleia... bon, essaye ce code :

Code: Select all

If B<56
getKey(1)
Else
-getKey(4)
End
+B→B

Perso j'économise 22 octets...
En fait ton code en Axe est pour moi aussi moche que le code asm qui en résulte. L'Axe est optimisable au codage et ça beaucoup de gens ont tendance à l'oublier. Et même en asm il arrive très fréquemment de voir des routines non optimisées... du au codage encore une fois. C'est pour ça que ton code ne veut rien dire, car quelqu'un qui programme bien en Axe n'aura jamais des routines aussi moches à écrire.
Aujourd'hui l'Axe Parser a beaucoup changé, tellement qu'on ne peut plus se fier à la différence entre l'asm et l'Axe pour dire si un programme sera mieux qu'un autre... cela tient beaucoup plus du programmeur.





PS : j'en rajoute encore pour dire qu'avec l'option framework activé, les programmes en Axe deviennent largement plus léger...



EDIT : Mais pourquoi t'entête tu à dire que les langages de bas niveau sont aussi facile à apprendre ? Moi je trouve pas du tout que c'est un préjugé, le tutoriel joue une grande importance certes, mais au premier abords c'est juste illisible si tu n'as pas de connaissances !
Go chatbox ?

Plus haut, j'ai demandé gentiment de ne pas se fâcher, pour garder une bonne ambiance bien entendu. Je réitère la demande de manière un peu plus insistante
mdr1, nous admettons que tu puisses penser que "Le z80 est simple" - mais je voudrais être bien sûr que tu admettes que d'autres puissent ne pas être d'accord, et avoir des arguments valides pour le penser.

Pour info, mdr1, ça fait bientôt onze ans que je programme en C, et un peu moins en ASM, sur TI-68k - et mon métier, depuis plus de quatre ans, consiste à faire de la programmation, en C et en Java, et dernièrement en C++ également.
J'ai aussi optimisé des dizaines de programmes C et ASM pour TI-68k, réduisant parfois la taille de plus de 10 KB sur 60 KB, ou une vingtaine de KB sur 100 KB, et même fait un tutorial pour faire bénéficier la communauté de ce retour d'expérience. Je maintiens ExtGraph, qui comporte des centaines de fonctions écrites en ASM.
Je ne t'en veux pas de ne pas le savoir, mais je le mentionne pour t'expliquer que oui, j'ai une certaine idée de l'optimisation et de la programmation bas niveau, et que non, je ne peux pas penser que C et ASM sont au même niveau