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

[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 ПЗУ
Просто компилятор это может сделать сразу, а вот интерпретатору придётся "опознать ключевое слово". Но блин, ключевое слово - ОДИН БАЙТ. А на это тратится тысячи тактов