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

[Barmaley_m]

Берем программу на бейсике, компилируем и она ускоряется ... в несколько раз.

Да, это опьяняет - поначалу. Но всё равно, это ускорение - ничто по сравнению с тем, что можно получить, программируя на ассемблере.

А почему так сильно ускорается, в несколько раз? Часто пишут, что интерпретатору сначала надо проанализировать программу.

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

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

По командам, если точнее. В одной строке могут встретиться несколько команд, разделенных двоеточием. Как только интерпретатор доходит до конца команды (последней в строке, или отделенной двоеточием от следующих команд) - то он ее выполняет. Потом переходит к следующей. Принципиальных отличий строк от команд два:
1) На строку можно перейти командой GOTO или GOSUB (исполнение продолжится с первой команды в строке, на которую переходит GOTO/GOSUB). На отдельную (не первую) команду в строке прямо перейти нельзя - нет таких команд. Хотя можно вернуться на вторую и последующие команды в строке с помощью RETURN.
2) Команда REM делает всё, что стоит в строке после нее, недостижимым для исполнения интерпретатором, и потому является последней в строке, где она встретилась.

Интерпретатор не переводит программу в машинный код. Он ее анализирует и, по мере анализа, исполняет действия, которые требуется. Например, встретилась команда BEEP - интерпретатор анализирует её параметры и вызывает подпрограмму в машинных кодах, которая издаёт звук. Встретилась команда DRAW - интерпретатор анализирует параметры и вызывает подпрограмму рисования линии в машинных кодах.

И вот вопрос - неужели интерпретатор самую большую часть времени тратит просто на анализ текста,

Да, это занимает львиную долю процессорного времени. Анализ текста программы - трудная задача. Большинство профессиональных программистов нашего времени не умеют ее решать эффективно и без ошибок. Учили когда-то в университете основы теории, но благополучно забыли и на практике не используют. Попробуй, ради интереса, написать на любом языке программирования, программу вычисления выражений, заданных формулами в текстовом виде. Сразу прочувствуешь всю глубину транса.

может еще какие технические причины есть для ускорения?

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

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

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

Наконец, не все подпрограммы действия в машинных кодах эффективны. В свое время я занимался переделкой Спектрум-бейсика, и удалось ускорить исполнение команды CIRCLE в разы, применив более эффективный алгоритм.

Например по операторам, в спектруме ключевые слова это же токены, а не строки букв. Значит надо проанализировать не всю строку до пробела, а всего 1 байт и понятно будет что за оператор - для ABS и CLS 1 байт вместо 3 букв, а для PAUSE 5 и RANDOMIZE 9 букв. И кроме того сразу можно сделать таблицу соответствия токен -- адрес его обработки, тогда переход к подпрограмме обработки оператора должен будет выполняться за время о(1), т.е. независимо от числа возможных токенов.

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

Но не токенизацией единой. Кроме самих команд, надо еще обрабатывать параметры, переводить в двоичную форму числа и вычислять выражения. Даже с числами в Спектрум-бейсике применяется трюк: внутреннее представление программы содержит числовые константы в предварительно интерпретированном, двоичном виде. Это внутреннее представление может отличаться от текстового. С этим связан хакерский трюк: реальные числа, с которыми работает программа, могут отличаться от отображаемых, если над внутренним представлением программы провести манипуляции. В программе может стоять команда RANDOMIZE USR 0, но при ее выполнении не произойдет сброс, как ожидается, а будет вызван машинный код совсем с другого адреса.

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

Ну ладно, я не знаю как внутри обработка в ROM устроено, может даже не сделали таблицу и выполняют сравнение токенов по цепочке if 200 else if 201 else if 202 итд.

Конечно, там сделали таблицу. Авторы бейсика, хоть и не боги, но вполне хорошие и опытные программисты уровня гораздо выше среднего (особенно в сравнении с нашим временем). У них можно многому поучиться. Для меня в свое время анализ интерпретатора Спектрум-бейсика был хорошей школой. Два добрых человека Ian Logan & Frank O'Hara провели полное дизассемблирование, анализ и комментирование Спектрум-бейсика, и издали результаты в виде книги. Там каждая команда разжевана, все идеи и алгоритмы расписаны. Очень рекомендую. Гугл в помощь. Был и русский перевод. "Ян логан, Френк о хара"

Потом подумал, что еще другие моменты есть. Например, интерпретатор все время опрашивает клавиатуру на предмет нажатия BREAK, а компилированный код не опрашивает - или тоже опрашивает?

Это от компилятора зависит. Большинство не опрашивают. Но такой опрос не занимает много процессорного времени, даже, если он есть.