Кстати, а есть ли тут требования к росту стека. Вверх или вниз?
А к следованию байтов?
Если стек растёт вниз, то удобней делать так, чтобы на вершине была младшая часть. Благодаря чему можно сразу использовать пересылку через mm-xxm или иное расширение процессора.

А превращать двойное в одинарное и наоборот можно при любом раскладе ( 'drop' or 'nip' )
Если верхушка стека есть регистр, то всё ещё лучше

Вот этого точно нету.

По порядку байтов вроде бы тоже нету. Но я напоролся при реализации Форта для 8-разрядного Атмел, что
5 SP@ @
у меня прочло не 5, а 0x500. Так-что придется подумать о перелопачивании. Короче, слово SP@ , которое присутствует в типовой реализации CATCH THROW в стандарте ANSI (хотя самого этого слова в наборе слов стандарта нет), скрытое требование на согласование слов ! @ и порядка байт в организации стека таки вводит. То есть фиксированного ограничения мол порядок байт тот или иной нет, но некоторое согласование разных мест Форт-системы требуется, если не хочется иметь вот такой смешной глюк.

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

Вот и интересуюсь, Как бы будущему себе грабли не вставить.

Думаю так. Вот пусть у нас число 0x11223344
Его в памяти можно хранить малым эндианом, как на IBM PC
44 33 22 11
Большим эндианом, как на всех процессорах от Моторолы, в общем как на Макинтоше
11 22 33 44
Вопрос - а какой эндиан для Форта будет родной ?
Пусть стек растет вниз ибо нам привычно и так делается аппаратно, пусть при хранении двойного целого в Форте на вершине стека старшая половинка ибо так принято, пусть мы очень хотим, чтобы С@ из ячейки cell читала ее младший байт, т.е. давала практически полезное и логичное усечение одинарного целого до байта. Тогда порядок байт напрашивается такой (рассматриваю случай 16-разрядного Форта) :
22 11 44 33
А такой был у PDP-11. Получается, что PDP-эндиан для Форта родной, а все остальные случаи будут так или иначе чуть-чуть да неудобны. Ну и пусть так. Я это воспринимаю как данность и не стал бы что-нибудь менять только из-за того, что мы сейчас в основном под Интелом сидим. К тому-же, как ни крути, а PDP-11 - архитектурный идеал.

Так были поползновения сделать стардарт Russian Forth, но я поставил в той ветке всех в тупик простым вопросом - нельзя писать, что 2/ это деление на 2, ибо 2/ это не то-же, что 2 /
-3 2/ .
-2 Ok
-3 2 / .
-1 Ok
И что-то обсуждение на этом заглохло.
В общем, создание стандарта, это гораздо более сложная вещь, чем создание удобной реализации под одну конкретную архитектуру. В таких вещах, как разница между делением с округлением по полу и симметричным делением, разными эндианами и прочая и прочая надо как в сору рыться. Делать все как оно само выходит под IBM PC тут явно недостаточно. И самое главное - не получается сделать заметно лучше, чем тот-же ANSI. В конце концов выходит в той или иной степени его повторение.

.....

Ветка этого обсуждения

причина в другом: недостаточная мотивация и отсутствие согласованных действий хотя бы трех человек 8(

Слушай, но тогда твоё "5 SP@ @ ." у меня не будет работать!(sorry) Да и процессор так не делает(из TD):

PUSH EAX

Так что как писал (разумеется не касается U/MOD), так и писать буду. А то путаешь тут меня

Есть даже пять, но авторство стандарта - это не медалька, чтобы вешать ее себе на шею и всем показывать. Эллочка-людоедка тоже хотела быть как дочь миллионера, а вылилось все в острую сатиру. Никто не против слова DUP. Многие против только того, что кто-то будет иметь право указывать, что в Форте правильно, а что нет, ссылаясь на им же самим придуманный "авторитетный" документ.

Да где-же путаю ? Говорю-же, что общепринято не так, а делай как хош.
Вот в SPF 4.22
HEX 1122334455667788. U. U.
11223344 55667788

По поводу затертого сообщения. Для себя делай с моим исходником что хошь, хоть во что его преврати и хоть где используй. А если хочется показывать и выкладывать, то показывай твои доработки Форта отдельно. Без моего исходника в комплекте.
Предположим, что перед строчкой
BOOT DW DECIMAL, _MAIN_
там инклудится файл с доработками. Вот например так.
Ну или доработки на языке Форт для докомпиляции, или готовые программы.
Короче, мой ассемблерный исходник не хотелось бы видеть "улучшенным" так,
что я в восторг не приду, а все остальное делай.

Ай! Опять забыл! Если что, реализуйте R> и >R лучше на ассемблере! Иначе это не оптимально(или ошибочно)...

Оп-на.
Приведика пример как реализовать примитивы >R и R> не на ассемблере.
Интересно стало.

OK.
Старый вариант:
: >R S@ DROP ; : R> R@ RDROP ;
Непраильно, т.к. забываю про адрес возврата(уж проще тогда использовать ассемблер!).

Можно и без ассма. Например, в SPF4 как-то так:

LOG


ps. Но надо разбираться в процессоре в части кодов инструкций и в форт-системе в части привязки ресурсов процессора к структурам данных форт-системы.