Cet article n'en sera pas vraiment un. Je voulais depuis le premier numéro du Rep écrire un article sur ce fameux "Flat Real Mode". Et puis par manque de temps (et de courage), je le repoussais à chaque parution.
Il faut dire qu'à mes yeux, expliquer le mode flat, cela passait par l'explication du mode multitâches (j'ai pris l'habitude d'appeler le mode protégé mode "multitâches" pour emmerder les partisans du mode protégé monotâche). Or ce type d'article serait au moins aussi long qu'une initiation à la VGA.
Si vous avez bonne mémoire, vous vous souvenez peut-être d'un article traitant des "Spécificités du 386 - partie 1" qui n'avait jamais eu de suite. Considérez donc ce texte comme les "Spécificités du 386 - partie 2 et fin", et n'en parlons plus.
Ce soir, je ne vais pas expliquer le mode multitâches. Il existe des livres pour ça ; et des DOCs, des conférences, etc... Je tiens même à votre disposition la DOC d'Intel sur le 386 si vous vous sentez d'attaque pour lire ces 800Ko de textes en anglais (envoyez une disquette, une enveloppe et un timbre à mon adresse avec un petit mot qui m'économisera une scéance de voyance pour deviner ce que vous voulez).
Mais avant de commencer, je dois remercier une des rares personnes sérieuses dans toute cette histoire : LCA. D'une part, c'est lui qui a "démocratisé" le mode flat en France (et par la suite à travers la demo-scène européenne) ; Ensuite, c'est aussi l'une des rares personnes qui a eu l'intelligence d'aller un peu plus loin dans la discution que l'état "C'qu'on est fort, Intel Suxx !".
Pour utiliser la mémoire haute/supérieure/étendue/tout- ce-vous-voudrez, les grandes entreprises qui guident le progrès ont standardisé plusieurs méthodes consistant toutes à limiter la mémoire haute/supérieure/étendue/autre-classification- officielle à une zône de stockage provisoire ou des données pourront stationner mais pas être utilisées avant d'être recopiées en mémoire basse/conventionnelle/zut!, comme il sied à tout bon programme DOS. Mais ce que n'avaient pas prévu ces compagnies, c'est la frustration bien légitime des codeurs (qui, à l'inverse des programmeurs, abandonnent parfois les manuels des DOS-Extenders pour consulter des DOCs techniques - quoique ce comportement tende à disparaître).
Bref, de l'étude du fonctionnement du 386, il ressort qu'il est tout à fait possible, et qui plus est parfaitement simple, d'utiliser toute la mémoire disponible en mode réel.
En fait, voici par quoi sont constitués les registres de segment du 386 :
La partie visible du segment dépend du mode. En mode réel, la partie visible est l'adresse de base. En mode protégé, c'est la location du sélecteur.
Lorsqu'on charge un registre de segment en mode réel, on ne modifie que la base du segment. Lorsqu'on charge un registre de segment en mode protégé la modification de la location du descripteur entraîne le chargement de tous les autres champs dans la partie invisible du registre (pour des raisons évidentes d'efficacité).
Lorsqu'on utilise un registre de segment en mode réel, le processeur ne se réfère qu'à la base, la taille et le type du segment. Lorsqu'on utilise un registre de segment en mode protégé, le processeur se réfère en plus à la partie "protection" pour la gestion du système multitâches.
Il est alors clair qu'en mode réel, la taille des segments n'est pas forcément 64 Ko comme sur les anciens processeurs. Tout comme la table d'interruption n'est pas nécessairement à l'adresse 00000h (Cf. IDTR). Tout ceci n'est qu'une EMULATION.
Pour passer en mode flat, le plus simple est encore de passer en mode protégé, de recharger les registres de segment avec la taille souhaitée (4 Go est raisonnable ;-), et de revenir au mode réel :
Ceci nous donne :
--8<--Snip-Snip--8<--------------------------------------------
cli
mov eax,cs ; ou un autre registre de segment si
shl eax,4 ; la GDT se trouve ailleurs
mov ebx,offset gdt
add eax,ebx
mov gdt_adr,eax ; A quand les assembleurs qui sauront
mov bx,offset gdt_ptr ; calculer une adresse 32 bits ?
lgdt fword ptr [bx]
mov eax,cr0
or al,1
mov cr0,eax
jmp short $+2
mov bx,8
mov fs,bx ; pourquoi se gener ?
mov ds,bx
mov es,bx
mov gs,bx
and al,0FEh
mov cr0,eax
sti
...
...
...
gdt LABEL WORD ; Deux selecteurs :
DW 0,0,0,0 ; Le selecteur zéro
DW 0FFFFh,0,9200h,8Fh ; et un selecteur de limite 4 Go
gdt_ptr dw 15
gdt_adr dd ?
--------------------------------------------8<--Snip-Snip--8<--
Ne vous laissez pas surprendre par le "mov eax,cs". En fait, il ne faut pas perdre de vue que l'instruction MOV pour un registre de segment est différente de l'instruction MOV pour autre chose (à ce sujet, la syntaxe instaurée par Intel pour son assembleur est assez discutable)... Il ne faut donc pas s'étonner qu'un MOVZX EAX,CS soit interdit (car MOVZX est une extention du "vrai" MOV) alors que MOV EAX,CS l'est (et met donc les 16 bits forts de EAX à 0).
Au fait : peut-être etes vous déjà en mode flat sans le savoir. En effet, certain gestionnaires d'XMS utilisent cette méthode pour accéder aux données. Pour vérifier ceci, essayez un petit "MOV AL,DS:[h10000]" ou pourquoi pas carrément un "MOV AL,DS:[hFFFFFFFF]". Si la machine plante, c'est raté (en fait, si l'exception 13 se declenche - ce qui plante la machine à tous les coups sous DOS).
De plus, lors de vos tests, n'oubliez jamais que le BIOS ne remet la taille des segments à 64Ko que pendant un cold-boot (ca m'a couté une demie-nuit de sommeil cette histoire, grrr).
Pour finir, sachez que la routine précédente est incluse dans REPLIB.LIB. Amusez-vous bien avec.
Vous devez savoir qu'il existe aussi des DOS-Extenders qui permettent l'utilisation de toute la mémoire en modèle flat, mais en mode protégé cette fois. Alors, que choisir ?
Simple : le mode réel !
Pourquoi ? Parce que c'est plus simple, plus court, compatible DOS/BIOS, compatible à 100% avec n'importe quoi, plus intelligent, plus rapide (pas de protections inutiles), etc...
On peut aussi changer le type du segment de code de façon à changer les tailles d'opérandes par défaut (16<->32bits), et à utiliser EIP au lieu de IP (mais alors là, évidement, ce n'est pas plus compatible-DOS que du mode protégé).
Utiliser le mode protégé pour adresser bon-grés mal-grés plus de mémoire est non seulement ridicule mais aussi moins efficace.
Dernière chose : Il est fréquent de lire des choses du genre : "On programme en mode-X -> IBM Suxx !" ou "On a trouvé le mode flat-réel -> Intel Suxx !". Seulement, depuis le début, Intel n'écrit ses DOCs que dans l'optique d'un OS multitâches. Notre petite gruge est tellement simple comparée aux possibilités réelles du processeur... Les sceptiques n'ont qu'à lire des DOCs.
Sur ce, je vous laisse. Vous pouvez maintenant allez vous jetter dans des bouquins traitant du multitâches (mais je ne veux plus voir de "Erreur : EMS driver not detected").
Qui sait, j'écrirai peut-être une série d'articles traitant du mode protégé... Mais à quoi bon ? J'attends de trouver un bon petit OS complet (début 95, l'OS de DOBB's Jrnl. devrait être terminé, on en reparlera à ce moment là).
Rixed
===============================================================
Un énorme merci à CyberMad pour sa relecture et ses
- nombreuses - corrections orthographiques. Grace à toi, ce
texte devrait être présentable. Smack !
===============================================================
N'achetez pas PC-Interdit ! Ce livre est d'une bêtise à faire
palir un crâne fraîchement décapé ! Ce sont des bouquins comme
celui-ci qui me motivent pour écrire dans ce zine...
Micro-Application Suxxx !!! :-)
=======================[JMP Near hFFFF0]=======================