Я глянул мельком.
Что вижу?
1. Штуки вроде
fld1
fxch
fsubp
можно заменить на
fld1
fsubrp
Т.е. убрать лишние шаги.
Посмотреть где ещё что-то подобное делается.
2. Оптимизировать:
macro deg2rad {
fmul qword[pi_180]
}
pi_180 dq 0.01745329251994 ; Pi/180
Мы избавляемся от деления и лишних этапов (3 инструкции превратились в 1).
Соответственно, удаляем все деления, какие только можем, заменяя их умножением на обратную величину.
Видел у тебя там
fdiv qword[_0.5], когда можно
fmul qword[_2.0] сделать. И не только
_0.5, а много таких мест.
3. Далее, переведи сопроцессор в режим работы с числами одинарной точности. Не могу гарантировать, но что-то мне подсказывает, что так будет работать быстрее. Нужно через
fldcw загрузить нужный режим. Плюс, замени все числа qword на dword. Зачем тебе такая точность?
4. Вот такие штуки замечены:
fld qword[bx+LABITEM.L]
fadd qword[bx+LABITEM.L]
Можно же написать без лишнего обращения к памяти:
fld qword[bx+LABITEM.L]
fadd st0,st0
5. Если не принципиальна поддержка 386 (или что там у тебя), используй
fcomi* вместо
fcom*, а лучше — вообще SSE.
Если важен 386, то замени
sahf +
.if CARRY? на
test ah,1.
6. Где можно обойтись целочисленной арифметикой, веди расчёт в целых числах (без f-инструкций).
7. Но это всё, мне кажется, даст прирост несущественный :)
Может, 10%, а может 5%, а может 0.5%.
А существенный прирост даст переработка алгоритма.
Что-то мне подсказывает, что 90% (95%) кода можно вообще в топку отправить.
Во-первых, найдя другой метод.
Во-вторых, оптимизировав алгоритм (сначала на бумажке, сократив какие-то множители или т.п.).
В-третьих, вероятно можно циклы сократить как-то. Ну или уменьшить их хотя бы, сделать где-то через один и пр.
В-четвёртых, убрать лишние преобразования туда-сюда (может, можно и без LAB обойтись, а как-то в RGB сделать? Не cпеши говорить "нет", подумай).
