Modele de memoire

Bonjour,

Sur http://fr.wikipedia.org/wiki/X86 on peut lire, en gros que le modèle de mémoire LARGE permet d'avoir plusieurs segments de code et de data.

Avec Turbo C, configuré avec le modèle de mémoire large, je compile le code suivant:

Code:

---

1 2 3 4 5 6 7

unsigned char toto[65000]; unsigned char titi[65000];   main() { return(0); }

---

Et la j'ai l'erreur:

Too much global data defined in file

C'est bizarre, en modèle tiny ou medium cela ne m'aurait pas choqué, mais en large le compilateur devrait trouver les adresses des variables à partir du segment et de l'offset ?

Sur un autre code, compilé toujours en mémoire large, et en regardant avec Turbo Debugger je constate qu'il accède à la variable uniquement avec son offset, DS étant initialisé au segment de début de donnée, et pas réactualisé si on change de segment. Donc si les données globales dépassent ce segment, il n'arrive pas à y accéder.

Je suis novice en C, quelqu'un pourrait-il m'expliquer d'où vient mon erreur ?

Cordialement.

Citation:

---

Envoyé par Lovmy

Sur http://fr.wikipedia.org/wiki/X86 on peut lire, en gros que le modele de memoire LARGE permet d'avoir plusieurs segments de code et de data.

Avec Turbo C, configurer avec le modele de memoire large, je compile le code suivant:

Code:

---

1 2 3 4 5 6 7

unsigned char toto[65000]; unsigned char titi[65000];   main() { return(0); }

---

Et la j'ai l'erreur:

Too much global data defined in file

---

Ce n'est pas un problème de C mais d'architecture. Un x86 en mode réel (16-bit) a une capacité d'adressage de 65536 octets par segment. Or, même en mode large, où le segment de donné n'est pas partagé avec le code, celui-ci ne peut dépasser 65536 octets (et encore, certains sont réservés par le système).

Ce que tu demandes est donc physiquement impossible en statique. Par contre, tu peux allouer jusqu'à 640k (voire plus avec des astuces plus ou moins complexes) en mémoire dynamique cumulée, tout en sachant qu'un objet ne peut dépasser 64k de mémoire contigüe.

Si tu as des problèmes de mémoire, je te conseille d'oublier le mode réel (obsolète depuis le 386 et Windows 3.x, années 90/95), et de passer au moins en mode protégé (32-bit) avec un compilateur moderne comme gcc. Quel est ton système ?

Il n'y avait pas un mode huge qui permettait de s'affranchir des contraintes du mode large sur la taille totale des données globales et la taille des objets?

Citation:

---

Envoyé par Jean-Marc.Bourguet

Il n'y avait pas un mode huge qui permettait de s'affranchir des contraintes du mode large sur la taille totale des données globales et la taille des objets?

---

A ma connaissance, il est buggé.

(Ca me rappelle un vieux Borland C pour window 3.1)

Citation:

---

Envoyé par Gruik

(Ca me rappelle un vieux Borland C pour window 3.1)

---

Citation:

---

Envoyé par P.O.

Avec Turbo C,

---

Bonjour,

Je pensait que l'option de sélection de type de mémoire jouait sur le comment le compilateur accède aux données (si il met a jour DS suivant les variables à atteindre). Mais dans mon cas ce n'est pas trés grave, en fait je fait un petit test de programme qui tourne sans OS, donc je connait l'adresse de début de code : 07C0:000 pour le début du code boot (les 512 octets chargés par le bios), 07E0:0000 pour le début de mon code en C (le kernel), et TC me fournit une variable, _DATA, qui contient le segment de mes données. Donc si par exemple _DATA = 0E6D, je sais sur mon segment de donnée commence en 07E0+0E6D=164D (oui TC me donne le segment par rapport à 0, quand je compile il ne sais pas que mon code commencera au segment 07E0). A partir de la, sachant que mon segment de données ne dépassera pas un segment, j'en déduit qu'il est compris entre 164D:0000 et 164D:FFFF.
Donc je peut faire un pointeur sur 264D:0000, 364D:000 etc... Pour avoir autant de bloc de 64k que je veux, dans la limite des 640k.

Merci de vos reponses !

Citation:

---

Envoyé par Lovmy

Bonjour,

Je pensait que l'option de sélection de type de mémoire jouait sur le comment le compilateur accède aux données (si il met a jour DS suivant les variables à atteindre). Mais dans mon cas ce n'est pas trés grave, en fait je fait un petit test de programme qui tourne sans OS, donc je connait l'adresse de début de code : 07C0:000 pour le début du code boot (les 512 octets chargés par le bios), 07E0:0000 pour le début de mon code en C (le kernel), et TC me fournit une variable, _DATA, qui contient le segment de mes données. Donc si par exemple _DATA = 0E6D, je sais sur mon segment de donnée commence en 07E0+0E6D=164D (oui TC me donne le segment par rapport à 0, quand je compile il ne sais pas que mon code commencera au segment 07E0). A partir de la, sachant que mon segment de données ne dépassera pas un segment, j'en déduit qu'il est compris entre 164D:0000 et 164D:FFFF.
Donc je peut faire un pointeur sur 264D:0000, 364D:000 etc... Pour avoir autant de bloc de 64k que je veux, dans la limite des 640k.

Merci de vos reponses !

---

Oui, très joli... Rien de tout ça n'a à voir avec le langage C...

Bonjour,

Le choix du modèle de mémoire d'un compilateur C n'a rien à voir avec du C ? Je développe mon kernel en C, et créer des pointeurs sur des zones mémoires fait aussi parti du C.

Maintenant si on entends par C le fait de développer sous Linux ou Windows en utilisant les librairies fournit par ces OS...

Cordialement.

Citation:

---

Envoyé par Lovmy

Le choix du modèle de mémoire d'un compilateur C n'a rien à voir avec du C ? Je développe mon kernel en C, et créer des pointeurs sur des zones mémoires fait aussi parti du C.

---

Ben non. Ca a à voir avec ton architecture, ton compilateur, ton système...

Les problèmes de modèles de mémoire en x86 mode réel éxistent en assembleur, Pascal, BASIC... Ils ne sont pas spécifiques au C (qui ne sait même pas ce que c'est, seul ton compliateur est au courant...)