"Patrick Brunet" <Patrick.Brunet @ cned.fr> writes:
| Arnaud Boulan a évoqué la possibilité (gcc) d'avoir l'adresse d'un
simple
| label. Je cherche actuellement à savoir si ça c'est normalisé.
Prendre l'adresse d'un label est un des GNUismes que je voudrais voir
confiner au niveau -10. C'est une merde totale ce truc.
"Patrick Brunet" <Patrick.Brunet @ cned.fr> writes:
| Arnaud Boulan a évoqué la possibilité (gcc) d'avoir l'adresse d'un
simple
| label. Je cherche actuellement à savoir si ça c'est normalisé.
Prendre l'adresse d'un label est un des GNUismes que je voudrais voir
confiner au niveau -10. C'est une merde totale ce truc.
"Patrick Brunet" <Patrick.Brunet @ cned.fr> writes:
| Arnaud Boulan a évoqué la possibilité (gcc) d'avoir l'adresse d'un
simple
| label. Je cherche actuellement à savoir si ça c'est normalisé.
Prendre l'adresse d'un label est un des GNUismes que je voudrais voir
confiner au niveau -10. C'est une merde totale ce truc.
Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto calculé (je
rappelle que dans mon contexte, le C n'est pas un langage source mais une
cible intermédiaire, donc la programmation structurée est hors de propos).
Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto calculé (je
rappelle que dans mon contexte, le C n'est pas un langage source mais une
cible intermédiaire, donc la programmation structurée est hors de propos).
Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto calculé (je
rappelle que dans mon contexte, le C n'est pas un langage source mais une
cible intermédiaire, donc la programmation structurée est hors de propos).
In 'fr.comp.lang.c', "Patrick BRUNET" <zener-fusekey @ fr.st> wrote:Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto calculé
(je
rappelle que dans mon contexte, le C n'est pas un langage source mais
une
cible intermédiaire, donc la programmation structurée est hors de
propos).
Un pointeur de fonction ne va pas?
<HS>
Si tu manques de pile, tu peux toujours la réinitialiser après. J'ai
utilisé
cette technique un peu barbare dans du code d'init un peu velu de logiciel
embarqué. Ca fonctionne.
</HS>
In 'fr.comp.lang.c', "Patrick BRUNET" <zener-fusekey @ fr.st> wrote:
Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto calculé
(je
rappelle que dans mon contexte, le C n'est pas un langage source mais
une
cible intermédiaire, donc la programmation structurée est hors de
propos).
Un pointeur de fonction ne va pas?
<HS>
Si tu manques de pile, tu peux toujours la réinitialiser après. J'ai
utilisé
cette technique un peu barbare dans du code d'init un peu velu de logiciel
embarqué. Ca fonctionne.
</HS>
In 'fr.comp.lang.c', "Patrick BRUNET" <zener-fusekey @ fr.st> wrote:Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto calculé
(je
rappelle que dans mon contexte, le C n'est pas un langage source mais
une
cible intermédiaire, donc la programmation structurée est hors de
propos).
Un pointeur de fonction ne va pas?
<HS>
Si tu manques de pile, tu peux toujours la réinitialiser après. J'ai
utilisé
cette technique un peu barbare dans du code d'init un peu velu de logiciel
embarqué. Ca fonctionne.
</HS>
"Patrick BRUNET" <zener-fusekey @ fr.st> writes:
| Bonsoir.
|
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > "Patrick BRUNET" <zener-fusekey @ fr.st> writes:
| >
| > | Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto
calculé
| (je
| > | rappelle que dans mon contexte, le C n'est pas un langage source
mais
| une
| > | cible intermédiaire, donc la programmation structurée est hors de
| propos).
| >
| > Quel est le point technique fondamental qui empêche une programmation
| > structurée ?
|
| Il y en a deux :
|
| 1) l'algorithme est composé dynamiquement (au runtime), et donc
implémenté
| par enfilage de p-instructions,
ceci en soit n'est pas une raison qui élimine une programmation
structurée.
| 2) pour des raisons commerciales qui vont immanquablement faire hurler
| certains, il y a un objectif cryptographique.
au risque de te décevoir, un goto calculé n'est pas un moyen de
cryptage :-/
| Pour autant, le code C qui sert de cible intermédiaire est bien destiné
à
| être ensuite compilé en un exécutable.
aucun de points (1) et (2) n'implique que « la programmation
structurée est hors de propos ».
| Le but de cette étape C est
| d'apporter une solution de portabilité quasi universelle, irréalisable
avec
| de l'assembleur.
dans ce cas, tu ne cherches pas un goto calculé :-)
| C'est pourquoi j'ai besoin d'un goto calculé performant implémentable en
C
| standard.
"Patrick BRUNET" <zener-fusekey @ fr.st> writes:
| Bonsoir.
|
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le
message
| news: m3ptin14im.fsf@uniton.integrable-solutions.net...
| > "Patrick BRUNET" <zener-fusekey @ fr.st> writes:
| >
| > | Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto
calculé
| (je
| > | rappelle que dans mon contexte, le C n'est pas un langage source
mais
| une
| > | cible intermédiaire, donc la programmation structurée est hors de
| propos).
| >
| > Quel est le point technique fondamental qui empêche une programmation
| > structurée ?
|
| Il y en a deux :
|
| 1) l'algorithme est composé dynamiquement (au runtime), et donc
implémenté
| par enfilage de p-instructions,
ceci en soit n'est pas une raison qui élimine une programmation
structurée.
| 2) pour des raisons commerciales qui vont immanquablement faire hurler
| certains, il y a un objectif cryptographique.
au risque de te décevoir, un goto calculé n'est pas un moyen de
cryptage :-/
| Pour autant, le code C qui sert de cible intermédiaire est bien destiné
à
| être ensuite compilé en un exécutable.
aucun de points (1) et (2) n'implique que « la programmation
structurée est hors de propos ».
| Le but de cette étape C est
| d'apporter une solution de portabilité quasi universelle, irréalisable
avec
| de l'assembleur.
dans ce cas, tu ne cherches pas un goto calculé :-)
| C'est pourquoi j'ai besoin d'un goto calculé performant implémentable en
C
| standard.
"Patrick BRUNET" <zener-fusekey @ fr.st> writes:
| Bonsoir.
|
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > "Patrick BRUNET" <zener-fusekey @ fr.st> writes:
| >
| > | Mais dans mon cas, ça m'aurait bien dépanné pour faire du goto
calculé
| (je
| > | rappelle que dans mon contexte, le C n'est pas un langage source
mais
| une
| > | cible intermédiaire, donc la programmation structurée est hors de
| propos).
| >
| > Quel est le point technique fondamental qui empêche une programmation
| > structurée ?
|
| Il y en a deux :
|
| 1) l'algorithme est composé dynamiquement (au runtime), et donc
implémenté
| par enfilage de p-instructions,
ceci en soit n'est pas une raison qui élimine une programmation
structurée.
| 2) pour des raisons commerciales qui vont immanquablement faire hurler
| certains, il y a un objectif cryptographique.
au risque de te décevoir, un goto calculé n'est pas un moyen de
cryptage :-/
| Pour autant, le code C qui sert de cible intermédiaire est bien destiné
à
| être ensuite compilé en un exécutable.
aucun de points (1) et (2) n'implique que « la programmation
structurée est hors de propos ».
| Le but de cette étape C est
| d'apporter une solution de portabilité quasi universelle, irréalisable
avec
| de l'assembleur.
dans ce cas, tu ne cherches pas un goto calculé :-)
| C'est pourquoi j'ai besoin d'un goto calculé performant implémentable en
C
| standard.
"Patrick BRUNET" <zener-fusekey @ fr.st> writes:
[...]
Je fais la différence entre "code structuré" et "code structuré et
humainement lisible". Un code généré automatiquement par des outils
n'a pas forcément besoin d'être dans la deuxième catégorie.
[...]
| > | Le but de cette étape C est
| > | d'apporter une solution de portabilité quasi universelle,
irréalisable
| avec
| > | de l'assembleur.
| >
| > dans ce cas, tu ne cherches pas un goto calculé :-)
| >
|
| J'en cherche une implémentation standardisable en C ANSI.
Je ne sais pas si ce que je vais te dire va beaucoup t'aider :
Le comité C considère qu'il est lui-même en mode maintenance en ce
qui concerne le core language. Je doute très fortement qu'il ait
envie d'ajouter des goto calculés au langage -- cela a beaucoup
d'implication que tu ne le penses.
| Comment nommerais-tu un algorithme mutant réalisé par enfilage au
runtime de
| sections de code prédéfinies, elles-mêmes fournies comme les sections
d'un
| monobloc de C compilé (même si les codes effectifs se retrouvent
finalement
| dans des fonctions interchangeables invoquées par les sections du
monobloc)
| ?
cela me fait penser au mécanisme de fonctions virtuelles en C++. Mais
je présume que j'ai besoin d'avoir une description plus précise avant
de me prononcer.
"Patrick BRUNET" <zener-fusekey @ fr.st> writes:
[...]
Je fais la différence entre "code structuré" et "code structuré et
humainement lisible". Un code généré automatiquement par des outils
n'a pas forcément besoin d'être dans la deuxième catégorie.
[...]
| > | Le but de cette étape C est
| > | d'apporter une solution de portabilité quasi universelle,
irréalisable
| avec
| > | de l'assembleur.
| >
| > dans ce cas, tu ne cherches pas un goto calculé :-)
| >
|
| J'en cherche une implémentation standardisable en C ANSI.
Je ne sais pas si ce que je vais te dire va beaucoup t'aider :
Le comité C considère qu'il est lui-même en mode maintenance en ce
qui concerne le core language. Je doute très fortement qu'il ait
envie d'ajouter des goto calculés au langage -- cela a beaucoup
d'implication que tu ne le penses.
| Comment nommerais-tu un algorithme mutant réalisé par enfilage au
runtime de
| sections de code prédéfinies, elles-mêmes fournies comme les sections
d'un
| monobloc de C compilé (même si les codes effectifs se retrouvent
finalement
| dans des fonctions interchangeables invoquées par les sections du
monobloc)
| ?
cela me fait penser au mécanisme de fonctions virtuelles en C++. Mais
je présume que j'ai besoin d'avoir une description plus précise avant
de me prononcer.
"Patrick BRUNET" <zener-fusekey @ fr.st> writes:
[...]
Je fais la différence entre "code structuré" et "code structuré et
humainement lisible". Un code généré automatiquement par des outils
n'a pas forcément besoin d'être dans la deuxième catégorie.
[...]
| > | Le but de cette étape C est
| > | d'apporter une solution de portabilité quasi universelle,
irréalisable
| avec
| > | de l'assembleur.
| >
| > dans ce cas, tu ne cherches pas un goto calculé :-)
| >
|
| J'en cherche une implémentation standardisable en C ANSI.
Je ne sais pas si ce que je vais te dire va beaucoup t'aider :
Le comité C considère qu'il est lui-même en mode maintenance en ce
qui concerne le core language. Je doute très fortement qu'il ait
envie d'ajouter des goto calculés au langage -- cela a beaucoup
d'implication que tu ne le penses.
| Comment nommerais-tu un algorithme mutant réalisé par enfilage au
runtime de
| sections de code prédéfinies, elles-mêmes fournies comme les sections
d'un
| monobloc de C compilé (même si les codes effectifs se retrouvent
finalement
| dans des fonctions interchangeables invoquées par les sections du
monobloc)
| ?
cela me fait penser au mécanisme de fonctions virtuelles en C++. Mais
je présume que j'ai besoin d'avoir une description plus précise avant
de me prononcer.
Bonjour.
Je voudrais faire un tour des différentes plates-formes sous C pour
savoir
s'il y existe des équivalents d'une extension Microsoft, les fonctions
"naked".
Une fonction dotée de cet attribut est appelée extérieurement selon la
convention dite cdecl (le code appelant empile les arguments puis la
partie externe de la stackframe, et fait le ménage au retour), mais par
contre aucune stackframe n'est créée du côté interne.
A propos de naked, la doc de microsoft dit :
« For functions declared with the naked attribute, the compiler generates
code without prolog and epilog code. You can use this feature to write
your
own prolog/epilog code using inline assembler code. Naked functions are
particularly useful in writing virtual device drivers. »
A propos de prolog et d'epilog, elle dit
prolog :
push ebp ; Save ebp
mov ebp, esp ; Set stack frame pointer
sub esp, localbytes ; Allocate space for locals
push <registers> ; Save registers
epilog :
pop <registers> ; Restore registers
mov esp, ebp ; Restore stack pointer
pop ebp ; Restore ebp
ret ; Return from function
l'effet de naked est donc plus ou moins équivalent à l'effet de l'option
-fomit-frame-pointer de gcc (sauf que cela affecte toutes les fonctions du
programmes).
Bonjour.
Je voudrais faire un tour des différentes plates-formes sous C pour
savoir
s'il y existe des équivalents d'une extension Microsoft, les fonctions
"naked".
Une fonction dotée de cet attribut est appelée extérieurement selon la
convention dite cdecl (le code appelant empile les arguments puis la
partie externe de la stackframe, et fait le ménage au retour), mais par
contre aucune stackframe n'est créée du côté interne.
A propos de naked, la doc de microsoft dit :
« For functions declared with the naked attribute, the compiler generates
code without prolog and epilog code. You can use this feature to write
your
own prolog/epilog code using inline assembler code. Naked functions are
particularly useful in writing virtual device drivers. »
A propos de prolog et d'epilog, elle dit
prolog :
push ebp ; Save ebp
mov ebp, esp ; Set stack frame pointer
sub esp, localbytes ; Allocate space for locals
push <registers> ; Save registers
epilog :
pop <registers> ; Restore registers
mov esp, ebp ; Restore stack pointer
pop ebp ; Restore ebp
ret ; Return from function
l'effet de naked est donc plus ou moins équivalent à l'effet de l'option
-fomit-frame-pointer de gcc (sauf que cela affecte toutes les fonctions du
programmes).
Bonjour.
Je voudrais faire un tour des différentes plates-formes sous C pour
savoir
s'il y existe des équivalents d'une extension Microsoft, les fonctions
"naked".
Une fonction dotée de cet attribut est appelée extérieurement selon la
convention dite cdecl (le code appelant empile les arguments puis la
partie externe de la stackframe, et fait le ménage au retour), mais par
contre aucune stackframe n'est créée du côté interne.
A propos de naked, la doc de microsoft dit :
« For functions declared with the naked attribute, the compiler generates
code without prolog and epilog code. You can use this feature to write
your
own prolog/epilog code using inline assembler code. Naked functions are
particularly useful in writing virtual device drivers. »
A propos de prolog et d'epilog, elle dit
prolog :
push ebp ; Save ebp
mov ebp, esp ; Set stack frame pointer
sub esp, localbytes ; Allocate space for locals
push <registers> ; Save registers
epilog :
pop <registers> ; Restore registers
mov esp, ebp ; Restore stack pointer
pop ebp ; Restore ebp
ret ; Return from function
l'effet de naked est donc plus ou moins équivalent à l'effet de l'option
-fomit-frame-pointer de gcc (sauf que cela affecte toutes les fonctions du
programmes).
Pas moyen de faire ça localement avec un pragma ?
Pas moyen de faire ça localement avec un pragma ?
Pas moyen de faire ça localement avec un pragma ?
Voilà une petite maquette pour préciser les idées :
- le code effectif des p-instructions peut éventuellement être déporté
dans des fonctions (avec une petite perte de performance),
- goto [Next] symbolise ce que je veux implémenter. Le choix de la cible
n'est déterminé qu'au runtime.
static char WorkSpace[ENOUGH_BYTES];
static char * pxCurrentPosition;
void main( ...)
{
/* Some initialization code */
goto [Next];
Instruction1:
/* Code for p-instruction 1 */
/* operates on WorkSpace[] at pxCurrentPosition
then prepares them for the next p-instruction
then computes the result for [Next] below : */
goto [Next];
Instruction2:
/* Code for p-instruction 2 */
/* similar */
goto [Next];
...
InstructionN:
/* Code for p-instruction N */
/* similar */
goto [Next];
Termination:
/* Some exit code */
}
Une implémentation possible est d'utiliser un tableau de N pointeurs de
fonctions à signature identique void(void).
J'éssaie seulement de limiter le surcoût en performances des appels. C'est
pourquoi je m'intéressais au *concept* des fonctions *naked* qui
justement semblent avoir été introduites dans ce but pour l'écriture de
drivers.
Voilà une petite maquette pour préciser les idées :
- le code effectif des p-instructions peut éventuellement être déporté
dans des fonctions (avec une petite perte de performance),
- goto [Next] symbolise ce que je veux implémenter. Le choix de la cible
n'est déterminé qu'au runtime.
static char WorkSpace[ENOUGH_BYTES];
static char * pxCurrentPosition;
void main( ...)
{
/* Some initialization code */
goto [Next];
Instruction1:
/* Code for p-instruction 1 */
/* operates on WorkSpace[] at pxCurrentPosition
then prepares them for the next p-instruction
then computes the result for [Next] below : */
goto [Next];
Instruction2:
/* Code for p-instruction 2 */
/* similar */
goto [Next];
...
InstructionN:
/* Code for p-instruction N */
/* similar */
goto [Next];
Termination:
/* Some exit code */
}
Une implémentation possible est d'utiliser un tableau de N pointeurs de
fonctions à signature identique void(void).
J'éssaie seulement de limiter le surcoût en performances des appels. C'est
pourquoi je m'intéressais au *concept* des fonctions *naked* qui
justement semblent avoir été introduites dans ce but pour l'écriture de
drivers.
Voilà une petite maquette pour préciser les idées :
- le code effectif des p-instructions peut éventuellement être déporté
dans des fonctions (avec une petite perte de performance),
- goto [Next] symbolise ce que je veux implémenter. Le choix de la cible
n'est déterminé qu'au runtime.
static char WorkSpace[ENOUGH_BYTES];
static char * pxCurrentPosition;
void main( ...)
{
/* Some initialization code */
goto [Next];
Instruction1:
/* Code for p-instruction 1 */
/* operates on WorkSpace[] at pxCurrentPosition
then prepares them for the next p-instruction
then computes the result for [Next] below : */
goto [Next];
Instruction2:
/* Code for p-instruction 2 */
/* similar */
goto [Next];
...
InstructionN:
/* Code for p-instruction N */
/* similar */
goto [Next];
Termination:
/* Some exit code */
}
Une implémentation possible est d'utiliser un tableau de N pointeurs de
fonctions à signature identique void(void).
J'éssaie seulement de limiter le surcoût en performances des appels. C'est
pourquoi je m'intéressais au *concept* des fonctions *naked* qui
justement semblent avoir été introduites dans ce but pour l'écriture de
drivers.