1. C'est génant si on passe une partie des arguments par registres, une autre par la pile (obligé, avec une va_list) ? Il suffit de ne préciser des registres que là où on en utilise et ça va ?
2. C'est gênant si on utilise des registres >= a2 ?
C'est génant si on passe une partie des arguments par registres, une autre par la pile
2. C'est gênant si on utilise des registres >= a2 ?
short TestCollide8_R(short x0 asm("%d0"), short y0 asm("%d1"), short x1 asm("%d2"), short y1 asm("%d3"), unsigned short height,
const unsigned char* data0 asm("%a0"), const unsigned char* data1 asm("%a1")) __attribute__((__stkparm__));(tiens au fait, faut mettre les '%' ??)
Le stkparm sert à quoi ?
Ce n'est pas évident que les arguments sans 'asm("...")' sont passés par la pile ?
), c'est pour ça que j'ai mis un stkparm explicite.
Et est-ce que ça veut dire qu'un programme utilisant d3 comme variable globale déconnerait en utilisant une telle fonction ?
; int pdtlib__ManageCmdline (CMDLINE* CmdLine, void* Data, const char* OptList, int (*Callback)(void* Data asm("a0"), int Status asm("d0")),
; void (*SwitchFunc)(void* Data asm ("a0"), char Sign asm ("d0")), ...);
) en ~410 octets d'assembleur une lib C qui en fait 625. Et niveau vitesse on en parle même pas.
Folco (./150) :
1. C'est génant si on passe une partie des arguments par registres, une autre par la pile (obligé, avec une va_list) ? Il suffit de ne préciser des registres que là où on en utilise et ça va ?
2. C'est gênant si on utilise des registres >= a2 ?
Folco (./152) :
Et est-ce que ça veut dire qu'un programme utilisant d3 comme variable globale déconnerait en utilisant une telle fonction ?
les global register variables sont une mauvaise idée.
const short OffsetsTable [] = {Func1-&OffsetTable, Func2-&OffsetTable, ...};
void Func1() {}
void Func2() {}
int main ()
{ LibCall(OffsetTable);}
#include "kernel.h"
#define USE_TI89
void func1 (void)
{
}
void func2 (void)
{
}
int pwet (unsigned short* Table)
{
return Table[0] = Table[1];
}
int _main (void)
{
unsigned short Table [] =
{
(unsigned short)((long)func2 - (long)Table),
(unsigned short)((long)func1 - (long)Table),
};
return pwet(Table);
}func1:
link.w %fp,#0
unlk %fp
rts
.even
.globl func2
func2:
link.w %fp,#0
unlk %fp
rts
.even
.globl pwet
pwet:
link.w %fp,#0
move.l 8(%fp),%a0
addq.l #2,%a0
move.w (%a0),%d0
move.l 8(%fp),%a0
move.w %d0,(%a0)
move.l 8(%fp),%a0
move.w (%a0),%d0
unlk %fp
rts
.even
.globl _main
_main:
link.w %fp,#-4
move.l #func2,%d0
move.w %d0,%d1
move.l %fp,%d0
subq.l #4,%d0
move.w %d0,%d0
move.w %d1,%a0
sub.w %d0,%a0
move.w %a0,%d0
move.w %d0,-4(%fp)
move.l #func1,%d0
move.w %d0,%d1
move.l %fp,%d0
subq.l #4,%d0
move.w %d0,%d0
move.w %d1,%a0
sub.w %d0,%a0
move.w %a0,%d0
move.w %d0,-2(%fp)
move.l %fp,%d0
subq.l #4,%d0
move.l %d0,-(%sp)
jbsr pwet
addq.l #4,%sp
unlk %fp
rts
pwet.c:20: error: initializer element is not constant (near initialization for 'Table[0]') pwet.c:21: error: initializer element is not constant (near initialization for 'Table[1]')
Godzil (./169) :
static peut-etre plutot non ?
Sally (./170) :
dans ce cas il faut effectivement le déclarer soit static soit comme une variable globale (dans les deux cas il sera créé à la compilation et non au runtime)
Kevin Kofler (./171) :
Bah, j'aurais dû expliciter mon ./164: on avait déjà cette discussion! Une différence d'adresses n'est pas une constante en C (sauf dans le cas particulier où ce sont 2 champs de la même structure)
void* ArcPtr; void* ArcBasePtr; long Offset; // initialisations toussa ArcPtr = ArcBasePtr + Offset;
Le type void* ne peut pas être soumis à des calculs arithmétiques
Exemple :
void *ad1, *ad2;
ad1 ++; // interdit
ad2 = ad1 + 5; // interdit
On notera que ces interdictions sont justifiées si l'on part du principe qu'un pointeur générique est simplement destiné à être manipulé en tant que tel, par exemple pour être transmis d'une fonction à une autre. En revanche, elles le sont moins si l'on considère qu'un tel pointeur peut aussi servir à manipuler des octets successifs ; dans ce cas, il faudra quand même recourir au type char*.
Ximoon (./174) :
Tu compiles en -Wall ?
Lionel Debroux (./175) :
Ca, c'est une extension de GCC au standard C. Ton livre documente le C standard - et donc, pas cette extension non standard
Ximoon (./174) :
je suppose que ça incrémente comme s'il s'agissait d'un char*, mais c'est à vérifier.
Lionel Debroux (./175) :
Il y en a qui ne voient pas trop l'intérêt par rapport à l'utilisation de char * / unsigned char * / int8_t * / uint8_t * ou types équivalents (pointeur vers octet).
)
