Débat langages de programmation & assembleur

[mdr1]

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.

Ok , j'admets que mon code n'est pas des plus optimisés, mais comme tu dis, si les gens n'optimisent pas en Axe, c'est que ça ne se voit pas que c'est horrible; Au contraire, en assembleur, on aura tendance à trop vouloir optimiser en n'utilisant que les registres, c'est ce qui m'arrive pour un projet que j'ai. Et quoi qu'il en soit, un code pas trop optimisé en assembleur (c'est à dire qu'on utilise pas à fond les registres) restera beaucoup plus optimisé que un programme très optimisé en Axe.

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.

Qu'entends-tu par "mieux" ? Si tu entends par là l'optimisation, je ne suis pas du tout d'accord. Pour preuve, le C est BEAUCOUP plus optimisé que l'Axe, et l'assembleur est pas mal plus optimisé que le C.

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

Pourrais-tu préciser tes dires ?

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 !

As-tu essayé de te mettre à l'assembleur ? Quand je dis s'y mettre, c'est pas lire superficiellement le tuto et s'arrêter à la moindre difficulté.

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

Excuse-nous si ça parait être une polémique, mais crois-nous que nous ne nous fâchons pas et restons amis, mais exprimons simplement nos pensées.

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.

Le problème, c'est que ceux qui ne sont pas d'accord n'ont pas vraiment essayé de faire d'assembleur.

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.
Mais je ne t'en veux pas de ne pas le savoir

Je ne t'en veux pas de sortir cette remarque (bien que je ne sache pas pourquoi tu dis ça), car cela illustre très bien mes dires en ce qui concerne le fait que l'asm est beaucoup plus optimisé.

[Lionel Debroux]

J'ai édité mon post, mdr1, avant de voir le tien - et j'ai justement précisé pourquoi je mentionnais ça.

Le problème, c'est que ceux qui ne sont pas d'accord n'ont pas vraiment essayé de faire d'assembleur.

Parmi ceux-là, il y en a, clairement. Mais tu as écrit ton post sans nuances, ce qui pourrait faire croire - même si ça n'est peut-être / probablement pas ton intention - que tu généralises... et cette généralisation est abusive.
Je sais que tu es encore jeune, mais essaie d'utiliser un peu plus de nuances dans certains de tes propos - surtout à l'écrit, où il n'y a pas la communication non verbale pour limiter les risques de mauvaise compréhension par ceux qui te lisent. Ca ne peut que t'être bénéfique

Pour preuve, le C est BEAUCOUP plus optimisé que l'Axe,

Si tu parles d'Axe, c'est que tu parles toujours de programmation sur TI-Z80... mais le jeu d'instructions Z80 n'est pas du tout fait pour la programmation en C, et les compilos C pour Z80 donnent souvent du code qui fait vomir les programmeurs ASM Z80.
En revanche, sur d'autres ISAs, la différence entre le C compilé, et un code généré par un JIT ou AOT qui n'optimise pas beaucoup, peut être importante.

et l'assembleur est pas mal plus optimisé que le C.

Sur Z80, forcément, vu que les compilos C pondent souvent du code horrible, et qu'il n'y a pas vraiment moyen de faire mieux.
Sur 68k, x86 et ARM, c'est beaucoup moins net.

car cela illustre très bien mes dires en ce qui concerne le fait que l'asm est beaucoup plus optimisé.

Hmm, est-ce que tu penses, d'après ce que j'ai écrit, que c'est en passant beaucoup de morceaux en ASM que j'ai optimisé les programmes TI-68k ? Si oui, tu te trompes lourdement
Sur TI-68k, la très grande majorité des changements était sur le code C et les options de compilation. Il y a déjà beaucoup de choses à faire avant d'introduire de l'ASM pour optimiser encore un poil plus (au prix d'une augmentation du temps de développement et debug, j'insiste). L'optimisation ASM ne vaut vraiment le coup (et le coût) pour les morceaux critiques.
J'ai fait un programme où j'ai remplacé par de l'ASM plus de C que raisonnable. Ca a évidemment donné un machin plus optimisé... mais nettement plus difficile à maintenir et faire évoluer. D'ailleurs, je l'ai abandonné avant d'avoir fini une des évolutions, car ça prenait trop de temps...

Dans les cours de génie logiciel, on apprend que l'optimisation entre en collision avec un nombre important d'autres axes, en particulier des propriétés qualifiées de "non fonctionnelles", telles que la maintenabilité, la portabilité, la sécurité, et j'en passe.
Un peu d'optimisation, c'est bien, mais point trop n'en faut.
On en revient à la notion de compromis entre des extrême: essayer d'aller loin dans un extrême a un impact très négatif sur la caractéristique opposée. Ca aussi, j'ai essayé, avec les boucles de clearscreen - faire une boucle étroite qui ne contient qu'une instruction de transfert inflige une pénalité importante en performance sur le 68000 (car il n'a pas de BPU), et dérouler complètement la boucle, pour transférer 3840 octets par paquets de 56 ou 60 octets (movem), coûte vraiment cher en taille - la vérité est entre les deux

[mdr1]

Si tu parles d'Axe, c'est que tu parles toujours de programmation sur TI-Z80... mais le jeu d'instructions Z80 n'est pas du tout fait pour la programmation en C, et les compilos C pour Z80 donnent souvent du code qui fait vomir les programmeurs ASM Z80.

À vrai dire, je n'ai jamais décompilé de C pour z80, mais je pense que le C est tout de même plus optimisé vu comment l'Axe n'est pas optimisé : pas de déclaration, pas de types, pas d'optimisation interinstructionnelle etc.

Sur Z80, forcément, vu que les compilos C pondent souvent du code horrible.
Sur 68k ou x86, c'est beaucoup moins net.

Bon, ok, on retombe sur le même problème car on a pas vraiment regardé si le C est plus optimisé ou pas que l'Axe, mais en tout cas, l'assembleur est nettement plus optimisé que l'Axe.

Hmm, est-ce que tu penses, d'après ce que j'ai écrit, que c'est en passant beaucoup de morceaux en ASM que j'ai optimisé les programmes TI-68k ? Si oui, tu te trompes lourdement
Sur TI-68k, la très grande majorité des changements était sur le code C et les options de compilation. Il y a déjà beaucoup de choses à faire avant d'introduire de l'ASM pour optimiser encore un poil plus (au prix d'une augmentation du temps de développement et debug). L'optimisation ASM, ça ne vaut vraiment le coup (et le coût) pour les morceaux critiques.

J'ai mal compris ce que tu voulais dire (zut pas de chance), mais je proteste si tu dis que l'asm optimise "un poil plus". Et ça optimise encore plus l'Axe sur z80 que le C sur 68k, car je rappelle que notre discussion se porte sur les z80.

Pas question de ne pas avoir le dernier mot, na !

[Levak]

Je pense que tout le monde est d'accord sur un point : coder en binaire est la forme la plus optimisée.

[Lionel Debroux]

mais je proteste si tu dis que l'asm optimise "un poil plus"

Sur la plupart des ISAs (l'ISA à propos de laquelle la discussion a commencé n'est pas représentative - c'est un vilain design des 70s, pré-C), c'est pourtant vrai
Et sur les x86(_64) modernes, c'est tellement difficile, pour la grande majorité des humains, d'optimiser vraiment le code pour chaque micro-architecture (et il y en a beaucoup ^^), que les bons compilos peuvent compiler le code généraliste en code natif qui s'exécute plus rapidement que ce que nombre d'humains peuvent produire en ASM, tout en y passant beaucoup moins de temps.
Pense que sur les x86 modernes (et certains ARM, à un degré bien moindre), il faut tenir compte de l'exécution superscalaire out of order engendrant des fractions de cycle, de l'impact plus ou moins grand des dépendances de données, des latences d'accès L1/L2/L3/RAM différents selon les patterns de code, des conseils nontemporal, et j'en passe. Et bien sûr, comme je l'ai déjà mentionné, tout ça change à chaque micro-architecture. Rares sont les humains qui en sont capables.
Et par code "généraliste", je veux dire le code normal, qui a des tests et branchements partout, dans lequel le parallélisme niveau instruction n'est quasiment pas exploitable, et les ISAs VLIW donnent de mauvaises performances.

Pour certains algorithmes de calcul scientifique lourd qui prennent du temps, il peut être important de gagner quelques pourcents qui ne sont pas accessibles en C, et il peut alors être utile de passer des jours, voire des semaines, à écrire des coeurs de routines en ASM. Pour ne citer que les librairies et programmes de factorisation d'entiers, c'est ce qui est fait dans GMP et MPIR, yafu, msieve, Prime95 (gwnum) et d'autres.
Pour le code généraliste, qui représente 70-90% du programme et dans lequel on ne passe que 30-10% du temps ("règle des 80-20"), les compilos C récents sont good enough.

Pas question de ne pas avoir le dernier mot, na !

Tu sais pourtant bien que sur un forum, ce sont toujours les admins qui ont le dernier mot

[mdr1]

Tu as peut-être raison pour les x86 (et encore j'émets des doutes), mais ce n'est pas du tout le cas avec les z80.
Comme je disais, l'Axe n'optimise pas à partir d'une vue globale de l'algorithme, et ne va pas chercher à remplacer des variables temporairement par un registre (par exemple pour une petite boucle à quelques instructions).
Comme je disais, Axe ne gère pas les types, les déclarations etc. ce qui ne le permet pas de sérieuse optimisations et une approche de la taille des programmes assembleur. C'est son inconvénient, mais je suis d'accord pour dire qu'il est plus rapide de développer avec.

[sandro]

Je pense que tout le monde est d'accord sur un point : coder en binaire est la forme la plus optimisée.

Tu pourrais m'expliquer en quoi c'est plus optimiser que l'asm?
Car que ce soit l'asm ou le binaire (ou l'héxadécimal), dans les 3 cas, les instructions sont "les mêmes" et prennent le même poid.
Par example, sur TI83+, ld hl,$000E <=> 210E00h <=> 0010 0001 0000 1110 0000 0000b

Sandro

[mdr1]

Ouf, un autre programmeur assembleur me vient en aide, je commençais à désespérer à combattre seul.

[sandro]

Bon, je doit dire que je programme à peu près autant en axe qu'en ASM, c'est à dire franchement peu. Par contre je pense qu'au niveau des langages assemblés/compilés, on peut en tout cas en théorie toujours faire aussi bien voire mieux en assembleur (en tout cas en terme de vitesse d'execution, ainsi que pour la taille si on compte les routines qui ne sont pas compilées avec mais qui sont "stockées" dans le compilateur, comme faisant partie du poid total).
Après, c'est sur que quelcun qui méttrise très bien un langage compilé fera propablement mieux qu'un débutant en assembleur vu qu'il saurra optimiser mieu l'algorithme même.

Après pour le basic, peut-être que dans certains cas c'est plus optimiser en terme de taille (vu que ce n'est basé que sur des tokens et qu chaque fonction à proprement parler est déjà incluse dans l'OS), par contre en terrme de vitesse, c'est franchement pas génial.

Sandro

[Lionel Debroux]

Je pense que tout le monde est d'accord sur un point : coder en binaire est la forme la plus optimisée.

Tu pourrais m'expliquer en quoi c'est plus optimiser que l'asm?

Levak était clairement en train de blaguer

on peut en tout cas en théorie toujours faire aussi bien voire mieux en assembleur

Le "en théorie" est important. Et c'est au prix d'un temps de codage+debug beaucoup plus élevé, il faut donc que ça en vaille la peine - ce qui est clairement un cas d'usage très minoritaire dans le monde réel.

Je suis également programmeur en ASM
Mais il ne faut pas en abuser, car penser en langage machine (qui plus est sur votre ISA de prédilection à tous les deux, très différent des ISAs modernes) donne de mauvaises habitudes, si on veut devenir professionnel de l'informatique. Je suis passé par là, et pourtant, je faisais du C et de l'ASM 68000 16/32 bits avec pas mal de registres, pas de l'ASM Z80 8/16 bits avec très peu de registres...