Бывает оптимизация по скорости, а бывает оптимизация по размеру. Причём во многих случаях имеет смысл именно оптимизация по размеру - ну не всё ли равно, будет некоторый код исполняться 2 мс или 3 мс? Если быстрый вариант занимает 200 байт, а медленный 50?
Во многих программах главный цикл обработки сообщений выглядит примерно так: При том, что могут приходить события только 1,2,3. Вот как стоит писать этот цикл: Первый вариант - 24 байта (если все переходы короткие), второй - 11 байт.
Далее, присутствующий код (пишу по памяти, так что в порядке сравнений могу ошибиться) эквивалентен Пояснения. Команда "mov eax,xxxxxxxx" занимает 5 байт; вариант "push xx/pop eax" - 3 байта; "mov al,xx" - 2 байта. Арифметические операции с al/ax/eax имеют форму на байт короче: "cmp ah,'d'" занимает 3 байта, "cmp al,'d'" - 2 байта. Команда "or al,20h" переводит заглавные латинские буквы в маленькие, а цифры оставляет на месте.

А нужна ли оптимизация по размеру? Понятно, что в 1976 году каждый байт был на вес золота, но через тридцать лет
что нам даст экономия 150 байт?

Медленный код заставляет процессор больше работать, а значит сильнее греться.
Экономьте электричество!

Serge
Действительно, зачем это нужна оптимизация по размеру? Давайте здесь за счёт лишних 150 байт сэкономим миллисекунду, там за счёт 150 байт ещё миллисекунду... Перейдём на Си, современные компиляторы хорошо всё оптимизируют, с учётом кучи разных тонкостей, а что при этом используется куча кода для системных библиотек - так кого интересуют лишние килобайты?.. И получится вместо KolibriOS сначала BirdOS, потом СтраусОС, потом разрастётся куча проектов, весящих больше винды...
Ну это я конечно утрирую, до такого не дойдёт. Но всё-таки Колибри позиционируется как система, умещающаяся на дискете, так что разница начиная с сотен байт заметна.
Это я не к тому, что не нужно проводить оптимизацию по скорости в ущерб размеру. Нужно! В определённых ситуациях. Например, при реализации математических библиотек или работы с графикой и т.д. Но существуют и ситуации, в которых имеет смысл оптимизировать именно по размеру. Например, вряд ли кто-нибудь заметит, что приложение инициализируется на миллисекунду дольше, а вот 150 байт, сэкономленных на коде инициализации, заметить можно.
<Lrz>
Не рекомендуется использовать bt* с непосредственными операндами: bt можно заменить test, bts на or, btr на and, btc на xor. Это и меньше, и быстрее.

diamond
А как долго Колибри должна помещаться на дискету? Размер сектора на дискете 512 байт. Сколько файлов из дистрибутива
точно укладываются в 512, 1024, 1536, 2048 и т.д. байт ?

Мое мнение такое: - там где критично к скорости выполнения кода стоит сделать оптимизацию по скорости выполнения - где участки не критичны к скорости там стоит задуматься о размере. Я думаю что так будет правильнее. А вообще дело каждого как оптимизировать. Вообще было бы не плохо, если сделать статью как не стоит делать т.е. программировать в колибри.
OS Kolibri - не считаю дискеточной ОС. т.к. уже сейчас если поместить все приложения и игрушки которые были портированы или написаны для нее явно не хватит дискеты. Дискеты уходят в прошлое - это факт и с этим ничего не поделаешь.

(забыл сказать, что искользовал для теста 64 инструкции завтра попробую 2048 для наглядности и исключения влияния разных факторов

Дело не в дискете.
Чем меньшим числом команд будет записан алгоритм(естественно до разумного предела),тем меньше вероятность глюка.
Я делаю также как и diamond.Там где нужна оптимизация по скорости - делаю оптимизацию по скорости.А где она не важна - оптимизирую код по размеру(насколько умею).

Оптимизация не обязательно сводится к уменьшению числа команд. Интересно когда команда
mov eax, 3 заменяется на
push 3
pop eax ; команд больше а байт меньше - это оптимизация?

Когда запущено приложение с графикой загрузка процессора возрастает до 100%. В этот момент
медленный код начинает воровать время у всех программ, ведь система многозадачная.

В нынешнем дистрибутиве еще около 200 кБ свободного места. Насколько необходима экономия байтов?

Протестировал на машине CELERON 633 с количеством инструкций в цикле 1024, произвел 10 тестовых запусков по 32 в тесте для команды inc и add. По среднему скорость выполнения команд примерно одинаковая и порой сильно отличается от запуска к запуску. Скорее всего с достаточной точностью не возможно подтвердить какая инструкция быстрее или медленне. Имеет смысл тестить не отдельную команду а реализацию алгоритма и смотреть с какими командами он выполнятся быстрее или медленне. Можно сделать вывод: при оптимизации смотреть в документацию, какие команды выполняются быстрее.

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

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

Можно попробовать замаскировать аппаратные прерывания записав маски в порты 0х21 и 0хА1, если к этим портам можно получить доступ.

Дописал статью, произвел оптимизацию в коде. Доступна по старому адресу http://test-kolibri.narod.ru/d/less1.7z

Молодец!
Полезная статья.
Надо будет её потом на kolibrios.org закачать,если там будет раздел для закачки программ и статей(чтобы потом любой человек мог скачать).

<Lrz>
Пара замечание по статье (надеюсь, я еще не задолбал тебя):
1) Нету подписи - надо либо внизу, либо вверху статьи указывать, кто ты есть и желательно контактные данные.
2) А не проще ли нарисовать рамку методом рисования прямых линий? Мне так кажется это будет быстрей если прикинуть все затраты системы на время в целом. Хотя я могу ошибаться.