Questions diverses - Page 1

Voila, j'ai plusieurs question à poser, donc plutot que de faire un topic par question, je n'en fait qu'un seul.

1) Est-ce qu'en mode protégé, les interruptions ne csont plus accessible. Pour moi on ne peut plus les utiliser.

2) J'utilise ca pour passer en mose protégé:
mov eax,cr0
or ax,1
mov cr0,eax
Est-xe que je doit mettre ca pour repasser en mode normal et ainsi pouvoir réutiliser les int:
mov eax,cr0
xor ax,1
mov cr0,eax
?

3) De ce que je sais sur le multitache, l'OS execute un certains nombre d'instructions du premiers programme, ensuite un certains nombre du deuxieme, etc... Bon, avec ceci on ne gagne pas de temps. Mais est-ce que l'ont en perd? Beaucoup? Pour moi, oui on en perd, car il faut faire le jonglage entre les differents programmes allumés. Mais comment fait l'OS pour ne faire executer qu'un certains nombre d'instructions?

EagleLIONHEART
: 1) Est-ce qu'en mode protégé, les interruptions ne csont plus accessible. Pour moi on ne peut plus les utiliser.

En effet. Mais d'après ce que je sais, il est possible d'installer des wrappers qui passent en mode protégé dès que l'interruption s'exécute.

2) J'utilise ca pour passer en mose protégé:
mov eax,cr0
or ax,1
mov cr0,eax
Est-xe que je doit mettre ca pour repasser en mode normal et ainsi pouvoir réutiliser les int:
mov eax,cr0
xor ax,1
mov cr0,eax ?

Probablement, mais je ne suis pas un expert du x86 à ce point.

3) De ce que je sais sur le multitache, l'OS execute un certains nombre d'instructions du premiers programme, ensuite un certains nombre du deuxieme, etc... Bon, avec ceci on ne gagne pas de temps. Mais est-ce que l'ont en perd?

Évidemment.

Beaucoup?

Normalement non.

Pour moi, oui on en perd, car il faut faire le jonglage entre les differents programmes allumés.

C'est clair.

Mais comment fait l'OS pour ne faire executer qu'un certains nombre d'instructions?

Il utilise une interruption timer (désolé, j'ai oublié le numéro de l'IRQ clock sur PC - en tout cas c'est l'équivalent de l'auto-int 1 ou 5 sur TI-89/92+/V200).

Kevin Kofler
: En effet. Mais d'après ce que je sais, il est possible d'installer des wrappers qui passent en mode protégé dès que l'interruption s'exécute.

Merci, je vais pointer mes recherches sur ca.

Probablement, mais je ne suis pas un expert du x86 à ce point.

Et bien en fait pour passer en mode protégé je met le premier bit de cr0 à 1. Et pour repasser en mode normal je le remet à 0. Je voulais savoir si c'est bien comme cela pour remettre le premier bit à 0, sans affecter les autres. Et si cela suffisait.

Il utilise une interruption timer (désolé, j'ai oublié le numéro de l'IRQ clock sur PC - en tout cas c'est l'équivalent de l'auto-int 1 ou 5 sur TI-89/92+/V200).

Voui...!
C'est tellement évident que je n'y avait pas pensé... Bon bin va falloir que je fasse des recherches aussi sur ca. Merci Kevin.

Lorsque j'utilise cli en mode reel, est-ce qu'il est encore valable lorsque je passe en mode protégé? Ou bien alors dois-je le réutiliser?

Euh...j'ai une question un peu simplette, mais qui me tourmente quand meme. Quelle est la difference entre "int 0x13" et "int 13h"? Les deux compiles, mais seul le deuxieme fonctionne. En effet, le premier fait rebooter mon pc... Tient, pourquoi d'ailleurs? Comment est-ce que cela peut reussir a faire rebooter mon pc? Est-ce qu'un opcode invalide peut lui aussi faire rebooter le pc?

-

Orion_ :
int 0x13 et int 13h c exactement la même chose, 13h = 13 en hexa et 0x13 = 13 en hexa aussi (cf la syntaxe du C)

Et bien en ce cas ^pourquoi est-ce que mon programme plante quand je met int 0x13, et qu'il fonctionne quand je met int 13h??? Au débyt je me suis dit comme toi, que c'était la meme chose, mais bon...je ne comprend pas pourquoi ca plante avec l'un et pas avec l'autre. Peut-etre que nasm interprete cela differament...c'est assez bizarre.

Sinon, quel systeme de fichier utilises-tu? Un deja existant, ou un que tu as fais toi meme?

En effet, ton assembleur ne comprend probablement pas la notation 0x, d'où le problème.

-

Surtout lorsque l'on sais qu'avant de passer en mode protégé, ca fonctionné avec le 0x13... M'enfin c'est pas important, le principal c''est que maintenant ca fonctionne a merveille.

Sinon, moi j'utilise un systeme de fichier proche de celui de la ti89 et de Fat: j'utilise le principe de table de relocation. Mais bon, j'ai des problemes quand à savoir ou stocké la table surtout quand elle augmente...

Bin dit donc, y'a pas grand monde qui s'interresse à ce pauvre x86...

Question 007> J'aurais besoin d'une reponse pour linux et d'une pour wondozes (pour etre savoir si la reponse est la meme pour les deux). Est-ce que à chaque fois que l'no execute un programmes, il se charge dans la ram et est ensuite executer a partir de laram par un saut?

Si tel est le cas, bin c'est un peu dommage, car ca empeche de faire comme sur ti pour un "systeme de sauvegarde".

Merci.

EagleLIONHEART
: Bin dit donc, y'a pas grand monde qui s'interresse à ce pauvre x86...

Bah non, je préfère le 68k, moi.

Question 007> J'aurais besoin d'une reponse pour linux et d'une pour wondozes (pour etre savoir si la reponse est la meme pour les deux). Est-ce que à chaque fois que l'no execute un programmes, il se charge dans la ram et est ensuite executer a partir de laram par un saut?

Ben oui, tu crois qu'on exécute directement à partir du disque dur??? Ça serait beaucoup trop lent...

Si tel est le cas, bin c'est un peu dommage, car ca empeche de faire comme sur ti pour un "systeme de sauvegarde".

Et ben, tu fais comme les systèmes de sauvegarde sérieux sur TI-89/92+/V200 (et pas les hacks affreux qui ne marchent plus dès qu'on archive ou compresse le programme): tu crées un fichier externe dans lequel tu places ta sauvegarde. C'est à ça que sert un système de fichiers.

Donc a chaque fois que l'on ouvre un fichier (enfin, qu'on y accede), il est copier dans la ram, c'est ca?

Euh pour le systeme de fichier....faudra repasser, c'est pas encore fait...

EagleLIONHEART
: Donc a chaque fois que l'on ouvre un fichier (enfin, qu'on y accede), il est copier dans la ram, c'est ca?

Normalement oui.

Mouais, et bin je voyais pas cela comme ca au debut. Je pensais que les accés, modif et execution direct était possible. Bon, merci pour ta réponse.

Kevin Kofler
:

Bin dit donc, y'a pas grand monde qui s'interresse à ce pauvre x86...

Bah non, je préfère le 68k, moi.

Personnellement je fais beaucoup d'assembleur MIPS en ce moment... c'est incomparable

Et pour répondre un peu plus sérieusement à EagleLIONHEART, tu es en train de t'interesser à la partie la moins utile et la moins intéressante d'un système d'exploitation. Ca fait déjà de nombreuses années que les systèmes d'exploitation (même dans le domaine de l'embarqué) ne se codent plus en assembleur. La première chose qu'on cherche à faire c'est avoir un cross-compilateur C, et le reste, même le scheduler (qui est pourtant critique au point de vue vitesse), tout se fait en C.

Ce que tu fais jusqu'à maintenant est complètement spécifique au x86, donc si tu changes d'architecture tu devra tout réaprendre. Je ne critique absolument pas le fait que tu souhaites en savoir plus, je dis juste que ce n'est pas la bonne approche si ce que tu veux vraiment c'est faire un système d'exploitation. On ne compte pas le nombre impressionnant de gens sur Internet qui se lancent dans un projet de "système d'exploitation", qui sont super motivés et qui apprennent l'asm x86, qui font un bootloader, affichent deux trois lignes de text à l'écran, jusqu'à une ligne de commande basique... et abandonnent parce qu'ils en ont marre de l'assembleur, et surtout parce qu'il n'y a plus du tout de tutorials sur le net qui explique la suite de manière détaillée. Un système d'exploitation ce n'est pas ça.

Après, si tu veux vraiment absolument faire de l'assembleur, il faut plutôt s'orienter vers les compilateurs, là où c'est encore utile (et nécessaire) de nos jours, il y a beaucoup à apprendre (séléction d'instructions, optimisations, allocation de registres, instruction scheduling), ou alors vers les simulateurs de processeurs.
Si tu veux plutôt faire un système d'exploitation, déjà fait le en C (ou C++ si tu es motivé, c'est encore plus interessant), et passe plutôt du temps sur ce qui fait la différence entre plusieurs systèmes d'exploitation (gestion des processus, interface des drivers, VFS, stratégies d'allocation mémoire, ...), pas sur ce que tout le monde fait toujours pareil (le bootloader).

Encore une fois ce n'est absolument pas une critique, je donne juste mon point de vue... bien sûr tu en fais ce que tu veux

Erci Nitro de m'avoir donner ton point de vue qu'y n'était pas juyste qu'un "arretes, ca serta rien'. Tu as bien argumenté ta critique. Merci.

Et pour répondre un peu plus sérieusement à EagleLIONHEART, tu es en train de t'interesser à la partie la moins utile et la moins intéressante d'un système d'exploitation. Ca fait déjà de nombreuses années que les systèmes d'exploitation (même dans le domaine de l'embarqué) ne se codent plus en assembleur. La première chose qu'on cherche à faire c'est avoir un cross-compilateur C, et le reste, même le scheduler (qui est pourtant critique au point de vue vitesse), tout se fait en C.

JE le sais. Meme mon cher nunux a était codé en c. Mais bon, que veux-tu, je suis un inconditionnel de l'assembleur. Deja sur Ti-89, meme en sachant que le c est plus simple à programmer et qu'il y a un très bon support avec Tigcc, je prefere toujours l'assembleur. Je suis un fou d'optimisation. Et j'aime beaucoup l'asm parce qu'il s'agit d'un langage de bas niveau contrairement au c. Ce qui fait, comme tu l'as dit, que le c a un leger probleme de vitesse.
Tu trouves que la partie que je dévellope actuellement est la moins interessante, mais moi je trouve que non. En effet, je rappel que ce systeme d'exploitation me sert d'apprentissage. Et crois moi, depuis le debut j'ai appris beaucoup de chose, et pas des moindre.
Et puis moi j'aime bien savoir comment ca fonctionne, donc je suis heureux de mieux comprendre comment fonctione un OS.

Ce que tu fais jusqu'à maintenant est complètement spécifique au x86, donc si tu changes d'architecture tu devra tout réaprendre. Je ne critique absolument pas le fait que tu souhaites en savoir plus, je dis juste que ce n'est pas la bonne approche si ce que tu veux vraiment c'est faire un système d'exploitation. On ne compte pas le nombre impressionnant de gens sur Internet qui se lancent dans un projet de "système d'exploitation", qui sont super motivés et qui apprennent l'asm x86, qui font un bootloader, affichent deux trois lignes de text à l'écran, jusqu'à une ligne de commande basique... et abandonnent parce qu'ils en ont marre de l'assembleur, et surtout parce qu'il n'y a plus du tout de tutorials sur le net qui explique la suite de manière détaillée. Un système d'exploitation ce n'est pas ça.

Le systeme d'exploitation que je developpe en x86 est de toute facon specifique au x86. A partir du moment ou je changerai de plate forme, il me faudrat changer beaucoup de truc, meme en c! Et puis je n'aurai peut-etre pas le meme projet sur une autre plate forme.
Regarde, sut ti, mon projet c'est de réaliser un RPG médieval fantastique uniquement en assembleur, avec pour le moment l'excellente librairie genlib, et sur x86, et bien c'est un OS. Donc deja, entre deux architecture, je n'ai pas gardé le meme projet.
Je sais qu'un systeme d'exploitation ne fait pas que booter sur le pc, afficher trois ligne à l'ecran et executer une seule commande. Et personnelement je ne fait pas un Os pour faire un OS. Je fait un OS uniquement dans le but d'apprendre le x86. Et peu importe si je finit l'OS ou pas, je ne désire qu'apprendre.
Et ne t'inquiète pas, meme si la suite n'est pas beaucoup détaillé, j'ai beaucoup d'idée, et puis je trouve quand meme des infos par ci, par là!

Après, si tu veux vraiment absolument faire de l'assembleur, il faut plutôt s'orienter vers les compilateurs, là où c'est encore utile (et nécessaire) de nos jours, il y a beaucoup à apprendre (séléction d'instructions, optimisations, allocation de registres, instruction scheduling), ou alors vers les simulateurs de processeurs. Si tu veux plutôt faire un système d'exploitation, déjà fait le en C (ou C++ si tu es motivé, c'est encore plus interessant), et passe plutôt du temps sur ce qui fait la différence entre plusieurs systèmes d'exploitation (gestion des processus, interface des drivers, VFS, stratégies d'allocation mémoire, ...), pas sur ce que tout le monde fait toujours pareil (le bootloader).

En ce qui me concerne, le bootloader est dejafinie depuis un petit moment. Là j'en suis au point d'essayer de charger en memoire un prog et d'essayer de le lancer. une fois réussi, je ferais le systeme de fichier.

Voila! Et encore merci d'avoir si bien exprimé ton point de vue
Si tu as d'autres critiques, n'h'ésite pas, tu es le bien venu!

Kevin Kofler
:

EagleLIONHEART
: Donc a chaque fois que l'on ouvre un fichier (enfin, qu'on y accede), il est copier dans la ram, c'est ca?

Normalement oui.

ben pas exactement, y'a des systemes de buffer quand meme !

C'est a dire? Tu peux expliquer s'il te plait? (en detail de préférances car sinon ca ne me seras pas de 'une grande aide)

Question 008> Sous win, lorsque l'on désassemble un prog, on peut très facilement localiser les appel system. Et sous linux, ca marche comment?

http://www.linuxassembly.org
Et comme la plupart des logiciels pour Linux sont open-source, au lieu de t'embêter à les désassembler, utilise gcc -S pour avoir le code assembleur.

EagleLIONHEART
: C'est a dire? Tu peux expliquer s'il te plait? (en detail de préférances car sinon ca ne me seras pas de 'une grande aide)

ben imagine, si tu as un fichier de 100Mo à éditer, notepad ne vas pas TOUT copier dans la ram !! ça serait totalement inutile !
Donc il en copie un petit bout du DD vers la RAM, et quand il a besoin d'un bout qui n'est pas en RAM, il va le chercher sur le disque, et il libere l'autre bout dont-il n'a plus besoin pour le moment. (en gros..)

c juste ça que je voulais dire.

Petit détail: Notepad ne gère pas les fichiers de 100 MO. C'est 32 KO maximum. Ou 64 KO sous certaines conditions. Mais pas plus.

Kevin Kofler :
http://www.linuxassembly.org
Et comme la plupart des logiciels pour Linux sont open-source, au lieu de t'embêter à les désassembler, utilise gcc -S pour avoir le code assembleur.

Merci. En effet l'option -S de gcc est très pratique. je ne savais pas que l'on pouvait faire cela avec.
Et grace à cela j'ai trouver ce que je cherché.

Pour le chargement des programmes, les systèmes d'esploitations 32 bits utilisent un espace d'adressage 32 bits (maximum 4 Go) en mode utilisateur (sauf pour les drivers, etc...) qui permet d'accéder à beaucoup de mémoire pour chaque programme. Chaque programme a un espace d'adressage à lui tout seul, ce qui permet de séparer les programmes entre eux. Au démarrage, l'OS crée l'espace d'adressage du programme et l'installe à son adresse de base qui peut-être fixée ou dynamique (à ce moment là, il faut des tables de relocation, comme sur les TI...). Ensuite quand le programme fait des demandes mémoire, tout est alloué de façon dynamique et transparente, de façon à ce que le programme ne ce soucie de rien. L'espace d'adressage n'est pas forcément que de la RAM (le plus utilisé/important est en RAM et le reste est chargé à partir du disque si besoin est, mais il peut arriver que ça ne soit jamais chargé dans la RAM je pense) et il n'est pas forcément tout utilisé. Les adresses sont invalides tant qu'elles n'ont pas été allouées. Ce mode à plusieurs avantages: si le programme exécute une instruction invalide (IN et OUT pour ne citer que ça) ou essaye d'accéder à de la mémoire qui n'est pas allouée, l'OS génère une erreur. Plsiuers programmes peuvent accéder à des données partagées, qui seront accessibles dans leur espaces d'adressages respectifs et le même programme peut être éxécuté deux fois (deux espaces d'adresses, donc) sans être chargé deux fois en mémoire...
Si je ne me suis pas trompé, c'est comme ça (à peu de choses près) que fonctionne par exemple Windows XP...

Kevin Kofler :
Petit détail: Notepad ne gère pas les fichiers de 100 MO. C'est 32 KO maximum. Ou 64 KO sous certaines conditions. Mais pas plus.

sur Me je sais, mais sur XP (et 2000 aussi je crois), 100Mo, c peut etre exagéré, mais en tous cas notepad gere bien plus de 64 Ko
quand on te dit que Me suux !!!
(enfin si y'av que ça, ça ne serait pas grave )