Forum des développeurs  

Le forum de référence en programmation et développement. Articles, cours et tutoriels du débutant au chef de projet et DBA confirmé.
Précédent   Forum des développeurs > Autres langages > Assembleur

Assembleur Forum d'entraide Assembleur. Avant de poster -> F.A.Q Assembleur Tutoriels Assembleur

Réponse
 
Outils de la discussion
Vieux 25/08/2008, 16h25   #1 (permalink)
Membre régulier
 
Date d'inscription: août 2008
Localisation: Canada
Messages: 125
Par défaut Gestion de la mémoire en Assembleur, octet ?

Je ne connais absolument rien en assembleur . . .

En apprenant le c, je me suis rendu compte que la mémoire est gérée automatiquement (je veut dire, l'endroit dans la mémoire ou est stockée la variable) . .

En assembleur, j'imagine qu'il faut faire cela manuellement non??

Si c'est le cas, comment faire pour ne pas utiliser un espace déjà utilisé par une autre application??

. . .

Aussi . . . J'avais une question stupide . . . Un octet, c'est 8 bits . . . Pourquoi c'est 8 bits Pourquoi pas autre chose

Merci beaucoup

Alex
Alexandreg12 est déconnecté   Envoyer un message privé Réponse avec citation
Vieux 25/08/2008, 17h26   #2 (permalink)
Membre expérimenté
 
Avatar de Obsidian
 
Date d'inscription: septembre 2007
Localisation: Évry
Âge: 32
Messages: 544
Par défaut

Citation:
Envoyé par Alexandreg12 Voir le message
En apprenant le c, je me suis rendu compte que la mémoire est gérée automatiquement (je veut dire, l'endroit dans la mémoire ou est stockée la variable) En assembleur, j'imagine qu'il faut faire cela manuellement non??
Soit tu utilises la pile (cas des variables locales, notamment) et dans ce cas, par conception, c'est automatique pourvu que tu aies initialisé correctement ton segment.

Citation:
Si c'est le cas, comment faire pour ne pas utiliser un espace déjà utilisé par une autre application??
Soit tu es tout seul et tu fais ta vie, soit tu ne l'es pas et tu demandes au système de t'en réserver. Autrement dit, tu appelles malloc en assembleur comme tu le ferais en C pour qu'une routine tierce te dise où te peux te mettre :-)

D'une manière générale, malloc(), vis-à-vis de la RAM, ne correspond à aucun prérequis technique. C'est juste qu'il faut qu'il y ait une autorité qui tienne le compte de tout ça, et qui soit la même pour tous les programmes. Ça se complexifie un peu avec le swap, bien sûr.

Pour étendre cela encore plus loin, avant l'apparition du mode protégé dans les processeurs, tout ceci était purement consultatif : un programme DOS, par exemple, réclamait de la mémoire au système mais rien ne l'empêchait d'aller écrire ailleurs si bon lui semblait. Ça veut dire aussi que les segfaults n'existaient pas. Si un étudiant faisait une connerie avec un pointeur, ça corrompait le système entier et, souvent le disque avec (loi de Murphy). Ça n'a pas empêché l'informatique de se développer. À l'époque, on faisait attention. Mais il faut dire aussi que les machines personnelles étaient souvent monotâches.

Citation:
Aussi . . . J'avais une question stupide . . . Un octet, c'est 8 bits . . . Pourquoi c'est 8 bits Pourquoi pas autre chose Alex
Parce que sinon, ce ne serait pas octet ! :-)

En fait, la taille des mots manipulés par un processeur est très variable. Les premières familles utilisaient des longueurs bâtardes comme 6, 7 ou 9 bits. Huit bits se sont rapidement imposés car 8 est une puissance de deux (en plus d'être un multiple) et que le nombre de combinaisons est suffisamment important pour que l'on puisse faire quelque chose avec, sans pour autant nécessiter une parallélisation massive au niveau électronique ! À l'époque, les techniques de gravures n'étaient pas ce qu'elles étaient et faire circuler un bus de huit bits sur une carte-mère, c'était autre chose qu'un bus de 64.

L'octet est devenu l'unité de référence parce que la plus pratique à manipuler, mais les processeurs modernes 32 bits, par exemple, exploitent en coulisses des mots de 32 bits, d'où l'importance de l'alignement de certaines instructions sur une adresse multiple de 4.

Certains microcontrôleurs ou µP spécialisés, par exemple les PIC12xxxx, utilisent directement des mots de 12 bits visibles par le programmeur.
Obsidian est déconnecté   Envoyer un message privé Réponse avec citation
Vieux 01/09/2008, 19h30   #3 (permalink)
Membre éprouvé
 
Avatar de dapounet
 
Date d'inscription: juillet 2007
Localisation: Belgique
Messages: 410
Par défaut

Citation:
Envoyé par Alexandreg12 Voir le message
En apprenant le c, je me suis rendu compte que la mémoire est gérée automatiquement (je veut dire, l'endroit dans la mémoire ou est stockée la variable) . .

En assembleur, j'imagine qu'il faut faire cela manuellement non??
Non, c'est le boulot de l'OS. Le programme qui assemble le code source génère quand même les adresses des variables globales lui-mêmes, celles des variables locales sont calculées à l'exécution. Au final le programme utilisera des adresses "virtuelles" et c'est l'OS qui se chargera de les faire correspondre avec une varie adresse physique.

Citation:
Envoyé par Alexandreg12 Voir le message
Si c'est le cas, comment faire pour ne pas utiliser un espace déjà utilisé par une autre application??
C'est le boulot de l'OS aussi. Chaque programme a un espace d'adressage virtuel séparé des autres et l'OS s'occupe de faire la correspondance avec la mémoire et le swap de la machine.
__________________
:wq
dapounet est déconnecté   Envoyer un message privé Réponse avec citation
NEWS ASSEMBLEURFAQ ASSEMBLEURLIVRES ASSEMBLEUR

Réponse

Précédent   Forum des développeurs > Autres langages > Assembleur



Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are non
Pingbacks are non
Refbacks are non
Navigation rapide


Fuseau horaire GMT +1. Il est actuellement 01h01.


Publiez vos articles, tutoriels et cours et rejoignez-nous dans l'équipe de rédaction du club d'entraide des développeurs francophones. Nous contacter
Copyright 2000-2009 www.developpez.com - Legal informations