Например давать ли программе доступ к стеку возвратов

Да, это нужно, поддерживаю forth@km.ru,

Но нельзя ли хоть самые общие элементы схемы этой ахитектуры предложить

Для совместимости лучше давать. Только какое отношение имеет ВМ к ОС ?

>R R@ R> однозначно давать.
Остальное - DEPTH и прямой доступ - можно обсуждать.
DEPTH хотелось бы, но не обязательно.
Прямой доступ лучше не давать для лучшей совместимости... Но если надо, делать и описать обоснование, почему пришлось и что без этого не работало!

Отлаживать алгоритмы проще!

У набора команд есть несколько вариантов:
Мне нравятся:

• Набор Мура, 27 команд, но он не полный...
• 4 битный процессор, но я бы добавил префиксы по-другому. Хотя, по-хорошему, набор команд надо подгонять к программам, а их надо сначала иметь... Замкнутый круг... Поэтом сначала подойдет любое решение. Потом пересмотрим и сделаем хорошо!
• F:) RTH от forth@km.ru, я правильно его написал?

Можно выбирать...

Но по-любому - сначала программы - потом подгонка набора команд...
Желательно второй шаг держать в уме и не заморачиваться с чрезмерной оптимизацией...
И обязательно описания!! Самодокументируемый код - это не наш случай! У нас слишком разные квалификации и привычные инструменты. Поэтому обязательно писать зачем и почему так сделано, что это дает и какие ограничения. Если есть нетривиальные вещи и изюминки (ну, то, что самому автору страшно нравится) - это обязятельно описывать.
Если библиотека не описана, она скорее всего - бесполезна!
Может уйти много времени на изучение, прежде чем поймешь, что она тебе не совсем подходит!
А за это время мог бы свою написать... (Тоже без описания... )
Так что лучше начинать как раз с описаний, а не с исходников...

Imho, начинать надо с объявления набора нчального команд. Дальше, если новые команды появляются, то их надо либо выражать через объявленные, либо как следует описывать и обосновывать необходимость ввода.
При этом, нормальным обоснованием не считать, что "команда в 100 раз быстрее работает, чем определение через начальные примитивы"
обоснованием можно считать только наличие необходимости конкретного действия и невозможность выражения через начальные примитивы.

Необходимость можно брать, например, из начального постулата о необходимости реализации на данном наборе полного Форта (F83/ANS94).

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

Согласно всему этому, план действий предлагается такой:

1. Выбирается набор команд (можно сказать, от балды)
2. Строится на нем имитатор ВМ,
3. К нему пишется простейший компилятор, которым и обрабатываются ВСЕ последующие исходники.

4. Если на каком-то шаге возникает непреодолимый затык, возвращаемся к 1, пока затык не будет пробит.

5. При острой необходимости (ну, там кого-то МУХА КУСИЛА или сильно захотелосьт ввести команду Вася-Стоять!), переделывается все, начиная с 1 и предъявляется общественности с последующим вынесением решения, принимать это изменение или нет.

Пока, кажется, все.


P.S. По поводу архитектиры ВМ, имхо, надо идти по такому же пути. Выбрать сначала минимальную аскетическую архитектуру, и добавлять
что-то новое потом, при острой необходимости.

Конкретно, выскажусь позже (вечерком, или ночью, или завтра)

Память программ/данных M[] с байтовой адресацией, на 16-битных системах до 64К, на 32-битных тоже лучше до 64К чтобы быстро божно было задачу перекинуть с узла на узел, порядок байт как на х86 процессоре как самом распространенном из легко программируемого пользователем железа

Совместимость кого с кем? Я понимаю совместимость с популярными форт-системами.
А они, доступ к стеку возвратов, имеют. Форт для меня, это прежде всего неограниченные возможности.



Чем проще? Вопрос был о другом. Или для отладки ОС возникают особые проблемы?

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

Да, возникают. Не все пишут код сразу без ошибок. Для того, чтобы удобно отлаживаться - не пререгружать комп с потерями 1-3минут на перезагрузку, брать примеры из файлов, записывать результаты, комментарии - нужно, чтоб хотя бы некоторые функции ОС работали. Поэтому и предлагается на этапе, когда еще нет работающих частей, отлаживаться на ВМ. Заодно и установленный софт не испортится при ошибках...

Согласен.

Выбирай от балды из трех предложенных вариантов
Итак, желающих выбрать набор пока оказалось 3.
У одного вообще нет ограничений (от балды ), другому подходят предложения третьего.
Значит, выбираем набор, предложенный forth@km.ru, как базовый!
forth@km.ru, давай ссылки на документацию!
Может, есть другие предложения?

Замечу, что можно перейти и к любому другому набору, если предлагающий сделает слой совместимости...
Тут правда, еще стоИт вопрос зависимости исходников от набора команд... Наличие определенных команд может вызвать значительные изменения исходников
Скрепя сердце, соглашаюсь на традиционную Форт- архитектуру...
Это позволит, по крайней мере использовать стандарты F94...
И наработки SPF

ВМ не зависит от архитектур процов (на то она и ВМ )
(равно как и от ОС под которой она работает).



Локальные переменные, мультизадачность.
Пройдись файндом по слову RP@ в \devel получиш кучу примеров.



До отладки программ в рантайме новой ОС еще дожить надо.



Чем не подходит обычная форт-система?



Какой софт? И где установленный? И почему он должен испортится?



http://devbiol.zoo.uwo.ca/~kvt/relf01.zip



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

Стоп-стоп-стоп! Не так быстро! А то, задавишь кого-нибудь!
Я же написал, вечером(ночью) вернусь и будет конкретное предложение...
Так вот, я только пришел с работы, и еще не подготовил свое конкретное предложение.

топик перенесен в "правильный" раздел форума

Коллега видимо хочет работать с полным комфортом, параллельно с отлаживаем ядром иметь запущенными несколько редакторов кода, справку или документацию ... разумное пожелание и таковые программы должны оставаться рабочими в процессе ?

потом нужно 3,5 раза отмерить (чтобы не 7) и только потом ... но быстро

осмелюсь предположить, forth@km.ru прав насчёт необходимости "согласовывать архитектуру", Потенциально и должна не то же, что уже обеспечила

Поспешишь - людей насмешишь!




Разумеется, прав! Но при согласовании надо отталкиваться от неких имеющихсся реалий.
Для меня эта реалия - имеющийся Форт-процессор.