win32 api tutorial

Спасибо. А то я чуть язык не поломал) Хотел смягчить грубость.
Так это, давно ж известно, вроде, что современный оптимизирующий компилятор делает такой код, какой может сделать далеко не средний ассемблерщик (и то не факт, что сможет). Ты хотя бы заглядывал в те листинги? Там так накручено, что мама не горюй.
Спорить на эту тему просто смешно.
Ну и второе.

Как же ты мог такое сказать? Да при мало-средней программе время написания на ассемблере увеличится в 10 раз. А при большой, я не знаю, в 100?
Ай-ай. Столько раз на всех форумах уже это всё обсосали.

 

Ну вот… опять прошу меня извинить за длинную паузу – рад бы общаться порегулярнее, но обстоятельства моей жизни мне этого, к сожалению, не позволяют…

Phuntik:

Что’ж, здесь я с тобой согласен.

То-то и оно, что заглядывал. Создал я на C (MS VS 2010) пустую процедуру (без входных аргументов и ничего не возвращающую). Запустил её в отладчике. Компилятор создал для неё следующий пролог

Код (Text):

1. 00411350  push        ebp  
2. 00411351  mov         ebp,esp  
3. 00411353  sub         esp,0C0h  
4. 00411359  push        ebx  
5. 0041135A  push        esi  
6. 0041135B  push        edi  
7. 0041135C  lea         edi,[ebp-0C0h]  
8. 00411362  mov         ecx,30h  
9. 00411367  mov         eax,0CCCCCCCCh  
10. 0041136C  rep stos    dword ptr es:[edi]

и вот-такой-вот эпилог

Код (Text):

1. 0041137E  pop         edi  
2. 0041137F  pop         esi  
3. 00411380  pop         ebx  
4. 00411381  mov         esp,ebp  
5. 00411383  pop         ebp  
6. 00411384  ret

. А теперь представь что будет, если я в эту процедуру вставлю код своего генератора случайных чисел (он у меня на основе команды RDTSC) и буду его активно использовать в 3D-игре для генерации местности, генерации типов игровых объектов, построения поведения AI и бог знает для чего ещё. В теле этой процедуры не найдётся столько команд, сколько шагов надо будет выполнить (включая 30-кратное повторение STOS) в одном только прологе.

Если разбивать Asm-код на множество мелких процедур, то, IMHO, разница в тексте и во времени будет явно менее чем 10-кратной.

Crollspase:

В общем, я считаю, что я прав, однако настолько сильно сгущать краски мне действительно не следовало – прошу новичков извинить меня за это: постараюсь больше таких ляпов не делать.

 

неумение пользоваться компилятором и линкером не является достойным аргументом...

 

Код (Text):

1. 00411367  mov         eax,0CCCCCCCCh  
2. 0041136C  rep stos    dword ptr es:[edi]

И при каких настройках такое скомпилица? А дебаг режим ...
И это все равно быстро отработает

ВСЕ РЕШАЕТ АЛГОРИТМ...

Асм для вирусятины + дизасм + дебаг.

 

Э. Таненбаум
В большинстве программ лишь
небольшой процент всего кода сказывается на времени выполнения программы.
Обычно 1 % кода отвечает за 50 % времени выполнения, а 10 % кода — за 90 %
времени выполнения.
Предположим, что для написания программы на языке высокого уровня требу-
ется 10 человеко-лет, а полученной программе нужно 100 секунд, чтобы выполнить
некоторую типичную контрольную программу. (Контрольной называют тесто-
вую программу, которая используется для сравнения компьютеров, компилято-
ров и т. п.) Написание всей программы на ассемблере может занять 50 челове-
ко-лет. Полученная в результате контрольная программа будет выполняться
примерно 33 секунды, поскольку хороший программист может оказаться в три
раза умнее компилятора (хотя об этом можно спорить бесконечно).


Так как только крошечная часть программы отвечает за большую часть вре-
мени выполнения этой программы, возможен другой подход. Сначала програм-
ма пишется на языке высокого уровня. Затем проводится ряд измерений, чтобы
определить, какие части программы по большей части сказываются на времени
выполнения. Для таких измерений обычно используется системный тактовый
генератор. С его помощью можно узнать, сколько времени выполняется каждая
процедура, сколько раз выполняется каждый цикл и т. п.
Предположим, что 10 % программы отвечает за 90 % времени ее выполнения.
Это значит, что из 100 секунд работы 90 секунд выполняется десятая часть про-
граммы, а 10 секунд — оставшиеся 90 %. Эти 10 % программы можно усовершен-
ствовать, переписав на ассемблере. Этот процесс называется подстройкой
(tuning). На подстройку основных процедур потребуется еще 5 человеко-лет, но
время выполнения программы сократится с 90 до 30 секунд.
Сравним этот смешанный подход, когда используются и ассемблер, и язык
высокого уровня, с подходом, в котором применяется только язык ассемблера
(см. табл. 7.1). При втором подходе программа работает примерно на 20 % быст-
рее C3 секунды против 40), но более чем за тройную цену E0 человеко-лет про-
тив 15). Более того, у смешанного подхода есть еще одно преимущество: гораздо
проще переписать на ассемблер уже отлаженную процедуру, написанную на язы-
ке высокого уровня, чем писать эту процедуру на ассемблере «с нуля». Отметим,
что, если бы написание программы занимало ровно 1 год, соотношение между
смешанным подходом и подходом, при котором используется только язык ас-
семблера, составляло бы 4:1 в пользу смешанного подхода.
В то же время программисту, пишущему на языке высокого уровня, не нужно
задумываться о перемещении отдельных битов, поэтому он может осмысливать
задачу в целом, и иногда ему так удается построить программу, что он добивает-
ся реального повышения производительности. Такая ситуация обычно не харак-
терна для программистов, пишущих на ассемблере, — как правило, они возятся
с отдельными командами, пытаясь сэкономить несколько циклов.

 

Э.Таненбаум

Как бы то ни было, существует по крайней мере 4 веские причины для изуче-
ния ассемблера. Во-первых, желательно уметь писать программы на ассемблере,
поскольку успех или неудача большого проекта иногда зависит от того, удастся
или нет в несколько раз повысить быстродействие единственной, но важной про-
цедуры.
Во-вторых, обращение к ассемблеру может быть единственно возможным вы-
ходом в случае нехватки памяти. Смарт-карты, например, содержат центральный
процессор, но лишь у некоторых из них есть хотя бы мегабайт памяти и уж со-
всем единицы имеют жесткий диск для разбиения на страницы. Однако при та-
ких ограниченных ресурсах они должны выполнять сложные вычисления. Про-
цессоры, встроенные в электроприборы, часто имеют минимальный объем
памяти, поскольку они должны быть достаточно дешевыми. Столь же незначи-
тельным объемом памяти обычно оснащаются различные электронные устройст-
ва, работающие на батарейках, поскольку им нужен компактный, но эффектив-
ный код.
В-третьих, компилятор должен либо на выходе производить программу, кото-
рая может использоваться ассемблером, либо самостоятельно выполнять ассемб-
лирование. Таким образом, знание языка ассемблера существенно для понима-
ния того, как работает компьютер. И вообще, кто-то ведь должен писать
компилятор (и его ассемблер).
Наконец, ассемблер дает прекрасное представление о реальной машине. Для
тех кто изучает архитектуру компьютеров, написание ассемблерного кода —
единственный способ узнать, что собой представляет машина.

Данную книгу могу выслать почитать
По книгам данного автора была написана Linux