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

Hello, rasmer

Берёшь программу вида -
1 LET A=A+1; GOTO; 1
99 LET A=1; GOTO; 1

Запускаешь сие (при помощи RUN 99) на протяжении, скажем, 10 минут (засекать по
таймеру). Останавливаешь. Смотришь А. Делишь [10 (минут)*60 (секунд)*50
(фреймов)*69998 или 71998 (в зависомости от модели)] на полученное число. Вот
тебе и будет почти точное количество тактов на цикл вида LET A=A+1; GOTO; XXX

Далее, усложняешь её до вида:

1 : LET A=A+1; GOTO; 1
99 LET A=1; GOTO; 1

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

Что не учитывает такой подход: дело в том, что бейсик транслятор мягко говоря
туповат, и каждую строчку он ищет от первой. Потому - в целях снижения этих
затрат - запуск начинает с 99 строки, которая делает переход на первую - самую
быструю строчку, тем не менее даже первую строчку ему приходиться искать.

Кроме того, у тебя обязательно будут затраты на переход от оператора к
оператору внутри строки, которые в общем то трудно учесть.

Более точный результат ты сможешь получить только если проанализируешь работу
машинного кода, обрабатывающего команды басика, да и то - это будет сильно
зависеть от того какие были начальные условия. Т.е. условные операторы могут
работать быстрее медленнее в зависимости от начальных условий - я думаю тут
даже объяснять не надо почему.