Des constantes pas forcément constantes !
Re: Des constantes pas forcément constantes !
Apparemment la bidouille n'est pas possible sur certaines machines... Soit l'OS protège la zone mémoire, soit les instructions asm ne sont pas de la même taille, soit autre chose... Sans le code assembleur, je ne saurais dire, et j'ai pas trop envie de lancer une machine virtuelle pour ça :/
-
- Messages : 604
- Inscription : lun. 26/avr./2010 16:14
- Localisation : S 48° 52' 31'' / O 123° 23' 33''
Re: Des constantes pas forcément constantes !
4 aussi chez moi...
PB 4.51 - Vista 32 bits
PB 4.51 - Vista 32 bits
Re: Des constantes pas forcément constantes !
4 c'est bon. Ce serait donc sur les procs x64 que ça ne fonctionne pas. Faudra attendre que j'en ai un 

-
- Messages : 604
- Inscription : lun. 26/avr./2010 16:14
- Localisation : S 48° 52' 31'' / O 123° 23' 33''
Re: Des constantes pas forcément constantes !
Je dis p't-être une connerie (vu que je peux pas tester)...
mais en déclarant a de type .l, sous x64, ca marcherait pas ??
mais en déclarant a de type .l, sous x64, ca marcherait pas ??
Re: Des constantes pas forcément constantes !
Pitêt. En théorie, les deux additions devraient prendre la même place, quel que soit la taille de i. Mais bon...
Re: Des constantes pas forcément constantes !
Code : Tout sélectionner
;
; PureBasic 4.51 (Windows - x64) generated code
;
; (c) 2010 Fantaisie Software
;
; The header must remain intact for Re-Assembly
;
; String
; Requester
; FileSystem
; Date
; Object
; SimpleList
; Memory
; :System
; KERNEL32
; :Import
;
format MS64 COFF
;
extrn ExitProcess
extrn GetModuleHandleA
extrn HeapCreate
extrn HeapDestroy
;
extrn PB_CopyMemory
extrn PB_FreeMemorys
extrn PB_InitMemory
extrn PB_InitRequester
extrn PB_MessageRequester
extrn PB_Str
extrn memset
extrn PB_StringBase
extrn SYS_InitString
;
extrn PB_StringBasePosition
public _PB_Instance
public PB_ExecutableType
public _PB_MemoryBase
public PB_Instance
public PB_MemoryBase
public PB_EndFunctions
macro pb_public symbol
{
public _#symbol
public symbol
_#symbol:
symbol:
}
macro pb_align value { rb (value-1) - ($-_PB_DataSection + value-1) mod value }
macro pb_bssalign value { rb (value-1) - ($-_PB_BSSSection + value-1) mod value }
define aligngosub1
define aligngosub2
define aligngosub3
define aligngosub4
public PureBasicStart
;
section '.code' code readable executable align 8
;
;
PureBasicStart:
;
SUB rsp,40
MOV r8,I_BSSEnd-I_BSSStart
XOR rdx,rdx
MOV rcx,I_BSSStart
CALL memset
XOR rcx,rcx
CALL GetModuleHandleA
MOV [PB_Instance],rax
XOR r8,r8
MOV rdx,4096
XOR rcx,rcx
CALL HeapCreate
MOV [PB_MemoryBase],rax
CALL SYS_InitString
CALL PB_InitMemory
CALL PB_InitRequester
;
; CompilerIf #PB_Compiler_Debugger = 1
;
; Goto CODE
JMP l_code
;
; !section '.code' code readable writeable executable align 8
section '.code' code readable writeable executable align 8
;
; CODE:
l_code:
aligngosub1
;
; a = 0
MOV qword [v_a],0
;
; CopyMemory(?DEBUT, ?DEST, ?FIN-?DEBUT)
MOV rbp,l_fin
MOV r15,rbp
MOV rbp,l_debut
SUB r15,rbp
MOV rax,r15
PUSH rax
MOV rbp,l_dest
MOV rax,rbp
PUSH rax
MOV rbp,l_debut
MOV rax,rbp
PUSH rax
POP rcx
POP rdx
POP r8
CALL PB_CopyMemory
;
; DEBUT:
l_debut:
aligngosub2
; a+2
ADD qword [v_a],2
; FIN:
l_fin:
aligngosub3
;
; DEST:
l_dest:
aligngosub4
; a+3
ADD qword [v_a],3
;
; MessageRequester("Code modifié", Str(a))
PUSH qword [PB_StringBasePosition]
SUB rsp,8
PUSH qword [PB_StringBasePosition]
SUB rsp,8
PUSH qword [PB_StringBasePosition]
PUSH qword [v_a]
POP rcx
POP rdx
SUB rsp,32
CALL PB_Str
ADD rsp,40
INC qword [PB_StringBasePosition]
MOV rax,_S1
PUSH rax
MOV rdx,[PB_StringBase]
ADD [rsp+8],rdx
POP rcx
POP rdx
SUB rsp,32
CALL PB_MessageRequester
ADD rsp,40
POP qword [PB_StringBasePosition]
;
; End
JMP _PB_EOP
_PB_EOP:
CALL PB_EndFunctions
MOV rcx,[PB_MemoryBase]
CALL HeapDestroy
MOV rcx,[PB_ExitCode]
CALL ExitProcess
PB_EndFunctions:
SUB rsp,40
CALL PB_FreeMemorys
ADD rsp,40
RET
;
;
section '.data' data readable writeable
;
_PB_DataSection:
pb_public PB_DEBUGGER_LineNumber
dd -1
pb_public PB_DEBUGGER_IncludedFiles
dd 0
pb_public PB_DEBUGGER_FileName
db 0
PB_ExecutableType: dd 0
public _SYS_StaticStringStart
_SYS_StaticStringStart:
_S1: db "Code modifié",0
pb_public PB_NullString
db 0
public _SYS_StaticStringEnd
_SYS_StaticStringEnd:
pb_align 8
pb_align 8
s_s:
dq 0
dq -1
pb_align 8
;
section '.bss' readable writeable
_PB_BSSSection:
pb_bssalign 8
;
I_BSSStart:
_PB_MemoryBase:
PB_MemoryBase: rq 1
_PB_Instance:
PB_Instance: rq 1
PB_ExitCode: rq 1
;
pb_bssalign 8
PB_DataPointer rq 1
v_a rq 1
pb_bssalign 8
pb_bssalign 8
pb_bssalign 8
pb_bssalign 8
I_BSSEnd:
section '.data' data readable writeable
SYS_EndDataSection:
Désolé j'ai mis du temps à répondre. Voila l'Asm...
Il y a deux méthodes pour écrire des programmes sans erreurs. Mais il n’y a que la troisième qui marche.
Version de PB : 6.00LTS - 64 bits
Version de PB : 6.00LTS - 64 bits
Re: Des constantes pas forcément constantes !
A priori le problème viendrait des OS 64 bits et du Data Executive Prevention (DEP) qui par défaut est activé pour les apps 64 bits sur windows x64
Je n'arrive pas à la désactiver.
Je n'arrive pas à la désactiver.

Il y a deux méthodes pour écrire des programmes sans erreurs. Mais il n’y a que la troisième qui marche.
Version de PB : 6.00LTS - 64 bits
Version de PB : 6.00LTS - 64 bits
Re: Des constantes pas forcément constantes !
@D.J. E/S t'assures!
Je n'avais pas vu ton astuce qui déchire... ça correspond à peu de choses près à ce qu'il faut pour "modifier" des constantes... Parfois perdre un temps fou à modifier un bout de code avant qu'il soit exécuté un nombre de fois très important, ça revient finalement à gagner du temps au moment où il y en a besoin.
C'est vraiment bon pour optimiser un code. Je pensais que Fred avait proscrit cette possibilité pour éviter les effets pervers. Peut-être qu'un jour, il aura l'occasion d'apporter des précisions sur la compatibilité dans les futures versions.
Je n'avais pas vu ton astuce qui déchire... ça correspond à peu de choses près à ce qu'il faut pour "modifier" des constantes... Parfois perdre un temps fou à modifier un bout de code avant qu'il soit exécuté un nombre de fois très important, ça revient finalement à gagner du temps au moment où il y en a besoin.
C'est vraiment bon pour optimiser un code. Je pensais que Fred avait proscrit cette possibilité pour éviter les effets pervers. Peut-être qu'un jour, il aura l'occasion d'apporter des précisions sur la compatibilité dans les futures versions.
Re: Des constantes pas forcément constantes !
Merci Ollivier. Je n'ai rien inventé, ça s'appelle du code modifié, un truc qu'on utilise énormément en assembleur à des fins d'optimisation, ou pour brouiller les cartes des petits malins qui cherchent à désassembler ton code. C'est aussi utilisé dans les virus, c'est pour ça que les AV surveillent ça de près.
Re: Des constantes pas forcément constantes !
Ah le code modifié,
Comme c'était bien l'ASM
Sans parler du code autogénéré !!
Comme c'était bien l'ASM


Sans parler du code autogénéré !!
Only PureBasic makes it possible
Re: Des constantes pas forcément constantes !
le bon terme c'est "code AUTO modifié"Cool Dji a écrit :Ah le code modifié,

Re: Des constantes pas forcément constantes !
Ouais, bof, c'est comme le vocabulaire de la scène, c'est nous qui l'avons créé alors... Le bon temps des parallax, des différentiels, des glenz et des copperbars!
J'ai un pote qui avait fait un excellent screen avec des dotballs en code généré. Il avait explosé le nombre affichable simultanément. Ça fait partie de ces petits records qui ne seront jamais dans les annales
J'ai un pote qui avait fait un excellent screen avec des dotballs en code généré. Il avait explosé le nombre affichable simultanément. Ça fait partie de ces petits records qui ne seront jamais dans les annales
