Discussion :

[Mercenary Developer]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Emmanuel Delahaye]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[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?

[Emmanuel Delahaye]

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é.

[Gruik]

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

[Emmanuel Delahaye]

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

Avec Turbo C,

[Mercenary Developer]

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 !

[Emmanuel Delahaye]

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...

[Mercenary Developer]

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.

[Emmanuel Delahaye]

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...)