FPU

[shurik-ua]

Посмотрел недавно проекты FPU на opencores, и нашёл парочку которые можно былобы приспособить к Спектруму (ну или любой ретро платформе).
Поэтому решил сделать опрос, а надо ли заморачиваться, пришло ли время или идея будет не востребована для большинства.

В общем голосуем и делимся соображениями по сабжу.

[Tronix]

Я, как многим известно, ни разу не спектрумист, но все-таки выскажусь -) Имхо - FPU это костыль, каких поискать. Не спорю, может быть в расчете каких-то там аццких матанов с тройными интегралами типа симуляции магнетизма оно и помогает, но вот в обычной жизни, если ты не физик и не математик, то оно не нужно. Наоборот, всякие 3D кубики все всегда крутили с фиксед поинт и по таблицам, ибо на PC-платформе FPU был всегда тормозом вплоть до первых пней, да даже и на них тормозом был. Возможно что воз и ныне там, не знаю как щаз дела обстоят, не интересовался. Но правило одно знаю - можешь обойтись без FPU - обойдись, ибо в скорости выиграешь однозначно. Wolf - фиксед поинт, дум - фиксед поинт, дюк 3д - фиксед поинт, унреал реалити - фиксед поинт и таблицы и тд.

[goodboy]

и нашёл парочку которые можно былобы приспособить к Спектрумуа как планируешь передавать/получать данные/команды ?

[shurik-ua]

Wolf - фиксед поинт, дум - фиксед поинт, дюк 3д - фиксед поинт, унреал реалити - фиксед поинт и таблицы и тд.
ну им легче у них MUL DIV в проце, вполне возможно чтобы не заморачиваться с полноценным FPU для ретрокомпов хватит только аппаратных умножения и деления.


а как планируешь передавать/получать данные/команды ?
это обычно решается к концу разработки, когда что-то уже реализовано и написаны первые тесты - может игра и не стОит свечь, поэтому вопрос преждевременный.


Я за. Идея хорошая, и даже реализуема в песочнице за несколько вечеров. Только не для всех. ))) А SSE сможешь?
я тоже выбраз вариант ЗА - исходя из соображений что вычислять SQRT или SIN за 1-10 тактов - это ли не мечта любого 3D-писателя ). Насчёт SSE ничего не могу сказать, так как ничего почти не знаю о них.

[Alex Rider]

ну им легче у них MUL DIV в проце, вполне возможно чтобы не заморачиваться с полноценным FPU для ретрокомпов хватит только аппаратных умножения и деления.
Вроде, Mick такое сделал в Фениксе.

[balu_dark]

Самая кулл вещь на спеке это отнюдь не FPU!!!
Самая кульная вещь это обычный DMA 4 сортов - память память,память порт,порт память,порт порт. Вот это кул! реализации есть и в генерал саунде и на спец микросхеме в девайсе датагир.

[Mick]

Вроде, Mick такое сделал в Фениксе.

Нет, я не делал. Умножение делал caro в своей мультикарте. У Феникса просто она как бы на борту :)

[denpopov]

Дался вам этот FPU.

лукапы и CORDIC в зубы.

[Tronix]

ну им легче у них MUL DIV в проце, вполне возможно чтобы не заморачиваться с полноценным FPU для ретрокомпов хватит только аппаратных умножения и деления.

Эт да... Я чего-то забыл что в Z80 нет деления умножения....

[shurik-ua]

CORDIC в зубы
CORDIC будет в ПЛИС - нечего процу дурной работой заниматься )

Ещё есть соображения заменить софтовый калькулятор Бейсика на аппаратный и так как дизасм неплохо документирован и переведён даже - думаю это не составит особых трудностей.
Но судя по голосованию скепсиса всё же больше - пусть проголосуют человек 50 - тогда можно будет принимать какое-то решение.

Кстати для некоторых платформ указывают только показатель быстродействия для операций с плавающей точкой, поэтому говорить что FPU почти нигде не используется немного опрометчиво - имхо )

[Reobne]

пусть проголосуют человек 50
Допустим проголосуют 3 миллиона человек. Два миллиона скажут, что им FPU не нужен. Один миллион скажет, что им FPU нужен. Так не стоит ли ради целого миллиона людей FPU всё-таки сделать. Неужели этим будут ущемлены другие 2 миллиона голосовавших? ;)

[Alex Rider]

Ещё есть соображения заменить софтовый калькулятор Бейсика на аппаратный и так как дизасм неплохо документирован и переведён даже - думаю это не составит особых трудностей.
Трудностей-то не составит, вот только профит будет очень сомнительный. CIRCLE станет работать заметно быстрее, и всякие математические программы возможно тоже. Игры бейсиковские используют в основном целочисленные расчеты (и калькулятор складывает, вычитает и умножает их как целые числа), да и, вообще, за редким исключением, большую часть скорость жрет интерпретация. Опять же, а том же калькуляторе куча кода выполняется между rst #28 и точкой входа в процедуру расчета, равно как и после выхода из нее до возврата в вызывающую программу, от этого кода тоже не получится отказаться.

[Slesar]

FPU мало, нужен 3д акселератор.

[Viktor2312]

По моему, спектруму в чистом виде, уже ничего не нужно, он итак хорош.

А все эти прибамбасы, делают его уже не Спектрумом, по крайней мере, таким каким он был в 80-х, в детстве...

[zx_]

приольный FPU был сделан к БК, статья есть в журналах.

микросхема калькулятора 145 серии , и какие то фантастические результаты по умножению делению и тригонометрии

результат вычислений снимался с выводов м/с для индикатора

вот такую хрень для спектрума - супер , кмк

а есть современные на авр или пиках , и си библиотеками

но, если кто сделает с интеграцией влоть до бейсика , - конечно очень и очень

есть же программа эмулятор МК54 , программируемого калькулятора
http://trd.speccy.cz/sbor/MK54EMUL.ZIP
и есть вот это проект
https://code.google.com/p/emu145/

вот это все поженить и в меню 128

ну а чего
)
эфемериды считать

[Viktor2312]

Тогда уж лучше классику:

AM9511
AM9512
MM57109N

AMD_9511_FPU (https://yadi.sk/i/vgP1pWtFiuMN9)
Am9511A-9512FP_Processor_Manual (https://yadi.sk/i/NoQ3QzKjiuMWB)

[shurik-ua]

По моему, спектруму в чистом виде, уже ничего не нужно, он итак хорош.
с момента появления этого форума частота появления такого поста в любой теме равна 100% )

Тогда уж лучше классику:
AM9511
синус за 8000 тактов - нет, не пойдёт ))

но, если кто сделает с интеграцией влоть до бейсика , - конечно очень и очень
с Бейсиком можно особо не заморачиваться - так как FPU планируется для любых ретро компов, но если при ближайшем рассмотрении окажется что это можно будет реализовать малой кровью - то почему бы и нет )

вот немного чтива про стандарт который планирую использовать - http://habrahabr.ru/post/112953/

[Alex Rider]

с Бейсиком можно особо не заморачиваться - так как FPU планируется для любых ретро компов, но если при ближайшем рассмотрении окажется что это можно будет реализовать малой кровью - то почему бы и нет )
Получится малокровью, если:
1. FPU будет понимать оба Спектрумовских формата чисел. Чуть большим кровотечением обойдется патчинг только операций с вещественным форматом.
2. Кто-нибудь сделает поддержку в эмуле.

Только профита от этого будет немного. Еще профита можно получить, если FPU будет уметь быстро делать STR$.

[breeze]

Самая кульная вещь это обычный DMA 4 сортов

Казалось бы, причём тут TS-Conf :rolleyes:

[denpopov]

Казалось бы, причём тут TS-Conf

да, причем?

[Viktor2312]

причём тут TS-Conf

А что это?

---------- Post added at 17:56 ---------- Previous post was at 17:55 ----------


нет, не пойдёт ))

Нет, значит нет.

[Ewgeny7]

А мы сможем рулить орбитальной группировкой сразу после установки FPU?
Если нет, то - нафиг.

[Reobne]

Ewgeny7, Сможем!
Сразу же у нас появится эта возможность. Чтобы ей воспользоваться надо будет написать программку-симулятор. И в реальном времени, в виртуальном пространстве, с помощью клавиш OPQASp. :)

[Alex Rider]

А мы сможем рулить орбитальной группировкой сразу после установки FPU?
Сможем. Надо будет только Elite поправить :)

[troosh]

Теоретически сделать такой сопроцессор нет проблем. Практический проблем куча. Главная: наперкуа? Вот один товарищ хотел как-то:https://github.com/cheveron/sebasic4/wiki/X80-Math-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 пишет в память...

[shurik-ua]

Теоретически сделать такой сопроцессор нет проблем. Практический проблем куча. Главная: наперкуа? Вот один товарищ хотел как-то:https://github.com/cheveron/sebasic4...h-Co-processor Да воз ныне там...
Интересная статья - возьму на вооружение.


Раз тут обсуждаются концепты, то можно рассмотреть такие варианты:

Варианты конечно замысловатые, но заточены они под то что ПЗУ нельзя модифицировать, я же думал наоборот - изменить программную реализацию некоторых (далеко не всех) команд калькулятора аппаратной (реализацией).


к тебе встречное предложение - заняться разработкой FPU для uGFX.

да думал об этом, но тот вариант что я задумал займёт около 5к ЛЕ и наверное не влезет.

[shurik-ua]

на opencores.org мне приглянулись несколько проектов:
FPU - http://opencores.com/project,fpu100
Cordic - http://opencores.com/project,cf_cordic или http://opencores.com/project,verilog_cordic_core


На сколько эффективно и оправданно будет работать FPU в сравнении с параллельными вычислениями на трех NextZ80@42MHz и какие операции способно будет выполнять FPU?

думаю это будет работать намного быстрее если реализовать на "Конечном Автомате" - да и для n>1 процессоров писать софты весьма нетривиальная задача )

[troosh]

Варианты конечно замысловатые, но заточены они под то что ПЗУ нельзя модифицировать, я же думал наоборот - изменить программную реализацию некоторых (далеко не всех) команд калькулятора аппаратной (реализацией).


Возможно я не до конца понимаю в чём смысл делать свой FPU в FPGA, когда можно взять заметно более быстрый ARM из младших кортексов и на его асме сделать функции бит в бит по результату совпадающией с оригинальной реализацией на Z80 (когда есть эталон отладка милое дело, иначе ад). Либо взять Cortex-M4 уже с железным FPU, если плевать на точность... Но это я по себе сужу, если б я такое решил делать.

Или тут какая-то блокировка в сознании, что это уже не правильно осквернять z80 каким-то армецом (но avr на клавиатуру это норм)? Или пинов не хватает, - ну так я выше расписывал как их сэкономить...

Улучшать только тригиометрию не имет смысла, тем более такими экзотическими способами, главное чтоб были быстрые плюс и умножение. Разве что под какой-то конкретный алгоритм, например при текстурировании.

Раз зашла речь о NextZ80, то там можно сделать, чтоб на некотрых участках ROM, переставал отслеживаться тайминг как у оригинального Z80 (начинал работать на полной скорости), а далее добавлять инструкции R800, пока это не будет вредить совместимости другим программам (помню были защиты от реверса программ на спектруме, которые использовали множество недокументированных опкодов и безумное число префиксов - они сдохнут от изменения системы команд и ПЗУ).

[shurik-ua]

Возможно я не до конца понимаю в чём смысл делать свой FPU в FPGA, когда можно взять заметно более быстрый ARM из младших кортексов и на его асме сделать функции бит в бит по результату совпадающией с оригинальной реализацией на Z80
Просто платка с FPGA уже есть - под неё и пишу, а ARM ещё спаять надо )

Или тут какая-то блокировка в сознании, что это уже не правильно осквернять z80 каким-то армецом
нету никакой блокировки - с ARMами дела не имел просто - была б у меня платка с ARMом - на ней бы упражнялся ))

тоб на некотрых участках ROM, переставал отслеживаться тайминг как у оригинального Z80
там как бы изначально нет такой привязки - всё заточено на максимум скорости.
Но опять же повторюсь - на процессоре всё равно не сделать быстрее чем на конечном автомате в FPGA - разве что если процессор на 500+ МГц или ядер овердохрена )

[troosh]

там как бы изначально нет такой привязки - всё заточено на максимум скорости.
Но опять же повторюсь - на процессоре всё равно не сделать быстрее чем на конечном автомате в FPGA - разве что если процессор на 500+ МГц или ядер овердохрена )

Я имел ввиду, что для совместимости (с плёнки погрузить, мультиколор насладиться) можно сделать там режим когда тайминг у команд 3.5МГц, но на некоторых участках ПЗУ будет разгоняться...

На сложных проектах прототип на FPGA может быть медленнее раз в 100 того же верилога в кремнии (суже по тому, с чем реально сталкивался).

Много ядер не нужно - там своя специфика начинается, обычно на это идут когда одно ядра быстрее нет возможности сделать. Или нужен реалтаим и/или задачи независимы и хорошо параллеляться.

[ogura]

Я с большим трудом представляю себе, как можно обеспечь 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 прошивать.