[Assembleur inline C++] Récupérer l'offset d'un label

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:

---

1 2 3 4 5 6 7 8 9 10

void fnct() { _asm { ... Label: ... mov eax, OFFSET Label ... } }

---

et le résultat :

Citation:

---

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

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++.

Citation:

---

Envoyé par 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++.

---

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?

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:

---

lea eax, [Label]

---

Ca devrait passer?

Malheureusement non :? toujours la même erreur...

Essaie tout simplement :

Code:

---

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.

Ç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.

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.

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:

---

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.

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:

---

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...

Citation:

---

Envoyé par 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é.

---

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 ;)

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 :cry:

Citation:

---

Envoyé par 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 :cry:

---

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

Citation:

---

Envoyé par Obsidian

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.

Citation:

---

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 ?

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)

:mrgreen: 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 :zoubi: ?

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.

Citation:

---

Envoyé par Rémi Coquet

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.

Citation:

---

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 :

Citation:

---

[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.

Citation:

---

Envoyé par Neutral

..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 :mouarf:

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)