Неиспользуемые и редкоиспользуемые команды

[bsivko]

Пример безусловно, когда ix накладно использовать. Некорректный. IX и IY используют, например, когда у нас есть некие наборы данных, которые мы упорядочиваем по смещениям. Достаточно установить на начало область индексный регистр - как мы получаем доступ к структуре. И можем моментально менять адреса разных структур. Иначе, придется заниматься вычислениями и сохрананениями восстановлениями. Индексы ведь не используют, когда надо обратиться к одной переменной. Смысла нет, так что пример некорректный.

Замечу, что с передачей структур в функцию конкурирует другой метод. А именно - копирование необходимой информации в ту область памяти, на которую настроена функция.

Например - файловый коммандер. У нас 2 панели. Так? Нужно хранить параметры для левой и правой панели, по сути одни и те же. Можно завести переменные, и работать с ними. 2 набора процедур или вычислять адреса переменных, а можно на переменные указывать индексным регистром и при вызове процедуры ставить в него нужное значение.

В общем случае я согласен с этим примером. Могу добавить ещё один. Если мы делаем игру для двух игроков, поведение каждого из которых одинаково, то можем создать две области памяти, в каждой из которых одинаково хранится информация каждого из игроков. И впоследствии, если хотим обработать игрока X, то устанавливаем в нужное значение индексный регистр и запускаем.

Для большинства же рабочих функций (которые влазят "на экран") если мы передаем более 4-х параметров (A, BC, DE, HL) с помощью структур (IX/IY или каким-то другим способом) является серьезным поводом задуматься о том, правильно ли мы разработали функцию.

Кроме того замечу, что IX/IY - это "аналоги" глобального пространства имен в языках высшего уровня. Другими словами, если мы задействовали где-то IX, и где-то у нас есть другая процедура, использующая IX, то это переменное использование нужно контролировать, и в случае проблем это стоит долгих часов отладки.

Ведь есть много случаев, когда компактность и понятность кода важнее скорости. Если мы не демках говорим. Пусть будет на 10-30 тактов дольше, но без сумасшедших сохранений, перемещений и восстановлений. Т.е. не надо путать время-критичный код от логики.

С этим согласен.
Только у меня речь идет о компактности и быстроте реализации, а не о понятных программах, которые занимают столько места и времени, сколько им позволяет пользователь.

[Advertiser]