OSDev

SII, по поводу ассемблерной оптимизации, о которой ты говоришь здесь
http://wiki.osdev.ru/index.php/Разрабатыва...С_на_Ассемблере
я не согласен, что человек оптимизирует лучше.
Дело в том, что процессорная оптимизация это чисто формальный процесс, и соответственно качество оптимизации напрямую зависит от точности соблюдения этих формальных правил. Интеллект программиста тут не имеет ни какого значения, даже наоборот, возрастающая сложность процессорной оптимизации становится не под силу программисту выполнить все условия оптимизации кода. Плюс оптимизирующего компилятора в том, что он соблюдёт абсолютно все правила оптимизации, и сделает это безошибочно.
Лучшая оптимизация делается на уровне алгоритма, и ЯВУ в этом деле ни как не ограничивает.

Соглашаться со мной вовсе не обязательно ;) Что "лучшая", а точнее, важнейшая, наиболее сильно сказывающаяся оптимизация производится на уровне алгоритмов, я абсолютно согласен (сколько не оптимизируй пузырьковую сортировку, она не станет лучше квиксорта). Однако с остальным поспорю и начну как раз с почти что конца.



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



Опять-таки далеко не всегда это так. Если говорить о "раскладывании" машинных инструкций в потоке команд наиболее оптимальным для данного процессора образом -- да, это процесс чисто формальный, и хороший компилятор это сделает не хуже программиста -- но, как я уже заметил выше, далеко не каждый компилятор умеет выполнять соответствующую оптимизацию (ну а если говорить точнее, самым оптимальным является интеловский -- есно, для интеловских же процессоров).

Ещё одна вещь, с которой транслятор справится не хуже человека, -- это оптимизация деления на константу (замена операции деления на смесь умножений, вычитаний и сдвигов). Однако и её делают не все трансляторы (борландовские не умеют, мелкомягкие, интеловский и гнусные умеют, насчёт ваткома и других не в курсе).

Наконец, есть и более "хитрые" виды низкоуровневой оптимизации. Возьмём, например, такой оператор:

if a = b then c:= 0 else if a > b then c:= 1 else c:= -1;

Многие ли компиляторы догадаются не странслировать его "в лоб", с помощью команды cmp, двух условных переходов, трёх мовов и двух безусловных переходов? Лично я не знаю, опытов не проводил, знаю лишь, что Дельфи именно так "в лоб" и странслирует, но эффективность компилятора Дельфи общеизвестна (никакая, грубо говоря). Хотя с точки зрения скорости на процессорах, начиная с Пентиума Про (вроде бы), эффективнее будет вообще обойтись без переходов:

cmp ebx, ecx
cmove eax, ConstZero
cmova eax, ConstPlus1
cmovb eax, ConstMinus1

Подобных примеров можно придумать достаточно много, так что согласиться с тем, что "интеллект программиста тут не имеет ни какого значения", не могу никак.

Да, компиляторы ЯВУ бывают разные, согласен, есть не идеальные. Но есть неплохие компиляторы (знаю что Visual C 2005, Open Watcom 1.7, GCC 4), где:

Встречающиеся ошибки не влияют на общий процесс. Также как ошибки в Ассемблерах.

Следуют всем правилам оптимизации кода.

Различия в результирующем коде оптимимизации связаны с работой высокоуровневого оптимизатора, из-за того что компиляторы пытаются оптимизировать не только код, но и алгоритм, каждый по разному. Как например замена сложных операций на последовательность простых.

"if a = b then c:= 0 else if a > b then c:= 1 else c:= -1;"
Интересный пример, надо будет протестировать. Не вижу принципиальных проблем, чтобы компилятор использовал cmov.
В общем идея такая, что лучше компилятор научить делать рутинные вещи, чем постоянно этим заниматься руками.

Ребят, а может не будем спорить, что лучше - ручная или автоматическая оптимизация, а лучше в отдельной теме составим шаблоны ассемблерной оптимизации? Мне бы очень пригодилось для моего компилера.

Шаблоны по типу (преобразования последовательностей инструкций):
mov EAX, 1234;
mov [EBX], eax;
---
mov [EBX], 1234;

или

cmp ebx, ecx;
jne @skip;
cmove eax, ConstZero;
@skip:
---
cmp ebx, ecx;
cmove eax, ConstZero;

Вообще-то конечно в любом случае, компилируя программу на ЯВУ, нужно анализировать распечатки ассемблерных листов, чтобы увидеть возможные пути усовершенствования кода или алгоритма. Я когда делал ядро на С++, то постоянно ориентировался на результирующий ассемблерный код, и подгонял исходный код С++ для лучшего результата. Тоесть для меня С++ это Ассемблер высокого уровня, я имею ассемблерное представление каждой операции, поэтому суть программирования похожа на Ассемблер. Что касается конкретно С/С++, то он и задумывался как Ассемблер высокого уровня, так что всё естественно.

Ещё одна идея. Я думаю, в Си можно использовать такой алгоритм оптимизации для вычисления условия в условном переходе:
if( a==1 && b==2 && c==3 ) {...}
обычно это компилируется в виде ряда условных переходов. Потому что таковы правила, что условия проверяются строго по очереди, и если очередное условие отрицательное, то остальные просто не вычисляются.
Но в некоторых случаях для минимизации команд условных переходов, наверно можно использовать бинарное "исключающее или":
if( ((a~1) ~ (b~2) ~ (c~3)) == 0 ) {...}
тогда команда условного перехода останется одна, причём для проверки результата на 0 не используется инструкция сравнения, потому что флаг "Z" устанавливается автоматически.

исправляю, символ другой
if( ((a^1) ^ (b^2) ^ (c^3)) == 0 ) {...}

Вот так пожалуй правильней:
if( ((a^1) | (b^2) | (c^3)) == 0 ) {...}