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