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