Почему компилированный Бейсик выполняется быстро?

[Barmaley_m]

Спасибо за хорошие отзывы. Хочу немного уточнить, сразу не все вспомнилось.

На отдельную (не первую) команду в строке прямо перейти нельзя - нет таких команд. Хотя можно вернуться на вторую и последующие команды в строке с помощью RETURN.

Не только RETURN, а еще NEXT и CONTINUE.

Да, есть и еще причины.

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

[goodboy]

В компилированной программе можно заранее (на этапе компиляции) рассчитать в памяти место программы, откуда надо продолжить исполнение. Кроме случая "косвенного перехода", когда параметром GOTO или GOSUB является не константа, а переменная или математическое выражение с переменными. Но последний случай не поддерживается большинством компиляторов бейсика. Его поддержка обошлась бы сложно и дорого (по времени исполнения).

первый-же проверенный компилятор (от Hisoft1988г.) спокойно поддерживает такой приём.

[Lethargeek]

Конечно, там сделали таблицу.

аж два уровня, и это еще до разбора выражений-параметров

собс-но вот, страница 84 -
http://www.primrosebank.net/computer...ssemblyThe.pdf

[vlad-kras]

Ну, к примеру, простая команда в ассемблере - jp на нужный адрес выполняется мгновенно.

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

дополню, здесь аналогичные вопросы и аналогичные выводы о тормознутости бейсика
https://zx-pk.ru/threads/3548-operat...ll=1#post55863

[null_device]

goodboy, Тут как бы, палка о двух концах. Быстродействие или полнота поддержки синтаксиса. Плюс, размер библиотек компилятора в памяти.

[Barmaley_m]

Кстати, раз уж мы тут "внутренности" бейсика обсуждаем - хочу поделиться найденной в нем ошибкой, о которой раньше публикаций не встречал.

А именно: можно без POKE, USR и прочих запрещенных приемов, заставить бейсик исполнять команды, стоящие за REM.

Ошибка происходит при попытке пропустить исполнение цикла FOR, если его условие сразу не выполнено. Например, при запуске следующей программы:
10 FOR i=1 TO 0
20 PRINT "loop"
30 REM hihi: NEXT i: PRINT "gotcha"
40 PRINT "end"
Будет напечатано:
gotcha
end

Также можно заставить бейсик ошибочно читать данные из команд DATA, стоящих за REM. Например:
10 READ a$: PRINT a$
20 REM aaa: DATA "gotcha"
30 DATA "ok"
При исполнении этой программы будет напечатано "gotcha".

Ошибка связана с тем, что при поиске команд NEXT и DATA интерпретатор ошибочно считает, что команда REM, как и прочие, заканчивается двоеточием, и за ней в строке могут следовать другие команды.

Особые эффекты будут наблюдаться, если в интерпретируемых за REM командах встречаются числовые константы (как если бы было не DATA "gotcha", а DATA 1 в строке 20). Ведь при проверке синтаксиса интерпретатор внедряет во внутреннее представление программы двоичное представление чисел. А тут числа стоят за REM, и они не интерпретируются, и их двоичное представление не внедряется. Но при попытке исполнения таких команд интерпретатор ищет это представление. У меня программа из первого примера, когда я в команде PRINT поставил не "gotcha", а 1, интерпретатор надолго задумался и напечатал C Nonsense in BASIC. Не помню уже, какие там возможны варианты, и может ли наступить серьезный сбой.

Также в случае с FOR/NEXT, логика пропуска тела цикла все равно реализована неверно. Например:
10 GO TO 30
20 NEXT i
25 STOP
30 FOR i=1 TO 2
40 PRINT i
50 GO TO 20
При запуске этой программы, как и должно быть, будут напечатаны числе 1 и 2.

Однако, если в строке 30 записать 30 FOR i=1 to 0

То при запуске программы интерпретатор не сможет понять, что цикл оканчивается командой NEXT i в строке 20, и пропустить его. Будет выведено сообщение I FOR without NEXT, 30:1.

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

[Advertiser]

[null_device]

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

Одной из особенностей переменных в циклах, командой NEXT n, можно продолжить его выполнение при выходе из середины тела (т.е. команд NEXT n) может быть больше одной.

[SfS]

Эх, поумничать хочу))

Я, с высоты теперешнего опыта, понимаю, что Спектрум-бейсик, очень неэффективен.

При создании переменных и строк там огромные куски памяти (по меркам спека) двигаются. Там же стековая организация. Реализация кучи была бы куда более быстрой. По памяти плюс-минус тоже.
Алгоритмы вывода на экран линий и окружностей - тоже совсем не быстрые.
Числа с плавающей запятой - вообще крайне медленно реализованы.
Поиск строки перебором при переходе - это жесть.
И так далее и тому подобное.

Я не хочу нисколько умалять заслуг создателей спектрум бейсика. У них куда хуже условия были для работы, чем у меня. И технически. И сроки. И не было тогда такого обилия информации по тому, "как писать языки" и "как организовывать системы".

[null_device]

SfS, поиск номера строки, даже перебором их, реализован вполне быстро (прибавив к адресу текущей строки, ее длину, находится номер следующей строки и так от строки к строке, до нужной).

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

[SfS]

SfS, поиск номера строки, даже перебором их, реализован вполне быстро (прибавив к адресу текущей строки, ее длину, находится номер следующей строки и так от строки к строке, до нужной).

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

Оно все "по отдельности" вполне. А все вместе существенно медленно работает.

Нет, для задач обучения вполне. Но для игр не вполне.
Есть же всякие мега бета Бейсики. И там многие вещи, в основном графика, куда быстрее.