Flash et RAM: exécution de code

J'ai récemment commencé à apprendre l'assemblage et j'ai découvert les scripts de l'éditeur de liens et d'autres détails de bas niveau sur la programmation matérielle. J'enseigne également l'architecture informatique et quelque part le long de la ligne, j'ai eu peur que mon image du modèle de mémoire ait toujours été erronée.

Selon ce que je comprends actuellement, tout le code et les données résident sur la mémoire non volatile juste après avoir `` gravé '' le binaire sur un processeur - la RAM volatile ne contient rien lors de la réinitialisation. Lorsque le programme commence à «s'exécuter», il le fait à partir de l'adresse 0x0000 qui est presque toujours (AFAIK) l'adresse la plus basse dans Flash. Ainsi, les instructions sont verrouillées sur le bus reliant Flash au cœur du processeur et c'est là que l'exécution réelle a lieu. Cependant, lorsque nous parlons de la récupération ou du stockage de données de la CPU par le CPU, nous parlons généralement de RAM - je suis conscient que nous pouvons également lire / écrire des données à partir de la mémoire du programme (j'ai vu cela fait sur les AVR) mais n'est-ce pas aussi courant? Est-ce parce que la RAM est plus rapide que la ROM que nous préférons y stocker des données?

La réponse acceptée à cette question indique que la plupart des morceaux de code s'exécutent hors de la RAM.

Cela signifie-t-il que le code d'exécution de démarrage (qui s'exécute lui-même à partir de Flash) doit copier tous les opcodes du programme de Flash vers la RAM et mappe en quelque sorte les adresses dans Flash pour pointer vers la RAM afin que le CPU récupère les opcodes à partir de là? Est-il similaire au processus dans lequel nous déplaçons les sections .data de la ROM vers la RAM au démarrage?

Je peux imaginer que cela soit plus simple dans les architectures von Neumann où le programme et les mémoires de données partagent un bus, mais dans les architectures Harvard, cela ne signifierait-il pas que tout le code et les données doivent d'abord passer par les registres du processeur?

Comme vous pouvez probablement le deviner, je suis un peu trop confus par toute cette affaire. Ayant toujours programmé à un niveau d'abstraction plus élevé, je suis facilement troublé par de tels détails. Toute aide est appréciée.

Cela dépend de l'appareil.

La RAM peut être construite plus rapidement que Flash; cela commence à devenir important dans la gamme des 100 MHz.

Microcontrôleurs simples

Les petits microcontrôleurs lents s'exécutent directement depuis Flash. Ces systèmes ont généralement plus de Flash que de SRAM.

Systèmes de milieu de gamme

Une fois que votre appareil devient plus rapide, la situation est un peu différente. Les systèmes ARM de milieu de gamme peuvent également le faire, ou ils peuvent avoir un chargeur de démarrage ROM de masque qui fait quelque chose de plus intelligent: peut-être en téléchargeant du code à partir d'USB ou d'EEPROM externes dans la SRAM interne.

Grands systèmes

Les systèmes plus grands et plus rapides auront une DRAM externe et une Flash externe. Ceci est typique d'une architecture de téléphone mobile. À ce stade, il y a beaucoup de RAM disponible et c'est plus rapide que le Flash, donc le chargeur de démarrage le copiera et l'exécutera. Cela peut impliquer de le pelleter à travers les registres du processeur ou cela peut impliquer un transfert DMA si une unité DMA est disponible.

Les architectures Harvard sont généralement petites, donc ne vous embêtez pas avec la phase de copie. J'ai vu un ARM avec "harvard hybride", qui est un espace d'adressage unique contenant diverses mémoires mais deux unités de récupération différentes. Le code et les données peuvent être récupérés en parallèle, tant qu'ils ne proviennent pas de la même mémoire. Vous pouvez donc récupérer le code de Flash et les données de SRAM, ou le code de SRAM et les données de DRAM, etc.

La RAM est généralement plus rapide que le flash, mais cela n'a pas vraiment d'importance jusqu'à ce que vous atteigniez des vitesses d'horloge supérieures à 80-100 MHz environ - tant que le temps d'accès au flash est plus rapide que le temps nécessaire pour exécuter une instruction, il ne devrait pas avoir d'importance.

La construction physique de la RAM nous permet de construire des appareils très rapides; beaucoup plus rapide que le flash. À ce stade, il est logique de copier des blocs de code dans la RAM avant l'exécution. Cela apporte également des avantages supplémentaires au développeur, comme la possibilité de modifier le code lors de l'exécution.

dans les architectures von Neumann où le programme et les mémoires de données partagent un bus mais dans les architectures de Harvard, cela ne signifierait-il pas que tout le code et les données doivent d'abord passer par les registres CPU?

Pas nécessairement. C'est là que l' adressage virtuel entre en jeu. Au lieu que le code de programme fasse référence aux adresses RAM matérielles brutes, il fait en fait référence à un espace d'adressage virtuel. Des blocs d'espace d'adressage virtuel sont mappés sur des périphériques de mémoire physique, qui peuvent être des mémoires RAM, ROM, flash ou même des tampons de périphérique.

Par exemple, lorsque vous référencez l'adresse 0x000f0004 sur un micro, vous lisez peut-être l'adresse 0x0004 à partir du flash. L' adresse virtuelle est 0x000f0004, mais l'adresse physique n'est que 0x0004 - tout l'espace d'adressage 0x000fxxxx est mappé sur un périphérique de mémoire physique de 4 Ko. Ceci n'est qu'un exemple, bien sûr, et la méthode de gestion et d'organisation de l'espace d'adressage virtuel diffère considérablement selon les architectures.

En tant que tel, lorsque vous dites que "le programme commence à s'exécuter [...] à partir de l'adresse 0x0000 qui est presque toujours l'adresse la plus basse en flash", vous n'êtes pas assuré d'être correct. En fait, de nombreux microcontrôleurs commencent à 0x1000.

Ce que vous dites n'est pas complètement vrai ou faux. Il existe différents scénarios pour cela.

Cela dépend si vous programmez sur le matériel brut ou sur le matériel installé avec OS.

Votre système d'exploitation exécuté sur l'ordinateur à usage général récupère le code du disque dur et le stocke sur la RAM pour un accès plus rapide. Si votre processeur essaie de récupérer directement à partir du disque dur sur une base continue, les opérations seraient beaucoup plus lentes en raison d'un décalage de vitesse entre deux. Ainsi, votre RAM entre en jeu où un morceau de votre code répétitif est stocké pour un accès plus rapide. Et cela encore plus est rendu disponible sur la mémoire cache du processeur pour la rendre encore plus rapide.

Maintenant, lorsque vous travaillez sur un microcontrôleur, tout dépend de vous où vous localisez vos données sur la puce. Si les données sont statiques, vous voudrez peut-être les localiser dans la mémoire de code, ce qui économisera votre RAM, qui est comparativement beaucoup plus petite que la mémoire de code. En langage C lorsque vous initialisez le type de données à l'aide de données statiques ou dans certains compilateurs, le préfixe const sera stocké dans la mémoire de code ou bien sera stocké dans la RAM. Et dans l'assemblage, vous utilisez directement DB (Define Byte dans le cas de Basic 8051) pour initialiser les données sur l'emplacement particulier. Maintenant, même dans certains contrôleurs comme PIC ARM, vous pouvez écrire de la ROM au moment de l'exécution, mais la récupération des données prendra beaucoup de temps.

De plus, il existe des matériels de chargeur de démarrage dans les contrôleurs de niveau moyen et sophistiqués qui indiquent aux contrôleurs ou au processeur où exécuter le code de démarrage ou c'est lui-même le code de démarrage qui est réellement segmenté dans la mémoire.Il y a donc beaucoup de possibilités d'avancement , Je dirais plutôt advnacement hybride dans l'industrie qui brouille tout le concept de RAM ROM & mémoires conventionnelles. Donc, fondamentalement, votre confusion est valable.