Один простойц пример и не понадобится кем-то себя ...
Ну пусть это будет предельно просто - консольное приложение - других пока и не нужно, пусть это будет компилятор форта для понятности. И задание - запуститься, прочесть файл инициализации и выдать запрос пользователю.
Что и в какой момент эта программа получит от ОС и почему это хорошо (плохо)

С сегментной моделью, я так понял, уже согласились все и везде.

нет, WingLion пока хочет плоскую модель.

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

страсти, страсти!
замечу, что, например, в СПФе всего две ф-ции подключаются при запуске - все остальное только по необходимости (то есть при первом обращении к ф-ции).

И чем это отличается от тупого разрешения обращаться к чему угодно, если при первом обращении подключается все что просишь?
Пришел GlukService, запросил Forrmat-C, a eму в ответ - "Нате, пользуйтесь!" ;(

Eсли говорить точнее, то я опять хочу "непойми-что-и-сбоку-бантик".
Я бы сказал, что не сегментную, но страничную организацию с изменяемым размером страниц,
от 256 байт до... э... ну, типа четвертинки всей памяти системы...
А городить в ПЛИС подобие интелевской байды меня совсем не прельщает.

Именно. (В хорошем смысле)
mOleg тоже хочет не сегменты, а "типа сегменты" - по этому пункту можно было бы прийти к согласию и найти наиболее экономичную модель

Ну, так предлагайте! "экономичную", а то для меня экономия исчисляется только сэкономлеными ресурсами ПЛИС...

ЧТо такое на самом деле сегмент?
Это очень быстрый "Range Check", когда адресовать за границу просто не получается. Особенно он быстрый, если аппаратный.
Тo есть можно организовать сегмент как-нибудь так:

БАЗА - тот самый сегментный регистр в i86 (cs ds ...)
СМЕЩЕНИЕ - типа bх или iр
БАЗА = (ПРЕДЫДУЩАЯ_БАЗА + МАКСИМАЛЬНОЕ_ПРЕДЫДУЩЕЕ_СМЕЩЕНИЕ) ... + выравнивание
СМЕЩЕНИЕ = СМЕЩЕНИЕ & МАКСИМАЛЬНОЕ_СМЕЩЕНИЕ,
где & - побитовое "И"
АДРЕС = БАЗА + СМЕЩЕНИЕ (если у нас массив из 256 элементов, то БАЗА + (СМЕЩЕНИЕ & 255))

таким образом, адрес никогда не выйдет за некоторые границы, на самом деле, конечно, сложнее.

в i86 в защищённом режиме программа могла сформировать физический адрес, выходящий за пределы сегмента, но процессор давал прерывание.
если выйти из защищённого режима, сегмент ограничится 2 ** 16, но БАЗА может иметь какое угодно значение, даже ПРЕДЫДУЩАЯ_БАЗА + 1
что налагает сегменты один на другой (делает их незащищёнными)


Сегментная модель может быть реализована
1. аппаратно (быстро) (аппаратно выполняется часть а то и весь алгоритм, что проиходит параллельно с выполнением основного алгоритма и не расходуется лишнее время)
2. отчасти аппаратно, отчасти программно (?) - если аппаратура не позволяет
3. полностью програмно - последнее никак не отличается от программного "Range Check"

Какая лучше?

в данном случае пока предложение за mOleg

Сижу, перечитываю тему, а форт-процессор-то у меня уже воркает...

И имеет:
1. разрядность 16 bit (64К адресов 16-разрядных слов)
2. Стек возвратов и стек данных глубиной по 256 слов каждый.
3. 16 килобайт (8Кx16) быстрой системной памяти (Fast-RAM)
(в адресах 0x0000...0x1FFF)
4. 16 килобайт (8Кx16) дисплейной памяти
(0x8000...0x9FFF) в режиме CGA (16-bit-word = 8-bit-color-attribute+8-bit-ascii)
5. Статическая память (SRAM) - немного медленее Fast-RAM -
объем - 256Kx16=512Kбайт,
доступна страницами по 16Kx16 по адресам 0x4000..0x7FFF
6. Flash-ROM - пока без возможности записи - 4Mбайт
доступна страницами по 16Kx8 по адресам 0xC000...0xFFFF
7. страничная адресация SRAM и Flash-ROM через адрес страницы, записываемый в память по адресу 0x0009 (SRAM_PAGE) и 0x000A (Flash_PAGE).

Что хочется сделать:

1. "Как бы сегменты"
1.1. сегмент 0x0000...0x00FF - системные переменные/порты (доступны не каждому процессу, но четко распределены по функциям) Процесс может читать/писать в этой области, но в зависимости от системных установок либо запишет в devnull, либо прочитает 0x0000 там, где ему запрещено.
1.1.1 - 0x0080..0x00FF - строка, передаваемая системной функции или ответ системной функции процессу. Процесс может писать/читать эту область произвольно, но для каждого процесса этот кусочек памяти - отдельный (делается железно).

1.2 сегмент 0x00100..0x01FF(SYS_FENCE) - адреса для вызова системных функций - (доступные не каждому процессу, распределены согласно запросам к ГСИ). Читать данные из этой области процессу можно, писать в нее нельзя (блокировано аппаратно). Переход в эту область JMP или CALL приводит к вызову назначенной системной функции.
1.2.1 Адрес 0x00100 - адрес для вызова Главного Системного Интерпретатора - аппаратно при переходе в этот адрес процесс должен "проваливаться" на уровень ниже (в ОС), где происходит интерпретация запроса, переданного строкой в области системных переменных (строка - тоже переменная). В стеке данных - параметры строки запроса (addr, len). Возврат из запроса происходит по RET (можно и NEXT, но формально - это все равно).
1.3 сегмент SYS-FENCE... 0xFFFF собственная память процесса. Единый сегмент памяти, используемый процессом как ему заблагорассудится.
В него же впечатывается предоставляемая процессу страничная память.

Свойства сегментов разные, но это не проблема для ПЛИС.

Соглашения.
1. Процесс имеет доступ только к собственной памяти и к страничной памяти, предоставленной ему через ОС.
2. ОС доступно все железо, вся память и все устройства
2.1 ОС имеет доступ к памяти процесса, так как имеет в своем распоряжении доступ ко всем страницам памяти. И через этот механизм может передавать процессу и получать от процесса большие куски данных.
3. Распределение памяти между процессами осуществляется с помощью ОС через железный механизм. Процесс в этот механизм вмешаться не может. Может только вызвать ОС и "вежливо попросить - мне надо еще 128 мегабайт через текстовый запрос или вызов функции, прописанной во втором сегменте"
4. Стеки процессора находятся в полном распоряжении процесса. При передаче запроса к ОС стеки так же используются. ОС "обязана" работать со стеками корректно (иначе, это полосатый-мух, а не ОС получится). Через стеки передаются параметры для функций и запросов.
5. Глубина использования стеков ОС-ом оговаривается отдельно, и процесс "должен знать", об этом и рассчитывать свои действия так, чтобы не потерять свои данные, если ОС-у понадобится залезть в стек на полную оговоренную глубину.
В первом приближении можно установить, что глубина использования стека для ОС - не более некой постоянной величины.
6. Планируется железное обеспечение смешанной многозадачности. Процессу предоставляется один tic, он использует его полностью или частично на свое усмотрение. Если частично - возвращает управление менеджеру, если полностью, по истечении tic-a менеджер прерывает работу процесса "на самом интересном месте" и решает, кому работать дальше.

В данный момент это только план построения форт-системы к конкретной реализации форт-процессора. Реализуется он или нет, ясности еще нет.

p.s. предложения по реализации к данному плану будут рассмотрены/приняты/отклонены

Ну, это можно сделать железно - механизм адрессации должен быть такой. чтобы адрес формировался с учётом некоторой "таблицы прав", которая расположена в памяти - для каждого процесса своя

даже совсем необязательно, чтобы эта таблица была размером с весь массив системных процедур (функций), достаточно, чтобы эти функции были удачно сгруппированы и табьличка может занимать 2 байта ...

это?

В железе делается проще. табличка имеет некий размер, скажем 10 разрешенных вызовов - 10 векторов на процедуры в системной области плюс к ним 10 флагов (в крайнем случае 20 - дополнительно по два бита на адрес). И все. Железо само проверяет, попал вызов на разрешенный адрес или не попал? Попал - идем дальше, не попал - в зависимости от настроек задачи - просто возврат или пинок коленом под зад на вылет.

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

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

Исходник загружается менеджером в страничную память, откуда и компилируется системой. Когда компиляция закончится, производится запуск скомпилированного кода, как отдельного процесса (если этот запуск действительно нужен).

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

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