Problème de pile que je comprends pas - Page 2

Ah, oui, si la table qui indique le type du RAM_CALL est elle-même une table de saut, ça doit effectivement être plus petit

Tu as testé si ca répondait à ton besoin ?

Le concept répond à mes besoins, oui, j'attends pour modifier eexec que tu valides l'interface. Mais à priori, ça devrait cartonner avec ça, ya pas de raison

(et ya pas mal à gagner en place, plus besoin de loader, utiliser kernel::exit deviendra systématique, ça va être chouette ^^)

Folco (./33) :
Le concept répond à mes besoins, oui, j'attends pour modifier eexec que tu valides l'interface. Mais à priori, ça devrait cartonner avec ça, ya pas de raison

(et ya pas mal à gagner en place, plus besoin de loader, utiliser kernel::exit deviendra systématique, ça va être chouette ^^)

Testes d'abord...
En particulier les RAMCALL qui prennent leurs arguments dans a0 et/ou d0 et/ou d1

Ah oué remarque, pas con comme test ... Bon ben on peut faire une croix sur d0/d1/d5/a0/a2/a5 ... => Remarque, c'est sympathique comme jeu

Ceci dit, j'ai testé pour LibsExec et ça marche

Et là ?

--- Vectors.asm.old	2009-07-16 20:41:31.000000000 +0200
+++ Vectors.asm	2009-07-22 20:51:58.000000000 +0200
@@ -147,38 +147,57 @@
 ;	ROM_CALL avec un word.
 ;	Example: dc.w $FFF2, HeapAlloc*4
 LINE_1111:
-	move.w	(sp)+,d1		; Get Old SR
-	move.l	(sp)+,a0		; Get Address of the 'crash'
-	move.w	(a0)+,d0		; We get the instruction and a0 ->next instruction
-	subi.w	#$F800,d0		; Is it > $F800 ? 
+	move.w	(sp)+,d2		; Get Old SR
+	move.l	(sp)+,a1		; Get Address of the 'crash'
+	move.w	d2,SR			; Restore SR
+	move.w	(a1)+,d2		; We get the instruction and a0 ->next instruction
+	cmpi.w	#$F800,d2
 	bls.s	\no			; No, so it is a crash (First_Window isn't a ROM_CALL)
-		move.l	a0,a1		; Jsr/Jmp with a 32 bits offset	
-		cmp.w	#$FFF0-$F800,d0
+		subi.w	#$F800,d2
+		move.l	a1,a0		; Jsr/Jmp with a 32 bits offset
+		cmp.w	#$FFF0-$F800,d2
 		bne.s	\NoRelJsr
-			adda.l	(a0)+,a1	; Get the Sub Routine
+			adda.l	(a1)+,a0	; Get the Sub Routine
 			bra.s	\Jump
-\NoRelJsr	cmp.w	#$FFF1-$F800,d0
+\NoRelJsr	cmp.w	#$FFF1-$F800,d2
 		bne.s	\NoRelJmp
-			adda.l	(a0)+,a1	; Get the Sub Routine
-			move.w	d1,SR		; Restore SR
-			jmp	(a1)		; Jmp with a 32 bits offset
-\NoRelJmp	cmp.w	#$FFF2-$F800,d0
+			adda.l	(a1)+,a0	; Get the Sub Routine
+			jmp	(a0)		; Jmp with a 32 bits offset
+\NoRelJmp	cmp.w	#$FFF2-$F800,d2
 		bne.s	\NoBigRomCall
-			move.w	(a0)+,d0	; Read Offset
-			lsr.w	#2,d0
-\NoBigRomCall	move.l	($C8).w,a1	; The address of the rom_call table
-		cmp.w	-(a1),d0	; Compare rom_call and number of entries
-		bcc.s	\no		; Out of range ? => Crash
-			move.w	d0,(VAR_SYSTEM1).w	; For debug purpose
-			lsl.w	#2,d0		; * 4
-			move.l	2(a1,d0.w),a1	; + ($C8) MAX: 8000 rom_calls
-\Jump			move.w	d1,SR		; Restore SR
-			pea	(a0)		; Push return address
-			jmp	(a1)		; Jump to Rom_call function
-\no:	lea	Line1111_str(Pc),a0
+			move.w	(a1)+,d2	; Read Offset
+			lsr.w	#2,d2
+\NoBigRomCall	move.l	($C8).w,a0	; The address of the rom_call table
+		cmp.w	-(a0),d2	; Compare rom_call and number of entries
+		bcc.s	\error		; Out of range ? => Crash
+			move.w	d2,(VAR_SYSTEM1).w	; For debug purpose
+			lsl.w	#2,d2		; * 4
+			move.l	2(a0,d2.w),a0	; + ($C8) MAX: 8000 rom_calls
+\Jump			pea	(a1)		; Push return address
+			jmp	(a0)		; Jump to Rom_call function
+\no:	subi.w	#$F000,d2				; Clear data of exception
+	cmpi.w	#MAX_RAMCALL,d2				; Valid ramcall ?
+	bcc.s	\error					; No, throw an error
+		pea	(a1)				; Push return adress
+		lsl.w	#2,d2				; Table of longwords
+		lea.l	RAM_TABLE(pc),a1		; Read the ramcall table ptr
+		adda.w	d2,a1				; Add offset : a0 now points to the ramcall
+		movea.l	(a1),a1				; Read it
+		lsr.w	#2,d2				; Table of bytes
+		move.b	RAM_TABLE_TYPE(pc,d2.w),d2	; Red type of ramcall (table of bytes)
+		bmi.s	\ReturnPtr			; -1 : return a ptr in a0
+		beq.s	\ReturnData			; 0  : return data in d0
+			jmp	(a1)			; 1  : else jump to the function
+\ReturnData:	move.l	a1,d0				; Data must be in d0
+\ReturnPtr:	movea.l	a1,a0				; Else it's a ptr, put it in a0
+		rts
+\error:	lea	Line1111_str(Pc),a0
 	bra	FATAL_ERROR
 
-	
+RAM_TABLE_TYPE					; -1 : ptr. 0 : data. +1 : routine
+	dc.b	-1,0,0,-1,0,0,0,0,0,0,0,0,0,-1,-1,0,-1,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,-1,-1,-1,1,0,0,0,0,0,1,1,1,1,-1,-1,-1
+
+
 Trap_7:
 Trap_8:
 Trap_10:		; Enter self test

Bon, par contre, j'ai un system corrupted au boot, mais après ça rentre dans l'ordre. C'est pas très grave, hein ?

kernel::exec marche, kernel::exit aussi (mais bizarement pour ce dernier, il me sort une "unknown error", je sais pas pourquoi mais c'est ptêt de ma faute encore)

Tu respectes pas l'ABI:
kernel::Hd2Sym, kernel::LibsBegin shall only destroy a0
kernel::LibsEnd shall destroy nothing.
Etc.
cf RAMCALLS.txt

Essaye encore.

Boah si c'est que ça Puis qu'est-ce que tu me fais des chichis pour 2-3 registres, yen a 16 on est pas à ça près quoi Puis toute façon, l'ABI ne fait pas le moine, tu devrais le savoir.

Bon ben je reviens. (bon ça va être chaud ce putain de LibsEnd qui détruit rien, va falloir plusieurs routines de saut avec différentes restaurations alors mon interface était vraiment plus simple )

Bon, ben en fait faut que le handler détruise jamais rien et c'est bon ?!?

Je peux avoir une variable de 4 octets ? A partir du moment où je vais restaurer SR, je perdrai mes registres sauvegardés vu que la pile changera. Il me faut donc au moins pouvoir stocker l'adresse de la fonction quelque part...
Ok, je pourrais aller trifouiller le SR pour savoir si je dois sauvegarder sur sp ou usp, mais voilà quoi.

AMHA, la seule interface raisonnable est de retourner le résultat dans %a0.l quel que soit le RAM_CALL. Ce n'est vraiment pas le boulot du gestionnaire de la F-Line de faire des devinettes. PpHd, tu veux aussi gérer les ROM_CALLs qui sont des variables (genre FiftyMsecTick)?

Hmm... l'interface proposée par PpHd en ./17 est sympa pour l'utilisateur, mais nécessite un handler de F-Line compliqué. C'est embêtant.
Puisque personne n'est manifestement content avec toutes les interfaces proposées jusqu'à présent, je pense qu'on doit continuer l'exploration des solutions possibles, à la fois dans leur design et dans leur implémentation

PpHd, tu veux aussi gérer les ROM_CALLs qui sont des variables (genre FiftyMsecTick)?

Si PedroM a des ROM_CALLs données en Flash (par exemple, sur AMS, il y a FLOATTAB), il faut pouvoir distinguer entre ROM_CALLs données en RAM, ROM_CALLs code en Flash et ROM_CALLs données en Flash.
Distinguer entre RAM et Flash est facile (comparaison d'adresse), mais deviner le type des ROM_CALLs en Flash n'est pas faisable. Il faut donc utiliser une table qui indique le type du ROM_CALL en Flash (code ou données), mais même en utilisant un bit par ROM_CALL, ça coûterait jusqu'à un peu moins de 200 octets, selon le numéro le plus élevé parmi les ROM_CALLs supportés par PedroM (FiftyMsecTick ?).

la seule interface raisonnable est de retourner le résultat dans %a0.l quel que soit le RAM_CALL.

Pas bon pour les RAM_CALLs qui prennent un argument dans a0...
Au prix d'une utilisation 8 fois plus grande de l'espace F000-F7FF, on pourrait permettre à l'utilisateur de spécifier le registre (soit de données, soit d'adresse) dans lequel il veut voir la valeur de retour: les bits 8-10 pourraient servir à ça.


Pour utiliser moins de registres, je pense (sans l'avoir codé, attention ) à quelque chose du genre:
[ul][li]rester en mode superviseur le temps de l'exécution du handler, modifier sur la pile superviseur l'adresse de retour (sans oublier, si c'est nécessaire, par exemple pour les ROM_CALLs en F-Line, de pousser l'adresse de retour du ROM_CALL sur la pile utilisateur), et utiliser RTE;[/li]
[li]On peut aussi pousser sur la pile d0-d7/a0-a6 tout au début du handler, les modifier comme nécessaire sur la pile superviseur pour le retour, et les restaurer juste avant le RTE.[/li][/ul]

Certes, sauvegarder et restaurer 15 registres, en plus des autres écritures en mémoire, n'est pas ce qui se fait de plus rapide... mais de toute façon, si c'est la vitesse qu'on cherche, on commence par ne pas utiliser des exceptions processeur comme les A-Line, F-Line ou autres TRAP !

Lionel Debroux (./41) :

la seule interface raisonnable est de retourner le résultat dans %a0.l quel que soit le RAM_CALL.

Pas bon pour les RAM_CALLs qui prennent un argument dans a0...

Mais non.

.word 0xF000 + 25 //LibsBegin
movea.l a0,a1
lea.l MaLib(pc),a0
jsr (a1)


Mais je vais coder la solution de PpHd, sans variable, j'ai trouvé une solution. Pour moi, c'est pas la meilleure interface, mais je la testerai.

"Pas bon", dans le sens "pas optimal", comme tu le montres

La modif au handler de F-Line que je propose ne nécessite pas de variable non plus. A quelle solution penses-tu ?

Ok. Ma solution n'est pas miraculeuse, c'est pratiquement la tienne.

Lionel Debroux (./41) :
rester en mode superviseur le temps de l'exécution du handler, modifier sur la pile superviseur l'adresse de retour (sans oublier, si c'est nécessaire, par exemple pour les ROM_CALLs en F-Line, de pousser l'adresse de retour du ROM_CALL sur la pile utilisateur), et utiliser RTE;

Oui, sauf que là, tu pars du principe que ton romcall a été lancé en tant qu'utlisateur, alors qu'à la base, t'en sais rien (tant que tu vas pas lire le bit S du SR de la pile superviseur)

Lionel Debroux (./41) :
On peut aussi pousser sur la pile d0-d7/a0-a6 tout au début du handler, les modifier comme nécessaire sur la pile superviseur pour le retour, et les restaurer juste avant le RTE.

-> en gras : d'une certaine manière, oui
-> le reste : encore une fois, qu'est-ce qui te dis qu'on est en utilisateur à la base ?

Le truc marrant, ça serait qu'on code ça chacun de notre côté et qu'on compare.
(1. ok, je suppose que t'as pas trop le temps
2. yen bien que moi que ça doit faire marrer ce genre de trip casse-tête en asm )

-> le reste : encore une fois, qu'est-ce qui te dis qu'on est en utilisateur à la base ?

En effet, tu as raison
(même si je ne suis pas sûr qu'il soit fréquent d'utiliser des ROM_CALLs en F-Line quand on est en mode superviseur )

Quid de mon idée (peu explicitée plus haut il est vrai ) de permettre de sélectionner le registre de retour de valeur:
* pour les RAM_CALLs données (KEY_*, par exemple): utiliser F0?? pour retourner dans d0, F1?? pour retourner dans d1, ..., F7?? pour retourner dans d7;
* pour les RAM_CALLs pointeur: utiliser F0?? pour retourner dans a0, F1?? pour retourner dans a1, ..., F7?? pour retourner dans a7;
* pour les RAM_CALLs code: N/A.

Ca complique le handler, mais permet une plus grande efficacité pour les RAM_CALLs KEY_*, par exemple (voir ./14).

Ben en soi, c'est pas mal, sauf que ça termine d'exploser le range utilisable. Puis faut le coder aussi, j'ai fait hier soir la liste de quel ramcall prend quoi ici ou là, et qu'est-ce qu'il renvoie ici ou là, c'est imbitable à implémenter (utilisation de d0,d1,d5,a0,a2,a5 , mais aussi... rien!). J'en suis arrivé à la conclusion que l'idéal, c'est de ne corrompre aucun registre.
=> C'est pour ça que l'adresse de retour, tu sais pas quoi en faire, vu que tu ne sais pas où sera la pile quand tu restaureras SR.
=> c'est pour ça que je demandais une variable
=> c'est pour ça que pour se passer d'une variable, faut pousser l'adresse de retour dans la bonne pile, et donc trifouiller le SR sur la pile superviseur.

C'est le fruit de mes tentatives de code d'hier soir.
(et aux dernières niouzes, c'était ptêt bien dl'a merde. Je suis en train d'accoucher)

(même si je ne suis pas sûr qu'il soit fréquent d'utiliser des ROM_CALLs en F-Line quand on est en mode superviseur )

Utilisation de BitmapPut pour faire afficher à l'int5 un curseur dans un éditeur, par exemple.

Chic je vais avoir deux routines au choix

Ma version, je poste l'ensemble du handler. Ca compile, mais c'est pas testé, j'attends encore une fois le verdict avant de me casser les dents ...

Description : le but est de retourner une valeur dans d0 ou un pointeur dans a0 sans avoir détruit le moindre registre, ou encore d'appeler un ramcall sans rien avoir détruit non plus.
Pour ce, il faut distinguer deux cas, vu que le ramcall retournera au programme : si le vecteur a été appelé en mode superviseur (à priori ça devrait être rare), il faut mettre l'adresse de retour du handler sur la pile superviseur, sinon, il faut la mettre dans la pile utilisateur qui sera ajustée à cet effet. Encore une fois, tous les avis sont les bienvenus.
(au passage, il est possible de pousser un registre en moins sur la pile, pour deux octets de plus, avec un simple move.l a1,d1). Je le fais au cas où. Je fournirai aussi le patch.

; If $FFF0, 
;	~ jsr abs.l (Return address +6 / jsr to a1 ->Crash code+2 a1+(a1)
;	Ex:	dc.w	$FFF0 dc.l JumpAdr-*
; If $FFF2,
;	ROM_CALL avec un word.
;	Example: dc.w $FFF2, HeapAlloc*4
LINE_1111:
	movem.l	d0-d2/a0-a3,-(sp)	; Musn't trash any register for ramcalls. a3 won't be trashed, but it reserves space
	move.w	4*7(sp),d1		; Get Old SR
	movea.l	4*7+2(sp),a0		; Get Address of the 'crash'
	move.w	(a0)+,d0		; We get the instruction and a0 ->next instruction
	cmpi.w	#$F800,d0		; Is it > $F800 ?
	bls.s	\ramcall		; No, so it is perhaps a ramcall (FirstWindow is not a romcall)
		lea.l	4*7+6(sp),sp	; Pop 7 registers + SR + Address of the 'crash'
		subi.w	#$F800,d0	; Clean data
		movea.l	a0,a1		; Jsr/Jmp with a 32 bits offset	
		cmpi.w	#$FFF0-$F800,d0
		bne.s	\NoRelJsr
			adda.l	(a0)+,a1	; Get the Sub Routine
			bra.s	\Jump
\NoRelJsr	cmpi.w	#$FFF1-$F800,d0
		bne.s	\NoRelJmp
			adda.l	(a0)+,a1	; Get the Sub Routine
			move.w	d1,SR		; Restore SR
			jmp	(a1)		; Jmp with a 32 bits offset
\NoRelJmp	cmpi.w	#$FFF2-$F800,d0
		bne.s	\NoBigRomCall
			move.w	(a0)+,d0	; Read Offset
			lsr.w	#2,d0
\NoBigRomCall	movea.l	($C8).w,a1	; The address of the rom_call table
		cmp.w	-(a1),d0	; Compare rom_call and number of entries
		bcc.s	\crash		; Out of range ? => Crash
			move.w	d0,(VAR_SYSTEM1).w	; For debug purpose
			lsl.w	#2,d0		; * 4
			movea.l	2(a1,d0.w),a1	; + ($C8) MAX: 8000 rom_calls
\Jump			move.w	d1,SR		; Restore SR
			pea	(a0)		; Push return address
			jmp	(a1)		; Jump to Rom_call function

\ramcall:
	subi.w #$F000,d0				; Clean data
	cmpi.w	#MAX_RAMCALL,d0				; Valid ramcall ?
	bcc.s	\crash					; No, it's a crash
		move.b	RAM_TABLE_TYPE(pc,d0.w),d2	; Read type of ramcall (table of bytes)
		lea	RAM_TABLE(pc),a1		; Ptr to the ramcall table
		lsl.w	#2,d0				; Table of longwords
		movea.l	0(a1,d0.w),a1			; Read ramcall
		tst.b	d2				; What type of ramcall ?
		bmi.s	\ReturnPtr			; -1 : return a ptr in a0
		beq.s	\ReturnData			; 0  : return data in d0
			btst.b	#5,28(sp)		; Called in supervisor mode ?
			beq.s	\UserMode		; No
				move.w	7*4(sp),6*4(sp)		; Rewrite SR (need another return adress on the stack)
				move.l	a1,6*4+2(sp)		; Set the ramcall ptr as the return adress of the handler
				move.l	a0,7*4+2(sp)		; Push the return adress of the ramcall
				movem.l	(sp)+,d0-d2/a0-a2	; Restore registers, but not a3 which hasn't ben destroyed
				rte				; And quit the handler, calling the ramcall
\UserMode:
	move.l	USP,a2					; Read user stack pointer
	move.l	a0,-(a2)				; And push the return adress of the ramcall
	move.l	a2,USP					; Save the new stack pointer
	move.l	a1,4*7+2(sp)				; Set the ramcall ptr as the return adress of the handler
	movem.l	(sp)+,d0-d2/a0-a3			; Restore all registers
	rte						; Call ramcall
	
\ReturnPtr:
	move.l	a1,12(sp)				; Modify saved a0
	bra.s	\EndDataPtr				; Useless ?
\ReturnData:
	move.l	a1,(sp)					; Modify saved d0
\EndDataPtr:
	movem.l	(sp)+,d0-d2/a0-a3			; Restore destroyed registers
	addq.l	#2,2(sp)				; Return adress points now after the 'crash'
	rte						; And come back

\crash:	lea	Line1111_str(Pc),a0
	bra	FATAL_ERROR

RAM_TABLE_TYPE:						; -1 : ptr. 0 : data. +1 : routine
	dc.b	-1,0,0,-1,0,0,0,0,0,0,0,0,0,-1,-1,0,-1,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,-1,-1,-1,1,0,0,0,0,0,1,1,1,1,-1,-1,-1
	even

C'est l'idée.
A noter que s'il faut retourner une donnée dans d0 ou une addresse dans a0, tu peux dans les 2 cas retourner les 2 dans les 2 registres. Ca simplifie le code.

PpHd (./50) :
C'est l'idée.

Ah ! Tant mieux, j'ai pas l'impression d'avoir perdu mon temps.
Mais ça veut dire quoi au juste :
- "ça marche peut-être, teste et tiens-moi au courant"
- "c'est ça grosso merdo, mais j'ai vu des bugs, cherche encore "
- "c'est pas tout à fait l'interface que je souhaite"
?

PpHd (./50) :
A noter que s'il faut retourner une donnée dans d0 ou une addresse dans a0, tu peux dans les 2 cas retourner les 2 dans les 2 registres. Ca simplifie le code.

J'y ai pensé, ça permet d'avoir une table de type juste faire de 1 et de 0 (ou un bitfield même, dis-moi ce que tu voudrais). Dans l'état en tout cas, ça gagnerait 4 octets (un bmi.s et un bra.s).
L'avantage de garder ça comme ça est qu'on n'a jamais de registre détruit. Pour 4 octets, je pense que c'est une bonne chose, après c'est toi qui décide. Que veux-tu ?

Folco (./51) :
- "ça marche peut-être, teste et tiens-moi au courant"

Voilà.

Folco (./51) :
Que veux-tu ?

L'avantage est de simplifier le contrat du RAM_CALL. A toi de voir après puisqu'il n'y aura que toi pour t'en servir ;p

Tout marche du premier coup !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Testé sur EExec (kernel::LibsExec, kernel::exit et kernel::exec), qui fait maintenant moins de 900 octets (dont 300 de texte), et qui bouffe la mémoire colossale de 0 octets au run-time ^10
Testé aussi avec d'autres retours de valeur, données et adresse, tout bon.

Voici le patch : Fichier joint : patch.diff



A noter que :
- j'ai laissé les retours de valeurs comme je l'avais implémenté. Les 4 octets perdus sont très vite rattrapés dans du code utilisateur. Mais c'est toi qui décide, la modif est minime à faire ; perso je préfère ma solution.
- faut vérifier absolument la table des types, doit y en avoir de faut, vu que je sais même pas à quoi ils correspondent (pas tous documentés). Yen a sûrement de faux.

Ca a l'air pas mal

+   cmpi.w  #$F800,d0       ; Is it > $F800 ?
+   bls.s   \ramcall        ; No, so it is perhaps a ramcall (FirstWindow is not a romcall)
+       lea.l   4*7+6(sp),sp    ; Pop 7 registers + SR + Address of the 'crash'
+       subi.w  #$F800,d0   ; Clean data
...
+\ramcall:
+   subi.w #$F000,d0                ; Clean data

->

+   subi.w  #$F800,d0       ; Is it > $F800 ?
+   bls.s   \ramcall        ; No, so it is perhaps a ramcall (FirstWindow is not a romcall)
+       lea.l   4*7+6(sp),sp    ; Pop 7 registers + SR + Address of the 'crash'
...
+\ramcall:
+   addi.w #$800,d0                ; Clean data

?

Anéfé. On peut aussi ne pas pousser a3, puis faire
\UserMode:
move.l a1,d1
move.l USP,a1
move.l a0,-(a1)
move.l a1,USP
move.l d1,4*7+2(USP)
Ca évite de pousser/popper un registre d'adresse, mais le code est moins lisible. En fait hier, j'ai rien optimisé j'avoue.

Just add '!' before the filename you don't want to compresse (The first file MUST be compressed !)

Ah mais nan c'est pas possible ça ! T'es vraiment très sûr que c'est vraiment très très obligatoire ? :'(

	.include	"kernel.h"

_main:	.xdef	_main

	.xdef	_ti89
	.xdef	_ti89ti
	.xdef	_ti92plus
	.xdef	_v200

	.xdef	_flag_2				|console apps : no redraw screen

	jmp	eexeclib__0000

J'ai l'air malin hein...


edit -> tiens tiens tiens...

	.xdef _nostub
__main:	.xdef	__main

	.xdef	_ti89
	.xdef	_ti89ti
	.xdef	_ti92plus
	.xdef	_v200

__main:
	clr.l	-(%sp)			|function + version
	bsr.s Push
	.asciz	"exclb"
Push:	.word 0xF000+ <LibsExec>

Faster, smaller, harder, stronger

(ya juste que je ne sais pas comment ne pas faire redessiner l'écran )

edit2 -> mon loader fait 17 octets, mais soi disant que c'est pas un programme, méssant PedroM :'(

Folco (./56) :
Ah mais nan c'est pas possible ça ! T'es vraiment très sûr que c'est vraiment très très obligatoire ? :'(

Chais plus. A une époque oui.

Folco (./56) :
Faster, smaller, harder, stronger

Heu, oué mais je vais interdire les RAM_CALL pour programmes _nostub.
Certains fonctionnalités kernel n'ont pas sens sinon. Genre exit

Eh merde. Mais au moins, les ramcalls en fline seront dans la prochaine RC ? #retient_son_souffle"

Folco (./58) :
Eh merde. Mais au moins, les ramcalls en fline seront dans la prochaine RC ? #retient_son_souffle"

Je ne sais pas. As-tu testé de manière à assurer le niveau de qualité de PedroM. C'est que j'intégre pas du code à la va vite, moi monsieur
Puis PedroM est trop gros, faut que je corrige là... Mais j'ai super mal aux yeux

Folco (./53) :
Tout marche du premier coup !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

As-tu testé tous les RAMCALL ?
As-tu testé en mode superviseur ?

Tous les ramcalls, non, mais au moins la moitié, oui. Si tu pouvais me corriger la table des types, sûrement fausse, ça m'aiderait. Je ne sais même pas à quoi correspondent tous les ramcalls donc j'aurai du mal à le faire...

superviseur -> je fais ça tout de suite, même pas pensé, je m'en servirai jamais ^^

---

Superviseur, testé sur trois fonctions, la fonction voulue est bien exécutée. Testé suur la moitié en utlisateur. Vérifié tous les registres, c'est bon.
En superviseur et utilisateur, les registres sont bien tous restaurés correctement à chaque fois (données et adresse), j'ai pas testé toutes les valeurs, mais toutes celles que j'ai demandées sont bonnes. J'ai besoin de la table corrigée pour les tester toutes ^^