Valeur de retour de certains ramcalls - Page 1

yop,


Autant c'est simple en assembleur, autant en C j'arrive pas à savoir comment ces ramcalls retournent les valeurs des fonctions appelées :

#define	kernel_LibsCall	_RAM_CALL_1B
__attribute__((__stkparm__)) unsigned long kernel_LibsCall(LibRef *lib, short function, ...);
#define	kernel_LibsExec	_RAM_CALL_1D
__attribute__((__stkparm__)) void kernel_LibsExec(char *name, short function, char version, ...);

Rappel de la doc :

34-kernel::LibsCall(LIB_DESCRIPTOR l, WORD function, ...)	(Preos only)

	The parameters are pushed on the stack.
	It will call the function without modifying the registers, and it will pop its argument
	during the call (LIB_DESCRIPTOR, function, and version).

	Destroy:
		Like the called function

	Example:
		lea	totolib(Pc),a0		; Toto string
		moveq	#1,d1			; Version 1
		jsr	kernel::LibsBegin
		move.l	a0,LibsDVar
		beq.s	\error

		...

		pea	arg2function		; Arg2 of the function
		move.w	#arg1function,-(a7)	; Arg1 of the function
		move.w	#3,-(a7)		; Function 3
		move.l	LibsDVar,-(a7)		; Libs descriptor
		move.w	#145,d0			; D0 = 145 for the function !
		jsr	kernel::LibsCall	; Call the function with stack args (arg2function, arg1function) and register args (d0).
		lea	(2+4+2+2+2+4)(a7),a7

		...

		move.l	LibsDVAr,a0
		jsr	kernel::LibsEnd
		...

	totolib		dc.b	"totolib",0
		BSS
	LibsCall	dc.l	0

35-kernel::LibsExec(char *lib_name, WORD function, BYTE version, ...)	(Preos only)

	The parameters are pushed on the stack.
	It calls the function without modifying the registers, and it pops its argument
	during the call (LIB_DESCRIPTOR, function, and version).
	BYTE doesn't follow the C convesion for char (Sorry). Uses macro instead.

	It relocs the library, calls the function and unreallocs the library.
	The parameters pushed on the stack are corrupted.
	If there is an error, the parameter 'lib_name' equals zero after the call.

	Destroy:
		Like the called function

	Example:
		pea	arg2function		; Arg2 of the function
		move.w	#arg1function,-(a7)	; Arg1 of the function
		move.b	#1,-(a7)		; Version 1
		move.w	#3,-(a7)		; Function 3
		pea	LibsName		; Libs Name
		move.w	#145,d0			; D0 = 145 for the function !
		jsr	kernel::LibsExec
		tst.l	(a7)
		lea	(2+4+2+2+2+4)(a7),a7	; Does not affect the flag
		beq.s	\error
		...

	LibsName	dc.b	"totolib",0

En assembleur, on sait quel registre lire, parce que c'est spécifié dans la doc de la fonction. Là, visiblement, on ne peut pas avoir de valeur de retour avec LibsExec ? Et avec LibsCall, on va se taper la valeur de d0 ? Mais si ma lib retourne un pointeur dans a0, je l'ai dans l'os avec ces ramcalls ?

kernell_LibsCall renvoie un Long non signé, pour les reste, il suffit souvent de regarder le détail des paramètres, ceux passés par adresse peuvent servir pour les retours

Yep, mais la lib que j'utilise est déjà designée, je vais pas en réécrire une identique pour le plaisir...
PpHd, je dois passer par LibsPtr, pas le choix ?

Tu peux mettre des trucs comme:

#define kernel_LibsExec_int _RAM_CALL_01D
__attribute__((__stkparm__)) int kernel_LibsExec_int(char *name, short function, char version, ...);
#define kernel_LibsExec_long _RAM_CALL_001D
__attribute__((__stkparm__)) long kernel_LibsExec_long(char *name, short function, char version, ...);
#define kernel_LibsExec_ptr _RAM_CALL_0001D
__attribute__((__stkparm__)) void *kernel_LibsExec_ptr(char *name, short function, char version, ...);

et normalement ça devrait marcher (pour GCC, ces fonctions sont différentes et peuvent donc avoir des prototypes différents, pour ld_tigcc, c'est toujours le même RAM_CALL).

(Mais c'est vrai que cette API est mal fichue pour le C. On voit qu'elle a été spécifiée par un programmeur en assembleur.)