Information sur les interruptions - Page 1

Bonjour,

Est-ce quelqu’un connaît une référence sur le fonctionnement précis des interruptions. Je sais comment programmer des Handler et tout, mais j’aimerais avoir plus de détails sur ces points :

- Lors d’une interruption, où est stocké la valeurs des registres du programme en cours d’exécution, des flags, l’adresse de la prochaine instruction, etc. ?

- Existe-t-il des fonctions en C pour retrouver ces information et les modifier ?

Merci.

>- Lors d’une interruption, où est stocké la valeurs des registres du programme en cours d’exécution, des flags, l’adresse de la prochaine instruction, etc. ?
Sur la pile.

>- Existe-t-il des fonctions en C pour retrouver ces information et les modifier ?
Nan.

PpHd :
>- Lors d’une interruption, où est stocké la valeurs des registres du programme en cours d’exécution, des flags, l’adresse de la prochaine instruction, etc. ?
Sur la pile.

>- Existe-t-il des fonctions en C pour retrouver ces information et les modifier ?
Nan.

Donc :

l'état est empilé ; exécution de l'interrupt (comme un call de procédure) ; dépilation et restoration de l'état ; poursuite de l'exécution du programme principal

Est-ce que c’est bien ça ?

Il y a une seule pile (de 16k si ma mémoire est bonne), si je comprend bien ?

Est-ce qu’elle est simulée dans une zone mémoire ou est-elle interne au CPU ? Est-ce que l’on peut y accéder (lecture/écriture) directement ?

Également, le détail des informations stockées sur la pile avant l'interruption est-elle disponible ?

Merci d'avoir pris le temps de me répondre ...

Quesoft
: Il y a une seule pile (de 16k si ma mémoire est bonne), si je comprend bien ?

Non, il y a une pile utilisateur et une pile superviseur.

Est-ce qu’elle est simulée dans une zone mémoire ou est-elle interne au CPU ?

Les 2 piles sont en RAM.

Est-ce que l’on peut y accéder (lecture/écriture) directement ?

Oui.

Également, le détail des informations stockées sur la pile avant l'interruption est-elle disponible ?

Oui, USP pointe vers le pointeur de pile utilisé par le programme, les interruptions utilisent la pile superviseur (SSP).

Kevin Kofler :
Oui, USP pointe vers le pointeur de pile utilisé par le programme, les interruptions utilisent la pile superviseur (SSP).

Deux piles donc...

Est-ce que les pointeurs USP et SSP sont gardés dans des registres ?
Je suppose que des tutoriels d’ASM doivent donner des infos là-dessus …

Comment obtiens-on un pointeur sur la base de la pile (le début de la zone en RAM) ?

PpHd :
>- Lors d’une interruption, où est stocké la valeurs des registres du programme en cours d’exécution, des flags, l’adresse de la prochaine instruction, etc. ?
Sur la pile.

La pile utilisateur ou superviseur ?

Quesoft
:

Kevin Kofler :
Oui, USP pointe vers le pointeur de pile utilisé par le programme, les interruptions utilisent la pile superviseur (SSP).

Deux piles donc...
Est-ce que les pointeurs USP et SSP sont gardés dans des registres ?

Oui. En mode utilisateur:
* a7 = usp
* ssp n'est pas accessible.
En mode superviseur:
* a7 = ssp
* usp est accessible à travers des instructions spéciales (move.l %usp,%an, move.l %an,%usp, n allant de 0 à 7, 7 déconseillé)

Je suppose que des tutoriels d’ASM doivent donner des infos là-dessus …

Oui.

Comment obtiens-on un pointeur sur la base de la pile (le début de la zone en RAM) ?

Ces adresses sont constantes. (Mais attention, la base de la pile superviseur dépend de la version de AMS si je me rappelle bien, ça a changé dans la 2.00.)

PpHd :
>- Lors d’une interruption, où est stocké la valeurs des registres du programme en cours d’exécution, des flags, l’adresse de la prochaine instruction, etc. ?
Sur la pile.

La pile utilisateur ou superviseur ?

Superviseur.
Et c'est à toi de sauvegarder les registres dans ton handler d'interruptions, ils gardent tous leur valeur et tu es obligé de remettre ces valeurs avant de retourner.
DEFINE_INT_HANDLER gère ça pour toi, mais à ta place, j'écrirais le handler entier en assembleur. Parce que dépendre de ce que DEFINE_INT_HANDLER te met sur la pile est dangereux, la définition de DEFINE_INT_HANDLER peut changer à tout moment (nous comptons virer le wrapper actuel et utiliser un attribut de GCC pour faire un handler d'interruptions directement).

Kevin Kofler :
Et c'est à toi de sauvegarder les registres dans ton handler d'interruptions, ils gardent tous leur valeur et tu es obligé de remettre ces valeurs avant de retourner.
DEFINE_INT_HANDLER gère ça pour toi, mais à ta place, j'écrirais le handler entier en assembleur. Parce que dépendre de ce que DEFINE_INT_HANDLER te met sur la pile est dangereux, la définition de DEFINE_INT_HANDLER peut changer à tout moment (nous comptons virer le wrapper actuel et utiliser un attribut de GCC pour faire un handler d'interruptions directement).

Je vais regarder le code généré pour DEFINE_INT_HANDLER dans ce cas ...
ASM 68K, je suppose que c'est un autre monde que MVS et Intel ...

nan, c'est le proc : quand il est en superviseur, a7 pointe vers SSP, quand il est en user, il pointe vers USP

Quesoft, tu devrais regarder un peu a68k guide, ça permet de bien comprendre tout ça, ainsi que les différentes interruptions

C'est le changement de mode qui gère ça automatiquement.

Ça s'appelle 68kguide, pas a68k guide!

Kevin Kofler :
Ça s'appelle 68kguide, pas a68k guide!

Ok

Et si tu veux modifier ce que j'ai l'impression que tu veux modifier, fais le en assembleur pas en C!

PpHd :
Et si tu veux modifier ce que j'ai l'impression que tu veux modifier, fais le en assembleur pas en C!

J'aimerais faire du multi threading (vraiment de base) juste pour m'amuser ... Je sais que ça a déjà été discuté ici, mais ma connaissance de l'ASM (surtout 68K) est assez limitée ...

J'ai regardé le 68Kguide de Jimmy Mardell, mais il ne parle pas beaucoup des interruptions. Par contre, c'est une bonne intro pour qqn qui connaît l'ASM sur d'autres plates-formes, donc ça va m'être utile ...

Je vais regarder le code intermédiaire ASM généré par TIGCC pour avoir une meilleure idée des conventions d'appel et tout.

Tu veux rajouter le support des Thread à ton compilo java ?

Sasume :
Tu veux rajouter le support des Thread à ton compilo java ?

Ça serait intéressant de supporter de 'vrais' threads java pour Moka, je n'exclu pas ça, mais pour l'instant, c'est plus par curiosité qu'autre chose...

En plus, j'ai peur que les threads se révèlent unsafe à utiliser sans aucune considération (je présume que l'OS ne met pas en file les requêtes qui lui sont adressées) ...

Ben il faut que ta lib standard soit thread-safe, ce qui fait que moka_malloc devra utiliser un verrou pour empêcher les autres tâches de s'exécuter pendant ce temps-là... A part ça c'est très jouable ^^

Pollux :
Ben il faut que ta lib standard soit thread-safe, ce qui fait que moka_malloc devra utiliser un verrou pour empêcher les autres tâches de s'exécuter pendant ce temps-là... A part ça c'est très jouable ^^

Je vais d'abord me familiariser avec le multi-thread de base, avant de songer au support par Moka, mais c'est vrai que ce serait vraiment amusant ...

MyThread t = new MyThread();
t.start();

Ouais, ça serait le fun ...

Regarde les sources de mon Task Switcher.
Remplace l'AI6 par l'AI 1 ou 5 et voilà le multithreading.

Kevin Kofler :
Regarde les sources de mon Task Switcher.
Remplace l'AI6 par l'AI 1 ou 5 et voilà le multithreading.

Bonne idée ...

Je l'ai dowloadé sur ton site ... Merci.

J'ai vu que Thomas Nussbaumer a développé une librairie de multitasking. Je compte la regarder aussi.