Tuto - Page 2

Je pinaille pas. Connaître l'ASM ne fait pas connaître le CPU c'est tout. L'inverse est aussi vrai, mais l'un des deux permet d'en apprendre plus que l'autre.

attends, tu parles juste des registres, ou le coup des cycles/pipelines/etc?

je n'ai pas parlé des registres, mais des effets du cache, pipeline & aurte truc lié au hard et non directement au soft, enfin qui peuvent avoir une incidence sur le soft, mais que l'assembleur directement n'apprend pas

savoir programmer en ASM, c'est évidemment connaître le CPU, pas seulement la syntaxe ^^

ce qui n'es malheuresement pas vrai, il suffit de voir le contenu de certain cours sur l'assembleur ou l'on te dit que tu apprend l'asm et ou l'on ne te dit rien sur l'archi complete du CPU. Et tu peut tres bien faire un programme en ASM x86 sans savoir comment marche le cache des x86 (par exemple)

oui enfin là on parle pas de cours, l'auteur du topic veut apprendre à programmer sur TI...

ce que j'essaye de dire depuis toute c'est que c'est pas forcement l'ASM qui faut mieux connaitre pour d'autre chose que l'ASM, mais le CPU, tu es pas obligé de savoir programmer en ASM (donc les mnemoniques) pour faire un programme en C/C++ qui utilise bien le CPU

./33> dans ce cas OK avec toi.

Martial Demolins (./22) :
on a appris l'asm en s'émulant l'un l'autre, mais ça ne permet pas "d'enseigner", c'est la nuance. Intéresser oui, mais pas enseigner.

La raison d'être d'un article (pour ne pas utiliser le terme de "tutorial", qui te donnerait plus raison ^^ ) est-il nécessairement d'enseigner ?
(mauvaise foi ? boah, un peu, mais pas que mauvaise foi)

Martial Demolins (./22) :
Un code bien écrit, organisé

Over-engineered ?

Martial Demolins (./22) :
est clair sera déjà assez dur pour lui à ses débuts

Pas nécessairement : un code "mal écrit / mal organisé" peut être de prise en main plus simple, dans le cas d'un petit programme, typiquement, que si on était passé par un gros bousin framework + mvc + trois tonnes de blahblah ^^
(Typiquement, ça peut être une différence entre un "script" et une "application" ; que ce soit en terme de facilité de prise en main, de rapidité de compréhension... et d'évolutivité / maintenance de l'autre côté)

Martial Demolins (./22) :

Jyaif (./17) :
le C est très très utilisé. Si jamais tu cherche un stage/boulot en info, connaitre le C est souvent requis.

Ah ça, je suis d'accord que c'est un excellent argument, et pour moi le seul valable pour dire de faire du C avant l'asm (donc dans un but utilitaire).

moué... En même temps, quand je cherchais un boulot (enfin, un stage, à l'époque ^^ ), je parlais que j'avais fait du C et que j'avais eu l'occasion d'écrire quelques articles à destination de débutants... Par contre, j'ai jamais dit le moindre mot sur les notions d'ASM que j'avais ^^
(ok, ok, ça dépend du boulot - dans le cas d'un développeur web, l'asm, bah... )

Pollux (./23) :
- l'ASM c'est mieux pour quelqu'un qui cherche à comprendre comment ça marche, et ça donne toutes les bases pour après écrire du code C efficace

sur de l'embarqué, ok (et je vois que Lionel est du même avis au post juste suivant, ./24 )
Après, sur un PC moderne, ça coutera tellement plus cher de passer du temps à apprendre des notions d'asm que d'acheter un n-ième serveur (ou un n-ième cpu, ou un n-ième Go de RAM, ou quelques centaines de MHz de plus, ...)...

Après la clarification, +1 ./33 & ./37 .

l'ASM c'est mieux pour quelqu'un qui cherche à comprendre comment ça marche, et ça donne toutes les bases pour après écrire du code C efficace

sur de l'embarqué, okAprès, sur un PC moderne, ça coutera tellement plus cher de passer du temps à apprendre des notions d'asm que d'acheter un n-ième serveur (ou un n-ième cpu, ou un n-ième Go de RAM, ou quelques centaines de MHz de plus, ...)...

Plutôt d'accord.

J'ai pas eut le courage de lire tout ce que vous avez dit, mais je vait finalement me mettre au C vu que c'est ce qui ressort de ce que vous avez dit.
Mais j'ai deux trois petites questions sur le C, qui n'ont peut-être pas leur place dans la section Assembleur...
Peut-on en C comme en Basic programmer directement depuis sa calculette sans avoir à ecrire le programmme sur le PC?
Car la programmmation est un passe-temps au lycée et à l'internat ou je n'ai pas accés à un Pc.

Peut-on en C comme en Basic programmer directement depuis sa calculette sans avoir à ecrire le programmme sur le PC?

On peut... mais actuellement, l'outil le plus intéressant pour faire ça n'est pas accessible: voir topics/111515-gtc-derniere

Bon j'ai lu le post sur lequel tu as mis le lien, si quelqu'un veut bien me l'envoyer.
Même si celà embête un certain Kevin mais les "Kevins" en informatique ...

Kevin n'est pas vraiment un "kevin" de l'informatique tu sais ^^

Ouais, Kevin Kofler est loin d'être un "kevin"...

Enfin Kevin Kofler c'est un Kevin, un double K meme mais pas forcement un Kevin, d'ailleurs je dirais qu'il n'est pas un Kevin, juste qu'il est le Kevin...

Martial Demolins (./22) :
Un de ceux qui dominent l'asm ET le C (PpHd, Kevin, Lionel ou toi) pourrait-il présenter son point de vue argumenté svp ? Ne maitrisant que l'asm (et vraiment que ça, absolument pas l'info en général ou autre vu que je n'ai fait aucune étude dans ce domaine), je serais intéressé par l'avis d'une personne compétente (qui, vous l'aurez compris, m'intéresse autrement plus que l'avis de personne disant tâtonner dans le sujet dont elle parle ^^).

Le C permet d'écrire du code portable fonctionnant sur différentes architectures.
L'asm est limité à une génération d'un processeur.
Le C ne permet pas d'utiliser pleinement les capacités de ton CPU, mais entre 50-95% en général.
L'asm permet d'utiliser toute l'instruction set, et de pouvoir pipeliniser à mort les calculs SI on s'y connait, sinon on sera plus lent que le compilateur C...
Le C possède une librairie standard, pas l'asm.
Certaines choses sont impossibles à écrire en C, le contraire n'est pas vrai.
Il y a des assembleurs de merde, le C est (grosso modo) partout pareil.
L'asm est plus facile à comprendre pour les débutants, mais pas forcément à écrire.
En C et asm, on peut écrire de belles saloperies.

Pollux (./23) :
Pour résumer mon avis :
- le C c'est bien pour quelqu'un qui veut tout de suite un résultat potable, on peut ignorer pas mal de problèmes au moins au début - l'ASM c'est mieux pour quelqu'un qui cherche à comprendre comment ça marche, et ça donne toutes les bases pour après écrire du code C efficace

Pollux (./23) :
Bref, je vois le C comme un choix à plus court terme et l'ASM comme un choix à plus long terme.

Au niveau de la compréhension, oui. Au niveau pratique, par contre, avec l'ASM, tu te limites à une génération de CPU. Donc tu dois maintenir ton code à chaque nouvelle génération ce qui peut être lourd.
Mais parfois nécessaire pour certains calculs.

Lionel Debroux (./24) :
Je ne pense pas qu'il soit obligatoire de connaître l'ASM pour programmer en C. L'ASM varie évidemment beaucoup d'une architecture à l'autre (même s'il y a quelques points communs)

Franchement, l'architecture varie pas tant que çà.
Tu as toujours des registres / de la mémoire / des caches / des pipelines / des out of order / des latences / des read / des writes / des add,sub,and... / des mul, div / des shift.

Godzil (./25) :
C'est indipensable de comprendre comment marche le CPU plus que l'ASM

Oui
Mais sentir ce que le compile va générer lorsque tu écris ton code C, aide beaucoup.

squale92 (./39) :
Après, sur un PC moderne, ça coutera tellement plus cher de passer du temps à apprendre des notions d'asm que d'acheter un n-ième serveur (ou un n-ième cpu, ou un n-ième Go de RAM, ou quelques centaines de MHz de plus, ...)...

Pas forcément
Et tu n'as peut être plus de budget pour acheter un nouveau serveur, ou tu as déjà acheté le serveur le plus performant, ou le serveur plus performant est hors de ton budget
Ou tu n'as plus la place pour mettre un nouveau serveur

Martial Demolins (./12) :

squale92 (./11) :
d'un certain point de vue, qui est le mieux placé pour expliquer à un débutant de façon progressive, si ce n'est un presque-débutant lui-même en train de progresser ?

Je comprends bien ce que tu veux dire, mais si c'était le cas des profs, ça craindrait, donc je doute qu'un débutant sans vue d'ensemble fasse un tuto avec la hauteur de vue suffisante pour apprendre à d'autres débutants. C'est d'ailleurs ce que j'avais pas aimé dans ton tuto de C, c'était cette approche "bon pour faire des gris, vous faites comme ça". J'ai besoin qu'on m'explique le principe de fonctionnement d'une auto-int, de la table des vecteurs, du mode superviseur/utilisateur, le principe général des grays (clignotement), et après je me dépatouille.
[...]
Mais je ne nie que ça puisse apporter beaucoup au rédacteur en effet.

Sinon je n'ai pas fait partie des personnes "dominant l'asm et le C" que tu as citées, mais je pense avoir une connaissance suffisante des deux pour donner mon point de vue sur la question : je rejoins complètement PpHd, j'ajouterais aussi que développer en ASM prend beaucoup plus de temps qu'en C.

Au final, je conseille à l'auteur de ce topic de s'intéresser à l'ASM tout de même pour comprendre ce qu'est un processeur, que c'est relié à différents composants (mémoire, etc.), ce que sont des interruptions, et ainsi avoir une petite idée de ce qu'il se passe "en-dessous" du code C qu'il écrira ensuite.

PpHd (./47) :
Le C possède une librairie standard, pas l'asm.

Mais il est possible d'utiliser la librairie standard C en assembleur, au moins en partie. (TIGCCLIB a beaucoup de macros C qu'il faut traduire à la main, mais les fonctions peuvent être appelées aussi en assembleur.)

Tu as toujours des registres / de la mémoire / des caches / des pipelines / des out of order / des latences / des read / des writes / des add,sub,and... / des mul, div / des shift.

Non.
Sur le 68000, tu n'as pas de cache, le pipeline se limite à un prefetch de quelques octets, il n'y a pas d'out of order.
Il y a aussi des processeurs sans instructions de multiplication ni de division, par exemple le Z80.
Et il y a les architectures VLIW comme l'Itanium qui sont très différentes (les jeux d'instructions classiques essaient de cacher l'out of order, le VLIW pas du tout, c'est au compilateur ou à la personne qui écrit en assembleur de s'en occuper).
Pourtant, tu connais ces machines, je ne comprends donc pas pourquoi tu généralises comme ça.

Sinon, j'ai un autre point à rajouter: en C, si on ne fait pas exprès d'écrire du code illisible, on n'a en général pas besoin de commentaires, ou de très peu de commentaires, pour comprendre son code (et en général celui des autres aussi). En assembleur, il est impératif de commenter, sinon on ne comprend vite plus son propre code! (Genre "mais qu'est-ce que j'ai donc mis dans le registre %a3 ici, et c'est quoi 4(%a2,%d7.l)?")

PpHd (./47) :
Au niveau de la compréhension, oui. Au niveau pratique, par contre, avec l'ASM, tu te limites à une génération de CPU. Donc tu dois maintenir ton code à chaque nouvelle génération ce qui peut être lourd. Mais parfois nécessaire pour certains calculs.

Ah mais je suis parfaitement d'accord, et sûrement même plus d'accord avec toi que toi puisque ça fait longtemps que je n'écris pas une ligne d'ASM en dehors des routines critiques

Franchement, l'architecture varie pas tant que çà. Tu as toujours des registres / de la mémoire / des caches / des pipelines / des out of order / des latences / des read / des writes / des add,sub,and... / des mul, div / des shift.

Mais sur 68k y a ni cache ni out of order (donc ni latence), c'est à la fois un avantage parce qu'on voit mieux ce qui se passe et que c'est plus facile d'optimiser et de comprendre les concepts de base (le temps d'exécution d'une boucle sur un processeur moderne est un peu "magique" alors qu'il se compte de tête sans problème sur 68k) et un inconvénient parce que ça ne correspond pas à la réalité des processeurs actuels.


EDIT : hmmf, j'avais zappé les posts après celui de Pphd

Kevin Kofler (./49) :
Sinon, j'ai un autre point à rajouter: en C, si on ne fait pas exprès d'écrire du code illisible, on n'a en général pas besoin de commentaires, ou de très peu de commentaires, pour comprendre son code (et en général celui des autres aussi). En assembleur, il est impératif de commenter, sinon on ne comprend vite plus son propre code! (Genre "mais qu'est-ce que j'ai donc mis dans le registre %a3 ici, et c'est quoi 4(%a2,%d7.l)?")

Peut-être aussi que l'illisibilité vient de ces % horribles qui sont éparpillés dans le code ? </troll>
L'allocation de registre est surtout gênante pour la maintenabilité, mais en général si tu appelles tes registres de façon logique et que tu mets éventuellement un commentaire pour dire quel registre contient quoi (l'équivalent des noms de variables en C) ça reste assez lisible...

Sauf que si tu veux écrire du code optimal, une variable donnée ne restera pas toujours dans le même registre, et un registre ne contiendra pas tout le temps la même variable non plus. GCC est capable d'allouer les registres de manière dynamique, donc si tu ne l'es pas, ton code assembleur risque fort d'être moins efficace que ce que pourrait donner GCC. Donc exit les equr (directive qui n'existe pas sous GNU as d'ailleurs).

j'utilise pas les equr parce qu'on peut pas vraiment voir où sont les conflits d'allocation, ni où il y a de la place libre...
mais ça te dispense pas de dire quel registre contient quoi si y a beaucoup de variables ^^ (et puis faut pas déconner, c'est pas comme si les variables bougeaient dans tous les sens avec du code [quasi-]optimal)

PpHd (./47) :

squale92 (./39) :
Après, sur un PC moderne, ça coutera tellement plus cher de passer du temps à apprendre des notions d'asm que d'acheter un n-ième serveur (ou un n-ième cpu, ou un n-ième Go de RAM, ou quelques centaines de MHz de plus, ...)...

Pas forcément

moué, enfin, si tu travailles dans un environnement "normal"

Kevin Kofler (./49) :
Non.
Sur le 68000, tu n'as pas de cache, le pipeline se limite à un prefetch de quelques octets, il n'y a pas d'out of order.
Il y a aussi des processeurs sans instructions de multiplication ni de division, par exemple le Z80.
Et il y a les architectures VLIW comme l'Itanium qui sont très différentes (les jeux d'instructions classiques essaient de cacher l'out of order, le VLIW pas du tout, c'est au compilateur ou à la personne qui écrit en assembleur de s'en occuper).
Pourtant, tu connais ces machines, je ne comprends donc pas pourquoi tu généralises comme ça.

Pollux (./50) :
Mais sur 68k y a ni cache ni out of order (donc ni latence), c'est à la fois un avantage parce qu'on voit mieux ce qui se passe et que c'est plus facile d'optimiser et de comprendre les concepts de base (le temps d'exécution d'une boucle sur un processeur moderne est un peu "magique" alors qu'il se compte de tête sans problème sur 68k) et un inconvénient parce que ça ne correspond pas à la réalité des processeurs actuels.

Oui sur 68000, il n'y a pas de cache, ni d'éxécution out of order.
Ce que je voulais dire c'est perso, je trouve que l'assembleur se ressemble beaucoup entre CPU différents.
A vous écouter, on pourrait penser qu'à chaque CPU il faille tout réapprendre, alors qu'en général, en moins d'une heure, t'es opérationnel.
Car les concepts clés, et les instructions de base (et ce sont celles qu'il est conseillé d'utiliser), sont toujours les mêmes.
Ensuite comprendre suffisamment la machine pour faire du code optimisé, c'est une autre histoire

Mention spéciale pour l'itanium, je vous l'accorde, mais c'est un processeur mort

squale92 (./53) :
moué, enfin, si tu travailles dans un environnement "normal"

Est-ce qu'un environnement normal correspond à une application écrite en Visual Basic qui rame sur un core 2 duo à 2GHz, alors que la même application écrite en C fonctionne sur un P3 500MHz avec 10 fois plus de charges ?

Voire sur un 68k à 12 MHz. VB rame à fond...

VB rame pas plus que C# ni du C++ actuellement. Il faudrait pas exagerer... mais bon

PpHd: tu trouve que l'ASM x86 ressemble a l'ASM ARM ? hé ben chapeau

Ils ont mis un JIT compiler dans VB ?

dans VB.net peut être, mais dans LE VB (jusqu'au 6) ça m'étonnerait

(si il y a une forme de JIT et ce depuis VB4)