]
En fait y a 3 niveaux de codage en C ou ASM, prenons l'exemple d'un émulateur:
1) La manière bourrin, tout le monde voit les variables internes aux autres et s'amuse à les modifier. Ce modèle est peu souple et un bug peut potentiellement venir de n'importe où.
2) La manière "modulaire", avec des fichiers .c/.h organisés par entité du programme. Dans le cas du CPU, tu auras un fichier cpu.c et un cpu.h. Le cpu.c aura des fonctions exportées et accessibles par les autres (déclarées dans le .h) ainsi que des variables et fonctions qui lui sont propres (mot clé static). Les autres modules communiquent avec le CPU au travers de ces méthodes, à la manière d'un échange de messages, et la réaction du CPU aux messages est opaque (inconnue des autres à priori). Exemple: lcd.c veut lever une interruption => il appelle cpu_trigger_irq(INT_STAT) déclaré dans cpu.h au lieu de pendingIrqs |= INT_STAT avec pendingIrqs une variable interne du CPU.
Ce modèle est puissant car il est facile de maintenir les modules individuels et d'isoler des bugs, et fait du C un langage que je préfère au C++, mais il a le désavantage de ne permettre qu'une instance des entités en question (i.e. 1 CPU).
3) La manière "objet" qui est une extension du précédent pour avoir plusieurs CPUs par exemple. A ce moment cpu.h définit une structure représentant les variables d'état du CPU, et les fonctions prennent toutes cette structure en paramètre (i.e. il n'y a plus de variable "globale", statique ou pas, dans cpu.c). Si c'est ce que tu faisais jusque là, alors tu as mis un pas dans l'objet
