Forum Graph100

laisse tombé, un "pointeur" far est en fait un unsigned long de 4 octets... tu ne peux pas le récupéré en asm de cette façon là... C'est une invention de Borland les far, et il n'y a que TC qui les gère.

Sonic est bourré de pointeurs far que je gere en asm avec "lds" et "les", exactement comme Swifter (en plus je pense qu'il bosse aussi en cpp), et je n'ai aucun bug! (bon d'accord ca m'a pris une semaine pour que ca soit au point, mais maintenant c OK  )

En fait je fais la meme chose pour ma fonction d'affichage de sprites, qui est déclarée comme ca:
void drawsprite(int x,char y,void far* spr);

La plupart du temps je lui donne un pointeur far directement vers le contenu de la memzone où sont stockés tous les sprites l'un derrière l'autre, mais parfois j'ai aussi des sprites déclarés dans le prog lui-meme, par exemple
u_char UnSprite[]={ ... };
et je peux faire drawsprite( ... , ... , UnSprite); sans le moindre problème 

Petite note qd meme sur lds, parce qu'apparemment c pas clair:

Si je fais un pointeur far, disons
unisigned char far* ptr=(unsigned char far*)MK_FP(0x8463,0xFFE2);
il indique donc bien l'offset 0xFFE2 dans le segment 0x8463.

Si en asm je fais
lds si,ptr
alors ca revient bien à mettre le numero du segment (0x8463) dans ds et le numero de l'offset (0xFFE2) dans si.
Donc après ca faire en asm
mov al,[si]
c la meme chose que faire en cpp _AL=*ptr; (sauf qu'il faudra faire gaffe parce qu'on a modifié ds en asm)

On peut aussi faire
les ax,ptr
par exemple, ca ca mettra le segment dans es et l'offset dans ax.

donc lds et les c bien pour charger l'adresse indiquée par le pointeur, pas l'adresse du pointeur lui-meme

Sinon allez jeter un oeil aux sources de sonic, ca peut servir 

Ah ben oui si les segments de la source et de la destination sont pas les memes, il faut passer aux far...

Moi je fais

void copy(void far* src, void far* dest, u_int taille)
{    //deplace 'taille' octets de l'emplacement 'src' vers 'dest'
asm {
    push ds
    cld

    mov cx, taille
    les di,dest            // es = segment du pointeur dest, di = offset
    lds si,src            // ds = segment du pointeur src, si = offset

    shr cx,1            // nombre de mots a copier
    jnc move_suite

    movsb                // si le nombre d'octets a copier est impair
    
} move_suite: asm {

    rep movsw            // copie chaque mot

    pop ds
    }
}

Et puis

unsigned char* new_str="test";  // adresse de new_str 0x802F:0x25A3 
    
if (condition_quelconque) 
{ 
   unsigned char* string="123456789"; // adresse de string 0x8486:0xFFE2 
   copy(new_str,string,5); 
} 

Et c ok...

Moui pour ce qui est de la sauvegarde des registres, en fait on s'en fiche, le seul qui est important c'est effectivement ds... TCC ne va jamais utiliser un registre autre que ds qui aurait pu etre modifié involontairement; il suffit d'examiner les traductions asm générées pour voir comment ca se passe

TC utilise les registres bien entendu, mais seulement qd c lui qui en a "fixé" la valeur; il n'utilisera jamais AX ou ES (ou les autres, sauf DS) si une fonction vient d'etre appelée ou si du code asm inline a été inséré, donc si sa valeur n'est pas connue a priori... ce qui me parait assez logique en fait  :?
Donc en conclusion, sauvegarder les registres que l'on utilise en asm inline dans un code cpp ne sert qu'à perdre du temps!  (sauf pour DS, mais c le seul qui en vaille la peine)
(au fait SI est le seul registre (avec BP) à être sauvegardé automatiquement qd il est utilisé par TC... Les autres étant des "registres de travail", leur modification ne devrait pas avoir de conséquences sur la suite si la structure du programme est "correcte".)