Index
> Main > Is That what Alignment is? |
| Author |
|
|
revolution 02 Oct 2010, 09:20
Nameless wrote: it starts the next declared data from the next address of memory thats divisible by 4 |
|||
02 Oct 2010, 09:20 |
|
|
Nameless 02 Oct 2010, 12:28
thanks
my learning is being accelerated, as i go further things gets kinda easier |
|||
|
02 Oct 2010, 12:28 |
|
|
Tomasz Grysztar 02 Oct 2010, 13:13
One detail: after "g" there should be a "0", because you have byte of such value defined at the end of your string. So it really should be "0" and two "x" instead of three "x".
|
|||
|
02 Oct 2010, 13:13 |
|
|
edfed 02 Oct 2010, 14:06
align fills the empty bytes with NOP (90h), not X, but really nops.
because align can be used inside code to align huge instructions, it can speed up the code to do so, because nops are frequentlly ignored in recent X86. a formula for align can be that: Code: Align: ;input: ;eax = boundary parameter = 2^N ;es:edi = current offset before align ;return: ;eax = count of bytes 'NOPed' ;es:edi = current offset after align push ecx edx edi ;save trashed registers xor ecx,ecx ;ecx=0 mov cx,es ;ecx=es shl ecx,4 ;ecx*16 add edi,ecx ;edi = linear adress xchg eax,edi ;eax=linear adress, edi=bound param xor edx,edx ;expand eax to unsigned qword for div div edi ;offset/bound param mov ecx,edx ;ecx=modulus = count of bytes to nop mov al,90h ;al=opcode for nop pop edi ;restore offset rep stosb ;nop bytes mov eax,edx ;eax=count of bytes noped pop edx ecx ;restore trashed registers ret ;quit |
|||
|
02 Oct 2010, 14:06 |
|
|
bitRAKE 03 Oct 2010, 01:32
We also see variations of ALIGN. Sometimes it is desired to have other data fill the gap. Data might compress better, or be more secure after encryption, etc...
Code: db $ and 1 dup 0 ; same as align 2 Code: dw (512-$+$$)/2 dup $AA55 ; pattern fill Code: times (4-$) and 3 db $FF There is much to be said about run-time alignment, but I'll leave that for another post...  |
|||
|
03 Oct 2010, 01:32 |
|
|
revolution 03 Oct 2010, 01:53
bitRAKE wrote: FASM's default behavior is to put NOPs in the code sections, and ? (0) in the data sections. |
|||
|
03 Oct 2010, 01:53 |
|
|
mindcooler 03 Oct 2010, 02:24
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ...
|
|||
|
03 Oct 2010, 02:24 |
|
|
bitRAKE 03 Oct 2010, 02:42
revolution wrote:
(Maybe, there was a discussion regarding this?) Code: macro ALIGN0 n { ; assuming (n) is a power of two rb (n-$) and (n-1) } _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
03 Oct 2010, 02:42 |
|
|
mindcooler 03 Oct 2010, 03:04
All I ever saw was 90 90 90 90 everywhere.
But I do not use sections. |
|||
|
03 Oct 2010, 03:04 |
|
|
revolution 03 Oct 2010, 03:24
bitRAKE wrote: Did that change, ... The alignment code does not know what section attributes the align is assembled within. Besides, not all file formats have separate data and code sections. Not all file formats have sections. Anyhow, it is easy to test what really happens. |
|||
|
03 Oct 2010, 03:24 |
|
|
bitRAKE 03 Oct 2010, 04:10
I just did,
Code: rb 3 align 16 rb 123 align 16 rb 256 |
|||
|
03 Oct 2010, 04:10 |
|
|
Tomasz Grysztar 03 Oct 2010, 10:05
fasm's ALIGN generates bytes that have value 90h and are marked as uninitialized at the same time.
Thus if they occur in the data that is not included in the output file (like large uninitialized block at the end of PE section, or any uninitialized data at the end of binary format file) they are not included in output either; however when they happen to be in the output, they always have value 90h each. |
|||
|
03 Oct 2010, 10:05 |
|
< Last Thread | Next Thread > |
Forum Rules:
|