J'ai un doute fondamental concernant l'exécutable stocké dans la ROM.
Comme je connais l'exécutable avec le texte et les attributs RO est stocké dans ROM. La question est que la ROM est la seule mémoire en lecture seule, que se passe-t-il s'il existe une situation où le code doit écrire en mémoire?
Je ne suis pas capable de susciter aucun exemple pour citer ici (probablement que je suis ignorant de cette situation ou je manque de choses de base;) Mais toute lumière sur ce sujet peut grandement m'aider à comprendre! :)
dernier éteint - 1. Y a-t-il une telle situation? 2. Dans un tel cas, la copie du code de ROM à la RAM est la réponse?
réponse avec un exemple peut grandement aider.
Merci beaucoup d'avance!
/ ms
4 Réponses :
Normalement, seuls le code de programme, les constantes et les données d'initialisation sont stockés dans ROM. Une zone de mémoire séparée dans la RAM est utilisée pour la pile, le tas, etc.
Salut Paul, je sais que nous configurons les sections de pile, de tas, de données, de RW à un emplacement de RAM approprié, mais mon tout doute est si la section de code (qui est en ROM) doit être écrite en mémoire? (qui se trouve être dans la ROM elle-même!) La liaison génère-t-elle une section de code avec des attributs de lecture / écriture et finalement il réside dans la RAM? Mais tout ce que nous faisons, c'est flash l'exécutable dans la ROM, alors comment ce transfert à la RAM arrive-t-il? Pourquoi avons-nous besoin de RAM alors ", où le code est copié de la ROM en RAM puis exécuté"? (Cela peut être simple à partir de ROM à droite? Merci pour votre réponse .. :) meilleures salutations ..
Dans la plupart des secteurs d'exploitation, les segments de code sont en lecture seule, même s'ils résident en RAM. Cela rend les programmes plus robustes et moins de problèmes de sécurité. Ainsi, le fait que votre code soit dans ROM ne fait aucune différence - vous ne devriez jamais normalement avoir besoin d'écrire sur ce segment. Si vous devez utiliser un code auto-modificateur ou un autre piratage de ce type, vous devrez le faire en RAM, puis éventuellement marquer la page comme exécutable (dépendante du système d'exploitation).
La mémoire en lecture seule est en lecture seule à cause des restrictions matérielles. Le programme pourrait être dans un EEPROM , mémoire flash protégée de l'écrit, un CD-ROM ou quoi que ce soit où le matériel désactive physiquement l'écriture physique. Si le logiciel écrit à ROM, le matériel est incapable de changer les données stockées, de sorte que rien ne se passe.
Donc, si un logiciel dans ROM veut écrire en mémoire, il écrit à RAM . C'est la seule option. Si un programme est en cours de rom et veut changer elle-même , il ne peut pas parce qu'il ne peut pas écrire à la rom. Mais oui, le programme peut fonctionner de RAM.
En fait, l'exécution de la ROM est rare sauf dans les plus petits systèmes intégrés. Les systèmes d'exploitation Copier le code exécutable de ROM à la RAM avant de l'exécuter. Parfois, Le code est compressé en ROM et doit être décompressé dans la RAM avant de courir. Si la RAM est pleine, le système d'exploitation utilise Paging pour le gérer. La raison en qui concerne la ROM est si rare est que RARE est que la ROM est plus lente que la RAM et parfois le code doit être modifié par le Chargeur avant de courir.
Notez que si vous avez du code qui se modifie, vous devez vraiment connaître votre système. De nombreux systèmes utilisent Prévention de l'exécution de données (DEP). Le code exécutable va en lecture + Exécuter des zones de RAM. Les données vont en lecture + zones d'écriture. Donc sur ces systèmes, le code ne peut jamais se changer en RAM.
Hmm .. SO ROM est utilisé uniquement car il peut contenir le code entre la mise sous / off. Autre que celui que nous dépensons deux fois (une fois pour la ROM et pour la RAM). Je me demande si seule la RAM peut être persistante entre les bottes, alors nous pouvons totalement éliminer la ROM? Ni flash & xip (exécuté en place) pourrait être. Je vais vérifier Wiki pour plus. Merci pour une réponse détaillée! :)
@MS: la raison pour laquelle le système actuel fonctionne si bien est que le code exécutable est très faible par rapport aux données. Vous dépensez deux fois, mais le code peut être partagé via des bibliothèques. Et même des programmes complexes ont tendance à être plus petits qu'une image JPEG haute résolution. Mais rapide, une bélier persistant pas cher serait une bonne technologie d'avoir, à coup sûr. La vitesse est importante dans les PC à usage général, c'est pourquoi il existe souvent des schémas de mise en cache à plusieurs niveaux: le disque dur mis en cache pour flash en cache en cache en cache en cache à processeur L1 et L2. Dans les systèmes adaptés à une utilisation spécifique, l'exécution de Flash pourrait être suffisamment rapide.
Merci vivre! Je me demande maintenant ce qui se passe dans la ROM quand nous flasions l'exécutable? Qu'advient-il des données qu'il a besoin lorsque la lecture / écriture se produit? Si seulement l'exécutable (code) que nous clignodifions dans ROM, comment est la configuration de la carte mémoire pour le code dans la ROM et les données en RAM pendant l'exécution?
Il y a peu de raisons légitimes pour lesquelles vous souhaitez modifier la section Code à l'exécution. Le compilateur lui-même ne générera pas de code qui nécessite cela.
Votre lieur aura une option pour générer un fichier de carte. Cela vous indiquera où tous les objets de mémoire sont situés.
La liaison choisit où localiser sur la base d'un script de liaison (que vous pouvez personnaliser pour organiser la mémoire à votre guise). Typiquement, sur un code de microcontrôleur basé sur un flash et des données constantes seront placées dans ROM. Également placé dans la ROM sont les données d'initialisation des données statiques initialisées non nuls, celles-ci sont copiées à la RAM avant que le principal () soit appelée. Les données statiques initialisées zéro sont simplement effacées à zéro avant la principale ().
Il est possible d'organiser la liaison pour localiser tout ou partie du code dans ROM et que le code de démarrage d'exécution de l'heure copie-le à la RAM de la même manière que les données statiques non zéro, mais le code doit être soit relocatoire ou être situé à la RAM dans la première instance, vous ne pouvez généralement pas simplement copier le code destiné à fonctionner à partir de la ROM à la RAM et à s'attendre à ce qu'elle fonctionne car elle peut avoir des références d'adresses absolues (à moins que votre cible ait peut-être une MMU et peut remapper l'espace d'adressage). La localisation en RAM sur les micro-contrôleurs est normalement effectuée pour augmenter la vitesse d'exécution, car la RAM est généralement plus rapide que Flash lorsque des vitesses d'horloge élevées sont utilisées, produisant moins d'états d'attente ou à zéro. Il peut également être utilisé lorsque le code est chargé au moment de l'exécution d'un système de fichiers plutôt que de stocké dans ROM. Même lorsqu'il est chargé dans la RAM, si le processeur a un MMU, il est probable que la section de code de la section RAM sera marquée en lecture seule.
Merci! Je suis capable de tout mettre ensemble ensemble maintenant. :)
De nombreux petits microcontrôleurs (PIC Microchip, Atmel AVR, Intel 8051, Cypress PSOC, etc.) ont une architecture de Harvard.
Ils ne peuvent exécuter que le code de la mémoire du programme (Flash ou ROM).
Il est possible de copier n'importe quel octet de la mémoire du programme à la RAM.
Cependant, Copier Data de la ROM à la RAM est assez courant.
Lorsque l'alimentation est d'abord appliquée, une application de micrologiciel typique Zeros Toutes la RAM puis copie les valeurs initiales des variables globales et statiques non constituées de la ROM dans la RAM juste avant le début principal ().
Chaque fois que l'application doit appuyer sur une chaîne fixe sur le port série, il lit cette chaîne hors de la ROM.
avec des versions précoces de ces microcontrôleurs, un "programmateur de périphérique" externe connecté au microcontrôleur est le seul moyen de modifier le programme.
En fonctionnement normal, l'appareil n'était nulle part près d'un "programmeur de périphérique".
Si le logiciel exécuté sur le microcontrôleur doit écrire à la mémoire de la mémoire de programme - désolé, trop mal -
c'était impossible.
De nombreux systèmes embarqués avaient une EEPROM non volatile que le code pouvait écrire à - mais c'était uniquement pour stocker des valeurs de données. Le microcontrôleur n'a pu exécuter que du code dans la ROM de programme, pas l'EEPROM ou la RAM.
Les gens ont fait des choses merveilleuses avec ces microcontrôleurs, notamment des interprètes de base et des interprètes de bytecode.
Donc, apparemment (1) code n'a jamais besoin d'écrire à la mémoire du programme.
avec quelques microcontrôleurs récents "auto-programmation" (de l'atmosphère, de la micropuce, de la cyprès, etc.),
Il existe un matériel spécial sur la puce qui permet aux logiciels exécutant sur le microcontrôleur d'effacer et de reprogrammer des blocs de son propre flash de mémoire de programme.
Quelques-quelques applications utilisent cette fonctionnalité "auto-programmation" pour lire et écrire des données sur "Extra" Blocks Flash - Données qui ne sont jamais exécutées, il ne compte donc pas comme code auto-modificateur - mais cela ne fait rien Vous ne pouviez pas faire avec un plus grand EEPROM.
Jusqu'à présent, je n'ai vu que deux types de logiciels en cours d'exécution sur les microcontrôleurs de Harvard-Architecture qui écrivent un nouveau logiciel exécutable à son propre programme Flash: BootLoaders et Forth Compilers.
Lorsque le chargeur de démarrage Arduino (bootstrap loader) exécute et détecte qu'une nouvelle image de microprogramme d'application est disponible, il télécharge le nouveau micrologiciel d'application (en RAM) et l'écrit pour flash.
La prochaine fois que vous allumez le système, il s'agit actuellement de nouveau micrologiciel de l'application de la version 16.98, plutôt que du micrologiciel de l'application Clunky Old Version 16.97.
(Les blocs flash contenant le chargeur de démarrage lui-même sont bien sûr inchangés).
Cela serait impossible sans la caractéristique "auto-programmation" d'écriture à la mémoire de programme.
Certaines implémentations d'une partie exécutent sur un petit microcontrôleur, compilant un nouveau code exécutable et en utilisant la fonction "auto-programmation" pour la stocker dans le flash de programme - un processus quelque peu analogue à la compilation "juste à temps" de la JVM.
(Toutes les autres langues semblent nécessiter un compilateur beaucoup trop grand et compliqué à courir sur un petit microcontrôleur et disposent donc d'un cycle d'exécution de la compilation édition-compilé qui prend beaucoup plus de temps d'horloge murale).
Vous parlez de code auto-modificateur?
En fait, ma question semble que! Mais mon doute réel est ce qui va dans la ROM? Seule la région de .text (code) et non les données (RW) lorsque nous clignotant le binaire? Dans ce cas, qu'est-ce que nous clignons dans ROM? Une chargeuse s'occupe-t-elle de la mappage de la cartographie / du code à la ROM et de quoi que ce soit des données RW à la RAM? Meilleures salutations..