flat assembler
Message board for the users of flat assembler.

 Index > Main > Is That what Alignment is?
Author
Nameless

Joined: 30 Apr 2010
Posts: 95
Nameless 02 Oct 2010, 08:27
thats how i understand ALIGN command
is it correct?
it starts the next declared data from the next address of memory thats divisible by 4
is that correct?

Image Attached

 Description: Filesize: 6.87 KB Viewed: 7510 Time(s)

02 Oct 2010, 08:27
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20306
revolution 02 Oct 2010, 09:20
Nameless wrote:
it starts the next declared data from the next address of memory thats divisible by 4
Yes
02 Oct 2010, 09:20
Nameless

Joined: 30 Apr 2010
Posts: 95
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

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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

Joined: 20 Feb 2006
Posts: 4330
Location: Now
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
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

Joined: 21 Jul 2003
Posts: 4024
Location: vpcmpistri
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    `
FASM's default behavior is to put NOPs in the code sections, and ? (0) in the data sections.
Code:
`dw (512-\$+\$\$)/2 dup \$AA55 ; pattern fill    `
Parallelism within the CPU makes alignment important. There is even an alignment exception which can be turned on for Ring-3 applications. Not to mention instructions which only work on aligned data!
Code:
`times (4-\$) and 3 db \$FF    `
At the source code level it is important to remember that alignment can only be guaranteed at a granularity of the present section. This is mostly important with object files. If the section is only aligned on a 16 byte boundary then it is impossible to get cacheline alignment at assemble-time (of course, it could be done programmatically at run-time).

There is much to be said about run-time alignment, but I'll leave that for another post...
03 Oct 2010, 01:32
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20306
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.
Nope, NOPs everywhere.
03 Oct 2010, 01:53
mindcooler

Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
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

Joined: 21 Jul 2003
Posts: 4024
Location: vpcmpistri
bitRAKE 03 Oct 2010, 02:42
revolution wrote:
bitRAKE wrote:
FASM's default behavior is to put NOPs in the code sections, and ? (0) in the data sections.
Nope, NOPs everywhere.
Did that change, or am I imagining things again?
(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

Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
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
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20306
revolution 03 Oct 2010, 03:24
bitRAKE wrote:
Did that change, ...
No change that I am aware of.

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

Joined: 21 Jul 2003
Posts: 4024
Location: vpcmpistri
bitRAKE 03 Oct 2010, 04:10
I just did,
Code:
```rb 3
align 16
rb 123
align 16
rb 256    ```
...and was surprised to find data produced anywhere I put it. Luckily, this is easy to resolve. I must have stumbled on this before.
03 Oct 2010, 04:10
Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland
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
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum