I'm trying to make a small proc that will fill a memory space with RGBA values later used for textures, but now matter how I access the memory or rewrite the dereference field, the program exits/crashes spontaneously when reaching the code.
invoke HeapCreate, HEAP_GENERATE_EXCEPTIONS, 0, 0 ;;make heap
mov heapHandle, eax ;;save handle, check success
.IF (!eax)
ret
.ENDIF
invoke HeapAlloc, heapHandle, HEAP_GENERATE_EXCEPTIONS or HEAP_ZERO_MEMORY, 12288 ;;allocate memory, zero just in case.
mov heapPointer, eax ;;save pointer, check success
.IF (!eax)
xor eax, eax
ret
.ENDIF
invoke RawI_RGBAFill, heapPointer, 12288, 4294967295 ;; 64x48x4 size, 0xFFFFFFFF color
RawI_RGBAFill proc buffer:DWORD, buf_size:DWORD, color:DWORD
shr buf_size, 2
mov eax, buf_size ;;measure DWORD loop count
xor ecx, ecx ;;clear counter
.while eax > ecx
push color ;;push & pop color from memory
pop DWORD PTR [buffer + ecx*4]
inc ecx ;;inc counter
.endw
mov eax, 1
ret
RawI_RGBAFill endp
I've tried using indirect addressing in various, some elaborated, ways and still no go. A weird oddity is that if I replaced 'buffer' with a register (placing 'mov edx, buffer' before .while) the code does absolutely nothing.
I'm stumped, any ideas?
Tatally suboptimal.
1. Load all values in registers (buff addr, size, ARGB...)
2. Use the simpliest way - rep stosd... Or write your analog.
Quote from: Pentacle
A weird oddity is that if I replaced 'buffer' with a register (placing 'mov edx, buffer' before .while) the code does absolutely nothing.
thats not true, if you place "mov edx,buffer" before .while the code is error free
Quote from: asmfan on May 31, 2006, 10:12:57 PM
Tatally suboptimal.
1. Load all values in registers (buff addr, size, ARGB...)
2. Use the simpliest way - rep stosd... Or write your analog.
I used the registers, the stack, memory calls, it just doesn't seem to work no matter my methods. Perhaps there is some sort of access violation but doesn't want to give me an error.
Quote from: drizz
thats not true, if you place "mov edx,buffer" before .while the code is error free
Yes, the code looks error free, and makes sense. After compiling and running it, the memory wasn't written to and I can't figure out why.
Your problem is this definately this line:
pop DWORD PTR [buffer + ecx*4]
"buffer" is a parameter on the stack, so cannot be used in this way. Try this (should be faster too):
RawI_RGBAFill proc buffer:DWORD, buf_size:DWORD, color:DWORD
mov ecx, buf_size
shr ecx, 2
mov eax, color
mov edx, buffer
@@:
mov [edx], eax
add edx, 4
sub ecx, 1
jnz @B
mov eax, 1
ret
RawI_RGBAFill endp
sorry, I just formatted my computer today, so I don't have MASM installed just at the moment to check if that works.
Ossa
pop DWORD PTR [buffer + ecx*4]
Definitely a problem, this will attempt to store a value into an "array" in the parameter list. Of course, you don't have an array in the parameter list.
All of the variable parts of an address (a pointer is a variable value) must be in registers for addressing.
mov eax,buffer ; load pointer parameter into register
pop DWORD PTR [eax + ecx*4] ; now, we can store the value
Quote from: Pentacle
Yes, the code looks error free, and makes sense. After compiling and running it, the memory wasn't written to and I can't figure out why.
if you did this:
mov edx,buffer
.while eax > ecx
push color ;;push & pop color from memory
pop DWORD PTR [edx + ecx*4]
inc ecx ;;inc counter
.endwthe code has no errors and your bug is somewhere else (memory is color filled guaranteed)
Why push and pop? why use inc? much better to use just the standard regs with movs.
Ossa
Quote from: OssaWhy push and pop? why use inc? much better to use just the standard regs with movs.
both me and tenkey had no intention to optimize his code, that's irrelevant... :wink