Reprise du message précédent :

pour moi pas de pb, je l'ai deja dit, je n'ai pas envie de polemiquer mais de debattre

 
Tu sais, plus tu te donnes du mal pour ne pas répondre a ma question, plus ta crédibilité chutte. Je fais expres d'etre lourd (et m'en excuse aupres des autres), mais devant ton comportement il me semble qu'il faille sortir l'artillerie lourde
 
Qu'est ce que la Vérité censé me faire sentir con ?  
 
Pourquoi ne reponds tu pas ? As tu peur de quelque chose ? Ne me dis pas que tu ne veux pas pourrir le topic, c'est encore moins crédible que le reste de tes affirmations, c'est juste une manoeuvre dilatoire absolument ridicule
 
 
 

non je le pense pas, je te connais pas.
je trouve dommage de balancer du code et une 'verite' comme ca, sans justification, et ca aurait pu m'instruire au passage

je suis pas responsable des autres, et je ne suis pas concerne par cette phrase. je demande juste des explications pour me coucher moins bete

surtout que la programmation est quelque chose de tres personnel, pour ne pas dire "artistique" dans le sens creatif du terme, donc demander a un compilo de savoir trascrire au mieux les etats d'ames des programmeurs reste une belle gageure

J'ai également pu remarquer une certaine stabilité (dans la performance) du compilateur DJGCC quelque soit le type de machine. Alors que VisualC est plus "variable".

c'est tout simplement qu'il est parti a 100km/h sur des theories fumeuses alors qu'au depart, il y avait un bug, et que le code generé a ete faussé par le bug
 
sujet clot! pour ce point

je n'ai pas en m'en plaindre pour l'utilisation que j'en fais  

.
c'est pas son but aussi

C'est envisagé dans les théories de compilation.
Mais il faut une forme d'intelligence artificielle.

oui mais on ne risque pas le pire??
je me rappel des machines lisp et de ce qu'elles generaient, c'etait moins bon qu'un ptit prog en basic

Je fais souvent le parallèle avec la compression.
Il y a pas mal d'années se battait lha, arj, zip et rar.
C'est également une forme d'intelligence (très limité c'est sûr).
C'est un des principes de Shannon-Fano : En se basant sur le passé, on peut prédire le futur avec plus ou moins d'exactitude.

ceci dit, c'est vrai que le code generé par vs c'est pas mal quand meme, j'ai vu a pliseurs reprises, du code bien mieux optimisé que ce qu'on fait soi-meme en assembleur
le seul pb c'est qu'un compilo ne fait qu'optimiser un codage typique du C, alors qu'un programmeur en assembleur fera deja une structure differente
 regarde par exemple l'utilisation des "case" pour la gestion des messages windows, en assembleur on passe par une table indexée, alors que le c risque de generer des tests a foison avec branchement en chaine

T'as testé le compilateur de Watcom ? Je serais curieux de voir ce qu'il donne sur les exemples de ce topic

oui c'est sur
par contre j'ai peur que le coté subjectif de la programmation empechera tj une bonne optimisation, ou alors il faudra que tous le sprogrammeurs travaillent de la meme façon
remarque avec .net c'est visiblement la tendance a l'uniformaisation

Harkonen> Pas testé Watcom.
En fait dans la plupart des cas je prévoit lors du développement les routines à optimiser en ASM et le reste sera codé en C.
Pour moi (personnellement), l'optimisation du code par le compilateur, je ne l'utilise jamais. Les logiciels vendus sont toujours compilés en mode Debug. En cas de problème, c'est plus simple à gérer.
Si le logiciel est lent, c'est qu'il est mal conçu ou pas adapter au matériel.
PS:Je fait des prog pour les écoles. Même dans leurs rêves, ils n'ont pas nos machines.

tu bosses à ton compte, ou pour un éditeur ?

Harkonnen> Pour un éditeur.
 
Qui pense que la programmation asm (optimisé) sera de plus en plus réservée à une élite ?
Si bien que ce seront les compilateurs qui feront tout le boulot.
 
Up> Je dis ça car je ne vois plus de publication ASM. J'ai l'amère impression que programmer de nos jours se résumes à écrire ce mot sur un CV, faire des sites, et "pisser" des lignes de code.

moi je le pense
 
et surtout ca sera la seule solution pour pouvoir sortir du moule "crosoft" et de ses interfaces hyper standardisées et hyper controlées
demain si tu veux faire un prog pour ignares en informatique, il faut que tu repense l'interface homme/machine, et là tu sera obligé de programmer autrement

c'est deja le cas je trouve

Peut-être mais je vois pas mal de débutants sur les forums.
 
Et ça, qu'en pensez-vous ?

Personnellement, je pense malheureusement que l'asm est voué à disparaitre (au moins sous Windows).
Si tu regardes les tendances, tu vois quoi ? .NET et Java principalement. Tous les nouveaux langages développés reposent sur des VM (Python, C#, etc...), très peu de langages compilés.
La disparition prochaine de l'API Win32 au profit de .NET sonnera à mon avis le glas de l'assembleur "pur", j'entends par là l'assembleur du processeur lui même. Il restera plus qu'à optimiser de l'IL ou du Bytecode, mais c'est tout. On n'aura aucun controle sur le désassemblage lui même.
C'est ça qui me fait peur. Personnellement, je fais de l'assembleur depuis 1993, et je t'avoue franchement que cette perspective me fait bien chier.
Sinon, je pense que ceux qui optimisent leurs programmes direct en assembleur aujourd'hui seront ceux qui optimiseront leur IL/Bytecode demain. C'est à dire une frange très petite des programmeurs (pas forcément l'élite).

le bp c'est que programmer en assembleur, c'est une autre façon de penser, d'architecturer son prog
avant c'etait plus naturel dans la mesure ou le lien entre hard et soft etait tres etroit, et le mec programmait en assembleur comme il concevait sa carte,
aujourdhui on est "pollué" par la methodologie propre au monde windows, et donc on en realise pas la difficulté a bien programmer en assembleur

c'est vrai en grande partie, ce que tu dis
par contre cela suppose aussi que les futurs outils soient complets
aujourd'hui l'utilisation de l'assembleur est necessité par le besoin d'un prog qu'on ne peut pas faire autrement, e quand tu vois .net, il ne resout pas tout
si je prends l'exemple que je connais le mieux, piloter des automates dans un process avec .net c'est de la folie

Ce qui me ferait vraiment mal c'est qu'on en vienne à programmer en Java dans les µContrôleur. Déjà que beaucoup utilisent les compilateurs gcc (c'est un peu normal selon la complexité du projet).
 
J'ai toujours vu l'assembleur comme un lien direct avec la machine, le seul hic, et cela devient vraiment difficile c'est de mettre la main sur les docs officielles des périphériques externes (bus, cartes...).
 
On s'éloigne peut-être un peu non ?

prorel+harkonnen> J'ai acheté il y a quelques mois un écran Samsung 193P. Super écran, mais leur utilitaire ne fonctionne pas sur ma machine. C'est sûr, c'est pas du C. On dirait un espèce de .NET / Director / Java.
Enfin un truc qui repose sur une interface toute faite.
 
Dans le même esprit, le Catalyst Control Center (30Mo) demande .NET FrameWork. Super mais le même prog en C pèse 1Mo max.

pour aller dans ton sens, avec les windows anciens (jusqu'a 98), on pouvait piloter les e/s directement, et maintenant depuis win2k, on est obligé de passer par le driver constructeur, et on se paye souvent les bugs ou les defauts d'utilisation

prorel> et quelle gageure mais quelque part, je trouve que c'est dans la logique d'un os de contrôler ce qui se passe.
 
Bon appétit, A+

 
D'accord mais est-ce vraiment pour ça qu'il doit t'empêcher de le faire si tu en as envie ???

c'est vrai, et je crains que ca devienne une mode, voir pire, pour nous obliger a passer sous .net
je n'ai pas chargé la nouvelle version ATI, a cause de ca!
bon appetit a tous aussi
A+

Mr Mala> Bien sûr que c'est pour ça !
Sinon comment le système peut assurer sa propre stabilité si les programmes peuvent le faire planter ou le manipuler ?

 
Bien sur qu'il doit l'en empecher. Si tu veux taper directement sur le materiel tu écris un drivers. Un des buts d'un OS bien fait est de faire marcher correctement la machine. L'autre jour sur le topic de Doom 3 il y a des gens qui disaient attendre un patch pour corriger un bug de Doom 3 qui fait rebooter leur machine. Si je ne savais pas que Windows empèche ce genre de choses, je ne pourrais pas leur dire que c'est de la faute de leur drivers ou de leur hardware. C'est une question de confiance.
 
Après, il y a le problème de la perenité du code que nous écrivons. Coder tout directement en ASM en tapant directement sur de l'hardware c'est un bon moyen d'écrire du code qu'il faudra jeter après le prochain changement majeur de système. Que ce soit une nouvelle version d'un OS ou une nouvelle archi CPU ou tout simplement du nouvel hardware.

Kristoph> Je pense qu'il ne faut pas tout confondre; je m'explique :
Dans un logiciel on peut très bien faire du code ASM sans que cela pose de problème sous 95, 98, NT, XP...
Il faut simplement éviter d'utiliser certaines instructions (in, out, cli, sti, registres cr...).
Dans 99% des cas, le code écrit ne posera jamais de problème.
L'asm n'est qu'une écriture différente d'un code pouvait être écrit en C, Java... En partant de ce principe, en langage de haut niveau, si on souhaite accéder à un périphérique, on utilise le driver ou librairie approprié.

Bien merci, j'ai ma réponse ...

 
Pour l'instant oui, mais il reste que le code n'est pas portable entre plusieurs archi differentes. Que feras tu le jour ou les PC changerons completement d'archi ? La transformation se prépare déjà avec les Athlon64. Bien sur, du code C n'est pas forcement beaucoup plus portable mais le fait est que :
- Il est possible d'écrire du code C portable sans avoir à tout réécrire ce qui n'est pas le cas pour de l'assembleur normal
- Tout le code que tu n'auras pas pris explicitement le temps d'optimiser en ASM sera plus lent que le code C compilé. Et même de nos jours il faut se battre pour produire du code ASM plus performant que ce que fait un compilater.
- 90% du temps d'execution est passé dans 10% du code. C'est ce code là qu'il faut optimiser. Tout le reste doit être écris le plus vite possible et donc sans optim. Le reste tu le réécris en assembleur si tu veux après le passage du profiler.
 
J'avais bien aimé l'époque ou je codais mes projets en assembleur ( forcement, sur CPC il n'y avais pas trop le choix, mais même là, je fesais en général des fonctions assembleur que j'appelais depuis le Basic ) mais il faut admettre que de nos jours, pour la perenité du code que l'on produit et pour les perfs que l'on en attend, il n'est pas rentable d'écrire tout en ASM
 
 
 
 
Pour la petite info par contre, je vous annonce la sortie imminente en france de "Chris Sawyer's Locomotion" qui est sans aucun doute le dernier grand projet écrit entièrement ( ou presque ) en assembleur. Chris Sawyer a qui l'on doit déjà sur PC et en ASM :
- Roller Coaster Tycoon 1 et 2
- Transport Tycoon Deluxe ou non
- Elite 2 et 3 ( et oui, c'est lui qui avait fait le portage PC de ces jeux )
 
Comme quoi il est encore possible de faire de l'ASM pour des projets somme toute très complexes

Kristoph> Je sens dans tes phrases des traces d'un certain Michael Abrash... Surtout pour le 90% / 10%
 
C'est le rôle de l'analyse de déterminer quelle seront les sections critiques.
http://forum.hardware.fr/hardwaref [...] tm#t846268

l'assembleur est certainement plus portable qu'on ne le croit, le pb vient plus de la façon de programmer que du langage lui-meme

le contre-exemple le plus flagrant est le passage au .net, et surtout si tu est en vb
et si tu as bien fait ton programme en assembleur, tu n'as pas de raison de tout re-ecrire simplement parceque tu change de version de windows, et puis il ne faut pas oublier que programmer en assembleur ne t'interdit pas d'utiliser des drivers constructeurs, donc en cas de changement de hard, tu fait comme avec le c, si tes drivers sont compatible, c'est immediat, sinon ben tu refait le module
 

ca c'est l'eternel lieu commun qui est utilisé pour faire croire a la superiorité du C sur l'ASM, en fait c'est archi faux, il ne faut pas comparer le code produit pour une fonction mais tout le code generé, ainsi que l'emploi de lib, si on compare deux progs du point de vue taille et temps d'execution, y a pas photo l'asm sera tj plus petit et plus rapide
biensur que si on compare juste une partir du code, le c fera souvent mieux qu'un programmeur asm, mais deja le programmeur ne fera pas son prog de la meme façon, ensuite il ne passera pas par les meme parametres entre modules, il utilisera plus souvent les registres et plus intelligemment, etc
si on prend l'exemple que j'ai donné un peu plus haut, on en fera pas le meme programme en c et en assembleur (demande a chris_d13), et en final, le prog asm sera plus petit, et plus rapide, et plus le code est gros plus la difference est visible
puisque tu parle des "tycoon", essaye d'imaginer la taille du meme prog s'il etait ecrit 100% en C

encore un lieu commun, tu n'as pas la meme structure de programme en C et en Assembleur, pour une meme appli, donc vouloir simplement optimiser un bout de code, c'est utiliser l'assembleur dans une structure en C, ce qui est le pire (utiliser les defauts de chacun sans en garder les avantages)

là encore rien n'est prouvé, il ne faut pas oublier qu'on passe plus de temps a "debugguer" un programme qu'a l'ecrire, et le temps de mise au point en assembleur est bien plus rapide qu'avec un langage plus evolué, pour la simple raison que le bug est visible sur le champs (erreur de registre, mauvaise adresse, etc) alors qu'avec un langage plus evolué il y a tj une part d'inconnu (librairy, dll, etc) non gerable, ou on ne peut travailler que par hypothese, par exemple on sait tres bien qu'une dll marche mais on ne sait pas pourquoi une valeur "a" revient en "b"  
de plus il ne faut pas comparer l'assembleur ancien du cpc, avec les outils actuels, genr fasm, ou visual_asm

Je suis plus ou moins d'accord :
Pour ma part, quand j'écris du code asm, c'est après avoir fait une analyse poussée, gain théorique, avantages, inconvénients... Tout cela pèse sur le temps de développement d'une application.
Donc je considère qu'un code asm ne doit être présent que s'il apporte vraiment un plus. Sinon, cela n'a aucun interêt. Mais attention, qui dit plus, dit également recherche du meilleur algo, pas seulement le meilleur codage asm.
On peut comparer ça avec quelque chose de très connu :
Dans la majorité des cas, quel est l'intérêt de vouloir implémenter un tri à bulle en asm, alors qu'un quick-sort ou qu'un tri par huffman sera bien plus rapide et simplement en c.
On attaque là l'épineuse question de la recherche du meilleur algo (même s'il y a toujours mieux). L'asm peut être un plus, mais pas dans tous les cas.
 
Dans tous les posts que je viens de lire, personne ne parle d'analyse. Or c'est ça qui détermine ou non l'emploi de tel ou tel langage. Pourquoi je dis ça ?
Car je débugge de moins en moins. Et que je passe plus de 50% de mon temps avec un papier et un crayon. Au final, j'écrit souvent le code sur papier (les parties critiques) et je corrige avant pour gagner du temps.

c'est evident que l'analyse est primordiale surtout avec l'ASM
pour le reste je suis d'accord avec toi

 
Encore une fois, tu limites la complexité des problèmes puis tu dis que l'assembleur est suffisant.
Moi je parle de cas réels. Passe ton code assembleur sur archi A64 en mode 64bits et on n'en reparle.
 
Prétendre que l'asm est plus facile à deboguer parce que l'on ne fais pas confiance à des lib externes est la plus grosse ineptie que j'aie vue depuis bien longtemps. C'est grace à des trucs pareils que Locomotion utilise des fichiers wav non compressé pour ses musiques alors qu'il est super facile d'utiliser la lib ogg pour décompresser des musiques. La réutilisabilité du code, tu connais ? Ne pas réinventer la roue à chaque fois ça te dis qq chose ?
 
Il faudra trouver de meilleurs arguments pour prétendre que l'ASM c'est plus facile à deboguer que du C ou que tout autre langage haut niveau.

C'est hélas un problème récurrent. D'où l'intérêt d'une analyse prenant en compte la complexisté du développement en intégrant un planning.

c'est quand meme fou cette incapacité que vous avez tous a ne pas savoir lire un post, et apartir a fond dans les hypotheses delirantes, parceque vous avez cru comprendre qq chose
je n'ai jamais dit que je ne faisais pas confiance aux librairies, je disait simplement qu'on ne sait pas ce qu'elles font (on part du principe que ces librairies marchent) et quand tu envoi "a" que tu recoit "b" alors que tu attend "c", c'est forcement que tu a un bug chez toi, mais pour le trouver c'est plus dur qu'en assembleur ou tu t'appercoit de suite que ce n'est pas le bon registre que tu renvoi, ou un flag du status qui est mal positionné
c'est tout, n'allez pas interpreter ce que je n'ai pas ecrit!
donc voila un exemple ou on peut se rendre compte que le debuggage est plus facile en asm qu'en "c"
 
quand au fait de ne pas re-inventer la roue, c'est d'une banalité affligeante
par contre ta roue risque d'etre inutile si tu veut naviguer sur l'eau, et il te faudra bien re-inventer uen autre roue (une roue a aube par exemple)
on fait un programme en fonction des besoins, et non en fonction des libraires qu'on a sur son disque

 
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.