Discussion :

[cotoporto]

Bonjour par ici ! Je suis êxtrèment heureux d’annoncer que je viens d’achever un livre qui reprends les bases en ASM. Il est orienté débutant mais il va également dans les sujets assez avancés. Si la cybersécurité vous intéresse, ce livre aborde les bases pour devenir de vrai hackers (des gentils hein ). Si par contre c’est la création de système d’exploitation qui vous intéresse, le livre vous permettra de naviguer les obscures tutos sur le net qui en parlent.

un chapitre entier est disponible gratuitement à l’adresse https://x86asmdemystified.landen.co

J’attends vos avis. Merci.

[Kannagi]

Ben quand un livre dit : "Partant d'un niveau débutant à un niveau expert" , je pense que tu peux le bruler
Aucun livre ne peut transformer un débutant en expert , deja que pour des langages plus haut niveau comme le C , c'est compliqué alors pour l'asm...

Ensuite le livre coûte cher pour ce que c'est de l'asm sur Nasm pour 23$...
Si on a de l'argent a perdre pourquoi pas

Le premier chapitre je l'ai lu , il est pas incroyable , ça reste basique , on retrouve ces infos sur le net , je dirait même une méconnaissance de l'histoire de l'informatique, tu propose comme exemple de programme fait en full asm un petit jeu sur Snake ?
Tous les jeux sorti jusqu'en 1994 sur consoles était fait en full asm , quelque fois aussi sur PC , ce qui fait pas mal d'exemple.
(En terme de code source Github en donne pas mal).

Une autre erreur , ton graf peut faire penser que l’hexadécimal et plus haut niveau que le binaire , ce qui est stupide ,vu que l'hexa ou le binaire ne sont que des représentations...
Écrire 1010b , 0Ah ou 10 , c'est exactement pareil

Tu explique que l'asm permet de communiquer avec le matériel , ce que j'ai envie de dire non
cela dépend quelque fois des machines , mais sur la plupart des architectures que j'ai touché toutes les I/O sont mappé en mémoire , et c'est fou le C permet de créer un pointeur et de lui donner une valeur x)
(donc on peut faire du bas niveau en C incroyable ^^).
Sinon l'utilisation de l'asm pour connaître l'ordinateur oui et non , l'asm permet juste de connaître le fonctionnement de son processeur , comme je l'ai dit on peut très bien programmer bas niveau et faire du C , si on fait du bas niveau on connaît le fonctionnement de la dite machine , sans forcément écrire une ligne en asm
Effectivement j'ai deja utilisé l'asm pour des raison ou la mémoire est très petite , ou pour l'optimisation , et l'utilisation des instruction SIMD.

L'autre point la façon d'expliquer que l'asm permet de faire des programme rapide , bof un bon compilateur C ou C++ fera mieux , et le pire c'est que tu galérera plus en asm.
Sinon je connais pas les autres chapitre , mais pour moi , un chapitre sur le bas niveau ,la pipeline et mémoire cache me semble au moins nécessaire si le cours se veut au moins 'complet'.
Sinon si c'est pour parler de la programmation de grand papa en 2018 , je vois pas l’intérêt d'acheter un tel bouquin (enfin je déconseillerai d'acheter tout bouquin sur l'asm en 2018 mais bref).

[cotoporto]

Ensuite le livre coûte cher pour ce que c'est de l'asm sur Nasm pour 23$...
Si on a de l'argent a perdre pourquoi pas

non c'est à 11,45$ soit 10 euro. Tu as d tomber sur une autre page (sûrement une de mes pages test avant le lancement. Désolé )

Le premier chapitre je l'ai lu , il est pas incroyable , ça reste basique , on retrouve ces infos sur le net , je dirait même une méconnaissance de l'histoire de l'informatique, tu propose comme exemple de programme fait en full asm un petit jeu sur Snake ?
Tous les jeux sorti jusqu'en 1994 sur consoles était fait en full asm , quelque fois aussi sur PC , ce qui fait pas mal d'exemple.
(En terme de code source Github en donne pas mal).

C'est justement, le but. Qu'il reste basique. Le problème, c'est que les membres confirmé comme toi trouvent cela facile. Mais ce n'est pas toujours le cas pour les autres. Quant à l'exemple choisi, il est représentatif. Le but étant de demontrer rapidement, ce qui a été fait avec le langage sans non plus citer tout internet. J'ai jeté mon dévolu sur ces deux choix sans plus. C'est tout.

Une autre erreur , ton graf peut faire penser que l’hexadécimal et plus haut niveau que le binaire , ce qui est stupide ,vu que l'hexa ou le binaire ne sont que des représentations...
Écrire 1010b , 0Ah ou 10 , c'est exactement pareil

Tu as tout à fait raison, je n'avais pas vu sous cet angle l'erreur que cela peut engendrer. Je vais mettre une note pour ceux qui penseraient comme toi.

Tu explique que l'asm permet de communiquer avec le matériel , ce que j'ai envie de dire non
cela dépend quelque fois des machines , mais sur la plupart des architectures que j'ai touché toutes les I/O sont mappé en mémoire , et c'est fou le C permet de créer un pointeur et de lui donner une valeur x)
(donc on peut faire du bas niveau en C incroyable ^^).

J'ai dit permet. J'ai pas dit qu'il est le seul....Mais je te comprends je vais voir si d'autres précisions peuvent aider le lecteur

Sinon l'utilisation de l'asm pour connaître l'ordinateur oui et non , l'asm permet juste de connaître le fonctionnement de son processeur , comme je l'ai dit on peut très bien programmer bas niveau et faire du C , si on fait du bas niveau on connaît le fonctionnement de la dite machine , sans forcément écrire une ligne en asm
Effectivement j'ai deja utilisé l'asm pour des raison ou la mémoire est très petite , ou pour l'optimisation , et l'utilisation des instruction SIMD.

C'est discutable. Mais comme ton avis est partagé (oui et non), je pense que tu comprends qu'en partie l'ASM permet d'aller un tantiner (plus?) plus loin que le C dans la compréhension du matériel.

L'autre point la façon d'expliquer que l'asm permet de faire des programme rapide , bof un bon compilateur C ou C++ fera mieux , et le pire c'est que tu galérera plus en asm.

Eh bien, d'autres préfèrent galérer Bon, plus sérieusement. Comme tu l'as mis plus haut (ton exemple avec les instruction SIMD), on peut avoir besoin dans ces cas-là de l'ASM. Et le compilo ne peut rien y changer (fonctions intrinsèques mis à part). Mais aussi, comme dans le chapitre gratuit que tu as téléchargé en parle, n'oubli pas la sécurité informatique (les virus, les patchs, le cracking, le hacking)

Sinon je connais pas les autres chapitre , mais pour moi , un chapitre sur le bas niveau ,la pipeline et mémoire cache me semble au moins nécessaire si le cours se veut au moins 'complet'.

Ce livre est en plusieurs volumes. On ne peut aborder tous ces points en détails dans un seul livre qui veut pas perdre ses lecteurs.

Sinon si c'est pour parler de la programmation de grand papa en 2018 , je vois pas l’intérêt d'acheter un tel bouquin (enfin je déconseillerai d'acheter tout bouquin sur l'asm en 2018 mais bref).

L'ASM monte (un tout petit peu) en ce moment. Sans parler du fait que la cybersécurité prend de plus en plus de l'importance, je doute du bien fondé de cette affirmation.

[Kannagi]

Je comprend qu'on veut défendre son taff , je trouve aussi que le livre promet mont et merveille ce qui est une erreur .

Sinon tu dis :

Ce livre est en plusieurs volumes. On ne peut aborder tous ces points en détails dans un seul livre qui veut pas perdre ses lecteurs.

ok pourquoi pas mais après tu dis :

L'ASM monte (un tout petit peu) en ce moment. Sans parler du fait que la cybersécurité prend de plus en plus de l'importance, je doute du bien fondé de cette affirmation.

c'est contradictoire avec ta volonté de parlé de cybersécurité , sachant que les failles actuelle Meltdown et Spectre sont du justement a des failles a cause d'un optimisation de la pipeline qui écrit sur la mémoire cache.

Sinon l'ASM a toujours attiré des curieux parce que c'est considérer comme le langage le plus 'puissant' et le plus 'complexe' ce qui est faux mais bon les jeunes aime bien se la raconter , si l'asm a était abandonné ce n'est vraiment pas pour rien hein
La cybersécurité ne s’inquiète rarement de ce que fait le processeur (Meltdown et Spectre sont des cas a part) , en général ce sont des failles venant d'un peu plus haut (niveau de l'os) que ça arrive.

[cotoporto]

La cybersécurité ne s’inquiète rarement de ce que fait le processeur (Meltdown et Spectre sont des cas a part) , en général ce sont des failles venant d'un peu plus haut (niveau de l'os) que ça arrive.

La facette de l'ASM liée à la cybersécurité est celle de l'exploitation. je parle de la compréhension que procure l'ASM pas d'autes choses. je parles également de l'exploitation qu'on peut en faire (shellcodes par exmeple pour ne citer que ça). ça n'a rien avoir avoir d'où vient la faille. Mais plutôt de comment on l'exploite. Exploite les failles liées à l'OS (kernel, user land) ou à tout programme (compilé) sans passer par l'ASM et tu comprendras mieux ce que j'essai d'exprimer.

[Forthman]

Je trouve louable le fait de vouloir continuer à faire vivre l'assembleur, et de permettre au personnes curieuses
de savoir comment fonctionne un ordinateur (ou autre machine ayant un processeur dedans).

Mais je rejoins Kannagi sur le peu d'intérêt aujourd'hui de coder en ASM... Sauf pour le plaisir
(mais du coup sur des architectures plus anciennes, ou sur des microcontrôleurs de faible puissance)

Quand à l’intérêt croissant pour l'assembleur, je pense que ce n'est que les médias qui donnent cette impression,
tout comme les vilains virus, et le dark web, et tous ces trucs qui font peur et où ils ne bitent rien.

Si on regarde le forum Assembleur de Developpez.com on voit qu'il n'y a plus d'activité...

[cotoporto]

Merci Forthman. Mais, l'intérêt de l'ASM n'est pas dû qu'aux médias. Il vrai que du côté ARM ça brûle un peu plus. Mais si tu regarde les shellcodes postés (qui subisent des tris en plus) sur exploit-db.com (celui-ci par exemple https://www.exploit-db.com/exploits/41827/ tu verras qu'ils sont plus ou moins récents.Il a y aussi les articles sur codeproject.com et les différentes conférences sur le shellcoding comme celui-ci https://www.fireeye.com/blog/threat-...shellcode.html.

C'est vrai que , malheureusement la scène francophone est un peu à la traine (l'histoire du forum en témoigne). Mais il faut, ensemble, rectifier ce tir. Merci

[Kannagi]

Oui ,enfin pas tout le monde s’intéresse a la cybersécurité hein ,tout simplement que pour ma part je fais de l'assembleur sur des machines qui sont dépourvu OS :p
Pour les bouts de code que tu montre, pour ma part je ne pense pas que cela soit très représentative de quelque chose ,tu trouvera aussi encore des bouts de code récents pour MS-DOS et Atari St en assembleur !

Et il est vrai que je reste persuadé que pour connaître le bas niveau et l'assembleur , les architectures plus anciennes ou sur des microcontrôleurs de faible puissance (comme le dit Forthman) sont sûrement la meilleur point d'entrée ^^
Et je conseille aussi en général de tester pas mal d'architecture différente , ça évite de s'enfermer et on apprend beaucoup de chose aussi , par exemple j'ai pas mal appris sur d'autre architecture et ça m'a permis du coup a mieux a comprendre le fonctionnement interne des processeurs modernes.

[Bros]

C'est marrant

Je vous vois tous parler de coder en asm, vous montrez des exploits avec du code asm ...

Personne ne parle de l'asm lors du reverse.

Vous croyez que les personnes qui reverse les malwares ou autres logiciels ils ont du code en C/C++/C#/Java/... sous les yeux ?

[cotoporto]

C'est marrant

Je vous vois tous parler de coder en asm, vous montrez des exploits avec du code asm ...

Personne ne parle de l'asm lors du reverse.

Vous croyez que les personnes qui reverse les malwares ou autres logiciels ils ont du code en C/C++/C#/Java/... sous les yeux ?

Tu as tout à fait raison. J'en parle durant l'introduction de mon livre (c'est disponible gratuitement sur mon site - https://x86asmdemystified.landen.co ). En plus il y a des TD de cracking dans le livre. Bref, oui l'ASM est utile dans ce sens. Je me permets de détailler cela ici :
*reverse enginerring
-reverse des malwares et vers
-reconnaissance des formats
-reconnaiances de fonctionnements internes et non documentés
-recherche de vulnérabilités (audit de binaires)


Les shellcodes deviennent de plus en plus performants, les rootkits aussi. Les chinois et quelques autres pays s'arment afin d'être les premiers à bien maitriser ces techniques de hauts niveaux. En plus avec les objets connectés (souvent processeur ARM) qui ne cessent d'augmenter, je pense qu'il faut de plus en plus s'intéresser à cet art.

ps: souvent la décompilation de binaires sous environnement android (donc java) se limite à juste du java. Il est vrai que dans certains cas, on va jusqu'à obtenir du code ASM (pour ARM) mais souvent c'est plus une décompilation.

[Invité]

Merci, Cotoporto pour ton travail de longue haleine. Pour ma part, je regrette que tu ne nous aies pas donné à lire un chapitre plus consistant. C’est à cette condition qu’un tel travail peut réellement être apprécié. Je ne formulerai donc pas d’avis sur le fond à défaut d’en savoir plus.

Pour le reste, je ne suis pas surpris par les réactions négatives de certains de mes honorés collègues du forum. Avec de tels amis, comme on dit, le forum Assembleur n’a pas besoin d’ennemis. Est-ce surprenant, dans ces conditions, qu’il brille par sa faible participation à part quelques étudiants pressés d’expédier leurs devoirs tout en ne manifestant aucun intérêt pour le sujet ? Est-ce surprenant enfin que les contributeurs animés d’ambitions pédagogiques fassent demi-tour après avoir reçu un tir nourri d’arquebuses et force encouragements sur le thème “l’assembleur, c’est le passé/ ça ne sert à rien/ etc.” ?

Non, mais j’espère que les choses changeront. Il existe d’autres lieux (principalement Anglo-saxons) où ces questions sont abordées avec plus de sérieux, c’est-à-dire sans ces querelles de clocher puériles et totalement stériles. Chacun se reconnaîtra...

[cotoporto]

Merci asmou pour ton soutient. En effet, je reconnais que j'ai été un peu refroidit par les réactions de certains. Le pire c'est quand je vois , comme tu le dis, les pays anglo-saxons, s'intéresser à cet art avec bcp de serieux. Les dernières percées en sécurité applicatives sont justement dûes à cela. L'espionnage de pays entiers tourne autour de la maîtrise de l'asm. Je me suis dit qu'il fallait repartir sur de bonnes bases. Car pour moi, rien de mieux que de solidifier les fondations. Je vais suivre ton conseil et proposer un chapitre plus intérsessant en téléchargement gratuit.

pour pimenter, voci quelques femmes (https://www.begin.re/) quise lancent pour rendre l'asm accessible et utile à israel où la technologie est en train d'être redéfinie

[bifur]

l'assembleur est bon pour la santé, mangez en!

je n'avait pas réagis encore au sujet parce que j'estimait ne rien avoir de pertinent a dire (comme d'habitude) mais je soutient cette initiative, bien que je soit intéressé par l'assembleur je n'ai pas les capacité d'en faire un bouquin alors je ne peut qu'applaudir au résultat. de nombreux râleurs (oui ils sont très très nombreux) auront toujours des critiques a formuler mais globalement faut pas trop s'en préoccuper. quoi qu'ils disent tout ouvrage sur l'assembleur ne peut qu'améliorer la compréhension sur le sujet. le choix de gravir la montagne assembleur par la face sécurité n'est peut être pas la meilleur selon certain mais cela donne au moins une face de plus a explorer

par contre je ne sais pas si ton bouquin est disponible sur d'autre plateforme mais je pense que ça serait mieux parce que je trouve que le formulaire d'achat est un peu louche

[Forthman]

Je ne vois pas de réactions particulièrement négatives.
Pour ma part je ne programme qu'en Assembleur et en Forth (niveau langage mort je suis bien logé )
Et ce n'est pas parce qu'un livre sort sur un sujet qui m'intéresse , que je dois crier sur tous les toits que "c'est génial et que ça va révolutionner l'informatique"

[Kannagi]

Il faut pas avoir peur de prononcer mon pseudo , je ne suis pas voldemort
Il me semble aussi que le posteur original avait posté sur OC aussi et les critiques n'était pas forcément plus 'enthousiaste' que certain ici

Et même si je fait une critique de l'assembleur ou des cours , cela ne veut pas dire que je ne l'utilise pas , que ça soit en full assembleur ou en C/asm (et mon utilisation de l'assembleur est certes pour l'optimisation et le bas niveau).

Et depuis que je traîne sur le forum , la question et le but de l'apprentissage de l'assembleur est souvent pour savoir comment fonctionne une machine et donc rien que de dire : "Comment faire un Hello World en asm " est déjà problématique parce que connaître l'assembleur ne permet pas de répondre a cette question (vu que cela dépend de la machine cible et donc plus généralement de l'architecture des ordis) ,sur un OS certes c'est légèrement différents vu que c'est l'OS qui le fourni (et donc savoir comment il fonctionne).
Donc pour cela que je reste assez sceptique sur ce tuto (qui parle du langage en lui même sur 11 chapitre sur 12).

[cotoporto]

@bifur le livre est en précommande actuellement. Le but cétait de receuillir un maximum de retour afin de parfaire le boulot déjà fait. Donc j'ai lancé une précommande et mis en ligne une ébauche . J'ai reçu assez de retour et actuellement j'ai pu améliorer significativement le contenu ( 4 chapitres sur la sécurité des programmes ont étés ajoutés). Je compte mettre à jour le site afin de rendre disponible la nouvelle version et l'envoyer à ceux qui ont précommandé (le prix change après la sortie officielle). Quant à la plateforme de publication choisie, j'ai déjà mis en place un compte sur payship (Amazon viendra avec un peu de temps). J'espère qu'ensuite, ce sera moins louche

@forthman Je suis tout à fait d'accord : pas besoin de crier "c'est génial et que ça va révolutionner l'informatique". Mais, il est vrai que cela fait quand même plaisir d'avoir un retour (même s'il est négatif ou neutre). Bref merci de soutenir et pourquoi pas de proposer de possibles pistes d'améliorations (qu'est-ce qui serait bien à y mettre et qui intéresserait...) avant la sortie définitve (prévu pour ce mois au plus tard le 20)

@kannagi Non, persone n'a peur de prononcer ton pseudo (en tout cas pas moi). Par contre j'adore ton jeu de mots avec voldemort . Ensuite oui j'ai posté sur OC. Mais, en beta j'avais déjà eu des retours vraiment positifs. Et tout comme toi les reproches était autour de l'aprofondissement du côté sécurité et quelques améliorations sur la forme et sur la rigeur des propos que j'avançais dans le livre. En bref, je parle du langage sur 11 chapitre sur 15 sans comptés les TDs et exercies (oui j'ai ajouté des chapitres) car c'est un livre sur L'ASM pas sur autre chose donc c'est normal. Je parles certes de la sécurité mais c'est pour montrer les pistes d'applications du langage. Néanmoins, vu que tant de gens me l'on dit, j'ai ajouté 4 chapitres sur la sécurité. Je devrais mettre cela en ligne d'ici deux jours (je parles du nouveau apperçu en libre téléchargement). Je ferai une mise à jour de ce poste en conséquence



Merci à la totalité des intervenants de me soutenir (certes, certains à leurs façons, mais j'aime cela). Je pense qu'ensemble, on peut vraiment avoir une documentation qui aidera n'importe quel nouveau venu sur la scène à grimper vite et partir de cette base pour faire des choses assez étonnnates. Oui car, il faut pas l'oublier : le but c'est d'aider. Ensemble, doté de connaissances similaires on pourra plus facilement faire une révolution.

[chrtophe]

Le livre parle t'il du mode protégé ? de la pagination ?

Si ton livre n'évoque pas ces sujets, il n'est pas à l'ordre du jour.

Voici quelques commentaires d'après le chapitre que j'ai lu en diagonale.

Un programme écrit en ASM occupe moins d'espace en
mémoire. Cela peut rendre rapide l’exécution d’un
programme.

Un compilateur C, qui génère du code assembleur lors de la phase de compilation, va chercher à générer du code le plus rapide possible, pas forcément le plus compact. Les compilateurs actuels sont capables de générer du code assembleur plus efficace qu'un humain. Utilise l'assembleur dans ce cas est contre productif.

L’ASM est également utile lorsque la performance, surtout la rapidité, est un facteur critique.

Ce n'est plus vraiment le cas, c'est surtout utilisé pour les pilotes et les micro-contrôleurs de nos jours.

Connaitre l’ASM permet de craquer (faire sauter les protections) des programmes, ou des formats propriétaires
On peut par exemple copier un algorithme ultra secret d'une entreprise par rétro-ingénierie afin d'en produire un meilleur
ou encore rendre gratuit un programme payant;

Ceci est illégal sauf pour l'interopérabilité si aucune documentation n'est fournie.

Lors de la création de système d’exploitation, au niveau du boot loader (si on en recrée un), il est impossible d’échapper à l’utilisation de L’ASM.

Ce n'est plus le cas avec l'UEFI.

[cotoporto]

Le livre parle t'il du mode protégé ? de la pagination ?

oui le livre aborde l'assembleur sur micro 64/32 bits. Le mode protégé est discuté en annexe avec ce qui s'y rapporte (descripteurs de segments...etc...). La mémoire virtuelle (et les autres types d'accès mémoire) aussi est expliquée.

Un compilateur C, qui génère du code assembleur lors de la phase de compilation, va chercher à générer du code le plus rapide possible, pas forcément le plus compact. Les compilateurs actuels sont capables de générer du code assembleur plus efficace qu'un humain. Utilise l'assembleur dans ce cas est contre productif.

Cela dépend des options d'optimisation du compilo. Mais c'est vrai que par défaut, la rapidité prise sur la taille lors de la compilation. Cela dit la taille d'un programme peut jouer sur la rapidité car cela aide la mémoire cache qui limité en taille a y charger le maximum de contenu (les plus solicités). Là encore je ne parle pas du runtime nécéssaire au C et de la section bss exploitable par le programmeur ASM qui tous deux influecent la taille.

Ce n'est plus vraiment le cas, c'est surtout utilisé pour les pilotes et les micro-contrôleurs de nos jours.

se rapporter à ma réponse précédente. Mais j'ajoute que même si les fonctions sont disponibles, lorsqu'on parlera d'optimisation spécifique à une architecture, c'est encore le cas. Et, là je ne parlepas SIMD et autres ou d'optimisations des boucles internes etc... Maintenant parlons de cas spécifiques : lorsque les virgules flottantes serons sollicitées, les compilateurs de nos jours seront toujours moins performant que l'ASM (intrinsèques mis à part qui ne sont que l'ASM déguisés). En effet, ces opérations n'étant pas associatives, le compilateur ne peut faire des manipulations complexes pour mieux optimiser le code. Il devra faire confiance au programmeur. Ainsi, même si les cas d'optimisation avec gcc ( options -O3 -ffast-math) ne gère pas ces cas.

Il ya aussi les multiplication de très grand nombres (64 bits par exemple) sur micro 64bits qui ne sont pasaussi optimisés en C (il aut faire des casting et des shift)que l'asm (et son equivalent intrinsèque)

Ceci est illégal sauf pour l'interopérabilité si aucune documentation n'est fournie.

Le but ici c'est d'aborder le concept afin de parler plus tard des techniques d'ofuscations de detection de debugger et autres outils. En effet, le crack des programmes pillullent sur internet. Et on est content quand c'est un crack de Windows ou encore d'un autre éditeur. Mais si c'est votre programme qui se fait craquer après vos dures efforts, ce n'est pas la joie. Le hacker qui crack dans le noir ne veux rien savoir de l'illégalité. Il faut donc aborder ces points. Je n'incite personne à passer du mauvais coté. J'informe des possibilités afin de mieux se préparer. A contiuer à dire cela on risque de voir toute une génération passer et la nouvelle génération ne connaitra rien de tout cela. Ce sera alors la chasse gardée des gouvernements et autres structures bien placées.

Ce n'est plus le cas avec l'UEFI.

C'est vrai. Mais depuis 2006 que cette spécification est sortie, regarde encore le nombres d'ordinateurs qui tournent sous le BIOS. Mais je vais mettre une footnote dans le livre pour les gens comme toi qui souhaitent les infos le plus précis possible

Merci.

[Kannagi]

Cela dépend des options d'optimisation du compilo. Mais c'est vrai que par défaut, la rapidité prise sur la taille lors de la compilation. Cela dit la taille d'un programme peut jouer sur la rapidité car cela aide la mémoire cache qui limité en taille a y charger le maximum de contenu (les plus solicités). Là encore je ne parle pas du runtime nécessaire au C et de la section bss exploitable par le programmeur ASM qui tous deux influecent la taille.

Il existe effectivement une mémoire cache pour les instructions , mais la taille de l'exe n'a aucune influence sur celui ci (aucun programme entier rentre dans cette mémoire cache) , (je ne sais pas si Intel le précise) mais ceux qui rend la pipeline plus longue c'est les cache miss (ceux des données) et justement les compilateurs optimise déjà pour éviter les caches miss
De plus la taille de l'exe ne veut absolument rien dire , par exemple en terme d'optimisation le precalcul , inline (donc pas d'appel de fonction) , le dépliage des boucles , tout ceci augmente la rapidité du code au détriment de la taille de celui ci.

En effet, le crack des programmes pillullent sur internet. Et on est content quand c'est un crack de Windows ou encore d'un autre éditeur. Mais si c'est votre programme qui se fait craquer après vos dures efforts

'content' pas vraiment, ton exemple ne vise peut être pas grand monde ici ,tu serait étonné de voir ici le nombre de personne qui utilise Linux + logiciel libre , je ne crack aucun programme , je n'en ai jamais eu le besoin (toujours trouvé un logiciel libre qui me convient ).
Sauf en pro mais là je m'en fiche que le programme se fait cracker ou pas , sur mes projets perso je ne fais que de l'open source disponible sur github

[cotoporto]

mais la taille de l'exe n'a aucune influence sur celui ci

Aucune est un mot osé. En effet, cela dépend des instructions les plus sollicité et de leur localisation dans le code. Cela dit, je ne soutiens aucunement que tout le programme entre dans la mémoire cache( il est trop petit pour cela) ou encore qu'il y a une relation directe entre taille et rapidité, mais cela fait partie des facteurs qui influencent. Et, il faut pas oublier que le cache miss concerne aussi les data donc quand tu parles d'inlining et autres tu te concentre trop sur le coté du code.
Et même dans ce cas, Trop d'inlining peut grossir le code et causer des page fault (donc plus de demande de mémoire virtuelle) car l'exécutables est trop gros (encore une influence de la taille) donc le système passera son temps à fetcher des instructions depuis le disques (donc plus de latence d'exécution)

'content' pas vraiment, ton exemple ne vise peut être pas grand monde ici ,tu serait étonné de voir ici le nombre de personne qui utilise Linux + logiciel libre , je ne crack aucun programme , je n'en ai jamais eu le besoin (toujours trouvé un logiciel libre qui me convient ).
Sauf en pro mais là je m'en fiche que le programme se fait cracker ou pas , sur mes projets perso je ne fais que de l'open source disponible sur github

Je ne parle pas des gens de developpez.com je parle du fait qu'il y a des gens qui sont content d'avoir des cracks. Mon point était de surtout montrer à quel point cela peut faire des dégats de ne pas connaitre.