Компиляция MBR загрузчика в Visual Studio

ntldr вы просто спорите о разных вещах.
Если я правильно догадался, тебе загрузчик этот нужен для твоего проекта по шифрованию разделов.
И в нём тебе надо реализовывать криптоалгоритмы, так?
Тогда действительно твой подход с переходом в PM и использованием 32-битного кода лучше.
Но для простого MBR задача супер максимум это показать меню чтобы пользователь выбрал с какого раздела грузиться, загрузить с него BootSector и передать ему управление.
В этом случае 16-битный код будет оптимальнее, и спокойно влезет в 512 байт.

Кстати Watcom C очень неплохо оптимизирует и его линкер умеет собирать чистые бинарники. (www.openwatcom.org)

 

Вы прикалываетесь? Пробовал я этот Watcom C, ничего хуже я никогда раньше не видел. Он выдает не просто плохой, а ОЧЕНЬ плохой код в котором оптимизацией даже и не пахнет. Borland c 3.1 по сравнению с ним просто шедевр оптимизации

 

+1. Хотя может в новых версиях что-то изменилось.

 

n0name
OpenWatcom выплевывает тоже ужас

 

Нет, не прикалываюсь.
Я начал пользоваться с версии по-моему 1.5 - вроди нормальный код генерирует...
А на какой например сишный код бинарник не оптимальный генерируется?
И всё равно во многих аспектах у него вообще нет конкурентов.
Я например не знаю больше ни одного компилятора способного компилировать 32-битный код для х86 с сегментированной моделью памяти.
Всё вышенаписанное относится к Open Watcom C++ 32-bit Optimizing Compiler, 16-битным я особо не пользовался.

 

Вот например:

Код (Text):

1. int mul20(int x)
2.  {
3.   return x*20;
4.  }
5. int main(void)
6.  {
7.   int x=3;
8.   return mul20(x);
9.  }

WC++ 1.6
wcc386 -6r -fp6 -fpi87 -otrnl+ -s test.c

Код (Text):

1. _TEXT       SEGMENT PARA PUBLIC USE32 'CODE'
2.         ASSUME CS:_TEXT, DS:DGROUP, SS:DGROUP
3. mul20_:
4.     push        edx
5.     mov         edx,eax
6.     shl         eax,2
7.     add         eax,edx
8.     shl         eax,2
9.     pop         edx
10.     ret        
11.     lea         eax,[eax]
12. main_:
13.     mov         eax,3
14.     jmp         mul20_
15. _TEXT       ENDS

VC++ 6.0 SP6
cl /G6 /Ot /Oy /Gs /Gr /c test.c

Код (Text):

1. @mul20@4:
2.     push        ebp
3.     mov         ebp,esp
4.     push        ecx
5.     mov         dword ptr [ebp-0x4],ecx
6.     mov         eax,dword ptr [ebp-0x4]
7.     imul        eax,0x00000014
8.     mov         esp,ebp
9.     pop         ebp
10.     ret        
11. _main:
12.     push        ebp
13.     mov         ebp,esp
14.     push        ecx
15.     mov         dword ptr [ebp-0x4],0x00000003
16.     mov         ecx,dword ptr [ebp-0x4]
17.     call        near ptr @mul20@4
18.     mov         esp,ebp
19.     pop         ebp
20.     ret

Жаль нету под рукой VS2005 чтоб попробовать.
Но если сравнивать VC++6 и Watcom, то Watcom меня гораздо больше радует.

 

Поправка, на работе оказался VC++ 6.0 SP6 Sandart - потому такая оптимизация фиговая.
Вот код сгенерированный Professional версией:

VC++ 6.0 SP6 Pro
cl /Ox /G6 /Gr /Gs /c test.c

Код (Text):

1. @mul20@4:
2.     lea         eax,[ecx+ecx*4]
3.     shl         eax,0x02
4.     ret        
5.     nop        
6.     nop        
7.     nop        
8.     nop        
9.     nop        
10.     nop        
11.     nop        
12.     nop        
13.     nop        
14. _main:
15.     mov         ecx,0x00000003
16.     jmp         near ptr @mul20@4
17.     nop        
18.     nop        
19.     nop        
20.     nop        
21.     nop        
22.     nop

VS 2005 Professional
cl /Ox /O2 /Ot /Gr /c test.c

Код (Text):

1. @mul20@4:
2.     lea         eax,[ecx+ecx*4]
3.     add         eax,eax
4.     add         eax,eax
5.     ret        
6. _main:
7.     mov         eax,0x0000003c
8.     ret

Везде использовал fastcall чтобы было по честному, Watcom по умолчанию параметры в регистрах передаёт.
Ну и по коду - в плане быстродействия особой разницы нет.
По крайней мере не на столько чтобы говорить что код ОЧЕНЬ плохой.
Хотя если честно то мне больше всего нравится код сгенерированный VC++ 6.0 Pro, т.е. на ASM я бы написал lea eax,[eax*4+eax]/shl eax,2
Вот почему VS2005 вместо shl eax,2 предпочла add eax,eax/add eax,eax - мне не очень понятно...

А вот к примеру умножение на 21:
Watcom:

Код (Text):

1.     push        edx
2.     mov         edx,eax
3.     shl         eax,2
4.     add         eax,edx
5.     shl         eax,2
6.     add         eax,edx
7.     pop         edx
8.     ret

VS2005

Код (Text):

1.     mov         eax,ecx
2.     imul        eax,0x00000015
3.     ret

Тут по-моему всё-таки быстрее будет работать вариант с разложением, чем умножение через imul.
В общем не всё так однозначно...

 

icc 10

Код (Text):

1. int __fastcall mul20(int x)
2. {
3.   return x * 20;
4. }

Код (Text):

1.         lea       eax, DWORD PTR [ecx+ecx*4]                    ;6.14
2.         shl       eax, 2                                        ;6.14
3.         ret                                                     ;6.14

Код (Text):

1. int __fastcall mul20(int x)
2. {
3.   return x * 21;
4. }

Код (Text):

1.         imul      eax, ecx, 21                                  ;6.14
2.         ret                                                     ;6.14

ага?

надо vtune поставить и посмотреть.

 

Delphi 7:

Код (Text):

1.   Result:=x*20;
2.  
3.   shl EAX, 2
4.   lea EAX, [EAX + EAX * 4]

Код (Text):

1.   Result:=x*21
2.  
3.   imul EAX, EAX, 0x15

 

VC 2008 (/O2):

Код (Text):

1. _mul20  PROC
2.     mov eax, DWORD PTR _x$[esp-4]
3.     lea eax, DWORD PTR [eax+eax*4]
4.     add eax, eax
5.     add eax, eax
6.     ret 0
7. _mul20  ENDP
8.  
9. _main2  PROC
10.     mov eax, 60                 ; 0000003cH
11.     ret 0
12. _main2  ENDP

Насчёт загрузчика на С - можно линковать без релоков (/fixed), указав базовый адрес (/base) равным загрузочному минус 4К.
Потом у полученного ехе отрезать заголовок.
Можно также объединить секции.

 

green как и у VS2005 - только у тебя не fastcall функция.

Да в этом смысла нет - всё равно код будет 32-битный, а CPU после загрузки в 16-битном RM.
Т.е. нужен как минимум 16-битный загрузчик который загрузит наш PE и перейдёт в 32bit PM.
Ну а он уже может и заголовок проанализировать, особенно если в PE нет релоков и он собран по нужному базовому адресу

 

Кстаи если у кого vtune стоит - можете сравнить?

Код (Text):

1.     push        edx
2.     mov         edx,eax
3.     shl         eax,2
4.     add         eax,edx
5.     shl         eax,2
6.     add         eax,edx
7.     pop         edx
8.     ret

Код (Text):

1.     mov         eax,ecx
2.     imul        eax,0x00000015
3.     ret

Код (Text):

1.         imul      eax, ecx, 21                                  ;6.14
2.         ret

А то у меня VTune не установлен, да и процессор AMD, так что VTune не поможет.
Может тему отдельную создать по сравнению компиляторов - а то жестокий оффтопик :/
Модераторы - если есть возможность и не лень - отрежте кусок темы с конца наверное где-то с 26 поста в отдельную тему.

 

Кстати вот ещё вариант

Код (Text):

1. LEA EAX,DWORD PTR DS:[ECX*8]
2. SUB EAX,ECX
3. LEA EAX,DWORD PTR DS:[EAX+EAX*2]
4. RETN

 

Да, давайте тему про компиляторы. У кого-нить есть жесткие тесты для компилятора? надо проверить. Я уверен Делфи рулит.

 

Не смеши.
Честно говоря мне смешны ваши примеры на которых вы сравниваете оптимизацию. Оптимизация это не только умение умножать x * 20. Поэтому для тестов нужно брать достаточно большой и сложный алгоритм из тех что применяются в реальных задачах.

 

И все эти алгоритмы так или иначе базируются на тех же арифметических операциях, в том числе умножении.
Я не говорю что умножение на 21 является показательным и полным примером для оценки оптимизатора.
Но кое-какие выводы сделать всё-таки можно.

 

Тема не та, что бы в ней перформанс компиляторов тестить. Но все же..
http://www.gamedev.ru/flame/forum/?id=12025&page=4
55 пост.