Просмотр полной версии : Почему Спектрум-бейсик такой медленный?
Для изучения скоростных характеристик бейсика накидал простенькую программу:
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 раз.
Alex Rider
28.06.2017, 23:53
В любом случае разработчики специально замедлили бейсик минимум в 20-30 раз.
Нет. Программа на Spectrum BASIC ничего общего с пи-кодом не имеет. Читаем дизассемблер ПЗУ (http://www.primrosebank.net/computers/zxspectrum/docs/CompleteSpectrumROMDisassemblyThe.pdf) и ищем ответы на вопросы.
В общем, моё мнение, что если бы в структуру строк бейсика добавить дополнительные штуки (как то переход по адресу строки - кроме номера строки хранить её адрес, длину параметров операторов - чтобы живее их на стек запихивать, адреса переменных и т.п.), то вполне можно получить пи-код, который бы интерпретировался по 200-500 тактов на команду (без учёта времени исполнения самой команды).
Практика показывает, что из этого применимо только первое - адреса строк вместо длин.
Lethargeek
28.06.2017, 23:58
бордер-то, может, и простая команда, но параметром может быть любое сложное выражение
синтаксически разбирается и вычисляется которое универсальной медленной процедурой
Spectramine
29.06.2017, 01:02
В любом случае разработчики специально замедлили бейсик минимум в 20-30 раз.
Пруф? Приведите пример кода ПЗУ, который специально замедляет бейсик? А иначе это утверждение основано только на ваших абстрактных соображениях.
Даже если бы вы сказали "Я вот тут слегка переделал код ПЗУ, бейсик теперь летает", это ещё не было бы доказательством того, что разработчики специально замедлили бейсик. Но, по крайней мере, было бы доказательством того, что в принципе возможно написать Бейсик с той же функциональностью попроизводительнее.
Oleg N. Cher
29.06.2017, 03:10
mmxdmv, я уверен, что разработчики не специально замедлили бейсик. Просто у них была задача, были требования и сжатые сроки, как это всегда бывает при коммерческой разработке. Если бы они приняли другие решения, вместо тех, которые положены в основу ROM-Basic (например, не медленное пятибайтовое представление вещественных чисел, а более быстрое четырёхбайтовое). Но ещё не будем забывать, что Z80 проц медленный, а бейсик из ПЗУ - интерпретатор. В любом случае, достоинство у этого бейсика одно - он помещается в ПЗУ, больше достоинств особо нет. Кроме ностальгии ;-)
- - - Добавлено - - -
Последняя сентенция - про то, что сегодня нет никаких причин разрабатывать на бейсике, кроме ностальгии.
Spectramine
29.06.2017, 03:50
Для изучения скоростных характеристик бейсика накидал простенькую программу:
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.
В любом случае разработчики специально замедлили бейсик минимум в 20-30 раз.
Ничего себе, какое гениальное маркетинговое решение, специально ухудшить характеристики своего продукта на фоне дичайшей конкуренции 1982 года!
Читал что многие процедуры брались практически без переделки из кода ПЗУ ZX81, в том числе и команда CIRCLE (не влезшая в тот ром и оставшаяся лишь в виде рекламы).
А так как все процедуры были оптимизированы на минимальное использование ОЗУ под буфер, чтобы работать на 1кб, то были очень медленны.
Разработчики из New Tiles предлагали доработать бейсик с учетом того что теперь не надо экономить память, но Синклер в приказном порядке это запретил.
Как результат в 16к ПЗУ осталась минимум одна (емнип больше) процедура от ZX81, нафиг не нужная Спектруму.
null_device
29.06.2017, 07:53
А если закомпилировать эту программу? Да, она будет исполнятся в сотни раз быстрее. А почему?
Рекомендую, "перечитать" одну замечательную книжку (http://trd.speccy.cz/book/DIALECT.ZIP). Во вступительной части про компилляторы, весьма доступным языком дается ответ на ваш вопрос.
NEO SPECTRUMAN
29.06.2017, 12:23
Ничего себе, какое гениальное маркетинговое решение
ну да!
разработчикам пришлось писать на асме
атоб они фтюхивали всякую фигню на бейскике...
хотя єтим они тоже активно занимались по началу...
бордер-то, может, и простая команда, но параметром может быть любое сложное выражение
синтаксически разбирается и вычисляется которое универсальной медленной процедурой
Нет. Я имел в виду немного другое.
Интерпретатор тратит около 10 тыс. тактов просто на команду. Не на выражение, а на команду.
А вот если сделать "сложное выражение" и прогнать через компилятор, то даже синусы-косинусы, которые вычисляются ТЕМИ ЖЕ процедурами ПЗУ будут работать быстрее "простых" команд.
Тем более интерпретатору НЕ НАДО разбирать параметр, при вводе строки этот параметр уже преобразовался к 5 байтному значению - его просто надо загрузить и выполнить.
- - - Добавлено - - -
Полосок, соответствующих одной команде BORDER N, на бордюре укладывается примерно 10. Делим 69888 тактов на 10, получаем примерно 7000 тактов на одну команду BORDER.
К сожалению я проверял в эмуляторе и из 128 режима, поэтому он мог мне приврать несколько процентов.
Но в любом случае 7 и 10 команд - цифры одного порядка, всё равно это тысячи тактов.
Это безумно много.
- - - Добавлено - - -
это ещё не было бы доказательством того, что разработчики специально замедлили бейсик
Я утрировано так написал. Понятно что у них не было ни времени с этим разбираться ни больших объёмов ПЗУ чтобы всё это хранить.
И даже бейсик-то они не с нуля присали а большую часть слизали из предыдущих проектов, где этот бейсик был ещё хуже.
Перефразирую по-другому, что если бы в проект добавить спеца, увеличить ПЗУ и дать чуток больше времени на подготовку, то без проблем бейсик мог бы работать почти со скоростью компилятора
- - - Добавлено - - -
сегодня нет никаких причин разрабатывать на бейсике, кроме ностальгии.
С этим никто не спорит. Это и 30 лет назад понятно было. Просто несправедливость-то вопиющая :)
- - - Добавлено - - -
Читал что многие процедуры брались практически без переделки из кода ПЗУ ZX81, в том числе и команда CIRCLE (не влезшая в тот ром и оставшаяся лишь в виде рекламы).
А так как все процедуры были оптимизированы на минимальное использование ОЗУ под буфер, чтобы работать на 1кб, то были очень медленны.
Разработчики из New Tiles предлагали доработать бейсик с учетом того что теперь не надо экономить память, но Синклер в приказном порядке это запретил.
Как результат в 16к ПЗУ осталась минимум одна (емнип больше) процедура от ZX81, нафиг не нужная Спектруму.
Дело как бы не в процедурах, которые рисуют на экране.
Ну медленные там CIRCLE, DRAW, PRINT и всё иже с ними, ну и положить на это.
Очень медленным получился сам интерпретатор.
- - - Добавлено - - -
Рекомендую, "перечитать" одну замечательную книжку (http://trd.speccy.cz/book/DIALECT.ZIP). Во вступительной части про компилляторы, весьма доступным языком дается ответ на ваш вопрос.
не помню, читал ли эту книжку в детстве. У меня не было свободного доступа к литературе. В любом случае, даже если листал её, то уже после изучения машинных кодов.
но даже оттуда цитирую (с сокращениями):
Наиболее простой способ трансляции - это немедленный "дословный" перевод, так называемая интерпретация.... Интерпретатор опознаёт ключевые слова языка и тут же подсовывает процессору соответствующую последовательность кодов.
Компилятор... создаёт программу в кодах, независимую от каких либо трансляторов.
Но ещё раз обращаю внимание (с BORDER это может быть и не показательно) что, и интерпретатор, и компилятор вызывают одни и те же процедуры ПЗУ: они оба в конечном итоге выполняют команду CALL ПЗУ
Просто компилятор это может сделать сразу, а вот интерпретатору придётся "опознать ключевое слово". Но блин, ключевое слово - ОДИН БАЙТ. А на это тратится тысячи тактов
Lethargeek
29.06.2017, 12:59
Интерпретатор тратит около 10 тыс. тактов просто на команду. Не на выражение, а на команду.
Еще раз, внимательно, по слогам. Для интерпретатора не существует "просто команды". Даже для уже токенизированной строки он сперва определяет по одной таблице класс команд по типу и количеству операндов, потом парсит и вычисляет операнды, каждый из которых может оказаться (а может и не оказаться, но интерпретатор не помнит этого) выражением весьма сложным, потом только находит по второй таблице через токен и вызывает нужную процедуру. Тыщи тактов на ВСЁ это вместе всегда уходит. Код к тому же не оптимизированный по скорости.
Нет. Программа на Spectrum BASIC ничего общего с пи-кодом не имеет. Читаем дизассемблер ПЗУ (http://www.primrosebank.net/computers/zxspectrum/docs/CompleteSpectrumROMDisassemblyThe.pdf) и ищем ответы на вопросы.
Я знаю что ПЗУ спектрума не предназначено для пи-кода.
Просто почему вы так категоричны что бейсик ничего общего с пи-кодом не имеет?
Все команды - токенизированы в коды, все числа - переведены в удобоваримую форму... очень похоже на пи-код.
Ну или по-другому сформулирую свою мысль.
Вполне можно было бы сделать такой пи-код, который сравнительно просто поддавался редактированию (как 128 бейсик переводит обратно токены в буковки, а 5 байтное представление цифр скрывается даже в 48), но в то же время исполняется почти со скоростью компилятора (100-200-300 тактов для перехода к следующей команде).
Т.е. интерпретация языка свелась бы к закидыванию чисел на стек калькулятора и косвенного вызова процедуры соответствующей токену...
Просто почему вы так категоричны что бейсик ничего общего с пи-кодом не имеет?
Потому, что так и есть. А еще в программе могут быть ошибки, которые интерпретатор тоже вынужден отлавливать в процессе выполнения.
Еще раз, внимательно, по слогам. Для интерпретатора не существует "просто команды". Даже для уже токенизированной строки он сперва определяет по одной таблице класс команд по типу и количеству операндов, потом парсит и вычисляет операнды, каждый из которых может оказаться (а может и не оказаться, но интерпретатор не помнит этого) выражением весьма сложным, потом только находит по второй таблице через токен и вызывает нужную процедуру. Тыщи тактов на ВСЁ это вместе всегда уходит.
Я вам верю что спектрум-бейсик это делает именно так.
Просто "определяет по одной таблице класс команд по типу и количеству операндов" - это звучит пугающе. А на самом-то деле раскидали по таблице токенов - первые 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
29.06.2017, 13:40
Но можно ж было как-то облегчить интерпретатору этот парсинг, чтобы он не тратил тыщи тактов на него.
Просто изначально непонятно ну зачем так тормозить ;(
блин 82 год был...
найди что нибудь написанное в это время
быстрое и качественное
компы хоть какието(доступные) у людей появились за пару лет до этого
А еще в программе могут быть ошибки, которые интерпретатор тоже вынужден отлавливать в процессе выполнения.
А вот нифига.
Ошибки бывают двух видов - ошибка синтаксиса и ошибки выполнения.
Синтаксис прекрасно встроенный редактор правит, а вот ошибки выполнения вынужден и компилятор проверять.
Вернее даже не компилятор проверяет, а сами процедуры в ПЗУ (Например если рисовать дугу DRAW так, чтобы загогулина вышла за конец экрана, то получим ошибку даже в компиляторе)
Т.е. мы не ведём речь про злостного хакера, который сделал сотни poke и у него бейсик-программа стала мутантом которую принципиально нельзя с клавиатуры ввести.
вот: https://zx.itch.io/sebasic3 за 5 баксов обещают оптимизацию по скорости.
Вот вы в этой троль теме написали всего 11 байт кода и уже в них сделали ошибку. А тогда нужно было не разглагольствовать а сделать рабочую версию в короткий промежуток времени и не отлавливать глюки от всяких оптимизаторов. Спектрум бейсик идеальный!
Вот вы в этой троль теме написали всего 11 байт кода и уже в них сделали ошибку. А тогда нужно было не разглагольствовать а сделать рабочую версию в короткий промежуток времени и не отлавливать глюки от всяких оптимизаторов. Спектрум бейсик идеальный!
90% сообщений про спектрум - это троллинг. В смысле я тролль, но тут половина таких.
Про ошибку - возможно. Больше 20 лет не писал в ассемблере Z80, на бейсике и того больше.
На счёт идеальности спектрумбейсика спорить не буду. То что запихнули в ПЗУ вышло довольно неплохое: со всякими там каналами и потоками, а также функциями пользователя можно нехило так извращатся.
Бета-бейсик правда чуток получше был, но компиляторов к нему не было и ОЗУ жрал немилосердно.
shurik-ua
29.06.2017, 15:51
Ну пикод в бейсике определённо есть - тот же код калькулятора - пикод для стековой машины в чистом виде. У меня кстати была идея реализовать аппаратный исполнитель именно для этого пикода.
Ну пикод в бейсике определённо есть - тот же код калькулятора - пикод для стековой машины в чистом виде.
Во. Правильно. Если строку бейсик-программы до ума довести, то можно было бы скармливать калькулятору практически напрямую. Правда калькулятор в обратной польской записи... но можно было придумать какую-нить преобразовалку.
Просто тот же калькулятор из ассемблера работает в десятки раз быстрее чем из бейсика.
У меня кстати была идея реализовать аппаратный исполнитель именно для этого пикода.
А для чего аппаратный калькулятор, если не секрет? Просто спектрумовские коды нигде кроме спектрума и не применяются. Да и в самом спектруме очень ограниченно (целочисленной арифметикой в десятки раз быстрее пользоваться).
Т.е. система холостой получается: в спектруме она нужна только полутора человекам, а вне спектрума - ту же малинку взять - всяко быстрее считать будет. ну или FCPGA ежели с сигналами связано. Но у сигналов обычно калькулятор не требуется.
- - - Добавлено - - -
Идея с быстрым интерпретатором запросто может масштабироваться и на другие приложения.
Вынес в системные переменные адрес интерпретатора и его таблиц. Скажем, загружаемая программа добавляет токенов к стандартным 91 (как делал бета-бейсик), либо подменяет своими целиком.
В играх класса dizzy рисование лабиринта тоже идёт по подобному принципу...
Типа если у тебя интерпретатор лишь на несколько процентов медленнее ассемблера, то последний можно и не использовать.
Разумеется это только для статической графики. Анимация - только на ассемблере.
null_device
29.06.2017, 17:29
если бы в проект добавить спеца, увеличить ПЗУ и дать чуток больше времени на подготовку, то без проблем бейсик мог бы работать почти со скоростью компилятора
При этом получив кучу проблем "совместимости" старого софта, использующего точки входа подпрограмм ПЗУ, ряда программ проверяющих "целостность" ПЗУ или тех, где используется IM2 и вектор "лежит" в ПЗУ.
shurik-ua
29.06.2017, 17:29
А для чего аппаратный калькулятор, если не секрет?
У спектрума обычный формат одинарной точности - просто в те времена не было единого стандарта вот они и ваяли каждый своё. Была идея сделать FPU полноценный - опять же синусы вычислять там или ещё чего полезное. Кстати не первый раз слышу что с FPU лучше не заморачиваться а пользоваться целочисленной арифметикой.
Вот кстати - http://zx-pk.ru/threads/25537-fpu/
null_device
29.06.2017, 17:46
Очень медленным получился сам интерпретатор.
Такое происходит при использовании любого ЯВУ.
компилятор это может сделать сразу, а вот интерпретатору придётся "опознать ключевое слово". Но блин, ключевое слово - ОДИН БАЙТ. А на это тратится тысячи тактов
Можно вырубить себе дом в скале, или построить конуру из ж\б блоков. Именно этим и приходится платить за то, чтобы не держать в голове адреса подпрограмм ПЗУ (те же команды работающие с магнитной лентой, явно стоят того, чтобы не заниматься эквилибристикой с ассемблером) и использовать "универсальные" конструкции типа арифметических и логических значений в одних и тех же операторах. Именно поэтому компилляторы имеют граниченный список операторов которые они могут "переварить" в набор маш. процедур.
- - - Добавлено - - -
раскидали по таблице токенов - первые 5 токенов = без операндов (cls, run)
Фишка в том, что тот же RUN может использоваться как с параметром, так и без (по сути, он всегда с параметром, даже если его не задал пользователь). С остальными командами, аналогичная ситуация (тот же GO TO n может использоваться с явным числовым выражением, а может использоваться алгебраическая конструкция GO TO n+m, и даже, алгебраически-логическая GO TO n+(m AND a)+(o AND b).
Топик стартер mmxdmv когда же Вы наконец попросите модератора исправить опечатку в названии темы ? Почему Spectrum-бейсик такой медленный? Это не за мат, а за грамматические ошибки надо давать жёлтую карточку. А за ошибки в названии темы можно давать даже красную карточку.
Если модератор в отключке, то есть супер-модераторы. В крайнем случае можно попросить админа.
Обидно, что авторы постов ленятся исправлять свои, даже самые бросающиеся в глаза опечатки и грамматические ошибки. Это неуважение к читателям, особенно к иностранным (т.к ошибки мешают сделать компьютерный перевод). Для борьбы с этим можно провести конкурс на самого малограмотного пользователя (по коээффициенту на сколько слов приходится сколько грамматических ошибок). Кстати, замена буквы 'ё' на 'е' по новым правилам тоже считается грамматической ошибкой.
А если откомпилировать эту программу? Да, она будет исполнятЬся в сотни раз быстрее.
Компилятор бейсика для ZX-Spectrum не может быть настолько эффективным. Компиляторы бейсика для 8-ми разрядок (от Microsoft и Digital Research) дают ускорение всего в 3...5 раз. Ещё меньшее ускорение дают компиляторы Turbo Basic, Quick Basic и Power Basic для IBM PC.
Очень много ошибок с буквой Ь в словах оканчивающихся на "ться". Вы никогда не ошибётесь, если вспомните метод проверки, которому учили в школе - для проверки достаточно "ся" отделить и заменить на слово "себя" (от которого этот суффикс и происходит).
shurik-ua
29.06.2017, 18:45
А за ошибки в названии темы можно давать даже красную карточку.
а за придирчивость никаких карточек не положено ? ) - там и ежу понятно о чём тема )
p.s. У нас же тут не литературный кружок - ёмаё )
Black Cat / Era CG
29.06.2017, 18:48
Кстати, замена буквы 'Ё' на 'Е' по новым правилам тоже считается грамматической ошибкой.
Это где? Ссылку на документ дайте. У меня на эту недобукву переключение языка повешено.
Кстати, замена буквы 'ё' на 'е' по новым правилам тоже считается грамматической ошибкой. Это где? Ссылку на документ дайте
Вы давно не писали школьных сочинений и забыли школьные годы. Забыли кампанию за грамотность, что была в СМИ пару лет назад, когда президент В.В.Путин специально выступил в защиту буквы 'ё' ? Это решение правительства, которое следует уважать.
Во всех европейских языках есть "умляуты" и "аксанты" и там буквы с ними и без них это совершенно разные буквы и тем более звуки. Это из-за того, что звуков оказалось больше, чем 26 латинских букв. Наш алфавит заимствовали у болгар (явно из-за того, что там букв побольше), но всё-равно нескольких букв для обозначения звуков не хватило (а буквы 'ё' в болгарском языке нет). Вот и пришлось использовать идею двух точек над буквой, как сделано в романских языках. Даже В.И.Ленин, который в 1918 отменил некоторые буквы, на букву 'ё' не покусился, т.к всякому ясно, что это отдельный звук, заслуживающий собственной буквы. Русский язык тем и превосходит убогий английский, что читается так, как пишется, а если 'ё' отменить, то при чтении надо гадать как читать, или же придётся законодательно изменить произношение слов.
за придирчивость никаких карточек не положено ? - там и ежу понятно о чём тема
Я не придираюсь. Тем более к топик стартеру, он далеко не самый неграмотный здесь.
Ежу и остальным может и понятно. Но когда уже 30 сообщений в "Ленте активности" читаешь одну и ту же ошибку, это сильно раздражает. Всё ждал, ждал... когда исправят, и извините не выдержал, влез в чужую тему с оффтопом. Если кого-то обидел, прошу прощения. Это у меня такой "бзик", - чувствую себя некомфортно, когда встречаю при чтении грамматические ошибки. Я тоже делаю при наборе море ошибок, но стараюсь их исправлять.
Вы давно не писали школьных сочинений и забыли школьные годы. Забыли кампанию за грамотность, чтобыла в СМИ пару лет назад, когда президент В.В.Путин специально выступил в защиту буквы 'ё'. Это решение правительства, которое следует уважать.
Пусть это правительство идет на "Ё"... Видимо другие проблемы в стране кончились.
Пусть это правительство идет на "Ё"
Здравствуй, Петр!
Здравствуй, Петр!
У меня в паспорте так и написано "ПЕТР" - не вижу никаких проблем :)
Даже если бы бейсик стал в три раза быстрее, что это улучшило бы? Игры бы на нём писать всё равно бы не начали, т.к. без спрайтового двигла это неудобно. А выводить спрайты руками через переопределяемые на лету UDG по сложности уже недалеко от использования Си и чуреры.
В.Ленин, который в 1918 отменил некоторые устаревшие буквы, на букву 'ё' не покусился, т.к всякому ясно, что это отдельный звук, заслуживающий собственной буквы.
Он и твёрдый знак он почему-то пощадил. И очень зря.
У меня в паспорте так и написано "ПЕТР" - не вижу никаких проблем :)
Ну то Пётр. Был бы Семён, то увидев, что написали в загранпаспорте, очень бы расстроился.
если бы в проект добавить спеца
При этом получив кучу проблем "совместимости" старого софта, использующего точки входа подпрограмм ПЗУ, ряда программ проверяющих "целостность" ПЗУ или тех, где используется 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
30.06.2017, 17:25
вот для команд, которые "ничего не делают", такие как border, ink, paper, in, out, poke, peek, plot, point - вот на этих командах ускорение должно быть гигантским.
вот давно пора наконец залезть в книжку с дизассемблером пзу и посмотреть, как они "ничего не делают"
тот же plot уже после вычисления операндов выполняться будет ~3600 тактов
из них ~2900 уходит на конвертацию координат из 5-байтной формы в однобайтовую
OrionExt
30.06.2017, 17:55
Тема. Это пять!
Почему моя утка, которая сдохла, была такая худая?
- - - Добавлено - - -
Вижу я. Форум для домохозяек пора открывать. Отголосок ZX-next=)
FPU не дает покоя всем
https://zx.itch.io/busra
да и народ одержим идеями и воплощает
https://zx.itch.io
чйорт побери (с)
OrionExt
30.06.2017, 18:57
FPU прикольная штука. Но Спектруму – это как мертвому припарка=)
Да ДМА припарка. Что уж тут делать?)
Ого. Вот и я втянулся в тему не о чем:v2_dizzy_indy:
- - - Добавлено - - -
Многие ZX пытались аппаратно эмулировать. В MSX он вписывается в виде одной платки. Это очень просто.
А Бейсик 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.
Фишка в том, что тот же RUN может использоваться как с параметром, так и без (по сути, он всегда с параметром, даже если его не задал пользователь). С остальными командами, аналогичная ситуация (тот же GO TO n может использоваться с явным числовым выражением, а может использоваться алгебраическая конструкция GO TO n+m, и даже, алгебраически-логическая GO TO n+(m AND a)+(o AND b).
Небольшой пример приведу на счёт с параметром и без параметра. Есть такая вроде бы функция BIN. Но это на самом деле не функция, это другое представление числа. После него так же идёт пятибайтная форма. И даже если BIN[/] без параметров то дальше идёт пятибайтный ноль. То есть не было проблем превратить команду без параметров в команду с параметрами на уровне редактора.
А вот теперь про выражения, тоже обращаю внимание: а как компилятор считает выражения?
Если мы возьмём современный оптимизирующий компилятор - то он оценит требуемый тип - целое, если в выражении все переменные целые - то он посчитает их без привлечения сопроцессора. Более того, современный компилятор умный, он может заметить, что "переменные" [B]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 работает работает намного быстрее бейсика, а ассемблер - ещё быстрее. Хотя казалось бы синус он и в Африке - синус. Да и калькулятор один и тот же (сопроцессор я не вставлял).
Значит основные тормоза давал интерпретатор, потому что арифметика во всех трёх случаях не менялась...
shurik-ua
17.07.2017, 09:59
но почему-то с Tobos FP работает работает намного быстрее бейсика
можно попробовать как-то то снять трассу выполнения интерпретируемой и компилированной программы - но подозреваю что под это надо ещё инструменты писать.
. Даже В.И.Ленин, который в 1918 отменил некоторые буквы, на букву 'ё' не покусился
Только это был не Ленин, а временное правительство. И не в 1918-м году, а в 1917-м. А вообще, данная реформа русского языка готовилась ещё при царе и людьми, далёкими от большевизма и революционной деятельности.
null_device
17.07.2017, 13:29
mmxdmv, вроде как tobos, использует свой калькулятор и формат хранения чисел ("Диалекты Spectrum-бейсика", изд. Питер).
Попутно, накладывается ограничение на некоторые операторов (где-то полностью, в других случаях, частично теряем ряд фукций операторов).
А если использовать целочисленные компилляторы, прирост скорости выполнения получается еще больше.
Lethargeek
17.07.2017, 15:38
Но насколько мне не изменяет память "пятибайтный" формат может специальным образом хранить целые в дополнительном коде
Соответственно, можно было десятком проверок пробежаться по команде PLOT 128,88 и вызвать PLOT_BC из ПЗУ
...что потребует радикально изменить формат хранимой бейсик-программы и потянет за собой дальнейшие переделки
Alex Rider
17.07.2017, 17:47
И получается разница совсем небольшая интерпретатор вызывает калькулятор или машинный код вызывает калькулятор.
Разница громадная, примерно как с парсером и без парсера. Интерпретатор обрабатывает дерево выражений, всегда проверяя синтаксис и тип значений. Компилятор уже знает порядок выражений и делает вызовы калькулятора подряд. Без проверки синтаксиса, типов выражений и много еще чего.
Лет 25 бы назад за такую книжку душу бы продал.
Вот и сейчас надо не лениться и почитать комментарии к интерпретатору (1b8a) и, возможно, калькулятору (335b) - это не "Война и мир" авось. И тут же найдутся ответы на все вопросы.
Нормальный Васик на Спектруме был. Когда быстродействия не хватало, но память свободная оставалась - тоже пользовался этим
https://en.wikipedia.org/wiki/ToBoS-FP
На фоне других Бейсиков - спекковский был нормальным компромиссом между точностью и скоростью вычислений (для 8-и битных машин). Кстати - автору темы можно попробовать ToBoS для своей программы - должно быть быстрее :)
NEO SPECTRUMAN
18.07.2017, 22:18
ToBoS-FP
это конечно хорошо
но по моему ему при этом самому нужно было находится в памяти в месте с скомпилированной программой
а еще была интересная возможность
скомпилировать и вызывать из другой бейсиковской программы
токо уже не помню как из этого тобоса возвращаться обратно
как то возвращался (может просто go to на адрес больший самого последнего?)
и бейсиковские адреса у обоих программ пересекались :v2_dizzy_turn:
не помню сохранялись ли переменные после этого :v2_conf2:
null_device
19.07.2017, 02:43
но по моему ему при этом самому нужно было находится в памяти в месте с скомпилированной программой
Правильно помните. Ему, как и почти всем, требовалось находиться в памяти при компиляции и работе скомпилированного блока.
Целочисленный MCoder2, Евдокимова в этом отношении был куда интересней.
как из этого тобоса возвращаться обратно
По команде оператора STOP. ЕМНИП, компиллятром она не воспринималась как конец программы.
NEO SPECTRUMAN
20.07.2017, 20:20
По команде оператора STOP. ЕМНИП, компиллятром она не воспринималась как конец программы.
интересно:v2_dizzy_step:
но я стоп никогда не юзал для этого
Недавно я делал сравнительный замер секундомером времини выполнения этой простой BASIC-программы в эмуляторе BBC Micro (BeebEm 4.14, эмуляция BBC Model B в реальном времени) и в эмуляторе UnrealSpeccy (эмуляция в 128 BASIC тоже в реальном времени).
10 FOR N=1 TO 50
20 LET A=COS (N)
30 NEXT N
40 PRINT A
Результат меня удручил: соответственно 1,7с и 3,2с, - не в пользу Спектрума.
SlashNet
03.03.2018, 10:18
Результат меня удручил: соответственно 1,7с и 3,2с, - не в пользу Спектрума.
На Энтерпрайзе ещё больше: ≈5с. (ещё в год анонса большинство рецензентов говорили, что бейсик тормозной)
MSX на Z80 посчитает за 4 сек (но у него точность выше), про Enterprise уже сказали. Вот Color Computer 2 на Motorolla 6809 справляется за 2 сек. и это при частоте меньше 1 MHz.
Мне кажется, именно выполнение самой команды, например, BORDER идёт очень быстро, а большую часть времени тратится на вычисление выражения. Разница по времени выполнения между BORDER 3 и BORDER x*2 довольно большая, что говорит в пользу этой версии. Да, наверное, можно было оптимизировать так, чтобы при наличии только одного явно указанного числа блок вычисления выражения не вызывался, а выдавалось это готовое число. Наверное, посчитали это бессмысленной оптимизацией на фоне остальных тормозов.
Barmaley_m
07.07.2018, 19:39
Бейсик не такой уж и медленный для своего времени. По сравнению с конкурентами (Apple ][, Atari, C64, MSX) работал весьма на уровне. РКшный бейсик был и того медленнее. Большинство этих бейсиков были токенизированные. Хотя и "прозрачно" для пользователя - тот не видел, что внутреннее представление программы имеет токены.
Я внимательно изучал дизассемблер ПЗУ. Конечно, большого упора на оптимизацию по скорости там не делалось, но и явных ляпов тоже нет (кроме, разве что, CIRCLE). По большей части, проводилась оптимизация по размеру кода. И тут важен не только объем доступного ПЗУ, но и ограниченность адресного пространства Z80. Если бы для бейсика потребовалось не 16, а 32К - то столько же было бы откушено от легкодоступного ОЗУ, либо пришлось бы переключать страницы. А это потребовало бы аппаратной логики, которая в те годы была на вес золота. Найденный разработчиками баланс оказался очень удачным, чему свидетельство - успех проекта. И провал последующих проектов (Sinclair QL), где "золотая середина" найдена не была.
Есть компилятор Laser Basic. Не знаю, как именно он работает; судя по звуку компилированных программ при записи на ленту, там как раз и идет преобразование в пи-код. По памяти впечатлений, которые я получил, когда игрался с этим компилятором 25 лет назад, ускорение было довольно существенным.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot