does it really matter if we use ALIGN in those overbloated memory times of computers (In ASM of course)?
it seems that few unused bytes s in our memory doesn't really bother us , does it ?
it seems that few unused bytes s in our memory doesn't really bother us , does it ?
Yes, it matters. The computer can only address memory in DWORD blocks and these are aligned at addresses divisible by 4. So consider the following scenario :
ABCD EFGH
Each letter represents a byte, If you want DWORD ABCD, no problem you are on a boundary and it only takes a single fetch. But If you want DWORD CDEF, the processor will fetch ABCD shift CD to the high order word then fecth EFGH and move EF into the low order word. This requires much more time, so in terms of wasted memory, your right, who cares but the value of align is increased speed of execution as it aligns everything to specified boundaries.
ABCD EFGH
Each letter represents a byte, If you want DWORD ABCD, no problem you are on a boundary and it only takes a single fetch. But If you want DWORD CDEF, the processor will fetch ABCD shift CD to the high order word then fecth EFGH and move EF into the low order word. This requires much more time, so in terms of wasted memory, your right, who cares but the value of align is increased speed of execution as it aligns everything to specified boundaries.
Performance speaking - yes, it matters. It can mean the processor has to load two two lines every time it should only need one.
Most SSE instructions only work when using 16-byte aligned data.
Some NT/XP/2000 data stuctures for API's only accept aligned data, and wont work without. (Also not telling you why either ;) )
:NaN:
:NaN:
ah, thnx =)
so i guess i should create my vars from big size -> small size .
so i guess i should create my vars from big size -> small size .
This chapter of Art of Assembly Language by Randall Hyde discusses an aligment:
http://webster.cs.ucr.edu/Page_AoAWin/HTML/SystemOrganizationa2.html#999072
http://webster.cs.ucr.edu/Page_AoAWin/HTML/SystemOrganizationa2.html#999072