Bonjours !

Je voudrais savoir si on peu programmer en ASM à l´interieur du code C, comme on peu le faire avec delphi 6 ou ou visual C ++ .

merci d´avance

tu peux, en créant un bloc d´assembleur :

_asm
{
MOV AX,0x10
MOV BX,23
MUL BX
JZ arf
. ..
}

vérifie, peut etre que d´un compilateur a l´autre, ce n´est pas _asm, peut etre asm ou __asm

rebonjour,

En fait je suis le papa de Rikkuman, moi aussi je m´interresse à l´informatique et je voudrais continuer l´étude de l´assembleur.j´ai fait qql prog avec A86 mais limité à 16 bits.
J´ai téléchargé NASM qui est simple dans la syntaxe mais j´ai des problème pour linker pour obtenir un fichier COM à partir d´un fichier OBJ
C´est sous DOS. Mon fils à téléchargé DEV C++ et je le trouve bien , de là à l´utuliser pour faire de l´assembleur. Votre réponse était oui, pouvez vous me dire quel type d´assembleur est-ce, etc.
Cela vaut-t-il la peine d´assembler pur avec ce programme. Qu´en pensez vous ?
Je suis un peu paumé devant les types différent d´assembleur, autonome et intégré, surtout que les syntaxes sont légerement différentes.

Cordialement.

nasm est relativement sympathique, mais pas aussi souple que certains autres produits ( malheureusement pas gratuits, comme masm). Quand à generer des . com, si la segmentation est plus simple à gerer, leur époque est revolue et leur exécution peut parfois poser certains problèmes sur les plates-recentes ( l´idéal serait de disposer d´un bon vieux dos, totalement indépendant)

En ce qui concerne l´assembleur inline, ce sera généralement du x86 ( 32 bits et extensions, si supportées, comme MMX, SSEx, etc.) et compatibles ( jeu AMD) ; mais impossible de faire de l´assembleur pur, tout le linkage sera pris en main par le compilo C/C++, donc on perd le controle de la segmentation.

à l´heure actuelle moi je conseillerai l´utilisation d´asm inline dans un projet de plus grande envergure. On notera quand meme qu´à moins d´exploiter les dernières technologies ( SSEx), le compilo fait généralement un meilleur boulot que le programmeur en manuel.
Avant c´était pratique, qq registres 16 bits, et on controlait tout, et on savait ce qui se passait. Ajd avec la complexité des proc ( multiplicité des pipelines, jeux d´instructions complexes, architectures tordues comme le HT ou le netburst, etc.) mieux vaut laisser faire le compilo, sauf exception.

Evidemment, si l´interet c´est de faire de l´asm pour faire de l´asm, pas pour les perfs dans un projet, on ne tiendra pas compte de ce que je viens de dire....

( pour les jeux d´instructions, à moins de coder sur un powerpc, un amiga, des RISC genre spark, ou dans le genre, la doc intel sur le x86 peut s´averer tres utile, car tres -trop ? - complete ! dispo sur leur site..)

Eh bien merci pour tout ces détails, je vois que je suis en retard d´un train si pas 2.
je ne me suis plus occupé de programation depuis environ 5 ans, les chose ont beaucoup évolués et se sont compliquées aussi.
Pour le moment je vais continuer à lire tout ce qui se dit sur ce sujet sur les forums .

Cordialement et félicitation pour votre disponibilité.
Le Papa de Rikuman

oui, maintenant en effet, le temps de l´assembleur est révolu.
Bon sans reparaphraser ce qu´a dit LGV, je dirais qu´un langage comme le C++, avec de bonnes librairies, permet de faire des effets magnifiques, 3D, etc, sans avoir besoin de descendre au niveau machine.
De moins en moins de personnes descendent au niveau machine car les compilateurs sont vraiment puissants maintenant.

Bienvenue sur le forum en tout cas !

pour le papa de Rikkumann4, pour faire un . COM, utilisez Debug ( commande debug sous dos).

" nasm est relativement sympathique, mais pas aussi souple que certains autres produits ( malheureusement pas gratuits, comme masm).">
? T´entend quoi par là?

" On notera quand meme qu´à moins d´exploiter les dernières technologies ( SSEx), le compilo fait généralement un meilleur boulot que le programmeur en manuel. "

Dans tes rêves. Les compilos font un boulot très moyen, même s´il s´améliorent lentement. Ils ne font globalement qu´utiliser quelques " plans" d´optimisation de base qu´ils se contentent d´appliquer, sans plus. Ils ont un mal fou à savoir concaténer différentes instructions high-level, et se contente généralement de séparer les macro-instructions en blocs à l´intérieur desquels ils font leur possible pour optimiser. En somme, c´est pas très beau.

D´un autre côté, on peut pas leur en vouloir totalement: une bonne partie de la faute ne leur est pas imputable dans le sens où ils ne savent pas vraiment ce que tu as dans la tête, ce que tu veux faire de ton code. Ils pourraient faire teeeelement mieux, mais quand même, ce n,est pas totalement leur faute au moins...

" On notera quand meme qu´à moins d´exploiter les dernières technologies ( SSEx), le compilo fait généralement un meilleur boulot que le programmeur en manuel. "
Bah c´est supposé être des specs à ce que je sache, donc ça a un usage plus large que celui d´assister à connaitre les instructions pour un programmeur lambda...

Sinon, je suis d´accord avec JYY:
De nos jours, à moins d´utilisations très spéciales et spécifiques, vaut mieux se choisir un bon language haut level.
" De moins en moins de personnes descendent au niveau machine car les compilateurs sont vraiment puissants maintenant. "

Bof. Moi je dirais plutôt parce que y´a tout simplement plus intéret, étant donné que le ratio effort/résultat est beaucoup trop bas de nos jours.

Comprennez moi bien: Je ne recommande pas vraiment de faire de l´assembleur pour optimiser. Je dis simplement que l´on peut faire mille fois mieux que ce que les compilos nous sortent comme diarrhée-machine. Hors, le fait qu´on PUISSE le faire ne signifie pas que l´on DOIVE le faire puisque la qualité du code machine importe de moins en moins de nos jours. Les algos comptent plus. Dans ce sens, je suis en accord avec le principe de laisser le compilo optimiser. Il optimise ptêt mal, mais la perte d´opti en code est compensée par les gains en algo.

Si les compilos s´améliorent, alors, ouais. Tant mieux.

Kelios
---------

Boarf, dans un langage intermédiaire comme le C je pense que le compilo fait un bon boulot. Par contre c´est plus dur de faire du bon boulot pour un compilo quand c´est un compilateur pour un langage de haut niveau ( comme les basics).

Sujet bien delicat que celui-ci.
Kelios, je ne suis pas tout a fait d´accord avec toi: les compilos font un excellent boulot, certes ils ne peuvent pas optimiser l integralite des tes algo, mais je doute que tu saches optimiser ( sans vtune ton code pour les caches. Par exemple, deja sur 68040 c´est delicat..
Ensuite faut voir le gain de temps: il est tellement plus rapide de laisser le compilo optimiser le code, et de ne recoder que les parties sensibles, inner loops etc.
Il est egalement tres intelligent d´optimiser ses algo pour les compilos, surtout en c++ ou les utilisateurs arrivent a faire du code bien moche car ils ne savent pas ce qui se passe en-dessous.
Intel´s compiler rulz.

T´entend quoi par là?

que MASM propose des choses telles que des macros pour les structures de controles courantes, des alias pour acces direct au param sur la pile, etc. Perso je ne suis pas tres fan, mais ce sont des fonctionnalites que certains exploitent et cela accelere leur developpement.
Cela fait looongtemps que je n´ai pas utilise NASM ( note que le commentaire date du debut de l´annee), mais je doute que celui-ci propose des fonctionnalites similaires.

Dans tes rêves

et oui, c´est triste hein ? mais c´est comme ca...
quand on faisait du x86 pur sur des bons vieux 386, c´etait autre chose, mais aujourd´hui serieusement, entre MMX/SSE/HT/Netburst/etc. ( branche Intel, l´inverse etant transposable en AMD), le programmeur n´a AUCUNE chance de prendre en compte toutes les interactions de ces technologies lorsqu´il ecrit du code un tant soit peu complexe. Et tu te vautres sur un truc minime, tu plombes les perfs royalement... Ok le compilo ne te donne p-e que " 90%" de la puissance theoriquement accessible, mais si tu depasses les " 50%" a la main, il faut s´estimer heureux.
Il reste encore bien sur des cas ou l´ASM *EST* interessant, car cas isoles tres restreints exploitant a fond l´une des technologies disponibles ( au pif, du skinning de bones en SSE, ca depote mortellement) ; mais les domaines d´applications ou il est utile de foutre de l´ASM sont tres restreints.

Les algos comptent plus

il est EVIDENT qu´il est completement denue de sens d´essayer de gratter 5% de perfs sur un algo mal gaule, alors que tu gagnes 300% en le reecrivant de maniere intelligente ( ex. encore au pif, des resolutions de systemes lineaires.)
Il n´est question de passer en ASM que lors de l´etape finale, ou TOUT le reste a deja ete mis en oeuvre pour favoriser les performances ; autrement gratter le 1% restants sur un algo qui tourne deja a " 101%"

Si les compilos s´améliorent, alors, ouais

ICC fait un boulot extraordinaire, sur des archis Intel