Discussion :

[ShivX]

Bonjour a tous,

J'ai un léger problème avec l'assembleur inline dans un programme en C++, n'étant pas un expert en asm j'espère que vous pourrez m'éclairer un peu.

J'essaye désespérément de récupérer l'offset d'un label... sans résultalt... la compilation bloque

Voici la portion de code qui pose problème :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
void fnct() {
	_asm {
	  ...
    Label:
          ...
        mov eax, OFFSET Label 
	  ...  
	}
}

et le résultat :

E029: col(1) symbol 'Label' has not been declared

Je compile avec open watcom... je sais pas si la syntaxe est bonne ou même permise sous ce compilateur...

Merci d'avance pour vos réponses

[Neutral]

Ton compilateur signale que Label, en tant que variable, n'est pas déclarée. Et c'est bel et bien le cas vu que tu utilises ce nom comme label .
Un label représente une adresse/position. Même utilisation qu'avec les goto etc que tu dois surement déjà connaitre si tu fais du C++.

[ShivX]

Ton compilateur signale que Label, en tant que variable, n'est pas déclarée. Et c'est bel et bien le cas vu que tu utilises ce nom comme label .
Un label représente une adresse/position. Même utilisation qu'avec les goto etc que tu dois surement déjà connaitre si tu fais du C++.

Je comprend bien ou est fondamentalement l'erreur... du moins comment le compilateur l'interprète mais justement étant très amateur dans l'assembleur, j'ai déjà pu voir ce genre de code dans des sources qui n'avaient pas l'air de poser problème... donc est ce que l'opérateur OFFSET peut d'une manière ou d'une autre récupérer l'offset d'un label? ou sinon... comment pouvoir récupérer cet offset?

[Neutral]

Ha ok, je vois maintenant ce que tu voulais faire. Je croyais que tu étais partis par mégarde sur autres chose.

Je n'ai jamais toucher à Open Watcom, mais un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lea eax, [Label]

Ca devrait passer?

[ShivX]

Malheureusement non toujours la même erreur...

[Obsidian]

Essaie tout simplement :

Code ASM :

Sélectionner tout - Visualiser dans une fenêtre à part

mov eax,Label

Une étiquette (label en anglais) est en elle-même un symbole, qui représente une valeur. Étant donné que celle-ci ne correspond à rien de plus compliqué qu'une position en mémoire, il n'y a pas d'ambigüité, et le symbole sera directement substitué par ce à quoi il correspond.

[Neutral]

Ça ne fonctionnera pas non plus.

Malheureusement même dans les exemples de code fournis par le compilo j'ai vu qu'ils utilisent surtout pragma pour l'asm.

[ShivX]

Effectivement ca ne fonctionne pas non plus
Je commence a désespérer... j'ai déjà un peu tout fouillé et testé pour trouver une solution à ce problème et rien de concluant pour l'insant.

[Neutral]

C'est que la documentation semble cruellement manquer du côté de l'asm inline sous watcom. Car sinon au niveau syntaxique, ce que l'on t'a présenté ci-dessus fonctionne. J'ai testé sur main qui est déjà définie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
     _asm
     {
       lea eax, [main]
     }

Et ca passe comme une lettre à la poste.
Si trouves ne serait-ce qu'un exemple je pense qu'il pourrait s'avérer utile.

J'ai fais un peu d'asm inline avec gcc mais l'analogie avec watcom n'est pas réellement possible ici on dirait. Si tu stagnes toujours essaye de dénicher quelques utilisateurs de watcom sur les news groups/mailing lists ou sur leur chan IRC.

[ShivX]

Oui effectivement ca marche... car tu reprends l'adresse de la fonction main() mais je cherche a récupérer l'adresse d'un label défini dans l'asm lui même comme dans le code présenté.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
void fnct() {
	_asm {
	  ...
    Label:
          ...
        mov eax, OFFSET Label 
	  ...  
	}
}

Récupérer l'offset de l'étiquette (ici nommée Label) et non pas l'adresse d'une variable ou d'une fonction définie en C++ et c'est la que ca bloque.

Je pense que je vais suivre ton conseil et essayer de trouver des utilisateurs de watcom ou p-e tout simplement change de compilateur...

[Neutral]

Oui effectivement ca marche... car tu reprends l'adresse de la fonction main() mais je cherche a récupérer l'adresse d'un label défini dans l'asm lui même comme dans le code présenté.

Oui j'avais saisis ce que tu recherchais, je confirmais juste le fait que le seul problème qu'il y a actuellement concerne la déclaration des labels. Et que donc les syntaxes que l'on a proposé étaient loin d'être les vraies solutions à ton problème.

Si tu la trouves tiens nous au courant

[ShivX]

C'est bien la le problème, étrangement les labels sont bien déclarés et ne causent aucun problème pour les instructions de type jump, call, loop... mais impossible de récupérer l'offset dans une autre instruction et c'est la que j'ai du mal a comprendre

[Neutral]

C'est bien la le problème, étrangement les labels sont bien déclarés et ne causent aucun problème pour les instructions de type jump, call, loop... mais impossible de récupérer l'offset dans une autre instruction et c'est la que j'ai du mal a comprendre

Oui c'est la grande zone d'ombre. Le traitement avec mov/lea/etc fait passer le label en non-déclaré ...

[Rémi Coquet]

Essaie tout simplement :


Code ASM :
mov eax,Label


Une étiquette (label en anglais) est en elle-même un symbole, qui représente une valeur. Étant donné que celle-ci ne correspond à rien de plus compliqué qu'une position en mémoire, il n'y a pas d'ambigüité, et le symbole sera directement substitué par ce à quoi il correspond.

+1: Tu confirmes que watcom "fonctionne" quand tu lui demandes un jump label. Ce n'est pas un lea ou un mov qui peuvent "faire passer en non-déclaré" (même si je comprends bien l'intention de Neutral).
Le problème est forcément lié à une spécificité de watcom.

J'essaye désespérément de récupérer l'offset d'un label... sans résultalt... la compilation bloque

Désolé de te demander de préciser: Où désires-tu récupérer l'adresse

1: En mode debugg dans eax dans la partie inline ?
2: Dans le C++ attribué à une varible ?

Est-ce qu'eax, en mode step, contient le LP -> Label ?

[Goten]

Moi j'ai une autre question :
pourquoi?

Si c'est pour essayer de battre le compilo parce que c'est une partie critique tu peux oublier déjà...
(le compilo est vraiment fort à ce jeu là :p)

[Rémi Coquet]

Je me vois mal aller sur la partie du forum ou tu discutes de ton super compilateur pour ballancer ce genre de propos incongrus.
Si tu veux aborder la question (enfin le troll) pourquoi ne pas le faire directement aux bons endroits ?

[Goten]

Je savais que pas que sur dvlp c'était cloisonné. (soit dit en passant jvois pas en quoi mon message concerne le compilateur, si peut être le : "il est fort à ce jeu là", bah si c'est que ça je l'enlève).
En gros non c'était pas un troll c'est au contraire une des choses qu'on apprends quand on commence à parler d'optimisation : il est rare de pouvoir battre le compilateur, et à ce petit jeu là c'est plus une perte de temps qu'autre chose.
Note bien la nuance (sinon on v'a m' accuser de troll) : "rare". Donc si je me suis permis de dire ça c'est que en l'occurrence le PO n'est pas ultra qualifié en asm (il le dit lui même) donc je vois pas l'intérêt.


ps (et pour ton information) : je supporte aucun compilo et ça m'est un peu égal d'ailleurs, ce qui m'intéresse c'est le code stout.

[Neutral]

Ce n'est pas un lea ou un mov qui peuvent "faire passer en non-déclaré" (même si je comprends bien l'intention de Neutral). Le problème est forcément lié à une spécificité de watcom.

Oui je faisais référence à son comportement, et donc à sa spécificité.
Tu l'avais compris.

Désolé de te demander de préciser: Où désires-tu récupérer l'adresse

1: En mode debugg dans eax dans la partie inline ?
2: Dans le C++ attribué à une varible ?

Il semblerait qu'il souhaite juste récupérer, pour le moment, l'adresse du label dans eax, et pas encore dans la partie C++ dans une variable précise.

Ce qui m'inquiète plutôt c'est le manque de doc de leur part sur le sujet
Si on se réfère à l'expérience d'un des utilisateurs de ton compilo :

[10:56] <MichalN> You can't do that.
[10:57] <MichalN> But if you don't absolutely positively have to, don't use _asm at all. Either use #pragma aux, which integrates with the code generation much better, or use external assembler modules.
[11:03] <MichalN> It's not impossible to do, but it's not implemented. It can be considered a feature do discourage people from writing inline assembly.
[11:04] <MichalN> Because believe me, inline assembly is bad. I've written enough of it to know

Cela confirme bien que _asm() est vraiment délaissé au profit de l'utilisation des pragma. Après je ne vois pas personnellement où se cache le troll que tu suspectes Rémi.

[Rémi Coquet]

..je ne vois pas personnellement où se cache le troll que tu suspectes...

La question posée n'a rien à voir avec un question d'optimisation et ce post n'apporte aucune aide à notre ami dans son problème.

Maintenant si tu veux répondre aux affirmations désespérement communes sur les rapports de perfs. compilateur vs codeur (le codeur assembleur est-il plus performant qu'un programme générique écrit par un autre codeur). Je t'en prie: Fais-toi plaisir

[Goten]

Non justement on ne sait pas pourquoi il veut le faire, d'où ma question, et si la réponse est performance (si j'ai dis ça c'est parce que c'est pas la première fois que je le vois) alors il vaut peut être mieux qu'il abandonne.

(mon premier post était dans cette optique, c'était pas le souhait de balancé une banalité trollesque, sinon j'irais sur #emacs et j'irais balancer vim ftw)