Qu'entend-on par cache de données et cache d'instructions?
De ici :
Les instructions et les données ont des modèles d'accès différents et accèdent à différentes régions de la mémoire. Ainsi, avoir le même cache pour les instructions et les données peut ne pas toujours fonctionner.
Ainsi, il est assez courant d'avoir deux caches: un cache d'instructions qui ne stocke que des instructions et un cache de données qui ne stocke que des données.
Il est intuitif de connaître la distinction entre instructions et données, mais maintenant je ne suis pas sûr de la différence dans ce contexte? Qu'est-ce qui constitue des données et est placé dans un cache de données et qu'est-ce qui constitue des instructions et est placé dans un cache d'instructions?
Je sais ARM Assembly. Est-ce que quelque chose nécessitant STR, LDR, LDMF ou STMFD utiliserait le cache de données? Mais techniquement parlant STR, LDR, LDMF et STMFD sont toutes des instructions, donc c'est pourquoi je suis confus. Les "données" doivent-elles toujours exister avec un "instruction"? Les données sont-elles considérées comme quelque chose dans le .data section?
Par exemple LDR R1, =myVar alors LDR irait-il dans le cache d'instructions et le contenu de myVar irait-il dans le cache de données? Ou ça ne marche pas comme ça?
Les instructions et les données ont des schémas d'accès différents. Quelqu'un pourrait-il préciser?
Ce commentaire que j'ai fait sur un article utile souligne ma difficulté à comprendre:
"L'idée est que si une instruction a été chargée depuis la mémoire, elle sera probablement réutilisée prochainement" mais la seule façon de connaître la prochaine instruction est de la lire. Cela signifie une lecture en mémoire (vous ne pouvez pas dire qu'elle est déjà dans le cache car une nouvelle instruction est en rouge). Donc je ne vois toujours pas l'intérêt? Supposons qu'une instruction LDR vient de se produire, alors maintenant LDR est dans le cache de données. Peut-être qu'une autre instruction LDR se produira, peut-être que ce ne sera pas le cas, nous ne pouvons pas être sûrs, nous devons donc lire la prochaine instruction - ce qui va à l'encontre de l'objectif du cache.
Les récupérations d'instructions peuvent être effectuées par blocs en supposant que la plupart du temps, vous allez exécuter de nombreuses instructions d'affilée. de sorte que les récupérations d'instructions peuvent être plus efficaces, il y a probablement une ou plusieurs horloges de surcharge par transaction, puis le délai pour que la mémoire ait les données prêtes, puis une horloge par largeur du bus pour la taille de la transaction. 8 mots ou instructions pourraient être disons 5 + n + 8 horloges par exemple, c'est plus efficace qu'une instruction à la fois (5 + 1 + 1) * 8.
Les données d'un autre côté, ce n'est pas une bonne hypothèse que les données seront lues séquentiellement la plupart du temps, de sorte que des cycles supplémentaires peuvent nuire, ne récupèrent que les données demandées (jusqu'à la largeur de la mémoire ou du bus car c'est un cadeau gratuit) ).
Sur les ARM que je connais sur le cache L1, I et D sont séparés, L2 ils sont combinés. L1 n'est pas sur le bus axi/amba et est probablement plus efficace d'un accès que le L2 et au-delà qui sont amba/axi (quelques cycles de surcharge plus le temps plus une horloge par largeur de bus de données pour chaque transaction).
Pour les espaces d'adressage qui sont marqués comme pouvant être mis en cache (si le mmu est activé), le L1 et par conséquent L2 va chercher une ligne de cache au lieu de l'élément individuel pour les données et peut-être plus qu'une quantité de données I pour une extraction d'instructions.
Chacune de vos instructions ldr et ldm va entraîner des cycles de données qui peuvent, si l'adresse peut être mise en cache, aller dans les caches L2 et L1 s'ils ne sont pas déjà là. l'instruction elle-même également à une adresse pouvant être mise en cache ira dans les caches L2 et L1 si elle n'y est pas déjà. (oui, il y a beaucoup de boutons pour contrôler ce qui peut être mis en cache et non, ne voulez pas entrer dans ces nuances, supposez simplement, pour les besoins de la discussion, que toutes ces récupérations d'instructions et tous les accès aux données sont en cache).
Vous souhaitez enregistrer les instructions qui viennent d'être exécutées dans le cache au cas où vous auriez une boucle ou réexécuter ce code. Les instructions qui suivent dans la ligne de cache bénéficieront également de la surcharge économisée de l'accès plus efficace. mais si vous n'exécutez que sur un petit pourcentage de la ligne de cache, alors dans l'ensemble, ces cycles sont un gaspillage, et si cela se produit trop, le cache ralentit les choses.
Une fois que quelque chose est dans un cache, la prochaine fois qu'il est lu (ou écrit en fonction des paramètres), la copie du cache est celle qui est utilisée, pas la copie en mémoire lente. Finalement (selon les paramètres) si la copie du cache d'un élément a été modifiée en raison d'une écriture (str, stm) et qu'un nouvel accès doit être enregistré dans le cache, puis un ancien est expulsé pour ralentir la mémoire et une écriture à partir de le cache pour ralentir la mémoire se produit. Vous n'avez pas ce problème avec les instructions, les instructions sont essentiellement en lecture seule, vous n'avez donc pas à les réécrire dans la mémoire lente, en théorie, la copie de cache et la copie de mémoire lente sont les mêmes.
ldr r1,=myvar
entraînera une charge relative de PC
ldr r1,something
...
something: .Word myvar
l'instruction ldr fera partie d'une extraction de ligne de cache, d'une extraction d'instruction (avec un tas d'instructions supplémentaires). ceux-ci seront enregistrés dans la partie I du cache L1 sur un bras et la partie partagée de L2 (si activée, etc.). Lorsque cette instruction est finalement exécutée, l'adresse de quelque chose subira une lecture de données qui, si la mise en cache est activée dans cette zone pour cette lecture, elle ira également dans le cache L2 et L1 (partie D) si elle n'y est pas déjà. Si vous bouclez et exécutez à nouveau cette instruction immédiatement, alors idéalement, l'instruction sera dans le cache L1 et le temps d'accès pour la récupérer est très rapide, une poignée d'horloges au total. Les données seront également dans le cache L1 et seront également une poignée d'horloges à lire.
Le 5 + n + 8 que j'ai mentionné ci-dessus, un certain nombre d'horloges de surcharge (5 est juste une possibilité, il peut varier à la fois par la conception et par ce qui se passe en parallèle). le N dépend des vitesses de mémoire plus lentes. que n est assez grand pour dram, donc les caches l2 et L1 sont beaucoup plus rapides, et c'est pourquoi le cache est là pour réduire le grand nombre de cycles d'horloge pour chaque accès dram, efficace ou non.
Le cache d'instructions comprendrait des lignes de cache extraites de la mémoire pour exécution. Le cache de données comprendrait des lignes de cache extraites de la mémoire pour être chargées dans un registre en tant que données.
Le cache d'instructions n'est qu'un autre niveau de mémoire pour accéder plus rapidement aux instructions. Cela ne fait pas partie de la logique d'horloge/parties internes/fetch-decode-execute du processeur - mais vous le nommeriez.
Quand on dit que l'instruction est mise en cache, cela signifie, elle est très proche du niveau de mémoire du processeur, donc lorsque le processeur doit charger l'instruction à l'adresse X, il le fait très rapidement par rapport à une autre adresse Y.
Les CPU en interne ne mettent pas en cache les instructions.
Les instructions et les données ont des modèles d'accès différents. Quelqu'un pourrait-il préciser?
Par exemple, il est mal vu de mettre à jour (écraser) les instructions et ce n'est pas courant. Donc, si vous concevez un cache pour les instructions, vous pouvez l'optimiser pour les lectures. Les instructions sont également séquentielles, donc si le processeur accède à l'instruction à N, il est probable qu'il accédera également à l'instruction à N + 1. Cependant, ces deux propriétés ne peuvent pas être aussi importantes pour les caches de données, ou les caches de données doivent être beaucoup plus détaillés.