flat assembler
Message board for the users of flat assembler.

Index > Main > Is That what Alignment is?

Author
Thread Post new topic Reply to topic
Nameless



Joined: 30 Apr 2010
Posts: 95
Nameless
i was readying about Alignment (http://www.asmcommunity.net/book/Alignment)
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: 3931 Time(s)

align.PNG


Post 02 Oct 2010, 08:27
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17476
Location: In your JS exploiting you and your system
revolution
Nameless wrote:
it starts the next declared data from the next address of memory thats divisible by 4
Yes
Post 02 Oct 2010, 09:20
View user's profile Send private message Visit poster's website Reply with quote
Nameless



Joined: 30 Apr 2010
Posts: 95
Nameless
thanks Very Happy
my learning is being accelerated, as i go further things gets kinda easier Very Happy
Post 02 Oct 2010, 12:28
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
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".
Post 02 Oct 2010, 13:13
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
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
    
Post 02 Oct 2010, 14:06
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2942
Location: vpcmipstrm
bitRAKE
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... Wink
Post 03 Oct 2010, 01:32
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17476
Location: In your JS exploiting you and your system
revolution
bitRAKE wrote:
FASM's default behavior is to put NOPs in the code sections, and ? (0) in the data sections.
Nope, NOPs everywhere.
Post 03 Oct 2010, 01:53
View user's profile Send private message Visit poster's website Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ...
Post 03 Oct 2010, 02:24
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2942
Location: vpcmipstrm
bitRAKE
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? Embarassed
(Maybe, there was a discussion regarding this?)
Code:
macro ALIGN0 n {
  ; assuming (n) is a power of two
  rb (n-$) and (n-1)
}    

_________________
¯\(°_o)/¯ unlicense.org
Post 03 Oct 2010, 02:42
View user's profile Send private message Visit poster's website Reply with quote
mindcooler



Joined: 01 Dec 2009
Posts: 423
Location: Västerås, Sweden
mindcooler
All I ever saw was 90 90 90 90 everywhere.

But I do not use sections.
Post 03 Oct 2010, 03:04
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17476
Location: In your JS exploiting you and your system
revolution
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.
Post 03 Oct 2010, 03:24
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2942
Location: vpcmipstrm
bitRAKE
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.
Post 03 Oct 2010, 04:10
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 03 Oct 2010, 10:05
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.