mcs51 - Page 1

je me suis amusé à reproduire le fonctionnement des ROM CALLS sur un 8051. voici ce que ça donne, je crois que le code est à peu près correct mais pas du tout optimisé, pour l'instant (généré par sdcc avec ses options les plus basiques)

#define ROM_CALL_TABLE 0x0004

#define __jmp_tbl (*(__code void * __code * __code *)ROM_CALL_TABLE)

#define _rom_call(type,args,intindex) (*((type(*)args)(__jmp_tbl[intindex])))

#define SerialInit _rom_call(void,(void),0)
#define SerialAvailable _rom_call(unsigned char,(void),1)
#define SerialRead _rom_call(char,(void),2)
#define SerialWrite _rom_call(void,(const char),3)

                          131 ;	src\main.c:4: SerialInit();
   0000 90 00 04            132 	mov	dptr,#(0x04&0x00ff)
   0003 E4                  133 	clr	a
   0004 93                  134 	movc	a,@a+dptr
   0005 FA                  135 	mov	r2,a
   0006 A3                  136 	inc	dptr
   0007 E4                  137 	clr	a
   0008 93                  138 	movc	a,@a+dptr
   0009 FB                  139 	mov	r3,a
   000A 8A 82               140 	mov	dpl,r2
   000C 8B 83               141 	mov	dph,r3
   000E E4                  142 	clr	a
   000F 93                  143 	movc	a,@a+dptr
   0010 FA                  144 	mov	r2,a
   0011 A3                  145 	inc	dptr
   0012 E4                  146 	clr	a
   0013 93                  147 	movc	a,@a+dptr
   0014 FB                  148 	mov	r3,a
   0015 C0 02               149 	push	ar2
   0017 C0 03               150 	push	ar3
   0019 8A 82               151 	mov	dpl,r2
   001B 8B 83               152 	mov	dph,r3
   001D 12s00r00            153 	lcall	__sdcc_call_dptr
   0020 D0 03               154 	pop	ar3
   0022 D0 02               155 	pop	ar2
.....
                          220 ;	src\main.c:8: SerialWrite('l');
   0082 90 00 03            221 	mov	dptr,#(0x04&0x00ff)
   0085 E4                  222 	clr	a
   0086 93                  223 	movc	a,@a+dptr
   0087 FA                  224 	mov	r2,a
   0088 A3                  225 	inc	dptr
   0089 E4                  226 	clr	a
   008A 93                  227 	movc	a,@a+dptr
   008B FB                  228 	mov	r3,a
   008C 74 06               229 	mov	a,#0x06
   008E 2A                  230 	add	a,r2
   008F F5 82               231 	mov	dpl,a
   0091 E4                  232 	clr	a
   0092 3B                  233 	addc	a,r3
   0093 F5 83               234 	mov	dph,a
   0095 E4                  235 	clr	a
   0096 93                  236 	movc	a,@a+dptr
   0097 FA                  237 	mov	r2,a
   0098 A3                  238 	inc	dptr
   0099 E4                  239 	clr	a
   009A 93                  240 	movc	a,@a+dptr
   009B FB                  241 	mov	r3,a
   009C C0 02               242 	push	ar2
   009E C0 03               243 	push	ar3
   00A0 74 6C               244 	mov	a,#0x6C
   00A2 C0 E0               245 	push	acc
   00A4 8A 82               246 	mov	dpl,r2
   00A6 8B 83               247 	mov	dph,r3
   00A8 12s00r00            248 	lcall	__sdcc_call_dptr
   004D 15 81               185 	dec	sp
   004F D0 03               186 	pop	ar3
   0051 D0 02               187 	pop	ar2

(et optimisé c'est pareil en fait )

L'optimisation de SDCC sux tout simplement.

C'est sûrement lié à cette partie-là du message « mais pas du tout optimisé »

oui mais

squalyl (./2) :
(et optimisé c'est pareil en fait )

(ça change absolument rien)

mais bon aussi c'est un cpu 8 bits, y'a just DPTR qui est une paire de registres, qui peut servir d'adresse mais doit être chargé en deux coups (DPL puis DPH) ^^

donc je peux me démerder pour virer les clr a totalement inutiles mais a part ça je pense que y'a pas grand chose à faire à part donner directement l'adresse de la table de rom calls pour virer une indirection.

KK> indirections multiples avec adresses 16 bits sur un cpu 8 bits sux surtout

euh... tu peux m'expliquer en 3 mots ce que ça fait stp, ça a l'air drôle (tu peux expliquer en 68k au besoin ^^)

Bah tu peux lire le code ASM, vu que tu connais l'asm 68k tu devrais pas avoir trop de problème ^^
Sinon c'est clair que le 8501 c'est assez la dèche niveau arithmétique pointeur (enfin, pas seulement). Mais en général il sont clockés assez haut.

Folco > des rom calls ^^

une partie de mon prog est en (ep)rom et contient un tableau de pointeurs vers des fonctions, l'adresse de cette table est stockée à une adresse fixe.
le code utilisateur est en (non volatile)ram et je lui fais appeler des fonctions de la ROM au lieu de les recoder.

sur ams c'est l'adresse $C8 qui contient l'adresse de la table des ROM CALLS, et à cette adresse t'as un tableau de pointeurs vers les routines elles mêmes.
et pour l'appeler, c'est le code de tigcc/gcc4ti dans default.h qui fait le lien. Ces trois jolies lignes font un cast magique qui transforme un numéro de rom calls en instructions jsr ou bsr vers cette adresse, tout en mettant les bons paramètres sur la pile:

#define ROM_CALL_TABLE 0x0004 
 #define __jmp_tbl (*(__code void * __code * __code *)ROM_CALL_TABLE) 
#define _rom_call(type,args,intindex) (*((type(*)args)(__jmp_tbl[intindex]))) 
#define SerialInit _rom_call(void,(void),0) 

(les __code c'est parce que le mcs51 a plusieurs types de mémoire, alors il faut dire quelle mémoire est pointée par le pointeur, et dans quelle mémoire est stockée le pointeur )
mais le code généré sur un micro 8 bits est assez pourri, et y'a pas le choix, j'ai pu simplifier un peu en donnant directement l'adresse de la table et pas l'adresse d'une case mem ou est stockée l'adresse de la table, ça supprime une indirection mais bon c'est pas encore ça:

Brunni> en fait ce qui suxe le plus c'est le SP qui fait 8 bits (et avant que je recode un compilateur pour faire une ABI qui supporte un SP de 16 bits, il se passera du temps, mais bon c'est un microcontroleur aussi, pas un microprocesseur).