Вид для печати
Посмотрел недавно проекты FPU на opencores, и нашёл парочку которые можно былобы приспособить к Спектруму (ну или любой ретро платформе).
Поэтому решил сделать опрос, а надо ли заморачиваться, пришло ли время или идея будет не востребована для большинства.
В общем голосуем и делимся соображениями по сабжу.
Я, как многим известно, ни разу не спектрумист, но все-таки выскажусь -) Имхо - FPU это костыль, каких поискать. Не спорю, может быть в расчете каких-то там аццких матанов с тройными интегралами типа симуляции магнетизма оно и помогает, но вот в обычной жизни, если ты не физик и не математик, то оно не нужно. Наоборот, всякие 3D кубики все всегда крутили с фиксед поинт и по таблицам, ибо на PC-платформе FPU был всегда тормозом вплоть до первых пней, да даже и на них тормозом был. Возможно что воз и ныне там, не знаю как щаз дела обстоят, не интересовался. Но правило одно знаю - можешь обойтись без FPU - обойдись, ибо в скорости выиграешь однозначно. Wolf - фиксед поинт, дум - фиксед поинт, дюк 3д - фиксед поинт, унреал реалити - фиксед поинт и таблицы и тд.
а как планируешь передавать/получать данные/команды ?Цитата:
Сообщение от shurik-ua
ну им легче у них MUL DIV в проце, вполне возможно чтобы не заморачиваться с полноценным FPU для ретрокомпов хватит только аппаратных умножения и деления.Цитата:
Сообщение от Tronix
это обычно решается к концу разработки, когда что-то уже реализовано и написаны первые тесты - может игра и не стОит свечь, поэтому вопрос преждевременный.Цитата:
Сообщение от goodboy
я тоже выбраз вариант ЗА - исходя из соображений что вычислять SQRT или SIN за 1-10 тактов - это ли не мечта любого 3D-писателя ). Насчёт SSE ничего не могу сказать, так как ничего почти не знаю о них.Цитата:
Сообщение от MVV
Вроде, Mick такое сделал в Фениксе.Цитата:
Сообщение от shurik-ua
Самая кулл вещь на спеке это отнюдь не FPU!!!
Самая кульная вещь это обычный DMA 4 сортов - память память,память порт,порт память,порт порт. Вот это кул! реализации есть и в генерал саунде и на спец микросхеме в девайсе датагир.
Нет, я не делал. Умножение делал caro в своей мультикарте. У Феникса просто она как бы на борту :)Цитата:
Сообщение от Alex Rider
Дался вам этот FPU.
лукапы и CORDIC в зубы.
Эт да... Я чего-то забыл что в Z80 нет деления умножения....Цитата:
Сообщение от shurik-ua
CORDIC будет в ПЛИС - нечего процу дурной работой заниматься )Цитата:
Сообщение от denpopov
Ещё есть соображения заменить софтовый калькулятор Бейсика на аппаратный и так как дизасм неплохо документирован и переведён даже - думаю это не составит особых трудностей.
Но судя по голосованию скепсиса всё же больше - пусть проголосуют человек 50 - тогда можно будет принимать какое-то решение.
Кстати для некоторых платформ указывают только показатель быстродействия для операций с плавающей точкой, поэтому говорить что FPU почти нигде не используется немного опрометчиво - имхо )
Допустим проголосуют 3 миллиона человек. Два миллиона скажут, что им FPU не нужен. Один миллион скажет, что им FPU нужен. Так не стоит ли ради целого миллиона людей FPU всё-таки сделать. Неужели этим будут ущемлены другие 2 миллиона голосовавших? ;)Цитата:
Сообщение от shurik-ua
Трудностей-то не составит, вот только профит будет очень сомнительный. CIRCLE станет работать заметно быстрее, и всякие математические программы возможно тоже. Игры бейсиковские используют в основном целочисленные расчеты (и калькулятор складывает, вычитает и умножает их как целые числа), да и, вообще, за редким исключением, большую часть скорость жрет интерпретация. Опять же, а том же калькуляторе куча кода выполняется между rst #28 и точкой входа в процедуру расчета, равно как и после выхода из нее до возврата в вызывающую программу, от этого кода тоже не получится отказаться.Цитата:
Сообщение от shurik-ua
FPU мало, нужен 3д акселератор.
По моему, спектруму в чистом виде, уже ничего не нужно, он итак хорош.
А все эти прибамбасы, делают его уже не Спектрумом, по крайней мере, таким каким он был в 80-х, в детстве...
приольный FPU был сделан к БК, статья есть в журналах.
микросхема калькулятора 145 серии , и какие то фантастические результаты по умножению делению и тригонометрии
результат вычислений снимался с выводов м/с для индикатора
вот такую хрень для спектрума - супер , кмк
а есть современные на авр или пиках , и си библиотеками
но, если кто сделает с интеграцией влоть до бейсика , - конечно очень и очень
есть же программа эмулятор МК54 , программируемого калькулятора
http://trd.speccy.cz/sbor/MK54EMUL.ZIP
и есть вот это проект
https://code.google.com/p/emu145/
вот это все поженить и в меню 128
ну а чего
)
эфемериды считать
Тогда уж лучше классику:
AM9511
AM9512
MM57109N
AMD_9511_FPU
Am9511A-9512FP_Processor_Manual
с момента появления этого форума частота появления такого поста в любой теме равна 100% )Цитата:
Сообщение от Viktor2312
синус за 8000 тактов - нет, не пойдёт ))Цитата:
Сообщение от Viktor2312
с Бейсиком можно особо не заморачиваться - так как FPU планируется для любых ретро компов, но если при ближайшем рассмотрении окажется что это можно будет реализовать малой кровью - то почему бы и нет )Цитата:
Сообщение от zx_
вот немного чтива про стандарт который планирую использовать - http://habrahabr.ru/post/112953/
Получится малокровью, если:Цитата:
Сообщение от shurik-ua
1. FPU будет понимать оба Спектрумовских формата чисел. Чуть большим кровотечением обойдется патчинг только операций с вещественным форматом.
2. Кто-нибудь сделает поддержку в эмуле.
Только профита от этого будет немного. Еще профита можно получить, если FPU будет уметь быстро делать STR$.
Казалось бы, причём тут TS-Conf :rolleyes:Цитата:
Сообщение от balu_dark
да, причем?Цитата:
Сообщение от breeze
А что это?Цитата:
Сообщение от breeze
---------- Post added at 17:56 ---------- Previous post was at 17:55 ----------
Нет, значит нет.Цитата:
Сообщение от shurik-ua
А мы сможем рулить орбитальной группировкой сразу после установки FPU?
Если нет, то - нафиг.
Ewgeny7, Сможем!
Сразу же у нас появится эта возможность. Чтобы ей воспользоваться надо будет написать программку-симулятор. И в реальном времени, в виртуальном пространстве, с помощью клавиш OPQASp. :)
Сможем. Надо будет только Elite поправить :)Цитата:
Сообщение от Ewgeny7
Теоретически сделать такой сопроцессор нет проблем. Практический проблем куча. Главная: наперкуа? Вот один товарищ хотел как-то:https://github.com/cheveron/sebasic4...h-Co-processor Да воз ныне там...
---------
Раз тут обсуждаются концепты, то можно рассмотреть такие варианты:
0) Т.к. эмулятор бейсиковского калькулятора всё равно нужно сначала написать хотя бы в виде прототипа, то для начала стоит сделать как доработку какого-либо ZX эмулятора. Причем, для отладки очень удобно делать снапшот системной памяти и регистров Z80 как на входе по адресу 0x38, так и на всех возможных выходах из калькулятора. Там собираем кучу примеров для эмулятора калькулятора и долго и муторно добиваемся, что наша реализация на Си или asm другого процессора будет давать точно такой же результат (такую же разницу в снапшотах)..
1) Замена Z80 своей реализацией на FPGA (пропускаем совсем дорого).
2) Замена Z80 своей реализацией на каком-нибудь ARM микроконтроллере + CPLD для реализации интерфейса с остальной системой (PSoC 4 тут как бы должен хорошо подойти). На ARM крутиться эмулятор Z80, при попадании адрес 0x38 переключаемся встроенный в ARM программный эмулятор спектрумовской плавучки.
3) Тот же ARM+CPLD устанавливаем между системой и реальным Z80, пока не дошли до выборки команды из 0x38 прозрачно работает только Z80, а иначе вместо кода, который считал бы Z80 из ПЗУ, ему подкидывает ARM несколько инструкций которые позволяют считать требуемый контекст Z80 (значения его регистров).
Потом, пока ARM вычитывает калькуляторные инструкции и сам непосредственно работает с системой памятью, а в это время Z80 получает постоянно инструкцию перехода на и инструкцию назад и таким образом дожидается пока калькулятор в ARM отработает (ес-но Z80 при этом не гадит на системной шине). Результаты (значение), которые нужно прописать в регистр Z80, выполняются подсовыванием соответствующих инструкций в Z80 до того, как ему отправят RET, чтоб он вернулся на место где был вызов калькулятора после того как его снова подключат в систему.
4) Вариант предыдущего пункта, но стоим не между процессором Z80 и системой, а сбоку, как ПЗУ (аля TR-DOS) или DMA устройство. Слушаем шину, встретили выборку инструкции по 38h, - начинаем пихать свои инструкции, а не то, что в ПЗУ. Опять же вычитываем контекст, а далее либо отправляем Z80 в короткий сон, а само через DMA получаем, всё что нам нужно, либо периодически отправляем нужные инструкции, что за нас Z80 что-то из памяти прочитал, либо записал. В пределе такой устройство вообще можно подключить вместо ПЗУ без дополнительных проводов (только оно не будет знать, что это именно началась выборка команды, а не простое чтение), кроме того не будет работать в системах, где у шина данных ПЗУ не подключена напрямую к процессору и нет возможности со стороны ПЗУ считать записи в ПЗУ... oops, не без дополнительных проводов не получиться - нужно понимать, что Z80 пишет в память...
Интересная статья - возьму на вооружение.Цитата:
Сообщение от troosh
Варианты конечно замысловатые, но заточены они под то что ПЗУ нельзя модифицировать, я же думал наоборот - изменить программную реализацию некоторых (далеко не всех) команд калькулятора аппаратной (реализацией).Цитата:
Сообщение от troosh
да думал об этом, но тот вариант что я задумал займёт около 5к ЛЕ и наверное не влезет.Цитата:
Сообщение от MVV
на opencores.org мне приглянулись несколько проектов:
FPU - http://opencores.com/project,fpu100
Cordic - http://opencores.com/project,cf_cordic или http://opencores.com/project,verilog_cordic_core
думаю это будет работать намного быстрее если реализовать на "Конечном Автомате" - да и для n>1 процессоров писать софты весьма нетривиальная задача )Цитата:
Сообщение от MVV
Возможно я не до конца понимаю в чём смысл делать свой FPU в FPGA, когда можно взять заметно более быстрый ARM из младших кортексов и на его асме сделать функции бит в бит по результату совпадающией с оригинальной реализацией на Z80 (когда есть эталон отладка милое дело, иначе ад). Либо взять Cortex-M4 уже с железным FPU, если плевать на точность... Но это я по себе сужу, если б я такое решил делать.Цитата:
Сообщение от shurik-ua
Или тут какая-то блокировка в сознании, что это уже не правильно осквернять z80 каким-то армецом (но avr на клавиатуру это норм)? Или пинов не хватает, - ну так я выше расписывал как их сэкономить...
Улучшать только тригиометрию не имет смысла, тем более такими экзотическими способами, главное чтоб были быстрые плюс и умножение. Разве что под какой-то конкретный алгоритм, например при текстурировании.
Раз зашла речь о NextZ80, то там можно сделать, чтоб на некотрых участках ROM, переставал отслеживаться тайминг как у оригинального Z80 (начинал работать на полной скорости), а далее добавлять инструкции R800, пока это не будет вредить совместимости другим программам (помню были защиты от реверса программ на спектруме, которые использовали множество недокументированных опкодов и безумное число префиксов - они сдохнут от изменения системы команд и ПЗУ).
Просто платка с FPGA уже есть - под неё и пишу, а ARM ещё спаять надо )Цитата:
Сообщение от troosh
нету никакой блокировки - с ARMами дела не имел просто - была б у меня платка с ARMом - на ней бы упражнялся ))Цитата:
Сообщение от troosh
там как бы изначально нет такой привязки - всё заточено на максимум скорости.Цитата:
Сообщение от troosh
Но опять же повторюсь - на процессоре всё равно не сделать быстрее чем на конечном автомате в FPGA - разве что если процессор на 500+ МГц или ядер овердохрена )
Я имел ввиду, что для совместимости (с плёнки погрузить, мультиколор насладиться) можно сделать там режим когда тайминг у команд 3.5МГц, но на некоторых участках ПЗУ будет разгоняться...Цитата:
Сообщение от shurik-ua
На сложных проектах прототип на FPGA может быть медленнее раз в 100 того же верилога в кремнии (суже по тому, с чем реально сталкивался).
Много ядер не нужно - там своя специфика начинается, обычно на это идут когда одно ядра быстрее нет возможности сделать. Или нужен реалтаим и/или задачи независимы и хорошо параллеляться.
Я с большим трудом представляю себе, как можно обеспечь FPU на Спектруме, процессор реально работает с 8-битными данными. Тогда FPU придется либо быть 8-битным либо FPU должен ждать пока дынные поспеют. Я как не крутил 8 битный FP, если даже взять 5:3 то это всего лишь -4096..4095 и те с промежутками, куда такой диапазон чисел приложить? Легче тогда просто с 16 битными работать. Если взять FP 16 бит Или при задержке шины удобнее работать с ними отдельно считая каждый байт как порядок и число 8:8, обычными инструкциями. Единственное что инструкции приведения к общему так сказать множителю.
Для того не нужен отдельные большие поля ALU, и набор отдельных инструкций.
Например число G надо сложить с Q. Каждое из них задано двумя байтами, один целое число другой порядок множителя. Чтобы их складывать мы должны знать на сколько каждое надо сдвинуть. Вычитаем порядок множителя Q из порядка множителя G. Если результат положительный целая часть Q сдвигается на разницу, а порядок результата пишется из G, если отрицательный то инвертируется и на полученное число сдвигается целая часть G, а в порядок результата пишется оный с Q. Потом они суммируются и соответственно. Но если случилось переполнение то надо прибавить еще единичку к порядку а результат сдвинуть вниз. При вычитании на оборот. Как минимум тут 2 ветвления и сдвиг в цикле. Если бы их как-то можно было заменить оба ветвления какими-то инструкциями то FP арифметика пошла бы как по маслу. Например если G Q содержится в BC и DE соответственно, то одной инструкцией чтобы можно было найти на сколько сдвигать и который или например сдвигается регистр B если число положительное и регистр D если число отрицательное. И чтобы была классная инструкция выбора большего из двух регистров. Потом по факту если переполнение или заем. То корректировался скажем HL соответствующим образом.
Пускай такая арифметика в отдельных случаях теряет один бит, все равно просто и эффективно.
Насчет умножения и деления то вопрос риторический, и с плавающей арифметикой не намного отличается от с не плавающие. Главное перемножить, а то потом суммируется порядки множителей и подгоняются под количество ведущих нулей, да и все. Хотя их тоже можно подравнять под порядок результата, отдельной инструкцией.
И того надо то же ALU, плюс несколько дополнительных просто реализуемых инструкций.
Если я нигде не "провтыкал" то получается вот такой диапазон.
{[-1048576...0.000244141];0;[+0.000244141 ...1048575]}.
Пускай и хиленькая в общем но какие эффекты можно было бы соорудить и пускай худо бедно но инженерные расчет и анализ переходных процессов можно было бы смастерить.
Но вопрос- ЗАЧЕМ на сегодняшний то день?
Можно конвенциально считать некоторые числа в 32 бита ARMа деленными на скажем на 4096 их можно даже отдельным типом назвать, а потом преобразовывать определенными процедурами или макроопределениям если шибко надо.
{[-524288...0.000244141];0;[+0.000244141 ...524287]}
И получаем диапазон по шире, а ARMы и с FPU бывают, сколько бы он не стоял все равно дешевле чем на FPGA прошивать.