Почему Спектрум-бейсик такой медленный?

[mmxdmv]

Для изучения скоростных характеристик бейсика накидал простенькую программу:

1 pause 1: border 2: border 3: border 4: border 5: goto 1

Она предсказуемо полосатит бордюр и практически не дрожит.
Итак, 6 команд выполняются за 1/50 секунды. Положим, команда pause притянута за уши, значит одну команду примерно бейсика Z80 исполняет около 10 тыс тактов.
Причём именно короткую команду с одним параметром. Если взять команды out 254,xx , то там время выполнения (ширина полоски на бордюре) побольше.

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

Итак, получается, компилятор преобразует бейсик-программу в машинный код вида CALL ПЗУ_1: CALL ПЗУ_2: CALL ПЗУ_3.
А что тогда делает интерпретатор?
Интерпретатор выполняет текущий оператор. Но текущий оператор это токен. Взяли код этого токена, умножили на 2, слазили в ПЗУ по этому адресу - получили адрес процедуры (которая ПЗУ_1) и вызвали её (сделали аналог CALL ПЗУ_1).
Да, скажете, ещё надо число-параметр кинуть на стек калькулятора и потом его заберёт процедура. Но постойте, число уже давно преобразовано к пятибайтному формату. Тысячи тактов тратить на то чтобы скопировать? Бред.
По сути дела, токенизированный бейсик с пятибайтным представлением чисел - это практически пи-код. Такой же в паскале оочень бодро интерпретируется тысячами команд в секунду.
Почему же бейсик такой медленный?

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

В любом случае разработчики специально замедлили бейсик минимум в 20-30 раз.

[Advertiser]

[Alex Rider]

В любом случае разработчики специально замедлили бейсик минимум в 20-30 раз.

Нет. Программа на Spectrum BASIC ничего общего с пи-кодом не имеет. Читаем дизассемблер ПЗУ и ищем ответы на вопросы.

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

Практика показывает, что из этого применимо только первое - адреса строк вместо длин.

[mmxdmv]

Нет. Программа на Spectrum BASIC ничего общего с пи-кодом не имеет. Читаем дизассемблер ПЗУ и ищем ответы на вопросы.

Я знаю что ПЗУ спектрума не предназначено для пи-кода.
Просто почему вы так категоричны что бейсик ничего общего с пи-кодом не имеет?
Все команды - токенизированы в коды, все числа - переведены в удобоваримую форму... очень похоже на пи-код.

Ну или по-другому сформулирую свою мысль.
Вполне можно было бы сделать такой пи-код, который сравнительно просто поддавался редактированию (как 128 бейсик переводит обратно токены в буковки, а 5 байтное представление цифр скрывается даже в 48), но в то же время исполняется почти со скоростью компилятора (100-200-300 тактов для перехода к следующей команде).
Т.е. интерпретация языка свелась бы к закидыванию чисел на стек калькулятора и косвенного вызова процедуры соответствующей токену...

[Xrust]

Просто почему вы так категоричны что бейсик ничего общего с пи-кодом не имеет?

Потому, что так и есть. А еще в программе могут быть ошибки, которые интерпретатор тоже вынужден отлавливать в процессе выполнения.

[mmxdmv]

А еще в программе могут быть ошибки, которые интерпретатор тоже вынужден отлавливать в процессе выполнения.

А вот нифига.
Ошибки бывают двух видов - ошибка синтаксиса и ошибки выполнения.
Синтаксис прекрасно встроенный редактор правит, а вот ошибки выполнения вынужден и компилятор проверять.
Вернее даже не компилятор проверяет, а сами процедуры в ПЗУ (Например если рисовать дугу DRAW так, чтобы загогулина вышла за конец экрана, то получим ошибку даже в компиляторе)
Т.е. мы не ведём речь про злостного хакера, который сделал сотни poke и у него бейсик-программа стала мутантом которую принципиально нельзя с клавиатуры ввести.

[Lethargeek]

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

[mmxdmv]

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

Нет. Я имел в виду немного другое.
Интерпретатор тратит около 10 тыс. тактов просто на команду. Не на выражение, а на команду.
А вот если сделать "сложное выражение" и прогнать через компилятор, то даже синусы-косинусы, которые вычисляются ТЕМИ ЖЕ процедурами ПЗУ будут работать быстрее "простых" команд.
Тем более интерпретатору НЕ НАДО разбирать параметр, при вводе строки этот параметр уже преобразовался к 5 байтному значению - его просто надо загрузить и выполнить.

- - - Добавлено - - -

Полосок, соответствующих одной команде BORDER N, на бордюре укладывается примерно 10. Делим 69888 тактов на 10, получаем примерно 7000 тактов на одну команду BORDER.

К сожалению я проверял в эмуляторе и из 128 режима, поэтому он мог мне приврать несколько процентов.
Но в любом случае 7 и 10 команд - цифры одного порядка, всё равно это тысячи тактов.
Это безумно много.

- - - Добавлено - - -

это ещё не было бы доказательством того, что разработчики специально замедлили бейсик

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

Перефразирую по-другому, что если бы в проект добавить спеца, увеличить ПЗУ и дать чуток больше времени на подготовку, то без проблем бейсик мог бы работать почти со скоростью компилятора

- - - Добавлено - - -

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

С этим никто не спорит. Это и 30 лет назад понятно было. Просто несправедливость-то вопиющая

- - - Добавлено - - -

Читал что многие процедуры брались практически без переделки из кода ПЗУ ZX81, в том числе и команда CIRCLE (не влезшая в тот ром и оставшаяся лишь в виде рекламы).

А так как все процедуры были оптимизированы на минимальное использование ОЗУ под буфер, чтобы работать на 1кб, то были очень медленны.

Разработчики из New Tiles предлагали доработать бейсик с учетом того что теперь не надо экономить память, но Синклер в приказном порядке это запретил.
Как результат в 16к ПЗУ осталась минимум одна (емнип больше) процедура от ZX81, нафиг не нужная Спектруму.

Дело как бы не в процедурах, которые рисуют на экране.
Ну медленные там CIRCLE, DRAW, PRINT и всё иже с ними, ну и положить на это.
Очень медленным получился сам интерпретатор.

- - - Добавлено - - -

Рекомендую, "перечитать" одну замечательную книжку. Во вступительной части про компилляторы, весьма доступным языком дается ответ на ваш вопрос.

не помню, читал ли эту книжку в детстве. У меня не было свободного доступа к литературе. В любом случае, даже если листал её, то уже после изучения машинных кодов.

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

Но ещё раз обращаю внимание (с BORDER это может быть и не показательно) что, и интерпретатор, и компилятор вызывают одни и те же процедуры ПЗУ: они оба в конечном итоге выполняют команду CALL ПЗУ
Просто компилятор это может сделать сразу, а вот интерпретатору придётся "опознать ключевое слово". Но блин, ключевое слово - ОДИН БАЙТ. А на это тратится тысячи тактов

[Lethargeek]

Интерпретатор тратит около 10 тыс. тактов просто на команду. Не на выражение, а на команду.

Еще раз, внимательно, по слогам. Для интерпретатора не существует "просто команды". Даже для уже токенизированной строки он сперва определяет по одной таблице класс команд по типу и количеству операндов, потом парсит и вычисляет операнды, каждый из которых может оказаться (а может и не оказаться, но интерпретатор не помнит этого) выражением весьма сложным, потом только находит по второй таблице через токен и вызывает нужную процедуру. Тыщи тактов на ВСЁ это вместе всегда уходит. Код к тому же не оптимизированный по скорости.

[mmxdmv]

Еще раз, внимательно, по слогам. Для интерпретатора не существует "просто команды". Даже для уже токенизированной строки он сперва определяет по одной таблице класс команд по типу и количеству операндов, потом парсит и вычисляет операнды, каждый из которых может оказаться (а может и не оказаться, но интерпретатор не помнит этого) выражением весьма сложным, потом только находит по второй таблице через токен и вызывает нужную процедуру. Тыщи тактов на ВСЁ это вместе всегда уходит.

Я вам верю что спектрум-бейсик это делает именно так.
Просто "определяет по одной таблице класс команд по типу и количеству операндов" - это звучит пугающе. А на самом-то деле раскидали по таблице токенов - первые 5 токенов = без операндов (cls, run), потом 10 с одним операндом (paper, border, peek), потом ещё 10 с двумя и т.п. - при грамотном порядке токенов "класс команды" определяется из её номера напрямую.

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

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

"потом только находит по второй таблице через токен и вызывает нужную процедуру"
ну и в чём проблема-то? LD A,код_токена: ADD A,A: LD H,адрес_таблицы: LD L,A: LD B,(HL): INC L : LD C,(HL): PUSH HL: RET = итого меньше 70 тактов получается
Если код токена известен и таблица удобно размещена, то вообще можно за 50 тактов сделать


Просто изначально непонятно ну зачем так тормозить ;(

[NEO SPECTRUMAN]

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

Просто изначально непонятно ну зачем так тормозить ;(

блин 82 год был...

найди что нибудь написанное в это время
быстрое и качественное

компы хоть какието(доступные) у людей появились за пару лет до этого