Escalade d'Elbrus - Reconnaissance au combat. Partie technique 1. Registres, piles et autres détails techniques

Comme promis , nous continuons de parler du développement des processeurs Elbrus . Cet article est technique. Les informations données dans l'article ne sont pas des documents officiels, car elles ont été obtenues lors de l'étude d'Elbrus un peu comme une boîte noire. Mais cela sera certainement intéressant pour une meilleure compréhension de l'architecture d'Elbrus, car bien que nous disposions d'une documentation officielle, de nombreux détails ne sont devenus clairs qu'après de longues expériences, quand Embox a fonctionné.

Rappelez-vous que dans l' article précédent, nous avons parlé du démarrage du système de base et du pilote de port série. Embox a commencé, mais pour avancer, nous avions besoin d'interruptions, d'une minuterie système et, bien sûr, je voudrais inclure un ensemble de tests unitaires, et pour cela, nous avons besoin de setjmp. Cet article se concentrera sur les registres, les piles et autres détails techniques nécessaires pour implémenter toutes ces choses.

Commençons par une brève introduction à l'architecture, qui est le minimum d'informations nécessaires pour comprendre ce qui sera discuté plus tard. À l'avenir, nous nous référerons aux informations de cette section.

Brève introduction: piles

Il y a trois piles dans Elbrus:

• Pile de procédures (PS)
• Pile de chaîne de procédure (PCS)
• Pile utilisateur (US)

Analysons-les plus en détail. Les adresses sur la figure sont conditionnelles, montrent dans quelle direction les mouvements sont dirigés - d'une adresse plus grande à une plus petite ou vice versa.



La pile de procédures (PS) est destinée aux données allouées aux registres «opérationnels».

Par exemple, il peut s'agir d'arguments fonctionnels: dans les architectures «ordinaires», ce concept est le plus proche des registres à usage général. Contrairement aux architectures de processeur «normales», dans E2K, les registres utilisés dans les fonctions sont empilés sur une pile distincte.

La pile d'informations de liaison (PCS) est conçue pour placer des informations sur la procédure (d'appel) précédente et utilisée lors du retour. Les données sur l'adresse de retour, ainsi que dans le cas des registres, sont placées dans un endroit séparé. Par conséquent, la promotion de la pile (par exemple, pour quitter par exception en C ++) est un processus plus long que dans les architectures «ordinaires». D'un autre côté, cela élimine les problèmes de débordement de pile.

Ces deux piles (PS et PCS) sont caractérisées par une adresse de base, une taille et un décalage actuel. Ces paramètres sont définis dans les registres PSP et PCSP, ils sont 128 bits et dans l'assembleur, vous devez vous référer à des champs spécifiques (par exemple, haut ou bas). De plus, le fonctionnement des piles est étroitement lié au concept de fichier de registre, plus sur celui ci-dessous. L'interaction avec le fichier se produit via le mécanisme de pompage / échange de registres. Un rôle actif dans ce mécanisme est joué par le soi-disant «pointeur matériel vers le haut de la pile» de la procédure ou pile d'informations de liaison, respectivement. À ce sujet également ci-dessous. Il est important qu'à chaque instant les données de ces piles soient soit en RAM soit dans un fichier registre.

Il convient également de noter que ces piles (la pile procédurale et la pile d'informations de liaison) se développent. Nous l'avons rencontré lorsque nous avons implémenté context_switch.

La pile d'utilisateurs reçoit également l'adresse et la taille de base. Le pointeur actuel est dans le registre USD.lo. À la base, c'est une pile classique qui grandit. Seulement, contrairement aux architectures «ordinaires», les informations provenant d'autres piles (registres et adresses de retour) ne s'y adaptent pas.

À mon avis, une exigence non standard pour les limites et les tailles des piles est l'alignement 4K, et l'adresse de base de la pile et sa taille doivent être alignées sur 4K. Dans d'autres architectures, je n'ai pas rencontré une telle restriction. Nous avons rencontré ce détail, encore une fois, lorsque nous avons implémenté context_switch.

Brève introduction: Registres. Enregistrez les fichiers. Enregistrer les fenêtres

Maintenant que nous avons un peu compris les piles, nous devons comprendre comment les informations y sont présentées. Pour ce faire, nous devons introduire quelques concepts supplémentaires.

Un fichier de registre (RF) est un ensemble de tous les registres. Il y a deux fichiers de registre dont nous avons besoin: un fichier d'informations de connexion (fichier de chaîne - CF), l'autre est appelé fichier de registre (RF), il stocke des registres «opérationnels», qui sont stockés sur la pile procédurale.

La fenêtre de registre est la zone (ensemble de registres) du fichier de registre actuellement disponible.

Je vais vous expliquer plus en détail. Qu'est-ce qu'un ensemble de registres, je pense, que personne n'a besoin d'expliquer.

Il est bien connu que l'un des goulots d'étranglement dans l'architecture x86 est précisément un petit nombre de registres. Dans les architectures RISC avec registres, c'est plus simple, généralement autour de 16 registres, dont plusieurs (2-3) sont occupés pour les besoins officiels. Pourquoi ne pas simplement créer 128 registres, car il semblerait que cela augmentera les performances du système? La réponse est assez simple: une instruction de processeur a besoin d'un endroit pour stocker l'adresse du registre, et s'il y en a beaucoup, beaucoup de bits sont également nécessaires pour cela. Par conséquent, ils passent à toutes sortes de trucs, créent des registres fantômes, enregistrent des banques, des fenêtres, etc. Par registres fictifs, j'entends le principe de l'organisation des registres dans ARM. Si une interruption ou une autre situation se produit, alors un ensemble différent de registres portant les mêmes noms (numéros) est disponible, tandis que les informations stockées dans l'ensemble d'origine restent là. Les banques de registres, en fait, sont très similaires aux registres fictifs, il n'y a tout simplement pas de commutation matérielle des ensembles de registres, et le programmeur choisit la banque (ensemble de registres) à contacter maintenant.

Les fenêtres de registre sont conçues pour optimiser le travail avec la pile. Comme vous le comprenez probablement, dans une architecture «normale», vous entrez une procédure, enregistrez les registres dans la pile (ou la procédure d'appel enregistre, dépend de l'accord) et vous pouvez utiliser des registres, car les informations sont déjà stockées sur la pile. Mais l'accès à la mémoire est lent et doit donc être évité. Lorsque vous entrez dans la procédure, rendons simplement disponible un nouvel ensemble de registres, les données de l'ancien seront enregistrées, ce qui signifie que vous n'avez pas besoin de le vider en mémoire. De plus, lorsque vous revenez à la procédure d'appel, la fenêtre de registre précédente renverra également, par conséquent, toutes les données sur les registres seront pertinentes. C'est le concept d'une fenêtre de registre.



Il est clair que vous devez encore enregistrer les registres sur la pile (en mémoire), mais cela peut être fait lorsque les fenêtres de registres libres sont terminées.

Et que faire des registres d'entrée et de sortie (arguments lors de la saisie de la fonction et du résultat renvoyé)? Laissez la fenêtre contenir une partie des registres visibles depuis la fenêtre précédente, plus précisément, une partie des registres sera disponible pour les deux fenêtres. Ensuite, en général, lors de l'appel de la fonction, vous n'avez pas besoin d'accéder à la mémoire. Supposons que nos registres ressemblent à ceci



C'est-à-dire que r0 dans la première fenêtre sera le même registre que r2 à zéro et r1 de la première fenêtre dans le même registre que r3. Autrement dit, en écrivant en r2 avant d'appeler la procédure (en changeant le numéro de fenêtre), nous obtenons la valeur en r0 dans la procédure appelée. Ce principe est appelé mécanisme de rotation des fenêtres.

Optimisons un peu plus, car les créateurs d'Elbrus l'ont fait. Soit les fenêtres que nous avons ne seront pas de taille fixe, mais variable, la taille de la fenêtre peut être définie au moment de l'entrée dans la procédure. Nous ferons de même avec le nombre de registres tournés. Bien sûr, cela nous conduira à certains problèmes, car si dans les fenêtres rotatives classiques, il existe un index de fenêtre à travers lequel il est déterminé que vous devez enregistrer les données du fichier de registre sur la pile ou les charger. Mais si vous entrez non pas l'index de la fenêtre, mais l'index du registre à partir duquel notre fenêtre actuelle démarre, ce problème ne se posera pas. Dans Elbrus, ces indices sont contenus dans les registres PSHTP (pour la pile de procédures PS) et PCSHTP (pour la pile d'informations procédurales PCS). La documentation fait référence aux «pointeurs matériels vers le haut de la pile». Maintenant, vous pouvez réessayer de lire sur les piles, je pense que ce sera plus clair.

Comme vous le comprenez, un tel mécanisme implique que vous avez la possibilité de contrôler ce qui est en mémoire. Autrement dit, synchronisez le fichier de registre et la pile. Je veux dire un programmeur système. Si vous êtes un programmeur d'applications, l'équipement fournira une entrée et une sortie transparentes de la procédure. Autrement dit, s'il n'y a pas suffisamment de registres lorsque vous essayez de sélectionner une nouvelle fenêtre, la fenêtre de registre se «pompera» automatiquement. Dans ce cas, toutes les données du fichier de registre seront enregistrées sur la pile appropriée (en mémoire) et le «pointeur vers le haut du matériel de la pile» (index de décalage) sera remis à zéro. De même, l'échange d'un fichier de registre de la pile se produit automatiquement. Mais si vous développez, par exemple, le changement de contexte, ce qui est exactement ce que nous avons fait, alors vous avez besoin d'un mécanisme pour travailler avec la partie cachée du fichier de registre. Dans Elbrus, les commandes FLUSHR et FLUSHC sont utilisées pour cela. FLUSHR - effacement du fichier de registre, toutes les fenêtres à l'exception de la fenêtre actuelle sont vidées dans la pile procédurale, l'index PSHTP est par conséquent remis à zéro. FLUSHC - effacement du fichier d'informations de liaison, tout sauf la fenêtre actuelle est vidé sur la pile d'informations de liaison, l'index PCSHTP est également remis à zéro.

Brève introduction: mise en œuvre dans Elbrus

Maintenant que nous avons discuté du travail non évident avec les registres et les piles, nous parlerons plus spécifiquement de diverses situations dans Elbrus.

Lorsque nous entrons dans la fonction suivante, le processeur crée deux fenêtres: une fenêtre sur la pile PS et une fenêtre sur la pile PCS.

Une fenêtre de la pile PCS contient les informations nécessaires pour revenir d'une fonction: par exemple, IP (Instruction Pointer) de l'instruction où vous devrez revenir de la fonction. Avec cela, tout est plus ou moins clair.

La fenêtre de la pile PS est un peu plus délicate. Le concept de registres de la fenêtre courante est introduit. Dans cette fenêtre, vous aurez accès aux registres de la fenêtre actuelle -% dr0,% dr1, ...,% dr15, ... Autrement dit, pour nous, en tant qu'utilisateur, ils sont toujours numérotés à partir de 0, mais c'est une numérotation relative à l'adresse de base de la fenêtre actuelle. Par le biais de ces registres, les arguments sont transmis lors de l'appel de la fonction, la valeur est renvoyée et la fonction est utilisée comme registre à usage général dans la fonction. En fait, cela a été expliqué lors de l'examen du mécanisme de rotation des fenêtres de registre.

La taille de la fenêtre d'enregistrement dans Elbrus peut être contrôlée. Comme je l'ai dit, cela est nécessaire à l'optimisation. Par exemple, dans une fonction, nous n'avons besoin que de 4 registres pour passer des arguments et certains calculs, dans ce cas, le programmeur (ou le compilateur) décide du nombre de registres à allouer pour la fonction, et en fonction de cela, il définit la taille de la fenêtre. La taille de la fenêtre est définie par l'opération setwd:

setwd wsz=0x10 

Spécifie la taille de la fenêtre en termes de registres quadruples (registres 128 bits).



Supposons maintenant que vous souhaitiez appeler une fonction à partir d'une fonction. Pour cela, le concept déjà décrit d'une fenêtre de registre tourné est appliqué. L'image ci-dessus montre un fragment d'un fichier de registre où une fonction avec fenêtre 1 (verte) appelle une fonction avec fenêtre 2 (orange). Dans chacune de ces deux fonctions, vous aurez accès à vos% dr0,% dr1, ... Mais les arguments seront passés par les registres dits rotatifs. En d'autres termes, une partie des registres de la fenêtre 1 deviendra les registres de la fenêtre 2 (notez que ces deux fenêtres se croisent). Ces registres sont également définis par la fenêtre (voir Registres rotatifs dans l'image) et ont l'adresse% db [0],% db [1], ... Ainsi, le registre% dr0 dans la fenêtre 2 n'est rien de plus que le registre% db [0] dans fenêtre 1.

La fenêtre du registre de rotation est définie par l'opération setbn:

  setbn rbs = 0x3, rsz = 0x8 

rbs définit la taille de la fenêtre pivotée et rsz définit l'adresse de base, mais par rapport à la fenêtre de registre actuelle. C'est-à-dire Ici, nous avons alloué 3 registres, à partir du 8.

Sur la base de ce qui précède, nous montrons à quoi ressemble l'appel de fonction. Pour simplifier, nous supposons que la fonction prend un argument:

 void my_func(uint64_t a) { } 

Ensuite, pour appeler cette fonction, vous devez préparer une fenêtre de registres rotatifs (nous l'avons déjà fait via setbn). Ensuite, dans le registre% db0, nous mettons la valeur qui sera transmise à my_func. Après cela, vous devez appeler l'instruction CALL et n'oubliez pas de lui dire où commence la fenêtre des registres tournés. Nous sautons maintenant la préparation de l'appel (la commande disp), car il ne respecte pas la casse. Par conséquent, dans l'assembleur, un appel à cette fonction devrait ressembler à ceci:

  addd 0, %dr9, %db[0] disp %ctpr1, my_func call %ctpr1, wbs = 0x8 

Donc, avec des registres un peu compris. Examinons maintenant la pile d'informations de liaison. Il stocke les registres dits CR. En fait, deux - CR0, CR1. Et ils contiennent déjà les informations nécessaires au retour de la fonction.



Les registres CR0 et CR1 de la fenêtre de la fonction qui a appelé la fonction avec les registres marqués en orange sont verts. Les registres CR0 contiennent le pointeur d'instruction de la fonction appelante et un certain fichier de prédicat (PF-Predicate File), une histoire à ce sujet dépasse définitivement le cadre de cet article.

Les registres CR1 contiennent des données telles que PSR (état du traitement de texte), numéro de fenêtre, tailles de fenêtre, etc. Dans Elbrus, tout est si flexible que chaque procédure stocke des informations dans CR1 même si une opération à virgule flottante est incluse dans la procédure, et un registre contenant des informations sur les exceptions logicielles, mais pour cela, bien sûr, vous devez payer pour enregistrer des informations supplémentaires.

Il est très important de ne pas oublier que le fichier de registre et le fichier d'informations de liaison peuvent être pompés et échangés hors de la mémoire principale et vice versa (à partir des piles PS et PCS décrites ci-dessus). Ce point est important lors de l'implémentation de setjmp décrit plus loin.

SETJMP / LONGJMP

Et enfin, au moins en comprenant comment les piles et les registres sont organisés dans Elbrus, vous pouvez commencer à faire quelque chose d'utile, c'est-à-dire ajouter de nouvelles fonctionnalités à Embox.

Dans Embox, le système de test unitaire nécessite setjmp / longjmp, nous avons donc dû implémenter ces fonctions.

Pour la mise en œuvre, il est nécessaire de sauvegarder / restaurer les registres: CR0, CR1, PSP, PCSP, USD, - déjà familiers pour nous d'une brève introduction. En fait, la sauvegarde / restauration est implémentée dans notre front, mais il y a une nuance importante qui a souvent été suggérée dans la description des piles et des registres, à savoir: les piles doivent être synchronisées, car elles se trouvent non seulement dans la mémoire, mais aussi dans le fichier de registre. Cette nuance signifie que vous devez prendre soin de plusieurs fonctionnalités, sans lesquelles rien ne fonctionnera.

La première fonction consiste à désactiver les interruptions lors de l'enregistrement et de la restauration. Lors de la restauration d'une interruption, il est obligatoire d'interdire, sinon, une situation peut survenir dans laquelle nous entrons dans le gestionnaire d'interruption avec des piles à demi commutées (en référence au pompage du swap de fichier de registre décrit dans la «courte description»). Et lors de l'enregistrement, le problème est qu'après avoir entré et quitté l'interruption, le processeur peut à nouveau échanger une partie du fichier de registre de la RAM (et cela ruinera les conditions invariantes PSHTP = 0 et PSSHTP = 0, un peu plus à leur sujet). C'est pourquoi, dans setjmp et longjmp, les interruptions doivent être désactivées. Il convient également de noter ici que les spécialistes du MCST nous ont conseillé d'utiliser des crochets atomiques au lieu de désactiver les interruptions, mais pour l'instant nous utilisons la mise en œuvre la plus simple (compréhensible pour nous).

La deuxième caractéristique est liée au pompage / pompage d'un fichier de registre depuis la mémoire. C'est comme suit. Le fichier de registre a une taille limitée et est donc souvent pompé en mémoire et vice versa. Par conséquent, si nous enregistrons simplement les valeurs des registres PSP et PSHTP, alors nous fixerons la valeur du pointeur actuel en mémoire et dans le fichier de registre. Mais comme le fichier de registre change, au moment de la restauration du contexte, il indiquera des données déjà incorrectes (pas celles que nous avons «enregistrées»). Pour éviter cela, vous devez vider l'intégralité du fichier de registre en mémoire. Ainsi, lors de l'enregistrement dans setjmp, nous avons des registres PSP.ind en mémoire et des registres PSHTP.ind dans la fenêtre de registre. Il s'avère que vous devez sauvegarder tous les registres PCSP.ind + PCSHTP.ind. Voici la fonction qui effectue cette opération:

 /* First arg is PCSP, 2nd arg is PCSHTP * Returns new PCSP value with updated PCSP.ind */ .type update_pcsp_ind,@function $update_pcsp_ind: setwd wsz = 0x4, nfx = 0x0 /* Here and below, 10 is size of PCSHTP.ind. Here we * extend the sign of PCSHTP.ind */ shld %dr1, (64 - 10), %dr1 shrd %dr1, (64 - 10), %dr1 /* Finally, PCSP.ind += PCSHTP.ind */ addd %dr1, %dr0, %dr0 E2K_ASM_RETURN 

Il est également nécessaire de clarifier un petit point dans ce code décrit dans le commentaire, à savoir, il est nécessaire de développer par programme le caractère dans l'index PCSHTP.ind, car l'index peut être négatif et stocké dans du code supplémentaire. Pour ce faire, nous passons d'abord à (64-10) vers la gauche (registre 64 bits), à un champ de 10 bits, puis à l'arrière.

Il en va de même pour la PSP (pile de procédures)

 /* First arg is PSP, 2nd arg is PSHTP * Returns new PSP value with updated PSP.ind */ .type update_psp_ind,@function $update_psp_ind: setwd wsz = 0x4, nfx = 0x0 /* Here and below, 12 is size of PSHTP.ind. Here we * extend the sign of PSHTP.ind as stated in documentation */ shld %dr1, (64 - 12), %dr1 shrd %dr1, (64 - 12), %dr1 muld %dr1, 2, %dr1 /* Finally, PSP.ind += PSHTP.ind */ addd %dr1, %dr0, %dr0 E2K_ASM_RETURN 

Avec une légère différence (le champ est de 12 bits, et les registres y sont comptés en termes de 128 bits, c'est-à-dire que la valeur doit être multipliée par 2).

Setjmp code lui-même

 C_ENTRY(setjmp): setwd wsz = 0x14, nfx = 0x0 /* It's for db[N] registers */ setbn rsz = 0x3, rbs = 0x10, rcur = 0x0 /* We must disable interrupts here */ disp %ctpr1, ipl_save ipd 3 call %ctpr1, wbs = 0x10 /* Store current IPL to dr9 */ addd 0, %db[0], %dr9 /* Store some registers to jmp_buf */ rrd %cr0.hi, %dr1 rrd %cr1.lo, %dr2 rrd %cr1.hi, %dr3 rrd %usd.lo, %dr4 rrd %usd.hi, %dr5 /* Prepare RF stack to flush in longjmp */ rrd %psp.hi, %dr6 rrd %pshtp, %dr7 addd 0, %dr6, %db[0] addd 0, %dr7, %db[1] disp %ctpr1, update_psp_ind ipd 3 call %ctpr1, wbs = 0x10 addd 0, %db[0], %dr6 /* Prepare CF stack to flush in longjmp */ rrd %pcsp.hi, %dr7 rrd %pcshtp, %dr8 addd 0, %dr7, %db[0] addd 0, %dr8, %db[1] disp %ctpr1, update_pcsp_ind ipd 3 call %ctpr1, wbs = 0x10 addd 0, %db[0], %dr7 std %dr1, [%dr0 + E2K_JMBBUFF_CR0_HI] std %dr2, [%dr0 + E2K_JMBBUFF_CR1_LO] std %dr3, [%dr0 + E2K_JMBBUFF_CR1_HI] std %dr4, [%dr0 + E2K_JMBBUFF_USD_LO] std %dr5, [%dr0 + E2K_JMBBUFF_USD_HI] std %dr6, [%dr0 + E2K_JMBBUFF_PSP_HI] std %dr7, [%dr0 + E2K_JMBBUFF_PCSP_HI] /* Enable interrupts */ addd 0, %dr9, %db[0] disp %ctpr1, ipl_restore ipd 3 call %ctpr1, wbs = 0x10 /* return 0 */ adds 0, 0, %r0 E2K_ASM_RETURN 

Lors de l'implémentation de longjmp, il est important de ne pas oublier la synchronisation des deux fichiers de registre, par conséquent, vous devez vider non seulement la fenêtre de registre (flushr), mais aussi vider le fichier de reliure (flushc). Décrivons la macro:

 #define E2K_ASM_FLUSH_CPU \ flushr; \ nop 2; \ flushc; \ nop 3; 

Maintenant que toutes les informations sont en mémoire, nous pouvons en toute sécurité enregistrer la récupération dans longjmp.

 C_ENTRY(longjmp): setwd wsz = 0x14, nfx = 0x0 setbn rsz = 0x3, rbs = 0x10, rcur = 0x0 /* We must disable interrupts here */ disp %ctpr1, ipl_save ipd 3 call %ctpr1, wbs = 0x10 /* Store current IPL to dr9 */ addd 0, %db[0], %dr9 /* We have to flush both RF and CF to memory because saved values * of P[C]SHTP can be not valid here. */ E2K_ASM_FLUSH_CPU /* Load registers previously saved in setjmp. */ ldd [%dr0 + E2K_JMBBUFF_CR0_HI], %dr2 ldd [%dr0 + E2K_JMBBUFF_CR1_LO], %dr3 ldd [%dr0 + E2K_JMBBUFF_CR1_HI], %dr4 ldd [%dr0 + E2K_JMBBUFF_USD_LO], %dr5 ldd [%dr0 + E2K_JMBBUFF_USD_HI], %dr6 ldd [%dr0 + E2K_JMBBUFF_PSP_HI], %dr7 ldd [%dr0 + E2K_JMBBUFF_PCSP_HI], %dr8 rwd %dr2, %cr0.hi rwd %dr3, %cr1.lo rwd %dr4, %cr1.hi rwd %dr5, %usd.lo rwd %dr6, %usd.hi rwd %dr7, %psp.hi rwd %dr8, %pcsp.hi /* Enable interrupts */ addd 0, %dr9, %db[0] disp %ctpr1, ipl_restore ipd 3 call %ctpr1, wbs = 0x10 /* Actually, we return to setjmp caller with second * argument of longjmp stored on r1 register. */ adds 0, %r1, %r0 E2K_ASM_RETURN 

Changement de contexte

Après avoir compris setjmp / longjmp, l'implémentation de base de context_switch nous a semblé assez claire. En effet, comme dans le premier cas, nous devons sauvegarder / restaurer les registres des informations de connexion et des piles, plus nous devons restaurer correctement le registre d'état du processeur (UPSR).

Je vais vous expliquer. Comme dans le cas de setjmp, lors de la sauvegarde des registres, vous devez d'abord réinitialiser le fichier de registre et le fichier d'informations de liaison en mémoire (flushr + flushc). Après cela, nous devons enregistrer les valeurs actuelles des registres CR0 et CR1 de sorte que lorsque nous reviendrons, sautez exactement d'où le flux actuel a été commuté. Ensuite, nous enregistrons les descripteurs des piles PS, PCS et US. Et enfin, vous devez prendre soin de la restauration correcte du mode d'interruption - à ces fins, nous enregistrons également le registre UPSR.

Code assembleur context_switch:

 C_ENTRY(context_switch): setwd wsz = 0x10, nfx = 0x0 /* Save prev UPSR */ rrd %upsr, %dr2 std %dr2, [%dr0 + E2K_CTX_UPSR] /* Disable interrupts before saving/restoring context */ rrd %upsr, %dr2 andnd %dr2, (UPSR_IE | UPSR_NMIE), %dr2 rwd %dr2, %upsr E2K_ASM_FLUSH_CPU /* Save prev CRs */ rrd %cr0.lo, %dr2 rrd %cr0.hi, %dr3 rrd %cr1.lo, %dr4 rrd %cr1.hi, %dr5 std %dr2, [%dr0 + E2K_CTX_CR0_LO] std %dr3, [%dr0 + E2K_CTX_CR0_HI] std %dr4, [%dr0 + E2K_CTX_CR1_LO] std %dr5, [%dr0 + E2K_CTX_CR1_HI] /* Save prev stacks */ rrd %usd.lo, %dr3 rrd %usd.hi, %dr4 rrd %psp.lo, %dr5 rrd %psp.hi, %dr6 rrd %pcsp.lo, %dr7 rrd %pcsp.hi, %dr8 std %dr3, [%dr0 + E2K_CTX_USD_LO] std %dr4, [%dr0 + E2K_CTX_USD_HI] std %dr5, [%dr0 + E2K_CTX_PSP_LO] std %dr6, [%dr0 + E2K_CTX_PSP_HI] std %dr7, [%dr0 + E2K_CTX_PCSP_LO] std %dr8, [%dr0 + E2K_CTX_PCSP_HI] /* Load next CRs */ ldd [%dr1 + E2K_CTX_CR0_LO], %dr2 ldd [%dr1 + E2K_CTX_CR0_HI], %dr3 ldd [%dr1 + E2K_CTX_CR1_LO], %dr4 ldd [%dr1 + E2K_CTX_CR1_HI], %dr5 rwd %dr2, %cr0.lo rwd %dr3, %cr0.hi rwd %dr4, %cr1.lo rwd %dr5, %cr1.hi /* Load next stacks */ ldd [%dr1 + E2K_CTX_USD_LO], %dr3 ldd [%dr1 + E2K_CTX_USD_HI], %dr4 ldd [%dr1 + E2K_CTX_PSP_LO], %dr5 ldd [%dr1 + E2K_CTX_PSP_HI], %dr6 ldd [%dr1 + E2K_CTX_PCSP_LO], %dr7 ldd [%dr1 + E2K_CTX_PCSP_HI], %dr8 rwd %dr3, %usd.lo rwd %dr4, %usd.hi rwd %dr5, %psp.lo rwd %dr6, %psp.hi rwd %dr7, %pcsp.lo rwd %dr8, %pcsp.hi /* Restore next UPSR */ ldd [%dr1 + E2K_CTX_UPSR], %dr2 rwd %dr2, %upsr E2K_ASM_RETURN 

Un autre point important est l'initialisation du thread OS. Dans Embox, chaque thread a une certaine procédure principale

 void _NORETURN thread_trampoline(void); 

dans lequel tous les autres travaux du flux seront exécutés. Ainsi, nous devons en quelque sorte préparer les piles pour appeler cette fonction, c'est ici que nous sommes confrontés au fait qu'il y a trois piles, et qu'elles ne croissent pas dans la même direction. Par architecture, notre flux est créé avec une seule pile, ou plutôt, c'est un seul endroit sous la pile, en haut nous avons une structure qui décrit le flux lui-même et ainsi de suite, ici nous avons dû prendre soin de différentes piles, sans oublier qu'elles doivent être alignées sur 4 ko, n'oubliez pas toutes sortes de droits d'accès et ainsi de suite.

En conséquence, nous avons décidé pour le moment de diviser l'espace sous la pile en trois parties, un quart sous la pile d'informations de liaison, un quart sous la pile procédurale et la moitié sous la pile utilisateur.


L'article contenait également du travail avec des interruptions, des exceptions et des minuteries, mais comme il s'est avéré si important, nous avons décidé d'en parler dans la partie suivante .

Au cas où, je le répète, ce matériel n'est pas une documentation officielle! Pour le support officiel, la documentation et le reste, vous devez contacter directement l'ICST. Le code dans Embox , bien sûr, est ouvert, mais pour le compiler, vous aurez besoin d'un compilateur croisé, qui, encore une fois, peut être obtenu auprès du MCST .