PureBasic

Bonjour,

Un truc qui déchirerait, ce serait des constantes numériques pas vraiment très constantes, mais constantes quand même.
Histoire d'avoir un superbe Setup interne à un fichier exécutable.

Point de vue programmeur, il y aurait une méta-instruction irréversible pour préciser que telle ou telle constante doit être préparée à être "bassement" modifiée.

Les inconvénients :
* la taille de l'exécutable qui doit contenir la cartographie des diverses constantes pas très constantes;
* la lenteur d'exécution de l'opération d'écriture de la valeur;
* un sac de 50Kg de Doliprane à payer à Fred;

Les avantages :
* la rapidité d'exécution de l'opération de lecture de la valeur;
* un pied de nez à quelques compilateurs concurents

Et... Viva el PorBAJICOS compilatores !

Ollivier a écrit :Bonjour,

Un truc qui déchirerait, ce serait des constantes numériques pas vraiment très constantes, mais constantes quand même.
Histoire d'avoir un superbe Setup interne à un fichier exécutable.

heu! j'ai rien compris là

Salut Dobro,

Ben, en fait une constante en PureBASIC qui est écrite par exemple comme ça :

Code : Tout sélectionner

#MaConstante = 5

se traduit par le nombre 5 directement écrit dans l'exécutable, et plus précisément dans l'instruction Assembleur.
L'exécution de l'instruction ASM est donc plus rapide.

Imaginons que le nombre 5 se transforme, comme par magie en un autre nombre, par exemple 1013.
Ce serait ça une "constante pas forcément constante" ou une "pseudo-constante" ou une "pseudo-variable"...

C'est un transfert de vitesse d'exécution en fait. Car, comparé à l'utilisation d'une variable qui jouit d'un équilibre assez conséquent en terme de durée de modification et en terme de durée de lecture...

Ex:
100 µs pour modifier la valeur de MaVariable.I
et 30µs pour lire la valeur de MaVariable.I

...dans le cas d'une pseudo-variable, il n'y aurait pas cet équilibre: on aurait des durées de traitement différentes favorisant la vitesse de lecture:

Ex:
5000µs pour modifier la valeur de #MaPseudoVariable
et 5µs pour lire la valeur de #MaPseudoVariable

Ce n'est irréaliste car il est fréquent de lire une valeur constante des milliards de fois durant l'exécution d'un programme et de la modifier moins d'une dizaine de fois.

D'ailleur on ma dit un jour (un mec) en pascale je croix
que il pouvais modifier ces constantes, ce qui m'as un peut laisser perplex

Mais éffectivement ce serais pas mal sa mais je voie plus l'interet d'une constante
et pourquoi ne pas utiliser une variable mise a part la vitesse de lecture et écriture evidement

Dayvid a écrit :(1) pourquoi ne pas utiliser une variable
(2) mise a part la vitesse de lecture et écriture
(3) evidement

Dayvid, je n'arrive à expliquer comment tu réussis ton compte pour créer des bugs internes dans mon bulbe.
1) Tu expliques quelque chose qui rend caduque ma suggestion;
2) Tu jartes la raison principale pour laquelle j'ai fait cette suggestion (un gain de temps assez important en lecture);
3) Tu impliques une assurance en quelque chose que je n'arrive toujours pas à dicerner;

Bref, reviens dès que tu peux sur le forum. Tes contradictions intrinsèques vont me mettre K.O. cash, ce qui enthousiasmera quelques membres du forum!

Je vais me fluidifier le sang à coup de Doliprane, parce que là je sens que ça grouille de petits bouchons...

Ca me donne l'occasion de poser une question qui me turlupine:
Sur CPC6128, je faisais des codes auto-modifiables en mettant un label pour connaitre l'adresse de l'instruction à modifier en assembleur et puis je prenais la valeur de l'instruction à remplacer et je l'écrivais à la place quand nécessaire. (ce qui pourrait revenir à modifier une constante aussi bien...)
C'est faisable sur pc ? (faut il modifier l'adresse du segment de donnée pour le superposer à celui des instructions ? est-ce faisable?)

Pas de souci.

Code : Tout sélectionner

CompilerIf #PB_Compiler_Debugger = 1
  Debug "Pas de debogueur, merci"
  End
CompilerEndIf

Goto CODE

!section '.code' code readable writeable executable align 8

CODE:

a = 0

CopyMemory(?DEBUT, ?DEST, ?FIN-?DEBUT)

DEBUT:
a+2
FIN:

DEST:
a+3

MessageRequester("Code modifié", Str(a))

End

djes,

ton code active mon antivirus sur l'exe de purebasic

@++

venom a écrit :djes,
ton code active mon antivirus sur l'exe de purebasic
@++

Normal, ils n'aiment pas ce genre de pratique

Essaye d'enlever le readable de la section pour voir...

Ollivier a écrit :
Code : Tout sélectionner
#MaConstante = 5
se traduit par le nombre 5 directement écrit dans l'exécutable, et plus précisément dans l'instruction Assembleur.
L'exécution de l'instruction ASM est donc plus rapide.

je ne suis pas un spécialiste de l'assembleur , mais il me semble que ce que tu dis là est faux
ce que tu décris correspond plutot au Macro au moment du linkage

je crois qu'une constante est écrite dans une zone Data
avec DC xxx quelque chose (ass 68000)....
ou equ sur x86

alors qu'une variable
Adresse1 DD 0F70ABCDh
sont des zones mémoires qui sont réservées lors de l'assemblage.

c'est la seule différence. non ? ..
au niveau temps d'exécution ça doit etre kif kif !

sauf s'il y a traitement comparaison, addition, etc ...
dans ce cas , ce n'est pas les variables qui sont plus longue a utiliser, mais
ces opérations...

additionner 2 constantes doit prendre autant de temps
que d'additionner 2 variables non ?

ce que tu veux reviens a faire du code Automodifié
le Soldat inconnu a fait une démonstration de ça , il y a longtemps (recherche Code auto modifié)

Djes> En fait c'est super simple ! Merci beaucoup, ça me "libère" un peu plus.

(... de la matrice

) Par contre je ne comprend pas pourquoi a n'est pas égal à 4 (a+2 et a+2 de la zone copié). une explication svp

Dobro>Je crois que equ définie une constante pour le compilateur assembleur (c'est une facilité comme une macro en somme) et non dans le langage lui même où comme l'a écrit Ollivier la valeur est directement écrite avec les op-codes des instructions. (mais bon je peux me tromper, je ne suis pas plus un pro de l'asm)

Fig a écrit :Djes> En fait c'est super simple ! Merci beaucoup, ça me "libère" un peu plus. (... de la matrice ) Par contre je ne comprend pas pourquoi a n'est pas égal à 4 (a+2 et a+2 de la zone copié). une explication svp

Chez toi ça ne fait pas 4?????????????????????????????????

Non, je viens de revérifier, ça me sort "2".

...et quelques secondes après avoir fermé la fenêtre: un problème de compilation.
Notamment:
Fichiers aidant à décrire le problème :
C:\Users\Figou\AppData\Local\Temp\WERD138.tmp.WERInternalMetadata.xml
C:\Users\Figou\AppData\Local\Temp\WERF0CA.tmp.appcompat.txt
C:\Users\Figou\AppData\Local\Temp\WERF2CD.tmp.mdmp

PureBasic 4.51 (Windows - x64) sur W7 x64

édite: le problème de compilation n'est pas systématique. parfois, ca marche bien, juste ça donne toujours 2.

Hum! Donc ça ne marche pas. Montre donc le code généré en assembleur (compilateur en ligne de commande, option /COMMENTED, ou l'excellent outil PureASM de notre ami Erix14)

djes a écrit :
Fig a écrit :Djes> En fait c'est super simple ! Merci beaucoup, ça me "libère" un peu plus. (... de la matrice ) Par contre je ne comprend pas pourquoi a n'est pas égal à 4 (a+2 et a+2 de la zone copié). une explication svp
Chez toi ça ne fait pas 4?????????????????????????????????

4 chez moi

PureBasic

Des constantes pas forcément constantes !

Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !

Re: Des constantes pas forcément constantes !