MarioЦитата:
1) Поддержка ASM это хорошо, и сразу видно что Cи все равно отъедает 20-30% по размеру занимаемой памяти (с учетом того что сама библиотека на Си написана). В бинарниках еще больше отъедает. И это с учетом того что писал человек разбирающийся в программировании.
Я так и думал, что все заметят разницу в размере. Причин столь значительной разницы в размере бинарников две.
1)Для вывода текста в консоль используется функция форматированного вывода printf() из стандартной библиотеки libC(небольшая часть этой библиотеки написана мной и используется в примерах). Функция printf() увеличивает размер бинарника на 7kb. Эта фукция рассчитана на форматированный вывод: отдельных символов,текста, целых чисел, вещественных чисел, строк, указателей. Также к размеру бинарника надо прибавить код для загрузки и линковки библиотеки console.
2)При компиляции программ компиляторами C(я использовал gcc) к заголовку программы добавляется код для разбора аргументов, передаваемых программе. Хотя сам код написан на ассемблере, но с учётом резервируемых для этого буферов, он расходует примерно 500-700 байт(зависит от того в каком формате объектный файл заголовка).
В ассемблерных примерах я не писал функции форматированного вывода. Лишь только для ProgressBar-а я использовал преобразование целого числа в строку(поэтому этот пример больше всех по размеру). Также в ассемблерных примерах нет вывода в консоль и нет кода разбирающего аргументы передаваемые программе.
Сейчас библиотека компилируется как объектный файл формата COFF. Только компилятор GCC добавляет в код служебную информацию(таблицу имён функций и т.д.). Для того, чтобы убрать эти лишние символы, нужно использовать утилиту strip. После её применения размер объектного файла libGUI.obj уменьшается на данный момент на 17kb. Только вот и ключевое слово EXPORTS тоже исчезает(потому что таблица экспорта представляется как обычный массив с именем EXPORTS). Поэтому библиотека перестаёт грузиться. Пока я не придумал, как обойти это. Нужно вникать в устройство формата объектного файла и писать свою версию утилиты strip, или пытаться править её код. Подумываю ещё сделать часть обёрток системных функций для MSVC++. Тогда библиотеку можно будет скомпилировать MSVC в ассемблер MASM, а потом скомпилировать код в dll формата COFF. В этом случае таблицы имён и прочего мусора не будет. Только MSVC вроде генерирует ассемблерный код без выравнивания, а вот gcc выравнивает. В общем я над этим поэкспериментирую.
Также я планирую переписать некоторую часть libGUI на ассемблер(работа с памятью, рассчёт градиентов и всё, что критично по скорости).
Цитата:
2) Обнаружил зверский баг - если запустить 2 примера и поместить их друг над другом (чтобы окна хоть немного пересекались) они начинают бесконечно перерисовывать свои окна. Впрочем баг похоже не редкий - я в zSea тоже обнаружил недели 2 назад, пока не разбирался в чем причина.
Этот баг я тоже заметил. Он связан частично с особенностью реализации оконного менеджера в Kolibri. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".
Регистрация
Вход
FAQ
Поиск
Пользователи
