[Le projet OS-9] OS9 sur TO9p

[jb_jb_fr]

Bonjour

Vous etes dans le noyau OS9:

Code : Tout sélectionner

*------------------------------------------------*
*                    F$NProc
*------------------------------------------------*
* FUNCTION:         Start the next process in the active queue
* ASSEMBLER CALL:   OS9 F$NPRC
* MACHINE CODE:     103F 2D
* INPUT:            None.
* OUTPUT:           Control does not return to caller.
*------------------------------------------------*
FNProc   clra
         clrb
         std   <D.Proc
         bra   L02C2
* execution goes here when there are no active processes
L02C0    cwai  #^(IntMasks)
L02C2    orcc  #IntMasks
         ldx   <D.AProcQ               get next active process
         beq   L02C0                   CWAI if none
         ldd   P$Queue,x               get queue ptr
         std   <D.AProcQ               store in Active Q
         stx   <D.Proc                 store in current process
         lds   P$SP,x                  get process' stack ptr
L02D1    ldb   P$State,x               get state
         bmi   L0308                   branch if system state
         bitb  #Condem                 process condemned?
         bne   L02AC                   branch if so...
         ldb   <P$Signal,x             get signal no
         beq   L02FF                   branch if none
         decb                          decrement
         beq   L02FC                   branch if wake up
         ldu   <P$SigVec,x             get signal handler addr
         beq   L02AC                   branch if none
         ldy   <P$SigDat,x             get data addr
         ldd   $06,s
         pshs  u,y,b,a
         ldu   $0A,s
         lda   <P$Signal,x
         ldb   $09,s
         tfr   d,y
         ldd   $06,s
         pshs  u,y,b,a
         clrb
L02FC    stb   <P$Signal,x
L02FF    ldd   <P$SWI2,x
         std   <D.SWI2
         ldd   <D.UsrIRQ
         std   <D.SvcIRQ
L0308    rti

Mais je doute que ca vous aide.

Jacques

[petitjd]

Vous etes dans le noyau OS9:
Mais je doute que ca vous aide.

Jacques, tu es passé en mode jeu d'aventure

[Daniel]

C'est précisément l'aspect jeu d'aventure que j'aime dans l'émulation. En l'absence de documentation c'est très sportif, comme pour Exelvision. Avec OS-9 la documentation est abondante, ça devrait être plus facile...

[__sam__]

Ah ok, c'est le context switch. Les taches sont une liste chainée. Ca me rappelle pleins de truc d'os ca

Si je comprends la fin

Code : Tout sélectionner

L02FF    ldd   <P$SWI2,x
         std   <D.SWI2
         ldd   <D.UsrIRQ
         std   <D.SvcIRQ
L0308    rti

Est-ce que ca signifie que sous OS9 chaque tache a son propre traitement de SWI2 (souvent appelle système) et IRQ particuliers (ou du moins redéfinissable) ?

[Papy.G]

Je profite sournoisement de ce sujet pour apprendre comment fonctionnent les OS multitâche.

Donc, les Process ne rendent la main que s'ils le décident (hors interruptions, j'imagine).
Il existe un dispositif permettant de reprendre la main sur un process planté?

Sam> Je pense que certains vecteurs d'interruptions doivent pouvoir rester globaux, notamment pour la gestion du port série, peut-être pour le driver d'affichage (s'il est synchronisé avec la VBL), sinon, ça poserait problème.

[__sam__]

Je profite sournoisement de ce sujet pour apprendre comment fonctionnent les OS multitâche.

Donc, les Process ne rendent la main que s'ils le décident (hors interruptions, j'imagine).

D'habitude sur les OS que j'ai vu les process rendent la main lors des appels systèmes ou lorsque scheduler le préempte (tous les 20ms sur OS9 thomson si j'ai bien tout suivi). Enfin pour les OS préemptifs (amiga par exemple). Sinon ce sont des OS coopératifs (vieux windows, vieux mac, etc).

[Papy.G]

Autant pour moi, ça m'étonnait aussi que OS9 ne soit pas préemptif.
Donc, c'est le scheduler qui reprend la main et appelle la tâche suivante via la routine dont vous parliez plus haut qui fait le changement de contexte (le stockage et restauration des différents registres) au passage?
20ms, c'est l'interruption du Vblank qui sert au scheduler, pour économiser un timer?

[Fool-DupleX]

@Papy G. (première intervention) :

Ce n'est pas exactement comme cela que ça marche. Il y a deux types de systèmes multitâches : coopératif et préemptif. Dans un système coopératif, chaque process redonne la main si il le veut bien. Les appels systèmes sont généralement utilisés par le noyau pour reprendre la main, ou un appel système spécial unique est utilisé, mais si une tâche est plantée, souvent, le système est planté.

Dans un système préemptif, c'est le noyau qui décide. OS-9 est un système préemptif. Sur Thomson, l'IRQ est programmée pour être appelée à intervalle régulier. Elle donne la main au noyau qui décide quel sera le process suivant qui sera exécuté. Un process planté peut donc toujours être supprimé : il suffit de ne plus lui donner la main (Certains me rétorqueront que parfois sous Windows, ça coince ; oui, mais sur le même processeur sous Linux ou BSD, ça ne coince jamais. Le problème est ailleurs).

Le souci avec le système préemptif, typiquement sur notre bon vieux 6809, c'est qu'un process peut tout a fait décider de masquer l'IRQ et dans ce cas, le système n'a plus la main. Un process peut aussi décider d'aller "jardiner" n'importe ou dans la mémoire et compromettre les autres processes et le noyau. C'est une réalité sur 6809.

C'est pour cela que les processeurs plus modernes comme le 68000 et le 80386 (et tous les successeurs) proposent un mode de fonctionnement différent appelé "protégé" sur 80386 et "superviseur" sur le 68000. En mode protégé, il y a plusieurs niveaux de sécurité et des gardes-fou matériels qui empêchent un code de niveau inférieur (applicatif) de réaliser une opération de niveau supérieur (noyau). Ainsi, si une application jardine dans une zone mémoire interdite ou tente de triturer un périphérique, le processeur va lever une exception (une super-interruption) qui sera traitée par le noyau. Il y a plusieurs niveaux sur le mode protégé, seulement deux avec le superviseur (privilégié/non privilégié) de Motorola, mais l'idée est la même.

Sur les processeurs encore plus modernes, il y a une gestion fine de la mémoire et des périphériques avec différents types de privilèges par zone et par périphérique et avec des niveaux de priorité. On peut par exemple décider qu'une zone mémoire est accessible en écriture mais pas en exécution et seulement pour des processes de niveau 2 mais pas 3.

Par un abus de langage tout à fait condamnable, beaucoup de gens parlent de mode 32 bits et d'applications 32 bits pour le mode protégé. C'est une bêtise, puisque le code 32 bits peut tout à fait être exécuté également en mode réel ou virtuel (i.e. sans protection) et le code 16 bits, en mode protégé. Cet abus de langage est lié au développement de Windows : Windows 95 est la première version de l'OS à proposer à la fois du code 32 bits et un système préemptif en mode totalement protégé. Enfin pas tout à fait, puisque les applications dites "16 bits" (i.e. pré-Win95) tournaient en coopératif. C'est une des raisons de certains écrans bleus et des écrans figés avec des fenêtres qui ne se rafraichissaient plus. Toujours est-il que l'amalgame est né à cette époque.

Edit : au sujet de ta deuxième intervention : le time slice est de 20 ms originellement pour le projet OS-9/MO5 car nous avons d'abord porté le système sur cette machine (MO5) et que celle-ci possède seulement une interruption à intervalle fixe de 20 ms, correspondant effectivement au vblank et pas de timer. Sur TO, le time-slice est programmable, car c'est le timer (programmable) du 6846 qui déclenche l'interruption.

[Papy.G]

Merci pour vos réponses très complètes et instructives.

Sur TO, le time-slice est programmable par l'utilisateur final, en fixe à la compilation/au démarrage dans un fichier de config, ou en dynamique par le système lui-même?
Le 6809 n'a pas de NMI, ou elle n'est pas utilisée dans le TO9?
Sur les petits processeurs ou dans des systèmes "limités", il faut user des interruptions avec parcimonie et la moindre source d'économies est la bienvenue.

[Fool-DupleX]

Je laisse Jacques répondre pour la programmation du time slice. Le 6809 a les interruptions Reset, NMI, FIRQ, IRQ, SWI, SWI2, SWI3 par ordre de priorité. Sur les Thomson natifs, NMI, SWI2 et SWI3 ne sont jamais utilisées. NMI n'est jamais utilisable sur Thomson : elle n'est pas câblée sur le bus. Par contre, SWI2 et SWI3 sont utilisées par OS-9.

Le noyau d'OS-9 est très léger. L'exécution des applicatifs va certainement sembler un peu plus lent que sur une machine native, mais c'est largement compensé par la richesse et la souplesse de l'OS. Et j'ai envie de dire qu'au final, la lenteur ne se ressent même pas, car la majorité des logiciels à l'époque sur Thomson étaient en BASIC interprété, donc franchement lents.

Il faut également savoir que le tout premier OS-9 a été écrit pour le 6809 par des spécialistes du 6809. De ce point de vue, c'est le meilleur OS qu'on puisse trouver sur cette architecture.

[Fool-DupleX]

Je me corrige moi-même : la NMI est câblée sur le bus du TO7 (toute première machine de la gamme). Mais à partir du TO7-70, elle a disparu pour laisser la place aux signaux nécessaires pour l'extension incrustation.

[jb_jb_fr]

Bonsoir à tous

Voila les dernières nouvelles d'OS9.

Je me suis attaqué à une tache énorme.
Et pour rien vous cacher, je suis assez fière du travail effectué (Je rentre encore dans mes chaussures, donc ca va )

Dans mon TO9+, j'ai remplacé le 6809E, par un Hitachi 6309.
Le but étant bien sur de gagner en vitesse.

Mais pour pouvoir faire cela il me fallait deux choses :
- Un assembleur qui soit capable de générer du code 6309
- un émulateur qui soit capable de gérer le 6309

Et donc j'ai fait les deux choses en parallèle :
- D'abord je vérifiais que l'assembleur générait bien le code souhaité avec les nouveaux CodeOp
- Ensuite, je codais l'instruction sur l'émulateur, et je la testais.

Il a fallu que je fasse les codes un par un avec, bien sur la prise en compte des différents mode d'adressage.
Ca m'a pris du temps mais maintenant c'est chose faite.

Je suis donc capable de générer un noyau OS9 avec la prise en compte des nouvelles instructions du 6309.
Grâce à ça j'ai pu commencer à optimiser mes drivers bas niveau d'OS9.

Et grâce à l'émulateur, j'ai pu constater que ça marche bien.

Mais bien sur, les tests n'étaient pas fini.
En effet le 6309 fonctionne dans 2 modes :
- Le mode émulé, ou il gère tout comme un 6809, mais avec des instructions supplémentaire
- le mode natif, ou des spécificités supplémentaires sont disponible (Gestion des IRQ différentes)

L'avantage du mode natif, c'est qu'il y a, en moyenne, un cycle de moins par instruction. Donc on y gagne en vitesse.

Et donc j'ai mis le 6309 en mode natif au démarrage d'OS9, et j'ai tenté de voir ce que ça donnait.
Et c'est la que (pour parler vulgairement) j'en ai chier

Déjà au départ je n'avais rien. Il fallu comprendre pourquoi.
Grâce à l'émulateur j'ai pu voir que c'était quand l’accès au disque virtuel se faisait.
J'ai donc vite compris que les offsets utilisés dans le driver RBF était en dure.
Alors qu'il aurait fallu utiliser des offsets définis dans des fichiers d'assemblage d'OS9 qui sont fonction du mode choisie.
Une fois le code corrigé, OS9 démarrait.

Mais la partie n'était pas fini. J'avais un plantage aléatoire d'OS9.
Et la j'en ai vraiment bavé. J'y ai passé tout mon WE de Pâque dessus.
Il a fallu que j'ajoute des moyens de tests à l’émulateur.
Il a fallu que je fasse afficher toutes les lignes assembleurs exécutées
Il a fallu que je fasse afficher tous les registres du 6309 pour chaque CodeOp exécuté
Il a fallu que j'initialise les registres spécifique du 6309 à des valeurs spécifiques.
Il a fallu faire stopper l'émulateur quand le code exécuté commençait à faire des choses bizarres.
Pour enfin m’apercevoir que les valeurs de ces fameux registres 6309 étaient corrompues.

Mais le pire c'est que le plantage n'était pas immédiat.
Il arrivait après 2 voir 3 RTI, et n'arrivait pas toujours au même moment d’exécution d'OS9.

Il a fallu donc remonter les lignes assembleurs, remonter la pile système pour comprendre ce qu'il se passait
Puis après il fallait mettre le doigts sur le code fautif.
Et j'ai trouvé à 2 endroits du noyau OS9 (sur la gestion des process (fork & sleep)) que la pile était initialisée avec des méthodes qui ne prenne pas du tout en compte le mode natif.

Le pire ont été ces deux lignes :
- pshs u,y,b,a : pour mettre les registres PC,U,Y dans la pile
et quelques lignes plus loin
- pshs u,y,b,a : pour mettre les registres X,DP,B,A,CC dans la pile aussi

Arrivé a comprendre que ces 2 instructions initialisaient la pile pour le futur process à vraiment été une super galère.

Mais maintenant que les 2 points noirs ont été identifiés et corrigés, j'arrive à faire tourner OS9 sur un 6309 en mode natif.

Mais attention, cela n'est que sous émulateur.
Bien sur reste encore le test réel : OS9 sur un VRAI TO9+

Il m'est déjà arrivé d'avoir du code OK sous l'émulateur et KO en vrai.
Mais généralement ce genre de soucis arrivait sur de la gestion de périphérique car le circuit concerné était mal émulé.
C'est ce qui m'était arrivé avec le 6846.

Voila donc mes dernières péripéties, ainsi que mes derniers avancement.

Je crois que j'ai encore pleins de cycles à gratter grâce au 6309.

Affaire à suivre

Jacques

[Edit] Je viens de voir que la fonction en cause est celle que j'ai posté le 7 Mars : FNProc

[__sam__]

Fécilitations Le 6309 est mieux fichu que le 6809 dont certaines instructions sont curieusement lentes.

Au cours de mes périgrinations sur le web je suis tombé sur du code NitrOS9 de gestion d'icones dont le code du noyau gfx était optionnellement compatible 6809 et 6309. http://geneslinuxbox.net:6309/gene/nitr ... /grfdrv.am. Ca semble être un OS9 compatible 6309 En farfouillant à parti de l'url ci-dessus je suis tombé sur les sources d'un basic et d'un pascal, et en creusant youtube j'ai vu une démo de NitrOS9 dans lequel les jeux "Leisure Suit Larry" et "King quest" tournaient (ici des images de ces jeux Sierra)

[jb_jb_fr]

Je connais NitrOS9, et je visite souvent le site pour voir s'il y a des évolutions de code.
Et bien sur après avoir trouvé les 2 bugs en question, je suis allé voir sur le site.
Et j'ai constaté que le noyau OS9 Level I contient les 2 bugs.
Et que OS9 Level II, contient un seul des 2 bugs.

Je vais en faire part à Boisy PITRE qui continue de bosser sur NitrosOS9.
Je suis quand même surpris qu'il ne s'en soit pas déjà aperçu.

Jacques

[jb_jb_fr]

Bonsoir

Voila les dernières news d'OS9.
J'ai testé ce jour OS9 en mode 6309 natif en réel.
Et ca marche tres bien.

J'ai vraiment pu noter une différence entre le mode 6809 et le mode 6309.
Ca saute aux yeux quand il est nécessaire de faire scroller l'écran vers le haut.
En mode 6809, c'est sacader, et on a le temps de voir les 2 page video qui monte.
Alors que en mode 6309, c'est vraiment plus fluide. C'est tres agréable.

Donc OS9 est capable de fonctionner soit avec un 6809 soit avec un 6309 en mode natif.

De plus ces essais mon permis de valider l'assembleur 6809/6309 que j'utilise.
Mais également de valider mon émulateur qui m'a bien servie a débugger OS9 en mode 6309 natif.

Voila donc d'une pierre, trois coup réalisés.

Jacques