Discussion :

[DegubError]

le segment pour la carte video est de tout façon de 64K pour n'importe quel des 2 modes parce que sur ce segment tu ne pointe pas dans la ram mais directement dans la carte graphique.

Pour utiliser toute la ram video à l'époque du DOS (je ne parlerais pas d'AGP qui est un autre moyen) cela fonctionne comme EMS ou XMS il s'agit d'1 segment de 64K qui est une fenêtre sur tout la ram, fenêtre que tu peux ensuite déplacer dans la ram

je m'explique, sur le segment A0000:0000/FFFF tu n'as que 64K de data. Cette adresse ne pointe pas sur la ram mais directement sur la ram de la carte vidéo. Imaginons que ta carte a 192K de ram video (bon je sais aujourd'hui ça parait ridicule mais bon) tu ne pourras donc adresser (avec ce segment) que le 1er 64K de la ram video, donc si tu veux adresser le 2nd segment de mémoire (à savoir entre 64K et 128K) tu dois utiliser une commande sur la carte qui déplace le pointeur, ainsi si tu positionne ce pointeur sur le 2nd 64Ko, en A0000:00000 -> FFFFF tu pointeras sur le 2nd segment de ta carte video (c'est le même principe pour EMS/XMS, sur un segment en dessous des 1Mo adressable en 20bits tu peux adresser par fenêtre de 64K sur toute la ram adressable en 32, en déplacant cette fenêtre)

Il faut savoir aussi qu'à l'époque tout n'était pas normé, VESA a amené un semblant de norme mais pas totalement.

(il savoir que toutes ces contraitnes viennent du fait que les ingénieurs qui ont pensé à tout ça, ne pensaient pas qu'on aurait besoin d'autant de data) (pour anecdote également à l'origine l'adresse était sur 16 bits donc 64K de ram adressable, les ingénieurs de l'époque ne pensait même pas comment on pouvait utiliser autant de ram ce n'est que plus tard que l'on est passer sur 20bits donc 1Mo d'où la notion de segment:offset, cela explique en parti cette segmentation dans la ram)

j'espère que j'ai été assez clair

[Jean-Marc.Bourguet]

(il savoir que toutes ces contraitnes viennent du fait que les ingénieurs qui ont pensé à tout ça, ne pensaient pas qu'on aurait besoin d'autant de data) (pour anecdote également à l'origine l'adresse était sur 16 bits donc 64K de ram adressable, les ingénieurs de l'époque ne pensait même pas comment on pouvait utiliser autant de ram ce n'est que plus tard que l'on est passer sur 20bits donc 1Mo d'où la notion de segment:offset, cela explique en parti cette segmentation dans la ram)

Quelle origine? Si les microprocesseurs des années 70 n'avaient que 16 bits d'adresse ce n'est pas parce qu'on ne savait pas que ça serait vraissemblablement insuffisant pour le futur (l'IBM 360 était déjà un 32 bits avec 24 bits d'adresse et le 370 introduit en 1970 avait 31 bits d'adresse; les mainframes et les mini étaient déjà passé par là et on savait déjà qu'un problème récurrent des architectures, c'était le manque de bits d'adresse) mais parce que c'était ce qu'il était possible de faire en tenant compte des contraintes.

On savait aussi dés son introduction que les 20 bits d'adresses du 8086 étaient insuffisant, mais pour Intel le processeur qui devait adresser le marché où c'était insuffisant, c'était l'IAPX 432. Le marché du 8086 était ceux qui étaient limités par le 8080 mais avaient investi dans ce processeur. Bon le choix d'IBM d'utiliser le 8088 pour ses PC a fait que la compatibilité avec est devenu un facteur important (l'iAPX 432 avait déjà suffisemment de problèmes sans cela) et donc on utilise donc des processeurs 64 bits conçus pour être compatible avec un processeur 32 bits conçu pour être compatible avec un processeur 16 bits conçu pour être compatible avec un processeur 8 bits.

[DegubError]

l'origine si j'ai bon souvenir : la bible PC je crois bien (1er édition) et dans un autre bouquin d'assembleur.

l'architecture 31 bits dont tu parles n'est apparue qu'en 1982 avec l'architecture 370-XA soit bien après la sorti du 8086 en 16 bits. Et l'ibm 360 était un 20 bits d'adresses qui a était étendu sur 24 par la suite.
En plus, les gros système de l'époque avaient rarement plus d'1Mo physique(ce qui était énorme pour l'époque vu le prix de celle-ci) d'autant plus que les séries d'IBM utilisaient déjà la virtual mémory.

Je pense aussi que le marché des microprocesseurs n'avaient pas le même but que celui des gros systèmes. C'est pourquoi dans le livre il parle qu'à la conception (donc bien avant la mise sur le marché) 16 bits leur paraissaient énorme pour le marché auxquel il était destiné.

[Jean-Marc.Bourguet]

l'origine si j'ai bon souvenir : la bible PC je crois bien (1er édition) et dans un autre bouquin d'assembleur.

Je voulais savoir si tu pensais qu'il y avait eu un predecesseur 16 bits au 8086 qui n'avait que 16 bits d'adresse. Il n'y en a pas eu.

l'architecture 31 bits dont tu parles n'est apparue qu'en 1982 avec l'architecture 370-XA soit bien après la sorti du 8086 en 16 bits.

Exact, j'ai confondu le 370 sorti lui en 70 et le 370 -XA.

Et l'ibm 360 était un 20 bits d'adresses qui a était étendu sur 24 par la suite.

La tu n'es pas d'accord avec mes sources:

A second major break with the pioneer area is the address size of 32 bits. This size was intended from the ouset to be available when needed, even though it was initially held at 24 bits, as presented here [Brooks, 1965]. The 32-bit address was somewhat compromised, yet is was sufficciently guarded to make the shift to it feasible in the 370-XA adn ESA.

En plus, les gros système de l'époque avaient rarement plus d'1Mo physique(ce qui était énorme pour l'époque vu le prix de celle-ci) d'autant plus que les séries d'IBM utilisaient déjà la virtual mémory.

Je disais que des bien avant les premiers micro-processeurs on savait que le manque de bits d'adresse etait un facteur limitatif important de l'evolution de toute architecture. Et quand je parle de bits d'adresse ici, il s'agit bien de la memoire virtuelle, pas de la memoire physique pour les systemes qui disposent d'une memoire virtuelle. Ajouter des bits a de la memoire physique si on a de la memoire virtuelle est beaucoup plus facile qu'ajouter des bits a de la memoire virutelle.

Je pense aussi que le marché des microprocesseurs n'avaient pas le même but que celui des gros systèmes. C'est pourquoi dans le livre il parle qu'à la conception (donc bien avant la mise sur le marché) 16 bits leur paraissaient énorme pour le marché auxquel il était destiné.

Tu m'as l'air de pretendre que les concepteurs des micro n'ont pas tenu compte de l'experience de leurs predecesseurs (vecues avec les mainframe puis les mini); on peut dire comme je le fais que les memes causes produisent les memes effets.Pour les premiers mini, pour les premiers microprocesseurs, les possibilites d'evolution n'etaient pas un facteur important face a d'autres contraintes technologiques et de couts.

Si on regarde la position du 8086, il etait destine a ceux pour qui la similarite avec le 8080 etait un facteur important mais qui avaient besoin de plus de bits d'adresses et accessoirement de registres generaux plus grands. Pour les autres il y avait le 432 qui allait venir. Chez motorola, le 68000 avait des registre generaux de 32 bits et un espace d'adressage physique de 24 bits (facilement extensible a 32 bits comme sur le 360, meme cause meme effet, on a utuilise les 8 bits disponibles pour autre chose et pose des probleme lors du passage a 32 bits).

Le fait est qu'il y a toujours un marche pour les 8 bits et les 16 bits. La derniere fois que j'ai regarde des chiffres, ils dominaient toujours largement en nombre les autres systemes. Il y a toujours dessystemes pour lesquels la possibilite d'avoir une meilleure evolution vers des systemes plus grands n'est pas un facteur important.

[WO]

zdra

Je sais que la préhistoire c'est passionant, mais

- que désires-tu faire et dans quel cadre ? Refaire tout le boulot d'Abrash ?

- ton environment est-il "limité" ?

- quels besoins de puisance ?

etc.

@+WO

[=TnT=]

zdra

Je sais que la préhistoire c'est passionant, mais

- que désires-tu faire et dans quel cadre ? Refaire tout le boulot d'Abrash ?

- ton environment est-il "limité" ?

- quels besoins de puisance ?

etc.

Mon but serait de faire un moteur 3D complètement en ASM de A à Z.
J'avais lu qu'une équipe de développement avait réalisé à l'époque un tel moteur, et ils avaient réalisé un doom-like sur un 286 qui étrait plus puissant que tous ceux de l'époque qui tournaient sur des 486 ! (le projet avaie été abandonné faute de moyens)
Il semblerait donc que l'ASM permette d'atteindre des performances inégalées à ce jour.

Dans un premier temps, il me faut donc par exemple savoir quels sont les avantages/inconvénients des modes réel/protégé.

A noter que les performances étant d'après moi bien supérieures s'il n'y a que mon moteur 3D qui tourne, il serait judicieux d'un point de vue des performances de faire un moteur qui puisse se lancer sans OS. Autrement dis, je souhaite programmer en ASM pur, sans API ni quoique ce soit.

[WO]

Bon,

tu vas comprendre très vite que ce n'est plus la bonne méthode :

M$ (entres autres) utilise le format WDM pour forcer les industriels à adopter un format commun de développement des drivers. Sous prétexte de simplifier le boulot (ce qui est vrai) ils tordent le bras aux constructeurs de hard (m’enfin je m’égard). L’intérêt pour toi c’est que ce n’est plus le CPU qui fait le boulot mais que la charge de travail est déportée dans le matériel cible. S’il était possible d’avoir un tromblon WDM à 8 Mhz (pour l’interface utilisateur) ça tournerai (presque pareil. Donc, WDM, kernel streaming etc. Les performances de l’ASM sont plutôt dans la possibilité de descendre très bas dans l’architecture sans perdre la portabilité (P&P) non seulement l’image le MIDI, l’audio mais tout… absolument tout est géré en objets bas niveaux. WDM fourni une sorte d’image symétrique des DSP VSP et tu peux les reconfigurer comme tu veux. C’est pas puissant, c’est démentiel comme lego. Si tu fais une application en mode kernel, tu accèdes à toute la mémoire (mais on s’en fout, vu que ce qui va t’intéresser c’est celles des matériels cibles). Le Kernel streaming, permet entre autre laisser la carte gérer les flux disques directement sans passer par le CPU et le mécanisme de gestion RAM.
Désolé d’être aussi succinct, mais un coup d’œil au DDK devrait te faire comprendre les nouveaux enjeux de l’ASM et dans le SDK la partie DirectShow (par exemple) te permettra de comprendre que les différents automates pour lesquels tu désires écrire des moteurs sont déjà dans les cartes !!! Donc, soyons sobres… les DSP/VSP tournerons dans tes cartes en // au CPU… tu peux pas lutter (c’est une perte de temps crois-moi) par contre tu pourras travailler beaucoup plus efficacement en ASM en contournant toutes les cochonneries Direct gniagnia qui sont pour les gus qui font du HLL à 10 milliards de km au-dessus… Il est possible de faire de l’ASM objet très bas niveau et vraiment optimisé… (arf)

@+WO.

[=TnT=]

tu peux pas lutter (c’est une perte de temps crois-moi) par contre tu pourras travailler beaucoup plus efficacement en ASM en contournant toutes les cochonneries Direct gniagnia qui sont pour les gus qui font du HLL à 10 milliards de km au-dessus… Il est possible de faire de l’ASM objet très bas niveau et vraiment optimisé… (arf)

Justement, mon but premier était de ne pas passer par les DirectX qui sont trop lentes généralement.
j'avais aussi pensé qu'il faudrait bien que j'utilise les fonctions des cartes qui sont intégrées dans celles-ci, mais je ne sais pas vraiment comment faire en ASM. Tu parle du WDM et de kernel Streaming ; en fait si je comprends bien il va falloir que j'écrive un programme bien optimisé mais qui fera appel à des fonctions déjà existantes et complètement optimisées dans la cartes 3D, c'est bien ça ? Ce qui en fait revient à faire un programme qui se contente d'envoyer les bonnes infos à la carte 3D sans réellement écrire un moteur 3D, mais qui sera optimisé afin de gagner du temps entre les différentes fonctions, c'est ça ?

[WO]

Version simplifiée: OUI !!!

Mais quand tu vas jeter un coup d'oeil au possibilités tu vas aimer ... vraiment aimer...

Ici, nous avons des performances à tomber par terre...

Ceci dit, rien ne t'empêche de développer tes propres algos pour les DSP...(héhé...)

@+WO

[=TnT=]

Version simplifiée: OUI !!!

Mais quand tu vas jeter un coup d'oeil au possibilités tu vas aimer ... vraiment aimer...

Ici, nous avons des performances à tomber par terre...

OK, donc c'est ce qu'il me faut. Mais je ne comprends pas pourquoi on gagne autant de performances "simplement" en écrivant les programmes en ASM (bien optimisés). Le C++ est-il si mauvais d'un poitn de vue performances ??

Ceci dit, rien ne t'empêche de développer tes propres algos pour les DSP...(héhé...)

Ce qui me chagrine, c'est que les algos qui existent ne seront peut être pas tout à fait adaptés à ce que je ferai (j'en sais rien), ce qui impliquerait une mauvaise optimisation donc une baisse de performances. J'étudierai tout ça en détail le moment venu.

[WO]

Le problème de l'automate qui gère tout ça (à la charge du CPU) reste entier (ton jeu par exemple) l'écrire en ASM ou en HLL c'est pas vraiment pareil

Les HLL sont empêtrés dans toutes leurs couches et ne peuvent pas descendre là où il faut (en plus M$ veille au grain). Le saupoudrage inline d'ASM n'y change rien pour de multiples raisons évidentes (vieux débat... ) la seule force des HLL c'est l'ignorance des gus et le compilateur qui fait le boulot à leur place d'une manière qui leur échappe et sur laquelle ils fantasment dur.

En fait, plus tu programme imbriqué plus le compilateur est perdu (mais vraiment perdu, gestion de pile, push/pop dans tous les sens, utilisation de tous les registres, deux appels pour un simple call etc. je t'explique même pas la FPU, le MMX SSE...
Vu que faire de l'interface en ASM ou avec n'importe quel HLL c'est du pareil au même aujourd'hui...
vu le nombre de mP différents (les nouveaux Mac sont sur Intel...) vu les mécanismes bas niveaux mis en places et le désire de M$ de vendre docs+bouquins+ bibliothèques+includes + + + ils ont pas fini d'intoxiquer tout le monde avec leur salades qu'ils appellent, en plus, Direct prout pour s'assurer la fidélité de tous les gus perdus dans les docs de surface... ils ont raisons remarques... tant que personne ne se pose de question ils peuvent tranquillement continuer à vendre leur soupes amère et les codeurs pleurer parce qu'ils sont dépasser par les"bruits" de surface... (arf)

Amuse-toi bien, mais PCI express et cartes WDM. (les deux marques fournissent aussi des SDK...)

@+WO

PS: pour les algos.. ne crainds rien, ça fuse. par contre là où c'est magique c'est la modification de topologie (le lego).

[=TnT=]

PS: pour les algos.. ne crainds rien, ça fuse. par contre là où c'est magique c'est la modification de topologie (le lego).

Qu'entends-tu par la topologie ? Elle fait référence à quoi ?

[WO]

En fait, toute la représentation objet de l'agencement du hard. le lego est là...
Le format WDM "donne" une vision quasi universelle (un peu comme la gestuelle via MIDI). Et le SysEx qui te permet de "sortir" de la norme MIDI pour bidouiller le matos est un peu similaire, mais, là en plus tu réorganises les éléments !

msdn .... ce que tu cherches s'appelle msdn... ce que tu cherches s'appelle msdn...

Tu peux comprendre les choses avec Graphedit.exe (DirectShow) ou mieux... KStudio.exe

@+WO

[mat.M]

En fait, plus tu programme imbriqué plus le compilateur est perdu (mais vraiment perdu, gestion de pile, push/pop dans tous les sens, utilisation de tous les registres, deux appels pour un simple call etc. je t'explique même pas la FPU, le MMX SSE...

Non monsieur un compilateur n'est jamais perdu !

Il applique bêtement des règles de compilation !
Par contre oui il n'optimise pas forcément toujours bien et on est amené à optimiser en assembleur

cette zone dans un programme .COM ????

Merci

Boudiou j'avais pas vu ça en aout 2002
Elle est bonne celle-là !
Zdra tu sais pas qu'un .com ( maintenant tu dois le savoir ) ça ne tient que dans 64 ko

[WO]

Waou….

Merci de nous rappeler que le compilateur n'a pas d'états d'âme mais le codeur à des intentions, voyez

Donc, quitte à optimiser en ASM la purée du compilateur, autant écrire directement en ASM (je ne t'explique pas les gains : )

Tu as déjà repris du code de compilateur pour l'optimiser (je ne parle pas de l'exercice pédagogique très intéressant certes... mais de boulot) ?
Par expérience je peux te dire que c'est absurde dans le principe même, d’ailleurs nous sommes d’accord et tu le dis toi-même : Pas de stratégie pour le compilateur, des règles (la plupart du temps hors contexte). Vu que l'optimisation stratégique prime sur l'optimisation locale… (ce qui un peu le sujet du post non ? Ce qui semble satisfaire le posteur initial...)

Puisque ici il faut expliquer chaque virgule : J'affirme donc que le compilateur est perdu car il ne répond pas aux attentes initiales du codeur (que je me garde bien de préciser les attentes initiales histoire de laisser les trolleybus habituels faire leur boulot ).

@+WO

[Euquigam]

Bonjour,
Le mode réel n'est pas vraiment encapsulé dans le mode protégé car en mode réel, les interruptions sont valables tandis qu'en mode protégé, on est obligé de passer par les ports d'I/O (...) car il n'y a plus d'interruptions du BIOS.
Les IRQ sont alors utilisées (elles permettent d'avertir quand une interruption matérielle ou d'exception s'est produite, mais le BIOS ne les gère plus. C'est donc à nous de réécrire le code de chaque interruption).