我寫在C和x86彙編兩個等價方案:大會對C的可執行文件的大小
.386
.model small
INCLUDELIB MSVCRT
EXTRN _printf:NEAR
.data
msg db "Hello World", 10, 0
.code
main PROC
push ebp
mov ebp, esp
lea eax, msg
push eax
call _printf
add esp, 4
mov esp, ebp
pop ebp
ret 0
main ENDP
END
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
我編組裝一個具有: ml hello.asm /link /ENTRY:main /SUBSYSTEM:CONSOLE
以及C一個用: cl /O1 /MD hello.c
/O1開關應該儘量減少空間,並且/ MD開關與MSVCRT.LIB鏈接,而不是LIBCMT(這與我的彙編程序中的相同)。
然而,當我調查實際的可執行文件下1實際上是裝配體中一個的兩倍的尺寸:
2014-02-08 10:48 AM 3,072 hello.exe
2014-02-08 10:53 AM 6,144 hello_c.exe
否則在兩個一DUMPBIN /DISASM
表明組件一個僅產生予指定而確切說明C的產生幾百倍...
有沒有人有解釋爲什麼要求最小化空間的優化編譯器仍然會產生比彙編程序更糟糕的結果?
拆開它們出於好奇 - 程序集「Hello world」實際上工作? –
你沒有說你正在使用什麼工具。 Visual Studio爲堆棧探針和安全功能添加了一堆代碼,並且可能還有一些樣板即使未被使用也無法刪除。靜態數據段可能還有一些浪費的空間。 – BitBank
我不會稱調試版本「臃腫」,但@rohitsan可能有答案 - C版本包含彙編器版本不包含的調試信息。 –