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

[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 тактов на команду (без учёта времени исполнения самой команды).

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

[Lethargeek]

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

[Spectramine]

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

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

Даже если бы вы сказали "Я вот тут слегка переделал код ПЗУ, бейсик теперь летает", это ещё не было бы доказательством того, что разработчики специально замедлили бейсик. Но, по крайней мере, было бы доказательством того, что в принципе возможно написать Бейсик с той же функциональностью попроизводительнее.

[Oleg N. Cher]

mmxdmv, я уверен, что разработчики не специально замедлили бейсик. Просто у них была задача, были требования и сжатые сроки, как это всегда бывает при коммерческой разработке. Если бы они приняли другие решения, вместо тех, которые положены в основу ROM-Basic (например, не медленное пятибайтовое представление вещественных чисел, а более быстрое четырёхбайтовое). Но ещё не будем забывать, что Z80 проц медленный, а бейсик из ПЗУ - интерпретатор. В любом случае, достоинство у этого бейсика одно - он помещается в ПЗУ, больше достоинств особо нет. Кроме ностальгии ;-)

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

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

[Spectramine]

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

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

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

Непонятно, к тому же, откуда вы взяли, что одна команда бейсика выполняется около 10 тыс. тактов. А если бы вы поставили одну команду BORDER, делили бы на 3? С командой PAUSE 1 ваши три команды так же выполнялись бы 1/50 секунды. PAUSE 1 выравнивает выполнение следующей команды на начало построения следующего кадра.

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

[SaNchez]

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

Ничего себе, какое гениальное маркетинговое решение, специально ухудшить характеристики своего продукта на фоне дичайшей конкуренции 1982 года!

[Бука]

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

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

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

[null_device]

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

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

[NEO SPECTRUMAN]

Ничего себе, какое гениальное маркетинговое решение

ну да!
разработчикам пришлось писать на асме

атоб они фтюхивали всякую фигню на бейскике...

хотя єтим они тоже активно занимались по началу...