J'ai eu une idée... - Page 2

Line 1010, c'est pour les erreurs, Line 1011 c'est pour les appels de ROM_CALL
par exemple, en hexa, $A00D va te dessiner une jolie boîte de dialogue avec le message d'erreur n°13 = $00D ( 13-> errornum : errdlg en ti-basic, pour voir ce qu'il raconte), alors que $B00D sera un équivalent de

move.l 200,a0
move.l $D*4(a0)
jsr    (a0)

avec qqes appels supplémentaires pris en compte (notamment par preos)
après, c'est peut-être pas A et B les valeurs, c'est juste que je ne m'en souviens plus et que je n'ai pas de doc sous la main

euh j'ai mal lu la question, désolé.
A ma connaissance, non, il n'y a aucune différence entre les deux Line Emulators

bonne question je l'ai su, mais je ne m'en souviens plus
doit y avoir le PC utilisateur qui est stocké sur la pile (mais je ne sais toujours pas si c'est user stack ou supervisor stack ), donc avec un peu de chance

 move.l (a7),a0
 move.w -2(a0),d0
 and.w  #$0FFF,d0

marche, sinon ça devrait être

 move.l usp,a0
 move.w -2(a0),d0
 and.w #$0FFF,d0

qui devrait marcher.

a priori, c'est la première version qui devrait marcher.

tiens, le code qui traîne dans preos, si ça peut aider

newLine1010:
	pea	(a0)					; Push a0
	lea	FirstRun(Pc),a0				; Test if we are under kernel final undo
	cmpi.b	#-1,(a0)
	beq	CrashHandler				; Yes => Crash Handler
	
	move.l	6(sp),a0				; The crash address
	cmp.w	#$A000+161,(a0)				; Test if it is 'Too long Exec Program'
	beq.s	ERThrow_return
	cmp.w	#$A244,(a0)				; Test if 'Illegal Program Reference'
	bne.s	ERTHrow_no			
AMS207_P1	cmpi.b	#$F3,(a3)			; Check if is an ASM program 
		bne.s	ERTHrow_no			; On AMS 2.08, it isn't a3 but a2 (That's why it is patched)
AMS207_P2	cmp.l	#$200000,a5			; If the variable is archived, we MUST NOT SKIP THE ERROR	
		bge.s	ERTHrow_no			; Otherwise, we crash the calc (It tries to execute archived programs !)
ERThrow_return		addq.l	#2,6(sp)		; Skip the illegal instruction
			move.l	(a7)+,a0		; Restore a0
			rte				; We return to the program, skipping the illegal
ERTHrow_no
	move.l	(a7)+,a0				; Restore a0
OldER_throw
	jmp	($0).l					; Jump to old ER_throw

donc mon code est faux, il ne faut pas de faire de -2(a0) mais (a0) directement

de rien

bah c'est juste que je m'étais planté 2 fautes sur 3 lignes, ça reste raisonnable

donc 0/1/2/3(sp) c'est le longword du pea
4/5 c'est le status register du mode utilisateur
6/7/8/9 c'est le pc du mode utilisateur

par contre, le "into" ça me paraît bizarre, j'aurais plutôt mis "from"

ah merde, c'est vrai qu'on parle de RTE, là j'étais parti sur l'idée que ça décrivait ce qu'il se passait lors du déclenchement de l'interruption
on va oublier ce que j'ai dit, ça vaut mieux

Les deux line emulator sont A et F (1010 et 1111 en binaire c'est pas par hasard)
Tu peut trouver le code de l'instruction comme ça =>

Trap frame pour line emulator =>
- PC (1long)
- SR (1word)

A noter que line xxxx emulator n'incrémente pas le PC avant de générer le trape frame, le traitement de l'instruction est stoppé avant.
Du coup, tu trouves le code à l'adresse indiquée par le PC du trap frame (et non pas 1 word plus bas comme dans l'exemple #1 de Flanker )

Ca veut aussi dire que si tu fais un rte dans le handler, il faut modifier le trap frame avant, sinon tu vas retourner sur l'instruction qui a provoqué l'exception et la réexécuter. Le code cité plus haut le fait (la ligne du ERThrow_return)

ah oué, pas con l'explication de 1010 et 1111. J'avais jamais percuté
ch'ui pas en forme aujourd'hui on dirait

je pense que le TIOS repasse en mode normal avant d'exécuter ça, il n'est pas fou

TIOS se moque royalement de savoir s'il est en mode superviseur ou non.
De toutes façons, il n'y a pas de différence fondamentale entre les deux modes. La pile fonctionne de la même façon même si c'est pas la même, et TIOS n'utilise pas les instructions superviseur hors des fonctions prévues pour, donc y'a pas de raison de changer.

spectras > par principe, c'est quand même mieux de se mettre en utilisateur, c'est comme si tu restais en permanence en root sous linux

nan.
Sur un système avec gestion des privilèges l'analogie serait déjà tirée par les cheveux (ie: ce serait une mauvaise illustration, même si l'idée que tu veux exprimer serait bonne).
Sur 68000 il n'y a pas de protection de toutes façons. Etre en mode superviseur ne représente absolument aucun risque de plus qu'être en mode utilisateur. Il n'est d'ailleurs même pas étanche (on peut lire le SR en mode utilisateur, ce qui est surement l'un des plus gros défauts de ce cpu, avec l'impossibilité de reprendre l'exécution après une exception du groupe 0).

spectras :
TIOS se moque royalement de savoir s'il est en mode superviseur ou non.
De toutes façons, il n'y a pas de différence fondamentale entre les deux modes. La pile fonctionne de la même façon même si c'est pas la même, et TIOS n'utilise pas les instructions superviseur hors des fonctions prévues pour, donc y'a pas de raison de changer.

Pas tout à fait, par exemple il me semble que le CAS exige que NeedStack() fonctionne correctement pour que certains calculs débouchent sur une erreur Memory plutôt qu'une corruption de la mémoire ; en superviseur, NeedStack() ne détecte évidemment pas si on va déborder de la pile...

M'enfin c'est vrai que dans les cas où on sait que l'exécution ne va pas causer d'erreur de ce style, ça doit être (sauf exception) plutôt sûr de rester en superviseur...

Martial Demolins :
dc.w $F000+HeapAlloc
Je me trompe ou ça ressemble à ça? Et ça ne gêne pas le TIOS d'aller éxécuter ça en superviseur?

Si, ça ne marchera pas.

-Chaque module qui veut en appeler un autre repasse la main au gestionnaire, afin que celui-ci vérifie si le module est déjà présent en RAM ou non (gérer tout ça avec une pile d'appels, c'est encore vague dans ma tête mais je pense que c'est faisable). Si le module n'est pas en RAM, il le recopie: il peut facilement connaitre son emplacement s'il a l'adresse par le n° de fonction dans la lib (merci le kernel), ainsi que sa taille (peut par exemple être stockée au début, sous forme (label_fin_module - label_début_module)).

Non. Il faut faire une librarie par module, et regrouper toutes les librairies en un seul pack.
A partir de la tout ce que tu dis est directement possible avec PreOS : il charge / decharge tout seul ce qui n'est plus necessaire quand ce n'est plus necessaire.
Le seul inconvenient est le surcout du header kernel pour les modules.
Mais apres reflexion (pour cf), je me suis rendu compte qu'on ne pouvait pas vraiment faire mieux.

-Toutes les allocations mémoires se font aussi par des fonctions du gestionnaire, afin que celui-ci libère si nécessaire de la RAM en effaçant autant de modules que
nécessaire, sauf le module courant (voire ceux marqués inneffaçables... à voir).

Simple: tous tes modules ne definissent pas de variables globales dynamiques mais font reference au gestionnaire principal (Et la PreOS te reloge correctement ton module).
Par ailleurs tu peux ajouter un systeme de cache (comme j'ai fait pour cf2 ) pour accelerer largement le tout.

-Impossibilité pour chaque module de conserver des données, vu qu'il peut être déchargé à tout instant. Le launcher doit donc s'occuper de créer un handle, et de réserver un registre d'adresse constamment pour que chaque module ait de la place pour aller écrire ce qu'il veut (handle, diverses données, bref toutes les variables habituelles).

Pas si tu les stockes dans ton launcher.
Le launcher a un nom de librarie (par exemple 'laucnher').
Dans launcher.asm:
launcher@0000: dc.l 0

Dans ton module chargé :
move.l laucnher@0000,d0
etc

PreOS reloge tout ca correctement (mais >= 0.70 seulement).

-Inconvénient majeur, que je ne sais pas comment contourner sans hack du format de fichier défini par PpHd (Kernel Format Vx), c'est la question des relogements... :'( Et donc là, pas de BSS et pas de lib dynamique...

Les BSS c'est niet. Desole

D'ailleurs à ce sujet, si tu passes par là PpHd, tu pourrais décrire comment tu gères l'attribut correspondant ?

PreOS ne deprotege pas la flash. Mais si on lui demande d'executer un programme readonly archivé, il va pas broncher, et il va l'executer en flash.
(Donc un autre programme peut deproteger la flash).

Et les RAM calls, ils marchent comment? Ils sont résolus en temps d'éxécution ou quand PreOS reloge le programme?

Au moment de la relocation.

PreOS ne permet pas l'exécution en Flash, parce que sous AMS c'est moyennement possible

Pourquoi moyennenement ?

Donc à priori on aurait $(3ff-100+1)/4=192 traps disponibles à partir de $100. Je ne me trompe pas?

Sur TI, ca fait parti de la pile superviseur.

./58: Ca depend. Si c'est le hook de PreOS, ca marchera. Si c'est le hook original de ti, non (car il force le passage en mode user et donc se perd dans les piles).