bubblesort et autres galeres

[christophe_de_Berlin]

Bonjour, je suis assez nul en programmation et j'ai un problème qui doit être assez élémentaire:

Il s'agit de programmer un code en C qui construit une liste de disons 10 nombres. Le programme appelle ensuite une fonction bubblesort écrite en assembleur.

Mon problème est élémentaire: Évidement je n'envoie pas la liste de tous les nombres, je veux envoyer l'adresse mémoire du premier nombre à Assembleur, et c'est déjà ca qui coince. J''ai commencé par écrire une programme qui en fait ne fait rien - l'algorithme bubblesort on verra plus tard.
Mon programme se contente d'envoyer la premiere adresse à ma fonction assembleur, qui d'après ce que j'ai compris d'assembleur, attérit dans le registre "rdi" (je travaille en linux 64bit). Ma fonction assembleur ne fait (pour l'instant) que copier rdi dans rax. C'est donc le résultat.
Mon programme en C fait un printf de cette adresse, puis il appelle la fonction, puis il refait un printf du résultat de la fonction.
les deux printf devraient être identiquent, il ne le sont pas. le deuxième ne me donne que la deuxième moitié car ma fonction est un int, donc trop petite pour 64 bits. Mais si je la fait plus grande, avec double par exemple, les résultats sont totalement faux...

Quelqu'un a une idée? Sûrement qu'il faut s'y prendre complètement autrement.

Merci d'avance.

Christophe

PS: voilà les codes en question

---
#include<stdio.h>

int  bubblesort();
 

int main() {

	int laenge = 10;
	int i;
	int j;
	int liste[laenge];
	
	
	printf("%p \n", &liste[0] ); 
		

for (i = 0; i < laenge; i++)
	{
	liste[i] = 1;
	}
printf("%x \n\n", bubblesort(&liste[0])); 
 	return 0; 

}

---ASSEMBLEUR

section .text

global bubblesort


bubblesort:

	mov rax, rdi
	jmp ende
	

ende:
	ret

-----

[lou_ibmix_xi]

Je ne peux pas t'aider pour la partie assembleur. En revanche, si un "int" n'est que 32 bits (ça m'étonne, il me semblait que la taille d'un "int" était la taille du pointeur de la plateforme...), alors "double" n'est certainement pas la solution, puisque c'est un type flottant (double precision), utilise 'long int', ou 'int64_t' (nécessite #include <stdint.h>), ou "void*" comme type de retour de ta fonction.

[whoami]

Bonjour,

+1 pour la taille, et pour l'utilisation de int64_t, qui te garantit la taille de la variable.

De plus, comme tu renvoies un pointeur, il faut également utiliser %p comme format d'affichage, ne serait-ce que pour rester cohérent.

[polo974]

Il y a moyen de comiler du C vers l'assembleur et de s'arrêter là, donc:

Tu écris ton code tout en C (avec un bon proto de ta fonction void bubblesort(int * tab, int len); )

tu le compiles (ajuster le nom des fichiers):

cc bl.c -o bl.s  -S -fverbose-asm -O

tu ouvres le .s et tu disposes d'un squelette de ta fonction que tu peux réécrire en assembleur.

[A voir en vidéo sur Futura]

[christophe_de_Berlin]

Bon, maintenant j'ai réussi à écrire mon truc en C, il envoie l'adresse liste[0] à assembleur, mais mon problème c'est mon algorithme dans assembleur qui ne fonctionne pas du tout. Pourtant je n'arrive pas à voir la faute de logique. Voila mon programme:

section .text

global bubblesort


bubblesort:

	push rbp	; base pointer wird gesichert
	mov rbp, rsp 	; 
	MOV rdx, 0	;counter

	

	
schleife1:		
			CMP rdx, 10
			je ende
			INC rdx
			MOV rcx, 0
			

	schleife2:	CMP rcx, rsi
			je schleife1

			MOV rax, [rdi + 4*rcx]
			MOV rbx, [rdi + 4*rcx + 4]

			CMP rax, rbx
			jg tausche

			INC rcx
			jmp schleife2

	tausche:	MOV [RDI + 4*RCX], rbx
			MOV [RDI + 4*RCX + 4], rax
			INC rcx
			JMP schleife2
	
	
	ende:		pop rbp        ; restore base pointer
			ret

[whoami]

Bonjour,

En standard, C passe les paramètres par la pile, et je ne vois rien dans ton code pour aller les chercher.

Peut-être que ton compilateur les passe directement dans des registres, mais il doit alors avoir besoin d'un mot clé pour le faire, ou alors c'est un drôle de compilateur.

Montre-nous tout ton code. Enfin tout ... la partie qui concerne ce problème, donc la partie déclaration, implémentation du C.

[christophe_de_Berlin]

Mon compilateur est gcc, sous ils passe les 3 premiers paramètres directement dans les resgistres rdi, rsi, rdx. Ca ca marche, j'ai largement vérifié. Voici mon code c:

--------------------

#include<stdio.h>


void bubblesort(int[], int);
 

int main() {

	int laenge = 10;
	int i = 0;
	int j;
	int liste[laenge];
	

		
	//Erzeugung einer Liste:

	for (i = 0; i < laenge; i++)
	  {
	    liste[i] =   i;
	  }

	

	printf("\n\n==============  UNSORTIERTE ZAHLEN ==========================\n\n");

	for(i = 0; i<laenge; i++)
	  {
	    printf("An der Adresse: %p ist der Wert %i gespeichert\n ", &liste[i], liste[i]);
	    
 	  }
       



       /* 
	* die Adresse von liste[0] wird an bubblesort.asm gegeben und 
	* bubblesort.asm hat die Adresse von &liste[0] in reg 'rdi', laenge landet im reg "rsi".
	*/


      bubblesort(&liste[0], laenge);
	printf("\n\n==============  NACH SORTIERUNG DER ZAHLEN ==========================\n\n");
	
      for(i = 0; i<laenge; i++)
	  {
	    printf("An der Adresse: %p ist der Wert %i gespeichert\n ", &liste[i], liste[i]);
	    
 	  }

	return 0; 

}

[christophe_de_Berlin]

Je viens de m'apercevoir que ma fonction assembleur d'échange des données ne marche pas: Je l'ai testé sur des segments de mon array: par exemple si j'échange [0] contre 1, j'obtiens:
1
0
1
3
4
5
....

Mais j'ai beau y regarder, je ne vois pas ma faute de logique


Désolé, les commentaires dans mes codes sont en Allemand car je suis sur Berlin, mais bon....

[JPL]

Cela fait trois fois que j'ajoute la balise Code (#) à ta place. Ce n'est pas aux modérateurs de faire ton travail.

[whoami]

Bonjour,

On a déjà insisté sur le fait qu'il faut utiliser un type dont tu sois sûr de la taille.

En C, tu as un int, taille probable 32 bits.

En assembleur, tu en tiens compte pour le calcul des adresses, mais tu charges et compares les données en 64 bits, soit 2 variables en même temps, et bien entendu, ton programme ne peut pas deviner que ce n'est pas ça qu'il faut faire.

J'espère que tu vois que ça ne va pas ?

[polo974]

avec quoi et comment compiles-tu tout ça (c, assembleur et link) ?
commandes complètes ou Makefile (pour comprendre ta syntaxe asm qui n'est pas celle de gcc)

sinon pour l'algo du tri à bulle, voir wiki (et wikibooks)

je répète que faire un cc -S permet de sortir l'assembleur, et donc de voir comment fait le compilo...

[christophe_de_Berlin]

Cela fait trois fois que j'ajoute la balise Code (#) à ta place. Ce n'est pas aux modérateurs de faire ton travail.

Oh pardon! j´étais pas au courant! Merci du renseignement.

[JPL]

Il suffisait de lire les messages automatiques annonçant une modification que le forum t'a envoyés.

[christophe_de_Berlin]

Bonjour,

On a déjà insisté sur le fait qu'il faut utiliser un type dont tu sois sûr de la taille.

En C, tu as un int, taille probable 32 bits.

En assembleur, tu en tiens compte pour le calcul des adresses, mais tu charges et compares les données en 64 bits, soit 2 variables en même temps, et bien entendu, ton programme ne peut pas deviner que ce n'est pas ça qu'il faut faire.

J'espère que tu vois que ça ne va pas ?

Bonjour, je sais pas exactement ce que tu veux dire, mais j´ai trouvé une solution, même si je ne suis pas sûr que ce soit la solution idéale. Après avoir comparé rax et rbx, au lieu de le renvoyer dans la mémoire respective, je n´envoie que eax et ebx, c´est-à-dire les 4 derniers bytes des valeurs inscrites dans la mémoire. Intuitivement j´ai bien l´impression que cela a à voir avec le problème que tu décris.

[whoami]

Bonjour,

Bravo, tu viens de découvrir la différence de taille des registres en fonction du préfixe (r.. => 64, e.. => 32, .. => 16, et ceux de 16 bits [pas tous] peuvent encore être divisés en 2 de 8 bits [AL et AH à partir de ax, ...).

Normalement, savoir ça est primordial si on veut faire de l'assembleur.

Mais il faut bien commencer un jour.

Ta solution est donc boiteuse, il faut lire les données dans eax, ebx, comparer ces 2 registres, et mettre les données au bon endroit si nécessaire.

[christophe_de_Berlin]

Normalement, savoir ça est primordial si on veut faire de l'assembleur.

Mais il faut bien commencer un jour.

Ben ouais, c´est mon cas, c´est pour cela que je fais ce cour hein.... Et pourtant, pourtant....ya encore quelquechose qui m´échappe: Je travaille en 64bit, donc la longueur de mes registres est de 64 bits.... mais la longueur de mes unités de mémoire aussi non? Quand je transfers un nombre de 64 bits de mon registre (qui a une capacité de 64 bits) dans une adresse mémoire (qui a également une capacité de 64 bits), pourquoi ce nombre devrait-il être tronqué?

Ou bien me goure-je?

Christophe

[whoami]

Bonjour,

Il ne fait pas confondre taille maxi des registres du processeur, et taille des données que tu veux traiter.

Dans ton cas, tes données font 32 bits, tu dois donc les traiter avec les instructions et registres 32 bits.

Attention, je parle des données, pas du calcul d'adresses pour y accéder en mémoire, qui lui doit se faire avec les registres 64 bits, du fait que tu utilises un système d'exploitation 64 bits.

J'espère que ça devient plus clair.

[polo974]

oups, ben oui, avec gcc version 4.4.3 Target: x86_64-linux-gnu
sizeof(...)
short 2
int 4
long 8

moi qui croyait que int, c'était le mot machine... quelle misère...

[whoami]

Bonjour,

oups, ben oui, avec gcc version 4.4.3 Target: x86_64-linux-gnu
sizeof(...)
short 2
int 4
long 8

moi qui croyait que int, c'était le mot machine... quelle misère...

C'est une des raisons pour lesquelles j'ai insisté sur la nécessité d'utiliser un type qui garantit la taille.

Pour cela, il suffit d'utiliser les définitions qu'on trouve dans <stdint.h>, avec des noms sans ambiguïté :
int32_t pour 32 bits signés
uint32_ t pour 32 bites non signés
int64_t ...

et ça met à l'abri des différences d'un compilateur à un autre.