Discussion :

[AsmCode]

Bon je ne sais pas si il y a bien des gens au courant de ça, mais il y a peu longtemps, j'ai réalisé que même les variables de bases sont des types définis par le compilateur et que une fois compilé, c'est l'exécutable lui-même qui vérifie les erreurs de types. Par exemple si on essaye de mettre un long dans un int, etc. Et que le comportement des erreurs, comme par exemple en java si on dépasse la capacité il ne fera pas un overflow mais plutôt il va recommencer "à l'envers" je veux dire quand il arrive avec un int de 2 octets à 65536 il recommence à -256 au lieu de planter ou un truc du genre, alors qu'en C c'est différent. Donc j'en ait conclu que lorsqu'on compile notre exe n'est pas exclusivement notre programme, mais il y a des routines de gestion du code d'inclus, etc. Alors au final une variable n'est qu'une adresse mémoire (ça je le savais déjà) mais qui est géré par des routines inclus à notre insu dans nos exe.

Est-ce qu'il y a autre chose qui est inclus à part cela ?

De plus, en asm, en code binaire pur, il n'y a donc aucune gestion ? Donc il n'y a qu'un seul type de variable, c'est-à-dire ce qu'on en fait ? Si je décides de mettre le nombre 4574 en mémoire, c'est à moi de gérer l'espace nécessaire ou si c'est le cpu qui s'en charge ?

Car en asm, comment s'assurer que la mémoire est libre ou non ?

[ShootDX]

Donc j'en ait conclu que lorsqu'on compile notre exe n'est pas exclusivement notre programme, mais il y a des routines de gestion du code d'inclus, etc

A mon avis non. Lorsque tu assignes une valeur à une variable, tu donnes en même temps une indication sur la taille de ta variable (byte, word, dword, etc.), directement dans la mnémonique de l'instruction si je me souviens bien. Ensuite, c'est au CPU de faire un modulo ce pourquoi tu peux te retrouver avec des valeurs négatives.

De plus, en asm, en code binaire pur, il n'y a donc aucune gestion ? Donc il n'y a qu'un seul type de variable, c'est-à-dire ce qu'on en fait ? Si je décides de mettre le nombre 4574 en mémoire, c'est à moi de gérer l'espace nécessaire ou si c'est le cpu qui s'en charge ?

Car en asm, comment s'assurer que la mémoire est libre ou non ?

En ASM pur, aucune gestion: le langage assembleur sert juste à s'y retrouver dans le binaire par l'utilisation de mnémoniques et à faire abstraction du format de l'exécutable (il y a un header que le compilateur rempli, des histoires d'import/export de dll etc.)

Donc en ASM pur, il n'y a aucune notion d'occupation de mémoire. Tu fais ce que tu veux avec l'ordinateur. Heureusement, le système d'exploitation est un garde-fous et, en limitant les opérations directes sur le hardware, il permet d'établir une convention pour utiliser la mémoire.

Voila.

[ToutEnMasm]

Salut,
Deux choses sont a distinguées.L'allocation de mémoire statique,en data, et l'allocation de mémoire dynamique pendant le déroulement du programme.
A la compilation tout est parfaitement défini en taille et l'éxécutable ne controle rien du tout,sauf si on gère les exceptions.
L'allocation de mémoire dynamique,elle,est controlé par le système,les API.
ToutEnMasm

[WO]

Désolé par avance pour la concision de ma réponse.

En ASM (comme pour le CPU) deux choses :

Une adresse et un contenu d’adresse (selon la largeur de bus).
C’est à toi de « découper » ce que tu lis dans une adresse.

Je situe mon contexte de travail : J'utilise pour faire de l’ASM RosAsm (http://www.rosasm.org/) et la syntaxe est simple à comprendre :

[LpMaVariable: B$ 0FF] Ici c'est une variable de taille Byte
[LpMaVariable: W$ 0FFFF] Ici c'est une variable de taille Word
[LpMaVariable: D$ 0FFFF_FFFF] Ici c'est une variable de taille DWord
[LpMaVariable: Q$ 0FFFF_FFFF_FFFF_FFFF] Ici c'est une variable de taille QWord
[LpMaVariable: F$ 3.14] Ici c'est une variable de taille DWord (float)
[LpMaVariable: R$ 3.14] Ici c'est une variable de taille QWord (réel)
[LpMaVariable: B$ 'Blabla' 0] Ici c'est une variable chaîne (ASCII (Bytes) + 0)

Tu peux accéder au pointeur par LpMaVariable par exemple :

mov esi LpMaVariable

Tu peux accéder au(x) contenu(s) de LpMaVariable en ajoutant un offset :

mov eax D$LpMaVariable+4 ( à toi de vérifier que tu as bien déclarée LpMaVariable en taille QWord…).

Idem pour une chaîne mov B$LpMaVariable+offset 0

En C++ quand tu fais +1 (pour une structure ou n’importe quel tableau) tu ajoutes à l’adresse de base la taille d’une structure d’un élément etc. En ASM tu dois tout vérifier toi-même (c’est beaucoup plus simple que tu crois !).

Tu parles de substitution de code (en C/C++ c’est une horreur, il n’y a que ça et c’est le prix de la soi-disant transparence et simplicité qui n’est en fait qu’un argument commercial pour vendre sans fin de soit disant nouveaux outils… J) certains ASM se prêtent même à cet affreux jeu : MASM (qui est en fait le compilateur des Visual gnangnan… ) par exemple. RosAsm ne fait aucune substitution de code, à moins que tu ne les définisses toi-même (y compris les Proc macros if etc..).
Voilà désolé d’être aussi succinct (certains hurleront.. Tant pis J).

@+

[Smortex]

en java si on dépasse la capacité il ne fera pas un overflow mais plutôt il va recommencer "à l'envers" je veux dire quand il arrive avec un int de 2 octets à 65536 il recommence à -256 au lieu de planter ou un truc du genre, alors qu'en C c'est différent.

Non, l'assembleur (et c'est paradoxale car c'est le language a eviter d'utiliser quand on peut en utiliser un autre) est le seul qui te permette de detecter des debordements d'entiers (flag overflow). Le fait que les langages de haut niveau ne fassent pas cette verification peut poser de graves problemes de securites (attaques par debordements d'entiers... bien moins evident a mettre en place qu'une attaque par debordement de chaine, et ne peut etre realise que dans des cas tres particulier et rares, mais existants).

En C++ quand tu fais +1 (pour une structure ou n’importe quel tableau) tu ajoutes à l’adresse de base la taille d’une structure d’un élément etc. En ASM tu dois tout vérifier toi-même (c’est beaucoup plus simple que tu crois !).

C'est le principe de base de l'arithmetique des pointeurs... Ca fait gagner un temps phenomenale, mais c'est facile a reproduire en assembleur...

Tu parles de substitution de code (en C/C++ c’est une horreur, il n’y a que ça et c’est le prix de la soi-disant transparence et simplicité qui n’est en fait qu’un argument commercial pour vendre sans fin de soit disant nouveaux outils… J)

Qui te permettent de developper des applications portables (manipulation d'une machine virtuelle) plus rapidement (la machine virtuelle est generique) des applications plus performantes (le compilateur optimise le code)... Il ne faut pas oublier pourquoi on fait de l'assembleur... c'est adapte a des projets, et pas a d'autres

[WO]

Facile à reproduire en ASM
ça fait gagner un temps phénoménal... ha oui ? tu as fait un benchmark ?
Il a sa propre logique qui ne faut surtout pas tirer vers d'autres inadaptées à son architecture (mais bon... c'est comme vouvoul)

Le compilateur optimise le code
D'ailleurs je ne code même plus ! Le compilateur est un truc magique écrit en Java certainement par une machine et pas par des tî gâs avec leurs neurones !

quand à la portabilité, elle est liée à un programme qui génère du code ASM, justement, compatible avec la machine cible

Et l'eternel argument : Rapidement...
Ne codons rien, ça ira encore plus vite !!!

l'assembleur (et c'est paradoxale car c'est le language a eviter d'utiliser quand on peut en utiliser un autre)

Et c'est un forum ASM
ça fait peur

bon Java...

Aux autres, courage, l'ASM est la fin (la compilation quel mauvais jeu de maux) de tous les autres et vous avez fait le bon choix !
bon code @+

[ToutEnMasm]

Bonjour,
Je cite WO

MASM (qui est en fait le compilateur des Visual gnangnan… )

Sont des propos rendant vite lassante la discussion,dommage
ToutEnMasm

[WO]

Il me semble que c'est gnian gnian qui pose problème... Vraiment ?!?

Explication pour "délasser" :

Je ne vais pas énumérer l'interminable liste des produits de la firme, et "gniangnian" sont les "maux apparemment" de substitution. Désolé, la prochaine fois je nommerais tous ces fabuleux produits hyper rapides et sophistiqués bien plus évolués que le code qu'ils génèrent grâce à leurs supers compilateurs !!! ( E.T. technologie, si si… écrits n’importe quoi, ça sera optimisé par le tout puissant COMPILE A TORS... cool… ET portable (comme les valises sous les yeux ) Ça, ça pourrait me rendre lassant...oui… effectivement…

Mais le propos reste fondé: MASM, est le compilateur de cette suite de produits. La fameuse firme "l'abandonne" même (des fois que l’open-source voudrait s’abriter à son ombre et revenir au bercail (cf. les C++ GNU), signe des temps et des profits liés, pour promouvoir des outils qui lui rapportent beaucoup plus et lui permettent de mieux protéger sa technologie et son noyau en maintenant tout le monde dans un flou juteux, très juteux…
Le plus amusant c'est que sur des forums ASM, justement, on soutienne cela avec une ferveur déplacée et incongrue en continuant à nous asséner des lieux communs sur L'ASM qui se résument tous à : Soyons sérieux, tout, mais pas l’assembleur (ou alors vraiment le minimum, vous savez, la pincé magique qui va faire que le code global va foncer !).

Il sont restés coincés à l’ASM 16 bits ces gars là ? Ou ils pensent que le C++ génère un meilleur assembleur ? Qu’on ne peut pas écrire simplement une interface avec les API win32 en ASM, aussi rapidement qu’en C++ et sans passer par la sacro-sainte protectrice MFC… Que la POO est l’apanage des seuls gniangnian (justement)… Ou l’argument n’est que la soit-disant vitesse pour sécréter des mégas de code opaque duquel on dit, sans l’avoir lu, qu’il est meilleur, optimisé voir parfait ! Le ridicule ne tuant pas, ils restent en vie...

Je sais que tu utilises MASM (comment j'ai pu comprendre ?) et que tu fais un énorme travail de promotion : Merci, merci encore ! Mais, si je comprends ta réaction (touche pas mon MASM), je penses néanmoins que tu te trompes de cible...

Pour ma part c'est ToutEnAsm je te fais grâce (pour une fois) de la pub pour mon outil préféré !

@+

[ToutEnMasm]

Salut,

Microsoft touche très bien a masm,le dernier fourni avec le VC++ est la version 7.10 et une version beta 8.00 circule sous le manteau.
Le VC++ sans Masm ?.
ToutEnMasm

[WO]

Salut,

La fameuse firme "l'abandonne" même (des fois que l’open-source voudrait s’abriter à son ombre et revenir au bercail (cf. les C++ GNU),

Les guillemets Yves, les guillemets !

Bien-sûr que croc$oft ne peut pas faire évoluer ses Visual GG sans toucher à l'ASM via MASM (ha bon, je croyais que c'était le C++ qui était le fondement de tout ça...) mais il l'abandonne sous une forme "pseudo libérée" qui continuera à servir leurs intérêts uniquement commerciaux (d’où référence au C++ GNU...): MicrosoftASM tout est dit.

Cet ASM reste orienté vers une implémentation liée à leurs outils Visual GG. Pour suivre MASM, ils le suivent... C'est sûr Ils sont pas idiots non-plus !

La question initiale était la substitution de code et, puisque nous sommes sur un forum ASM, je précisais que MASM n’est pas un modèle de transparence dans ce domaine

Au fait, il est écrit en quoi MASM ?

Bon code
@+

[ToutEnMasm]

Le dernier abandon de microsoft http://xdev.co.nz/vsip2003/
ToutEnMasm

[WO]

Merci Yves,
mais j’ai déjà donné :lol

This software is free for all use... Microsoft free... cherchez l'erreur
Et le plus Update: 18 Oct 2005 (nous somme le 17 octobre, ils sont très très forts...)

Qu'ils sont gentils chez M$ quand-même, bientôt le source et ils nous payeront même pour l'utiliser, il n'y aura plus d'include de lib de macros en C… et tout sera accessible... super et puis ils développent gratuitement maintenant… vraiment quel désintéressement… Bienvenue dans un monde meilleur (non.. zut… c’est déjà pris…)

Avec un peu de chance nous pourrons récupérer aussi le DDK gratuit et la réouverture des pages (DDK) de sites comme OSR.Online, et puis Kernel sera "véritablement" documenté et il sera possible de faire des softs sans leur payer de redevance ni obligation tacite d’utiliser leurs outils devenus incontournables…

Donc, toujours d'actualité: La fameuse firme "l'abandonne" même (des fois que l’open-source voudrait s’abriter à son ombre et revenir au bercail (cf. les C++ GNU), signe des temps et des profits liés, pour promouvoir des outils qui lui rapportent beaucoup plus et lui permettent de mieux protéger sa technologie et son noyau en maintenant tout le monde dans un flou juteux, très juteux…

Ils essaient de nous faire croire que MASM est libre ? Qu'ils sont gentils, un peu comme les PS2 quoi Tu paies juste les jeux… et l'abonnement.. et les MAJ... et... sinon tu peux pas bosser ?

Le fait "d'abandonner" MASM, comme s'il s’agissait d’une sorte d’Open source, ça fait très mode mais ce n'est qu'une tentative de récupération des véritables outils Open source (suis-je plus clair ? A moins que tu penses qu’ils en restent qui ne sachent pas que MASM un produit M$ maintenu par eux, puisque c'est la BASE de toute leur artillerie !!! )

Mais tout ça ne nous éclaire pas sur l’opacité liée à la substitution de code, ni même son intérêt…

AsmCode :

Alors au final une variable n'est qu'une adresse mémoire (ça je le savais déjà) mais qui est géré par des routines inclus à notre insu dans nos exe.

Est-ce qu'il y a autre chose qui est inclus à part cela ?

Un paquet que tu n’oses même pas imaginer !
Regarde (vraiment) sous le capot…

Bon code
@+

[Smortex]

Facile à reproduire en ASM
ça fait gagner un temps phénoménal... ha oui ? tu as fait un benchmark ?

Je parle de temps de developpement (c'est pas explicite ? "reproduire")

Le compilateur optimise le code
D'ailleurs je ne code même plus ! Le compilateur est un truc magique écrit en Java certainement par une machine et pas par des tî gâs avec leurs neurones !

L'optimisation de code fait appel a des notions complexes de representation des donnees pour leur transformations et leur retransformation en code compilable, tout en tenant compte des specificites de l'architecture de destination. Ca fait une quantite de choses telle qu'un etre humain normalement constitue ne peut penser a tout (ni meme tout connaitre), et de nombreuses etudes vont encore dans ce sens (l'optimisation de code est un sujet qui a de l'avenir).

Si tu veux te documenter je te recommande :
http://www.prism.uvsq.fr/~cedb/index_fr.html (Chunky, un optimiseur de localite de donnees)
http://www.prism.uvsq.fr/~cedb/bastools/cloog_fr.html (CLooG, le generateur de code de Chunky)
http://smortex.developpez.com/?tex=cloog (Une des options de CLooG en cours de developpement)

quand à la portabilité, elle est liée à un programme qui génère du code ASM, justement, compatible avec la machine cible

L'interet est que le code binaire non portable est genere de maniere automatise en fonction d'un code qui l'est. Porter un code assembleur sur une autre architecture consiste a reecrire le rpogramme, dans les autres langages il suffit de recompiler sur l'autre architecture en question (voir faire du cross-compiling)

Et l'eternel argument : Rapidement...
Ne codons rien, ça ira encore plus vite !!!

Si tu veux faire un programme qui affiche Hello World et qui fonctionne sur PC sous Windows, Linux i386, FreeBSD, Mac OS et 68HC11 avec un afficheur LCD... Tu as le choix, faire 5 programmes differents en assembleur de quelques dizaine de lignes ou un seul en C de 4 lignes... Prouve moi qui l'assembleur est un meilleur choix que le C...

l'assembleur (et c'est paradoxale car c'est le language a eviter d'utiliser quand on peut en utiliser un autre)

Et c'est un forum ASM
ça fait peur

Certes, mais tout depends de ce que tu fais, cf ci-dessus.

Aux autres, courage, l'ASM est la fin (la compilation quel mauvais jeu de maux) de tous les autres et vous avez fait le bon choix !
bon code @+

Pour en etre sur...

[WO]

C'est la fête 8)

Temps 1 : Le temps de dev n'est pas la question posée mais la substitution, mais bon... soyons bon camarade de jeux :
Borland et ses outils glissé déposé... le copier collé en basic ça va vite aussi ça tente quelqu’un ? En plus, pas de risque(s), c’est super optimisé grâce au compilo super intelligent qui pense à tout (prenez-nous pour des trompettes (arf))
Je maintiens, reproduire une forme ne présente que peu (pas) d'intérêt. Maintenant si tu veux faire de la POO en ASM, comme tu le sens : C'est cool et possible. (en fait, pour ceux qui sont pressés : Le temps c’est de l’argent ! (c’est en fait la seule base de cet argument qui ne répond en rien au premier post)

Optimisation : Le C++ (et c’est pas le pire loin s’en faut) génère du code de plus en plus impossible à optimiser. Ah, le portage.. vous savez ce truc... ce code tellement générique que c’est une horreur de généralité… optimisée… donc… optimisable bien-sûr.. mais c’est très très complexe à expliquer.. je comprends que ça soit complexe… ça tousse drôlement même (arf)) Je ne parle pas des optimisations millimétrées (possible qu’en ASM n’importe comment, et on y renonce souvent, tellement c’est du machinage de Mosquito EN RAPPORT AVEC LE SUJET QUE TU ABORDES (je te remercie pour la doc, c’est très aimable, mais j’ai déjà un tout petit peu lu sur le sujet (arf) En passant, utiliser SSE3 / MMX quand ils sont présents sur une machine c’est pas de l’optimisation -> c’est du bon sens : Pas besoin de supercompilator pour super penser à ça… ). Le simple fait que le compilateur ne comprenne pas vraiment l’architecture alambiquée du code généré par du C++ (donc le codeur qui alambic par-dessus en disant : l’important c’est de bien connaître son compilo (arf)) fait qu’il est déjà hors course.. Pas besoin de m’étaler plus, tellement c’est hurlant. Désassemble du super code super portable en C++ super assemblé par $ASM , même du VC… c’est sûr que c’est optimisé aux petits oignons (tu retrouves la MFC dans tous les appels pour appeler les api win32 ouais cool…. C’est complexe…comme tu dis.. je te passe les chargements déchargements de variables à tour de bras…), t’as raison l’ASM (en fait le pôvre codeur) peut pas lutter (re arf)) Je sors d’un portage VC / ASM, tu m’as convaincu, c’est sûr !

Portabilité : Sur terre je n’ai jamais vu de portage sérieux comme tu le racontes… c’est bô…
Tu devrais offrir tes encouragements à.. tiens.. Bull par exemple… La plupart du temps ça re-écrit dur dans les foyers et ça gueule un peu partout… Ils seraient contents de t’écouter (faudrait simplement que ça marche en vrai.. tu vois…juste ce petit détail qu’on lit pas dans les livres (arf) enfin le sujet de base est loin… (substitution quand tu nous tiens)

Prouve-moi : C’est ton problème, trouves les solutions que tu veux…
Faire du Z80 en C++ tu crois que ça tiendrais... ? (un peu débile ma question (arf))

Donc -> On obtient le maximum de résultats en s’enmerdant au maximum, toute économie entraînant immanquablement une perte à court ou moyen termes (Loi de D Small Article 1 un tî gâ qui a un peu pratiqué…). Je trouve ça limpide. Maintenant faire du pognon rapidement avec un peu de bagout… Tu peux faire ça en C# (tiens pour jeter une autre quille… vous sentez pas obligé de jouer avec… y’en a déjà pas mal et ça part déjà bien en bâton de sucette (arf)) Nan, jrigole… On travaille tous pour le fun (arf arf arf)

Temps 2 : Quant au temps de dev je ne suis vraiment pas convaincu non plus: Les outils ASM ont aussi largement évolués que les autres... Yves (ToutEnMasm), par exemple, à fait un travail intéressant là dessus. De toute façon le temps de dev n'est pas vraiment un argument justifiant l'opacité et la substitution de code (qui est quand même la question amusée du premier post… ouf….)

Bon code
@+

PS: Les (arf) c'est pour les smilies que j'ai pas eu le courage de coller (pfut.. même pas po(r)table ni optimisé mon truc)