С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Даже если бы бейсик стал в три раза быстрее, что это улучшило бы? Игры бы на нём писать всё равно бы не начали, т.к. без спрайтового двигла это неудобно. А выводить спрайты руками через переопределяемые на лету UDG по сложности уже недалеко от использования Си и чуреры.
Он и твёрдый знак он почему-то пощадил. И очень зря.
Ну то Пётр. Был бы Семён, то увидев, что написали в загранпаспорте, очень бы расстроился.
Граф Дракула наш кумир, патамушта он вомпир!
VKINK 9 : BORDER NOT PI
Прошу прощение за своё косноязычие. Имелось в виду время создания спектрума.
Разумеется, начиная года с 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 буквы получается - круглое число
- - - Добавлено - - -
Фиг знает. На самом деле грамотность надо пропагандировать хлеще здорового образа жизни.
И так страна деградирует. Тем более, на этом форуме школоты не бывает.
В общем, обещаю читать то что пишу, и дебильных вырвиглазных ошибок постараюсь больше не делать.
Прихожу без разрешения, сею смерть и разрушение...
Тема. Это пять!
Почему моя утка, которая сдохла, была такая худая?
- - - Добавлено - - -
Вижу я. Форум для домохозяек пора открывать. Отголосок ZX-next=)
Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2, Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...
FPU не дает покоя всем
https://zx.itch.io/busra
да и народ одержим идеями и воплощает
https://zx.itch.io
чйорт побери (с)
FPU прикольная штука. Но Спектруму – это как мертвому припарка=)
Да ДМА припарка. Что уж тут делать?)
Ого. Вот и я втянулся в тему не о чем
- - - Добавлено - - -
Многие ZX пытались аппаратно эмулировать. В MSX он вписывается в виде одной платки. Это очень просто.
А Бейсик Zx, что бейсик. Я его на Орионе запускал, прикольная штука
Последний раз редактировалось OrionExt; 30.06.2017 в 18:44.
Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2, Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...
еще всяко плавающее
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.
Последний раз редактировалось zx_; 30.06.2017 в 21:48.
Небольшой пример приведу на счёт с параметром и без параметра. Есть такая вроде бы функция 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 работает работает намного быстрее бейсика, а ассемблер - ещё быстрее. Хотя казалось бы синус он и в Африке - синус. Да и калькулятор один и тот же (сопроцессор я не вставлял).
Значит основные тормоза давал интерпретатор, потому что арифметика во всех трёх случаях не менялась...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)