Да, это опьяняет - поначалу. Но всё равно, это ускорение - ничто по сравнению с тем, что можно получить, программируя на ассемблере.Сообщение от vlad-kras
Да, надо проанализировать. Синтаксический анализ - очень непростая тема. Особенно, когда начинаешь думать, какие сложные варианты конструкций языка программирования могут встретиться, и их все интерпретатор должен правильно понять и обработать.
По командам, если точнее. В одной строке могут встретиться несколько команд, разделенных двоеточием. Как только интерпретатор доходит до конца команды (последней в строке, или отделенной двоеточием от следующих команд) - то он ее выполняет. Потом переходит к следующей. Принципиальных отличий строк от команд два:
1) На строку можно перейти командой GOTO или GOSUB (исполнение продолжится с первой команды в строке, на которую переходит GOTO/GOSUB). На отдельную (не первую) команду в строке прямо перейти нельзя - нет таких команд. Хотя можно вернуться на вторую и последующие команды в строке с помощью RETURN.
2) Команда REM делает всё, что стоит в строке после нее, недостижимым для исполнения интерпретатором, и потому является последней в строке, где она встретилась.
Интерпретатор не переводит программу в машинный код. Он ее анализирует и, по мере анализа, исполняет действия, которые требуется. Например, встретилась команда BEEP - интерпретатор анализирует её параметры и вызывает подпрограмму в машинных кодах, которая издаёт звук. Встретилась команда DRAW - интерпретатор анализирует параметры и вызывает подпрограмму рисования линии в машинных кодах.
Да, это занимает львиную долю процессорного времени. Анализ текста программы - трудная задача. Большинство профессиональных программистов нашего времени не умеют ее решать эффективно и без ошибок. Учили когда-то в университете основы теории, но благополучно забыли и на практике не используют. Попробуй, ради интереса, написать на любом языке программирования, программу вычисления выражений, заданных формулами в текстовом виде. Сразу прочувствуешь всю глубину транса.
Да, есть и еще причины.
Во-первых, как уже говорили выше, для исполнения команд GOTO или GOSUB интерпретатору приходится сканировать весь текст программы, от ее начала, пока он не найдет нужную строку. В компилированной программе можно заранее (на этапе компиляции) рассчитать в памяти место программы, откуда надо продолжить исполнение. Кроме случая "косвенного перехода", когда параметром GOTO или GOSUB является не константа, а переменная или математическое выражение с переменными. Но последний случай не поддерживается большинством компиляторов бейсика. Его поддержка обошлась бы сложно и дорого (по времени исполнения).
Во-вторых, подпрограммы, с помощью которых выполняются конкретные действия (рисование линий, печать символов, выдача звука и т.д.) являются универсальными и потому неэффективными для отдельных частных случаев, где программирование на ассемблере могло бы в десятки и сотни раз увеличить быстродействие.
Наконец, не все подпрограммы действия в машинных кодах эффективны. В свое время я занимался переделкой Спектрум-бейсика, и удалось ускорить исполнение команды CIRCLE в разы, применив более эффективный алгоритм.
Токенизация строк - это очень важный момент, и если бы ее не было - то бейсик работал бы в разы медленнее. Большинство интерпретаторов бейсика используют токенизацию для внутреннего представления программы, даже те, где надо набивать операторы по буквам, и токенизации как бы не видно.
Но не токенизацией единой. Кроме самих команд, надо еще обрабатывать параметры, переводить в двоичную форму числа и вычислять выражения. Даже с числами в Спектрум-бейсике применяется трюк: внутреннее представление программы содержит числовые константы в предварительно интерпретированном, двоичном виде. Это внутреннее представление может отличаться от текстового. С этим связан хакерский трюк: реальные числа, с которыми работает программа, могут отличаться от отображаемых, если над внутренним представлением программы провести манипуляции. В программе может стоять команда RANDOMIZE USR 0, но при ее выполнении не произойдет сброс, как ожидается, а будет вызван машинный код совсем с другого адреса.
Но даже и предварительное преобразование числовых констант не решает все проблемы быстродействия. Для вычисления выражений все равно приходится использовать сложные процедуры, которые долго исполняются. А компилятор может один раз проверить синтаксис и преобразовать любое выражение в обратную польскую запись. Даже при сохранении затрат на собственно математические операции, это может в разы повысить быстродействие.
Конечно, там сделали таблицу. Авторы бейсика, хоть и не боги, но вполне хорошие и опытные программисты уровня гораздо выше среднего (особенно в сравнении с нашим временем). У них можно многому поучиться. Для меня в свое время анализ интерпретатора Спектрум-бейсика был хорошей школой. Два добрых человека Ian Logan & Frank O'Hara провели полное дизассемблирование, анализ и комментирование Спектрум-бейсика, и издали результаты в виде книги. Там каждая команда разжевана, все идеи и алгоритмы расписаны. Очень рекомендую. Гугл в помощь. Был и русский перевод. "Ян логан, Френк о хара"
Это от компилятора зависит. Большинство не опрашивают. Но такой опрос не занимает много процессорного времени, даже, если он есть.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
