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

[creator]

Пусть это правительство идет на "Ё"

Здравствуй, Петр!

[Advertiser]

[error]

Здравствуй, Петр!

У меня в паспорте так и написано "ПЕТР" - не вижу никаких проблем

[Eltaron]

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

В.Ленин, который в 1918 отменил некоторые устаревшие буквы, на букву 'ё' не покусился, т.к всякому ясно, что это отдельный звук, заслуживающий собственной буквы.

Он и твёрдый знак он почему-то пощадил. И очень зря.

У меня в паспорте так и написано "ПЕТР" - не вижу никаких проблем

Ну то Пётр. Был бы Семён, то увидев, что написали в загранпаспорте, очень бы расстроился.

[mmxdmv]

если бы в проект добавить спеца

При этом получив кучу проблем "совместимости" старого софта, использующего точки входа подпрограмм ПЗУ, ряда программ проверяющих "целостность" ПЗУ или тех, где используется IM2 и вектор "лежит" в ПЗУ.

Прошу прощение за своё косноязычие. Имелось в виду время создания спектрума.
Разумеется, начиная года с 83-84 правки в ПЗУ вносить уже было бессмысленно.

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

У спектрума обычный формат одинарной точности - просто в те времена не было единого стандарта вот они и ваяли каждый своё.

Ну не совсем обычный. Пятибайтовый. "Обычный" - это 4 байта в одинарной точности и 8 байт - в двойной.

Была идея сделать FPU полноценный - опять же синусы вычислять там или ещё чего полезное. Кстати не первый раз слышу что с FPU лучше не заморачиваться а пользоваться целочисленной арифметикой.

С FPU лучше не заморачиваться по другой причине. Спектрум - дитя своего времени. Сейчас он используется только для вау-эффекта: смотри какую демку я замутил - всего килобайт, а круче 50 мегабайтной игрульки у тебя на телефоне и даже без рекламы.

Поэтому если тебе нужны вычисления, то выбираешь по нарастающей - ардуину, STM, малинку, атом, i7, xeon; считаешь на видюхах, уходишь в распределённые вычисления и облака...
А к Z80 привязать сопроцессор с FPU - это дорого, несовместимо и непонятно зачем. Как к луку самонаводящиеся стрелы делать. Оно может будет прикольно, но пулемёт с несколькими ящиками патронов круче и дешевле.

Ну и на Z80 вычисления не ведутся, потому что нафиг не надо: даже в 3д играх легче заранее отабличить несколько синусов-косинусов и сделать поворот не на произвольный, а на фиксированный угол. В большинстве случаев поворот меньше чем на 1 градус не нужен, а таблицу синусов на 90 градусов составить - нефиг делать. Можно и косинусы по этой же таблице считать. Тоже самое и с корнями: проще ограничить мир определённой точностью и не нужны будут эти числодробилки.

Если ты всё же впаяешь в спектрум ту же малинку, которая будет считать плавучку...
То внезапно сразу ой. Придётся как-то передавать данные из Z80 в малинку и обратно.
Если повесишь на порты ввода-вывода, то простое умножение это десять байт в одну сторону и 5 байт в другую. Плюс квитирование, плюс коды операций. В не самом плохом случае тактов 30 на один байт получится - 400-500 тактов на операцию. Если хочешь быстрее - то нужна будет эмуляция: процессору скармливаешь команды NOP, а сам внешней схемой читаешь память и делаешь что надо. Но тут вылезают конфликты с ULA и прочая катавасия... Проще уж на одной малинке считать, без спектрума. И быстрее, и дешевле, и точнее, и нервов меньше потратишь.

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

Топик стартер mmxdmv когда же Вы наконец попросите модератора исправить опечатку в названии темы ?

Позор на мои седины. Писалось ночью и с радиоклавиатуры. Может сам промахнулся, а может и не пропечаталось.
Попрошу исправить обязательно.

По поводу других ошибок - тут даже не ошибки, а описки. Сделал масштаб 200% - может так разгляжу свои непотребности.

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

Компилятор бейсика для ZX-Spectrum не может быть настолько эффективным. Компиляторы бейсика для 8-ми разрядок (от Microsoft и Digital Research) дают ускорение всего в 3...5 раз. Ещё меньшее ускорение дают компиляторы Turbo Basic, Quick Basic и Power Basic для IBM PC.

Под ускорением тут подразумевалось немного другое.
Вот смотрите: есть сама программа, полезный код. Например команды CLS: CIRCLE
Если заменить на машинный код CALL CSL: CALL CIRCLE - то получим ускорение на сколько там я тактов писал в начале? 10 тысяч?
Ну пусть я неправильно измерил и реально на две команды получим ускорение в 15 тысяч тактов.
А сколько выполняется CLS? Наверное все 200 тысяч, а для CIRCLE вообще миллионы тактов потребуются. Следовательно в этом конкретном случае 15 тысяч делим на миллионы - и получаем ускорение даже не на десятые доли процента...

Но вот для команд, которые "ничего не делают", такие как border, ink, paper, in, out, poke, peek, plot, point - вот на этих командах ускорение должно быть гигантским. Так что ускорение сильно зависит от структуры команд. Если изменится время исполнения команд BEEP и SAVE/LOAD - то это всё, тушите свет.

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

Даже В.И.Ленин, который в 1918 отменил некоторые буквы, на букву 'ё' не покусился, т.к всякому ясно, что это отдельный звук, заслуживающий собственной буквы.

Он и твёрдый знак он почему-то пощадил. И очень зря.

Букву Ё оставили для симметрии. Очень уж прекрасно она ложится в алфавит - 5 гласных обычных и 5 гласных - им в пару йотированных.
А вот про твёрдый знак солидарен. И не потому что его писать не умею, но потому что без него в алфавите 32 буквы получается - круглое число

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

а за придирчивость никаких карточек не положено ? ) - там и ежу понятно о чём тема )

p.s. У нас же тут не литературный кружок - ёмаё )

Фиг знает. На самом деле грамотность надо пропагандировать хлеще здорового образа жизни.
И так страна деградирует. Тем более, на этом форуме школоты не бывает.
В общем, обещаю читать то что пишу, и дебильных вырвиглазных ошибок постараюсь больше не делать.

[Lethargeek]

вот для команд, которые "ничего не делают", такие как border, ink, paper, in, out, poke, peek, plot, point - вот на этих командах ускорение должно быть гигантским.

вот давно пора наконец залезть в книжку с дизассемблером пзу и посмотреть, как они "ничего не делают"
тот же plot уже после вычисления операндов выполняться будет ~3600 тактов
из них ~2900 уходит на конвертацию координат из 5-байтной формы в однобайтовую

[OrionExt]

Тема. Это пять!

Почему моя утка, которая сдохла, была такая худая?

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

Вижу я. Форум для домохозяек пора открывать. Отголосок ZX-next=)

[zx_]

FPU не дает покоя всем

https://zx.itch.io/busra

да и народ одержим идеями и воплощает

https://zx.itch.io

чйорт побери (с)

[OrionExt]

FPU прикольная штука. Но Спектруму – это как мертвому припарка=)

Да ДМА припарка. Что уж тут делать?)
Ого. Вот и я втянулся в тему не о чем

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

Многие ZX пытались аппаратно эмулировать. В MSX он вписывается в виде одной платки. Это очень просто.

А Бейсик Zx, что бейсик. Я его на Орионе запускал, прикольная штука

[zx_]

еще всяко плавающее
Floating-Point Math Package for GameBoy or Z80 in Assembler, by Jeff Frohwein
http://www.z80.info/zip/math.zip

Math48.zip 48 bit floating point mathematical package for Z-80 based microcomputers, by Anders Hejlsberg.
http://www.z80.info/zip/math48.zip

все это лирика и троллинг , конечно

но есть ведь SE Basic, который можно прошить вместо родного
а в этом бейсике много чего ускоренно , плюс искомая фишка
--- Assembly file includes X80 virtual co-processor definitions.

[mmxdmv]

Фишка в том, что тот же RUN может использоваться как с параметром, так и без (по сути, он всегда с параметром, даже если его не задал пользователь). С остальными командами, аналогичная ситуация (тот же GO TO n может использоваться с явным числовым выражением, а может использоваться алгебраическая конструкция GO TO n+m, и даже, алгебраически-логическая GO TO n+(m AND a)+(o AND b).

Небольшой пример приведу на счёт с параметром и без параметра. Есть такая вроде бы функция BIN. Но это на самом деле не функция, это другое представление числа. После него так же идёт пятибайтная форма. И даже если [B]BIN[/] без параметров то дальше идёт пятибайтный ноль. То есть не было проблем превратить команду без параметров в команду с параметрами на уровне редактора.
А вот теперь про выражения, тоже обращаю внимание: а как компилятор считает выражения?

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

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

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

вот давно пора наконец залезть в книжку с дизассемблером пзу и посмотреть, как они "ничего не делают"
тот же plot уже после вычисления операндов выполняться будет ~3600 тактов
из них ~2900 уходит на конвертацию координат из 5-байтной формы в однобайтовую

Лет 25 бы назад за такую книжку душу бы продал. А сейчас к сожалению лениво.
Но насколько мне не изменяет память "пятибайтный" формат может специальным образом хранить целые в дополнительном коде
Соответственно, можно было десятком проверок пробежаться по команде PLOT 128,88 и вызвать PLOT_BC из ПЗУ.
Конвертация-то не всегда нужна.

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

Ещё раз резюмирую что хотел сказать про компиляторы.

Есть оптимизирующий компилятор. Который понимает код лучше программиста.
Например делаем CLS: RUN - компилятор понимает, что два раза чистить экран не нужно, поэтому команду CLS можно выкинуть.
или DRAW 128,88: PLOT 128,88 - тут тоже компилятор видит, что точка уже поставлена, команда PLOT 128,88 - лишняя.

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

В детстве набирал программку из ZX-Ревю http://zxpress.ru/book_articles.php?id=750 по рисованию криволинейной поверхности.
Она работала безумно медленно. Попробовал заменить синус (вернее сразу всю функцию) на массив - получилось лишь немногим быстрее.
Откомпилировал обе версии в Tobos FP - вариант с синусом работал сносно, с массивом - довольно неплохо.
Если же писать в ассемблере на кодах калькулятора, то получалось ещё быстрее чем Tobos FP в варианте с синусом.
Вот и получается ересь: во всех трёх случаях (без массива которые) используются одни и те же процедуры ПЗУ, но почему-то с Tobos FP работает работает намного быстрее бейсика, а ассемблер - ещё быстрее. Хотя казалось бы синус он и в Африке - синус. Да и калькулятор один и тот же (сопроцессор я не вставлял).
Значит основные тормоза давал интерпретатор, потому что арифметика во всех трёх случаях не менялась...