Вообще сопроцессор внутри всегда работает с 80-битными числами. Это внутренний формат comp, который в целом можно выгрузить в память, но обычно так не делают. Форматы 32 и 64 бит появляются только в моменты загрузки на сопроцессор и записи в память и определяют внутренние правила преобразования. Если речь идет о преобразовании целого числа в число с плавающей точкой, то результатом все равно будет comp. Если использовать именно стек сопроцессора и не делать его эмуляцию в памяти, то смысла в преобразованиях нет - сопроцессор всегда считает одинаково, а загружает числа в соответствии с их разрядностью в памяти. При этом числа с плавающей точкой обычно явно выбираются в процессе анализа математики, потому что речь в первую очередь о динамическом диапазоне значений. Нет ничего необычного в 32-битной целочисленной системе, которая адресует 64-битные числа с плавающей точкой. На целочисленном стеке адреса, которые указывают на данные в памяти. Наоборот тоже можно.

Вам виднее конечно.
С другой стороны я рассматривают больше вопрос портируемости.

Легче иметь на двух разрядностях одни и те же слова типа >F F> int>F F>int
чем весь спектр редкоиспользуемых вида
D>F FD> S>F S>F и пр.

Ну вот какой забор числа двойной длинны на стек с плав. точкой, если размер ячейки 8 байт?

А то как вычисляет сопроцессор, я не лезу.
Вычисляет в 80-битном формате ну и отлично, а на стек данных пусть переносит в зависимости от основной разрядности

Думаю, это не совсем правильно, поскольку данные могут исходно представляться в определенном формате. Сопроцессор работает со всеми форматами, включая 80-битный, так что не давать ему какие-то числа немного странно. Опять же, динамический диапазон значений определяется задачей, у 32- и 64-битных чисел очень уж разный "машинный ноль", поэтому 32 бита могут в определенных численных алгоритмах просто не подойти.

Помню в целях портируемости, хе-хе, решил отказаться от слов которые работают, со стеком плав. точки в зависимости от разрядности.
Чтобы не было гемора с переносом кода
Так на 32-битном интеле данные переносятся на стек плав. точки только в виде 32-битных чисел.
А на 64-битном интеле, в свою очередь, будут приниматься только 64-битные числа.

Зато слов меньше переписывать

Где-то да. В одном из форт-процессоров удалось уложиться в 32 опкода, с добавлением структур управления (которые так или иначе сводились к условным переходам, т.е. на нескольких командах процессора "выращивались" слова Форта) получалось как раз около 40-50 слов. Можно добавить вспомогательные слова, и варианты базовых, например, от @ "отпочковывается" целый набор C@ W@ D@ Q@ (а с плавающей точкой еще F@ SF@).

Ну кросплатформенность можно обеспечить переписью примитивов под каждую архитектуру)
Желательно конечно, чтобы этих примитивов было как можно меньше.

Вот думаю сейчас ради интереса
Получилось 45 простых примитивов
и 3 компилирующих слова ( RET, COMPILE, LIT, )

Итого 49 вполне терпимо, как по мне.

И еще остается реализация доступа ко внешним функциям.

Да, вариант Форт-машины, управляющей порядком запуска библиотечных функций вполне неплох.

Начавшийся в 90-е годы спад Форта привел к попыткам "играть по старым правилам", откуда и возникали призывы писать очень производительные или очень надежные реализации. Дескать, сейчас напишем, все восхитятся и сразу бросятся учить Форт, забросив остальные языки. Сейчас можно видеть, что попытки сделать "самый-самый" язык программирования изначально провальны. Собственно, и "священные войны" по этому поводу существенно снизили свой накал. Сейчас многие программисты вполне разумно скажут, что разные языки нужны для разных задач. Главное, понимать, что именно требуется и как можно применить освоенные инструменты.

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

Так по моему сейчас вполне распространен варианты запуска вроде шитого кода.. там ява, питон...
Производительность компов позволяет.. да и телефоны/планшеты тоже следом идут. А возможность выпустить под несколько платформ (например управляющую каким либо оборудованием программу) расширяет применяемость. А многие расчеты сейчас делают внешние библиотеки.. и управляющее по к ним отношения имеет довольно слабое.

Список слов Форта, которые в целом понятны всем и не вызывают возражений - где-то 40-50 слов. Возможно, чуть больше, если взять еще версии для чисел с плавающей точкой, двойной длины и т.п. По сути, там DUP DROP OVER SWAP ROT @ ! + - AND (и прочая математика) CREATE DOES> VARIABLE CONSTANT IF ELSE THEN DO I LOOP WHILE REPEAT BEGIN UNTIL - вот примерно подобного уровня. Но дальше уже начинается интереснее, потому что разные реализации по-разному относятся к интерфейсам. Где-то консоль, где-то воспроизводится GUI, начинаются ОС-зависимые вещи. Наконец, видеть вылезающее окно со строками копирайта и приглашением ввести слова для интерпретации файла (интереснее, если обязательно руками в консоль) - это годится только ввести 2 2 + и убедиться, что получилось 4.

Поэтому глобальных стратегии на переносимый код видится две. Или долго думать над слоем абстрагирования от платформы и тщательно проверять, что все одинаково работает под Windows/Linux (Android? IOS?), или наоборот, резко уменьшить размер и функциональность переносимого ядра и отдать реализацию GUI и прочих интерфейсов инструментам реализации верхнего уровня, оставляя Форту внутреннюю машину.

Не совсем понял. Можно же зафиксировать структуру слов и стиль использования для конкретного проекта/приложения/предметной области. Или имелось ввиду что-то другое?

Кроссплатформенность чего-то стоит. Существуют два подхода.
1. Форт сам по себе воспринимается как уровень абстрагирования. Недостатком является достаточно размытая структура слов и множество стилей использования Форта.
2. Шитый код в основе и язык высокого уровня для описания практически всех слов. Для переноса между платформами понадобится еще какой-то "общий знаменатель" для системных вызовов, интерфейса и пр., поэтому придется чем-то поступаться.

вот, нужно что-то чтобы при переходе между разными системами, не приходилось сильно перетряхивать код

Главное, что выбор средств разработки не так сильно сужается.

С переходом Эппл на свой собственный арм выбор форта для лаптопа или десктопа ещё больше сужается.

Хм, вроде во всех отечественных есть такой функционал
Про заграницу не знаю)