При этом получив кучу проблем "совместимости" старого софта, использующего точки входа подпрограмм ПЗУ, ряда программ проверяющих "целостность" ПЗУ или тех, где используется IM2 и вектор "лежит" в ПЗУ.Сообщение от mmxdmv
При этом получив кучу проблем "совместимости" старого софта, использующего точки входа подпрограмм ПЗУ, ряда программ проверяющих "целостность" ПЗУ или тех, где используется IM2 и вектор "лежит" в ПЗУ.
Когда есть, но не знаешь где - это все равно, что нету.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Такое происходит при использовании любого ЯВУ.
Можно вырубить себе дом в скале, или построить конуру из ж\б блоков. Именно этим и приходится платить за то, чтобы не держать в голове адреса подпрограмм ПЗУ (те же команды работающие с магнитной лентой, явно стоят того, чтобы не заниматься эквилибристикой с ассемблером) и использовать "универсальные" конструкции типа арифметических и логических значений в одних и тех же операторах. Именно поэтому компилляторы имеют граниченный список операторов которые они могут "переварить" в набор маш. процедур.
- - - Добавлено - - -
Фишка в том, что тот же RUN может использоваться как с параметром, так и без (по сути, он всегда с параметром, даже если его не задал пользователь). С остальными командами, аналогичная ситуация (тот же GO TO n может использоваться с явным числовым выражением, а может использоваться алгебраическая конструкция GO TO n+m, и даже, алгебраически-логическая GO TO n+(m AND a)+(o AND b).
Когда есть, но не знаешь где - это все равно, что нету.
vlad-kras(16.11.2023)
Небольшой пример приведу на счёт с параметром и без параметра. Есть такая вроде бы функция BIN. Но это на самом деле не функция, это другое представление числа. После него так же идёт пятибайтная форма. И даже если [B]BIN[/] без параметров то дальше идёт пятибайтный ноль. То есть не было проблем превратить команду без параметров в команду с параметрами на уровне редактора.
А вот теперь про выражения, тоже обращаю внимание: а как компилятор считает выражения?
Если мы возьмём современный оптимизирующий компилятор - то он оценит требуемый тип - целое, если в выражении все переменные целые - то он посчитает их без привлечения сопроцессора. Более того, современный компилятор умный, он может заметить, что "переменные" n и m на самом деле константы (задаются один раз в программе, либо однозначно задаются недалеко от места их использования)... поэтому в некоторых случаях оптимизирующий компилятор заменит выражения на их значение.
Но разговор-то про примитивный компилятор. Который ничего не придумывает за программиста, а тупо выполняет.
Соответственно "скомпилированная" программа также будет считать выражения. И интерпретатор считает и компилятор считает - получается разница не слишком большая...
- - - Добавлено - - -
Лет 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 работает работает намного быстрее бейсика, а ассемблер - ещё быстрее. Хотя казалось бы синус он и в Африке - синус. Да и калькулятор один и тот же (сопроцессор я не вставлял).
Значит основные тормоза давал интерпретатор, потому что арифметика во всех трёх случаях не менялась...
можно попробовать как-то то снять трассу выполнения интерпретируемой и компилированной программы - но подозреваю что под это надо ещё инструменты писать.
mmxdmv, вроде как tobos, использует свой калькулятор и формат хранения чисел ("Диалекты Spectrum-бейсика", изд. Питер).
Попутно, накладывается ограничение на некоторые операторов (где-то полностью, в других случаях, частично теряем ряд фукций операторов).
А если использовать целочисленные компилляторы, прирост скорости выполнения получается еще больше.
Последний раз редактировалось null_device; 17.07.2017 в 17:39.
Когда есть, но не знаешь где - это все равно, что нету.
Разница громадная, примерно как с парсером и без парсера. Интерпретатор обрабатывает дерево выражений, всегда проверяя синтаксис и тип значений. Компилятор уже знает порядок выражений и делает вызовы калькулятора подряд. Без проверки синтаксиса, типов выражений и много еще чего.
Вот и сейчас надо не лениться и почитать комментарии к интерпретатору (1b8a) и, возможно, калькулятору (335b) - это не "Война и мир" авось. И тут же найдутся ответы на все вопросы.
ZX Evolution Rev C + ZXM-SoundCard Extreme + NeoGS.
Прошу прощение за своё косноязычие. Имелось в виду время создания спектрума.
Разумеется, начиная года с 83-84 правки в ПЗУ вносить уже было бессмысленно.
- - - Добавлено - - -
Ну не совсем обычный. Пятибайтовый. "Обычный" - это 4 байта в одинарной точности и 8 байт - в двойной.
С FPU лучше не заморачиваться по другой причине. Спектрум - дитя своего времени. Сейчас он используется только для вау-эффекта: смотри какую демку я замутил - всего килобайт, а круче 50 мегабайтной игрульки у тебя на телефоне и даже без рекламы.
Поэтому если тебе нужны вычисления, то выбираешь по нарастающей - ардуину, STM, малинку, атом, i7, xeon; считаешь на видюхах, уходишь в распределённые вычисления и облака...
А к Z80 привязать сопроцессор с FPU - это дорого, несовместимо и непонятно зачем. Как к луку самонаводящиеся стрелы делать. Оно может будет прикольно, но пулемёт с несколькими ящиками патронов круче и дешевле.
Ну и на Z80 вычисления не ведутся, потому что нафиг не надо: даже в 3д играх легче заранее отабличить несколько синусов-косинусов и сделать поворот не на произвольный, а на фиксированный угол. В большинстве случаев поворот меньше чем на 1 градус не нужен, а таблицу синусов на 90 градусов составить - нефиг делать. Можно и косинусы по этой же таблице считать. Тоже самое и с корнями: проще ограничить мир определённой точностью и не нужны будут эти числодробилки.
Если ты всё же впаяешь в спектрум ту же малинку, которая будет считать плавучку...
То внезапно сразу ой. Придётся как-то передавать данные из Z80 в малинку и обратно.
Если повесишь на порты ввода-вывода, то простое умножение это десять байт в одну сторону и 5 байт в другую. Плюс квитирование, плюс коды операций. В не самом плохом случае тактов 30 на один байт получится - 400-500 тактов на операцию. Если хочешь быстрее - то нужна будет эмуляция: процессору скармливаешь команды NOP, а сам внешней схемой читаешь память и делаешь что надо. Но тут вылезают конфликты с ULA и прочая катавасия... Проще уж на одной малинке считать, без спектрума. И быстрее, и дешевле, и точнее, и нервов меньше потратишь.
- - - Добавлено - - -
Позор на мои седины. Писалось ночью и с радиоклавиатуры. Может сам промахнулся, а может и не пропечаталось.
Попрошу исправить обязательно.
По поводу других ошибок - тут даже не ошибки, а описки. Сделал масштаб 200% - может так разгляжу свои непотребности.
- - - Добавлено - - -
Под ускорением тут подразумевалось немного другое.
Вот смотрите: есть сама программа, полезный код. Например команды CLS: CIRCLE
Если заменить на машинный код CALL CSL: CALL CIRCLE - то получим ускорение на сколько там я тактов писал в начале? 10 тысяч?
Ну пусть я неправильно измерил и реально на две команды получим ускорение в 15 тысяч тактов.
А сколько выполняется CLS? Наверное все 200 тысяч, а для CIRCLE вообще миллионы тактов потребуются. Следовательно в этом конкретном случае 15 тысяч делим на миллионы - и получаем ускорение даже не на десятые доли процента...
Но вот для команд, которые "ничего не делают", такие как border, ink, paper, in, out, poke, peek, plot, point - вот на этих командах ускорение должно быть гигантским. Так что ускорение сильно зависит от структуры команд. Если изменится время исполнения команд BEEP и SAVE/LOAD - то это всё, тушите свет.
- - - Добавлено - - -
Букву Ё оставили для симметрии. Очень уж прекрасно она ложится в алфавит - 5 гласных обычных и 5 гласных - им в пару йотированных.
А вот про твёрдый знак солидарен. И не потому что его писать не умею, но потому что без него в алфавите 32 буквы получается - круглое число
- - - Добавлено - - -
Фиг знает. На самом деле грамотность надо пропагандировать хлеще здорового образа жизни.
И так страна деградирует. Тем более, на этом форуме школоты не бывает.
В общем, обещаю читать то что пишу, и дебильных вырвиглазных ошибок постараюсь больше не делать.
вот давно пора наконец залезть в книжку с дизассемблером пзу и посмотреть, как они "ничего не делают"
тот же plot уже после вычисления операндов выполняться будет ~3600 тактов
из них ~2900 уходит на конвертацию координат из 5-байтной формы в однобайтовую
Прихожу без разрешения, сею смерть и разрушение...
Пруф? Приведите пример кода ПЗУ, который специально замедляет бейсик? А иначе это утверждение основано только на ваших абстрактных соображениях.
Даже если бы вы сказали "Я вот тут слегка переделал код ПЗУ, бейсик теперь летает", это ещё не было бы доказательством того, что разработчики специально замедлили бейсик. Но, по крайней мере, было бы доказательством того, что в принципе возможно написать Бейсик с той же функциональностью попроизводительнее.
mmxdmv, я уверен, что разработчики не специально замедлили бейсик. Просто у них была задача, были требования и сжатые сроки, как это всегда бывает при коммерческой разработке. Если бы они приняли другие решения, вместо тех, которые положены в основу ROM-Basic (например, не медленное пятибайтовое представление вещественных чисел, а более быстрое четырёхбайтовое). Но ещё не будем забывать, что Z80 проц медленный, а бейсик из ПЗУ - интерпретатор. В любом случае, достоинство у этого бейсика одно - он помещается в ПЗУ, больше достоинств особо нет. Кроме ностальгии ;-)
- - - Добавлено - - -
Последняя сентенция - про то, что сегодня нет никаких причин разрабатывать на бейсике, кроме ностальгии.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
