News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Recommended section alignment

Started by WYVERN666, February 07, 2012, 12:00:24 AM

Previous topic - Next topic

WYVERN666

I have some doubts. If i am correct, the ".cpu 386" directive defines DWORD aligned sections by default, and ".cpu 486" PARAGRAPH aligned sections. However this can be overriden with the SEGMENT declarations, altough is not common practice, most people is using ".DATA" and ".CODE". I read somewhere that in 80x86 cpu's the PARAGRAPH must be used, but i dont normally see poeple worried about this topic. The question is what is the preffered section alignment for 32-bit?, and what for 64-bit?,, and is this really important?.

hutch--

If its LINKER alignment you are talking about, stick to the default 512 bytes and the EXE will run on any 32 bit Windows version. You can set much smaller but it may not run on all versions.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

WYVERN666

mmm but if im correct the default alignment for LINK.EXE is 4K (4096).

clive

Quote from: WYVERN666 on February 07, 2012, 02:03:36 AM
mmm but if im correct the default alignment for LINK.EXE is 4K (4096).

Which version? Microsoft has changed this setting a number of times, in fact I could probably find a version that would create unusable files on some systems.

4K probably makes the most sense based on the page size, 512 bytes makes sense for a sector granularity, but realistically unless it's incessantly swapping it won't matter much. If you enable relocations, and an unpredictable base address, it will live in the PAGEFILE rather than be backed by the original file.
It could be a random act of randomness. Those happen a lot as well.

WYVERN666

Ok, anyway i can enforce that value with /ALIGN switch in the linker. But i still dont get it, the linker wll override the alignment specified in the "SEGMENT" directives in the source code?, for example:

Quote
.CODE

Starts a code segment (with segment name <name>, if given) and ends the previous segment, if any. Aligns the segment on a 2-byte boundary (.8086, .186, .286) or a 4-byte boundary (.386, .486). The .MODEL directive must precede this directive.

That would be the same that declaring _TEXT SEGMENT DWORD PUBLIC FLAT 'CODE' witouth using the .MODEL directive, but the linker will override that alignment?

By the way, what would be the difference of declaring
Quote
ASSUME cs:FLAT, ds:FLAT, ss:FLAT, es:FLAT, fs:ERROR, gs:ERROR
and
Quote
ASSUME cs:_TEXT, ds:_DATA

And what would be the difference of declaring:
Quote
_TEXT SEGMENT DWORD PUBLIC FLAT 'CODE'
and
Quote
_TEXT SEGMENT DWORD PUBLIC USE32 'CODE'

In the two cases, the two options works.

dedndave

QuoteThe question is what is the preffered section alignment for 32-bit?, and what for 64-bit?,, and is this really important?

the answer to that is simple enough
for word data, even alignment is best
for dword data, 4 alignment is best
for qword data, 8 alignment is best
for xmm data, 16 alignment may be required

it is important because misalignment can cause code that accesses the data to run slower
in the case of xmm data, it is often a requirement

section alignment and data alignment are only related in a small way
for example, if you want to 4-align data in a section, the section must be at least 4-aligned

that's why we use .DATA, .DATA?, .CONST with seemingly little care about section alignment
as long as the sections are at least paragraph-aligned, we can achieve the required data alignment

as for code alignment, i have found that it makes little difference for short branches, at least on a P4
near branches may prefer to have a 16-aligned target address
you have to time your code to see if it makes a difference   :P

MichaelW

According to this:

http://msdn.microsoft.com/en-us/library/8xx65e1y(v=VS.80).aspx

The default is 4096, but in my test under Windows 2000, judging from the results and the map file this does not apply to the uninitialized data section, which appears to follow the initialized data in the same section.

;==============================================================================
    include \masm32\include\masm32rt.inc
;==============================================================================

;----------------------------------------
; Returns the maximum alignment of _ptr.
;----------------------------------------

alignment MACRO _ptr
    push ecx
    xor eax, eax
    mov ecx, _ptr
    bsf ecx, ecx
    jz @F
    mov eax, 1
    shl eax, cl
  @@:
    pop ecx
    EXITM <eax>
ENDM

;==============================================================================
    .data
        data0 dd 0
    .data?
        data1 dd ?
    .code
;==============================================================================
start:
;==============================================================================
    printf("%d\n",alignment(OFFSET start))
    printf("%d\n",alignment(OFFSET data0))
    printf("%d\n",alignment(OFFSET data1))

    inkey "Press any key to exit..."
    exit
;==============================================================================
end start


4096
4096
64


alignment

Timestamp is 4f316de9 (Tue Feb 07 12:31:05 2012)

Preferred load address is 00400000

Start         Length     Name                   Class
0001:00000000 000001a2H .text                   CODE
0002:00000000 00000028H .idata$5                DATA
0002:00000028 00000028H .idata$2                DATA
0002:00000050 00000014H .idata$3                DATA
0002:00000064 00000028H .idata$4                DATA
0002:0000008c 00000084H .idata$6                DATA
0002:00000110 00000000H .edata                  DATA
0003:00000000 00000040H .data                   DATA
0003:00000040 00000004H .bss                    DATA

  Address         Publics by Value              Rva+Base     Lib:Object

0001:00000000       _start                     00401000     alignment.obj
0001:0000008c       _StdOut@4                  0040108c f   masm32:stdout.obj
0001:000000d0       _wait_key@0                004010d0 f   masm32:wait_key.obj
0001:00000100       _StrLen@4                  00401100 f   masm32:strlen.obj
0001:00000172       _ExitProcess@4             00401172 f   kernel32:kernel32.dll
0001:00000178       _GetStdHandle@4            00401178 f   kernel32:kernel32.dll
0001:0000017e       _WriteFile@20              0040117e f   kernel32:kernel32.dll
0001:00000184       _FlushConsoleInputBuffer@4 00401184 f   kernel32:kernel32.dll
0001:0000018a       _Sleep@4                   0040118a f   kernel32:kernel32.dll
0001:00000190       _printf                    00401190 f   msvcrt:msvcrt.dll
0001:00000196       __getch                    00401196 f   msvcrt:msvcrt.dll
0001:0000019c       __kbhit                    0040119c f   msvcrt:msvcrt.dll
0002:00000000       __imp__GetStdHandle@4      00402000     kernel32:kernel32.dll
0002:00000004       __imp__WriteFile@20        00402004     kernel32:kernel32.dll
0002:00000008       __imp__FlushConsoleInputBuffer@4 00402008     kernel32:kernel32.dll
0002:0000000c       __imp__Sleep@4             0040200c     kernel32:kernel32.dll
0002:00000010       __imp__ExitProcess@4       00402010     kernel32:kernel32.dll
0002:00000014       \177kernel32_NULL_THUNK_DATA 00402014     kernel32:kernel32.dll
0002:00000018       __imp___getch              00402018     msvcrt:msvcrt.dll
0002:0000001c       __imp___kbhit              0040201c     msvcrt:msvcrt.dll
0002:00000020       __imp__printf              00402020     msvcrt:msvcrt.dll
0002:00000024       \177msvcrt_NULL_THUNK_DATA 00402024     msvcrt:msvcrt.dll
0002:00000028       __IMPORT_DESCRIPTOR_kernel32 00402028     kernel32:kernel32.dll
0002:0000003c       __IMPORT_DESCRIPTOR_msvcrt 0040203c     msvcrt:msvcrt.dll
0002:00000050       __NULL_IMPORT_DESCRIPTOR   00402050     kernel32:kernel32.dll

entry point at        0001:00000000

Static symbols

eschew obfuscation

dedndave

QuoteThe /ALIGN option specifies the alignment of each section within the linear address space of the
program. The number argument is in bytes and must be a power of two. The default is 4K (4096).

that could be taken 2 ways, i guess
perhaps they mean, "...default (if the /ALIGN option is used with no argument)..."   :P