Эффективное программирование в KOLIBRI OS

Assembler programming questions
  • Спасибо всем кто мне помог в написании статьи советами предложениями и критикой! Без вас всех ее бы просто не было! Статья более чем завершена, но все же продолжает быть в разработке и нуждается в ваших коментариях и предложениях. Адрес ее размещения прежний - добавил метод рисования прямыми - этот метод более оптимальный.
    http://www.test-kolibri.narod.ru/d/less1.7z
  • <Lrz>
    Вот теперь статья будет более востребована.
    Теперь можно писать исследование на тему: Рисование круга различными методами.
    Дальше можно будет расширить тему: Рисование круга с заполнением.
    Есть еще две смежные темы: Рисование многоугольников и оно же с заполнением.
    В принципе круг это и есть многоугольник. И его можно рисовать различными методами: точками и прямыми.
    Причем прямыми опять таки быстрей. А количество опорных точек при рисовании можно вычислять как квадратный корень от радиуса. Так вообще быстро рисуется, но получается малость коряво.
    А вот с заполнением сложней, этим вопросом я не занимался.
  • Круг - кривая второго порядка и рисуется соотвествующими методами (алгоритм Брезенхема). Круг с заполнением рисовать еще легче - поскольку доля вычислений по сравнению с рисованием уменьшается и можно использовать менее эффективные алгоритмы (для вычислений).
  • Немного переделал компонент от Maxxxx32 CheckBox описания пока нет, но уже доступен для скачивания
    http://www.test-kolibri.narod.ru/docs.html.
    Теперь при проверке и рисования чекера, нет вычисления длины символов надписи. Это значительно экономит процессорное время. Работа еще на закончена, планируются дальнейшее совершенствование.
  • Немного переделал компонент от Maxxxx32 Editbox, произведена оптимизация. Доступен для скачивания пример http://www.test-kolibri.narod.ru/d/EDITBOX.7z
  • Кстати про оптимизацию.
    1. Я твёрдо убеждён, что команды

    Code: Select all

    xor eax,eax
    add eax,12
    
    исполняются медленнее, чем банальный mov. В то время как и этот код, и mov занимают 5 байт. Уж если оптимизировать, то надо писать

    Code: Select all

    push 12
    pop eax
    
    (как это делается в стандартном macros.inc).
    Или, если есть уверенность, что на момент вызова некоторой сисфункции eax=0,
    то можно писать

    Code: Select all

    mov al,12
    
    - это ещё на байт короче и несколько быстрее.
    2. В коде компонентов активно используется 16-битная арифметика. Но 16-битный код в 32-битном режиме больше на байт и медленнее на такт. Почему бы не использовать 32-битные параметры в макросе? Да, при этом несколько увеличивается область данных, но это с избытком окупается размером и скоростью кода.
    3. Ещё раз повторяю, что

    Code: Select all

    bt word [a], 1
    jc @f
    
    длиннее и медленнее, чем

    Code: Select all

    test byte [a], 1
    jnz @f
    
  • diamond На счет push и pop
    Согласно справочнику Юрова по Ассемблеру (стр 476)
    ------------
    push r16/32 - занимает 3 микрооперации.
    pop r16/32 - занимает 2 микрооперации.
    -------------
    команада xor -занимает 1 микрооперацию
    mov r16/32,i16/32 - 2 микрооперации
    add r16/32,i16/32 - 1 микрооперация.

    Производить оптимизацию следует только для микропроцессоров Pentium Pro/II/III/IV
    Учитывая особенности конвейеров данных процессоров, то для достижения наибольшей производительности необходимо подавать команды, декодируемые в микрооперации в последовательности 4+1+1.

    Мы не можем сказать в какой последовательности попадут в конвейер команды, следовательно их нужно сделать такими, что бы попав туда они максимально быстро выполнились. Мой вариант более универсален, т.к. в любом случае в коде
    ------------
    xor eax,eax
    add eax,12
    ------------
    не будет задержке в конвейере. То что ты предлагаешь, короче, но и выполняться он будет дольше. С командой mov почти та же история, тут как повезет.
  • Смысл оптимизации по скорости есть только в циклах, где код выполняется сотни и тысячи раз. В остальных случаях это только делает код неудобочитаемым. Смысла оптимизации по размеру команд тоже нет, если нет цели запихнуть всё на одну дискету ;)
  • Иван Поддубный - пожалуй ты прав, как говориться на современных процессорах +/- 100 тактов погоду не сделает :)
    В общем выбирать программистам, но я думаю что люди смогут понять что написано.
  • <Lrz>
    Не следует путать скорость декодирования и скорость исполнения команд. По скорости декодирования - всё, как ты сказал. По скорости исполнения - команда mov имеет гораздо более простую логику и вроде бы исполняется быстрее (извините, соответствующих таблиц под рукой нет), чем имеющие сложную логику xor и add. Причём время работы в основном определяется именно скоростью выполнения. Юров приводит только таблицу скорости декодирования.
    Код, оптимальный по скорости на одном процессоре, запросто может оказаться хуже неоптимизированного варианта на другом. Код, оптимальный по размеру на одном процессоре, остаётся оптимальным по размеру на любом совместимом на уровне команд процессоре.
    P.S. А вообще в технике оптимизации по скорости на современных процессорах чёрт ногу сломит. Кстати, рекомендую почитать книгу Криса Касперски
    http://kpnc.opennet.ru/0.zip
    http://kpnc.opennet.ru/1.zip
    http://kpnc.opennet.ru/2.zip
    http://kpnc.opennet.ru/3.zip
    - очень интересные вещи пишет, хотя и не совсем на обсуждаемую тему.
  • diamond - спасибо за замечания к статье, я их учел и исправил. Частично удалось отказаться от 16 битной арифметики. Спасибо за книжку.
  • Переписал компонент editbox пока демо версия добавил insert
    скачать можно тут http://lrz.land.ru/
  • Обновил компонент + добавил выделение по shift. Версия текущая, рабочая. Скачать можно с сайта указаного выше.
  • Обновил компонент теперь ведет себя как виндовый editbox. Скачать можно с svn или с http://lrz.land.ru/
  • Who is online

    Users browsing this forum: No registered users and 4 guests