Дело в том, что цепочечные команды (cmps, movs, ...) ожидают указатели на строки именно в этих регистрах. Т.е. они не принимают регистр в качестве аргумента, как тот же add, а хотят именно esi/edi.Leency wrote:1. я обращал, что обработка строк (копирование например) во многих реализациях идёт через регистры ESI и EDI, почему? Они в данной задаче стравляются быстрее, чем через EAX?
У максимального числа все биты установлены в единицы. Для 32-битного случая это 0xffffffff = 2^32 - 1. Вообще, 2^k выглядит как единица с k нулями, а 2^k - 1 как k единиц.Leency wrote:2. есть у нас регистр EAX. Максимальное число, которое в него можно записать - это 2^32 степени?
Как уже ответили, mov eax, 0x7d00 даёт ah=0x7d, al=0. Но это при записи непосредственного значения. Будь внимателен при чтении из памяти: если по адресу my_var лежит 0xaa, 0xbb, 0xcc, 0xdd, то после чтения mov eax, [my_var] в eax будет 0xddccbbaa. В этом и заключается little endian.Leency wrote:3. Окей, пишем в EAX, допустим, 32000. Cколько теперь будет в AH и AL?
В основном через обычные. В декодере jpeg есть код fpu, потому что нужно работать с вещественными числами. В декодере xcf можно выбрать mmx или sse. Я это сделал потому что:Leency wrote:4. Обработка изображений в libimg идёт через обычные регистры или через MMX? Почему?
1. В mmx есть удобные команды, например, сложения с насыщением. В случае работы с регистрами общего назначения пришлось бы заменять каждую из таких команд целым блоком (и повторять такие блоки по четыре раза: для каждой из ARGB компонент). В результате код короче, понятнее и быстрее.
2. Команды mmx позволяют обрабатывать за раз все четыре канала ARGB изображения, т.е. целый пиксель. Тут ещё влиет 64-битность mmx регистров -- больше влазит.
3. У нас всё равно поддержка оборудования с i586, а там даже у vortex-x86 есть mmx, никого не обделяю.