Reprise du message précédent :

 
Dsl mais c'est n'importe quoi ce que tu dis là. Ce n'est absolument pas plus facile en assembleur de trouver un bug dans ce cas que avec du C. Je ne comprend même pas comment tu peux affirmer ça. Si au moins tu essayais de te justifier et d'expliquer mieux que ça au lieu de balancer des affirmations sans fondement.

bah avec un debuggueur, si tu descends au niveau instruction d'un code issu d'un compilo C/C++, oui tu peux avoir plus de mal à retrouver tes petits, que si tu avais écrit toi même l'asm.
 
mais c'est un peu défoncer une porte ouverte.
 
de plus les problèmes d'appel/retour, ça n'existe plus tellement quand même.

ptain j'aime l'assembleur, j'aime réinventer la roue et je l'assume, mais franchement, tu trouves peut-être plus facile de débugguer en assembleur, mais c'est TON cas uniquement, faudrait voir à pas généraliser
 
purée dire que c'est plus facile à débugguer en assembleur
faut oser

justifier quoi?, j'ai ete assez clair
mais bon tu as l'air d'avoir du mal a maitriser la langue francaise, alors je vais t'expliquer d'une autre façon
 
quand j'ai un programme que j'ai ecrit de A à Z, j'ai quand meme plus de facilité pour savoir ce qui ne marche pas, que si je passe par un module dont je n'ai pas la maitrise
 
si tu veux un exemple
solution A: je fais un moteur de base de données
soluton B: j'utilise les lib mysql
je fait un prog de gestion qui utilise une base de données: sur une recherche d'index, mon prog me donne une mauvaise valeur
certainement que j'i un bug dans ma requette, mais j'aurais moins de pb a trouver mon bug si je peut entrer dans le moteur de la base (solution A), car je verrais de suite ou jai fait une erreur, dans la solution B, je serais obligé de faire des hypotheses, de modifier ma requette jusqu'a ce que ca marche, bref je risque meme de reussir a reparer sans meme savoir pourquoi ca marche, ce qui est le pire du debuggage
 
toi y en avoir compris cette fois??

Les compilos Lisp d'aujourd'hui donnent des résultats honorables, souvent dans un facteur 2 ou moins par rapport au C++, plus rien à voir avec les vieux Lisp.

je te crois sur parole, c'est vrai que le potentiel du lisp est suffisament fort pour esperer une evolution dans le bon sens
quand je me rappel des premieres machines lisp, c'etait impressionnant l'avance qu'elles avaient a l'epoque, au point qu'aujourd'hui elles sembleraient banales

 
Ce n'est absolument pas un argument pour prouver que l'ASM c'est plus facile à deboguer que le C. Ceci est un argument pour prouver que c'est plus facile de deboguer du code quand on dispose des sources de toutes les libs que l'on utilise. Et encore, l'intention première était de prouver que c'est plus facile de deboguer quand on a tout écrit nous même.
 
Encore une fois tu tapes completement à coté de la plaque.

(et moi j'attends toujours ma vérité )

as tu bien désassemblé a partir de la bonne adresse?
sinon ca va tout decallé?
ton desassembleur est il a jour ?

 
moi je trouve ca plus simple en effet en assembleur mais uniquement dans un environnement simple style dos. j'utilisais le turbo debugger de borland a tout va a l'epoque et trouvait les erreurs en 10 s
en c , les pbs de syntaxes sont extremement difficile a trouver (manque une parenthese, etc..) et un coup de turbo debugger et on savait direct ou ca allait pas.
 
dans un systeme multitache ou ton programme depend d'autres programmes et de librairies en tt genre alors la le debuggage en assembleur devient de plus en plus difficile car c'est plus uniquement son travail et ca devient aussi flou qu'un debuggage classique.
au moins on savait pourquoi y avait des memory leaks a l'epoque, maintenant pour les trouver parfois.....

 
je suis d'accord avec toi, c'etait vraiment simple de debugger a l'epoque, un petit jump juste avant que ca plante, on regardait les registres et on se disait, ah bah voila.
le temps economisé par rapport aux bugs d'ajourd'hui ou tu as des memory leaks et tu mets 3 h a les resoudre , des libs microsoft qui deconne de telle ou telle facon enfin c'etait le bon temps.

les instructions 32 bits sont compatibles sur un  amd 64, je vois pas le pb.
un mov eax,edx marchera toujours sur un amd 64 , sinon plus aucune compatibilité entre amd ou un pc IBM et compatible.
 
la seule chose qui est genante c'est quand AMD et INTEL font des instructions incompatibles , dans ce cas il faut ecrire un code pour amd et un code pour intel mais de tte facon ca a tjs existé, on faisait du code optimisé pour 486, du code optimisé pour pentium, ensuite mmx, etc...
 
 

ca t'amuse de ressortir des threads pareil 2 mois après leur mort?
 
(surtout si c'est pour ne pas être capable d'éditer un post ou de tout poster en même temps )

ah nan pas encore ce topic
 
(et en plus si c'est pour melanger erreur de syntaxe et debugging, on est pas couché )

cela dit j'attends toujours ma vérité

 
1) premierement, rien ne t'oblige de lire
2) ca va les chevilles?  
3) et toi es tu capable de repondre poliment stp

 
Le .NET est un langage compilé
Simplement Microsoft a introduit la notion de MSIL afin de rendre les executables cross-platform    
En effet les executables .NET sont chargés en mémoire avec le framework puis compilé par ce dernier, avant d'etre execute  

 
je crois que tu nous as appris qqchose la
cela dit il existe des interpreteurs .net  
donc voila

 
Et oui j'ai etais voir une conférence Microsoft sur le .NET pendant 1 journée entiere    
Et j'ai posé quelques questions genre "on peut dump un exe .NET en mémoire ?"  "oui on peut théoriquement vu que le framework .NET se contente de compiler (sous entendu en asm x86) votre code MSIL en mémoire puis l'execute"
 
 

haha