ZXNet эхоконференция «code.zx»

Hello, GriV

даже 10 прямых вызовов через Call может уже привести к выигрышу по сравнению с
системой Call на Jp.

А если их много? А если их очень много?

И вообще, ещё раз - сам процесс "пропатчивания" по сравнению с временем
загрузки программы (которое обязон есть) - порядка 5-10% (для средних
исполнительных файлов - для игр и дем эта цифра будет значительно меньше) -
т.е. вы загрузили программу, у вас ещё флопарь не перестал крутиться а
программа уже настроена - остались только прямые Call и никакой таблица в
памяти уже нет - чистейшая программа.

После этого ВСЕ функции выполняются быстро - потому что нет никаких
дополнительных переходов и т.д.

Т.о. своя оценка (плюсом обозначаю достоинства минусом недостатки):

1. RST - слишком медленно(-) хотя может показаться удобным(+) - на каждый вызов
требуется порядка 200(-) тактов (может и чуть быстрей) на определения куда
прошёл вызов; может возвратиться с ошибкой(+) - если нет заданной функции.
Использовался в старых программах как наследие системы прерываний от PC-шных
монстров. Требуется меньше всего памяти для вызова(+) - около 3х байт,
позволяет растаскивать процедуры по ПЗУ как угодно, внутренний транслятор
адресов сам всё вычислит и сделает(+).

2. Метод установленных точек перехода - Jp (Call) на таблицу Jp внутри ПЗУ -
требуется порядка 5-6 байт из программы (-), но работает очень быстро(+) по
сравнению с предыдущим вариантом. Тратится условно 20/26 тактов на один вызов
процедуры. Передача параметров (загрузка регистров) требует дополнительных(-)
вложений (где-то до 50 тактов максимум), от компилятора требуется
согласованность с версией ПЗУ (-), потому что прямой вызов/перезод на ПЗУ может
привести к фатальному исходу(?-), практически невозможно контролировать
"неправильные" вызовы/переходы(-). Требуется дополнительная таблица в ПЗУ(-).

3. Метод прямого вызова с предварительной настройкой. Подразумевает наличие в
файле таблиц для коррекции адресов вызовов(-) - что требует дополнительного
места на носителе (4 байта на каждую точку). Требует предварительной настройки
(-), порядка 100 тактов на одну точку вызова, однако настройка идёт только один
раз(?+), больше она не выполняется. Требует 5-6 байт для своей работы(-).
Скорость выполнения вызова самая высокая(+) - быстрей просто не бывает - 10/16
тактов. Загрузка регистров параметрам увеличивает(-) время вызова и память
отводимую для вызова условно до 40 тактов. Имеется возможность отследить
неверный вызов(+) ещё на этапе настройки вызовов - контролируются "неправильные
переходы". Требуется дополнительная таблица в ПЗУ(-).

Я для себя выбрал третий вариант, а Вы? ;)

Hello, GriV

мне не совсем понятно зачем нужна длительность выполнения операторов басика.
Может быть сравнивать производительность разных басик-трансляторов?
Скорей всего точную информацию по времени работы операторов ты нигде не найдёшь
- просто потому что это никому не надо.