А как насчёт реализации стека потока управления?
Отдельный стек?
Или всё же стек данных?
А может стек возвратов?
А может лучше под каждый вид свой стек? Для условий один, для циклов другой? Всё равно многим, в моём лице :D , требуются "нестандартные" структуры управления

Хочу попробовать сделать несколько вариантов реализации ColorLessColorForth с разными ВМ и для разных архитектур(x86, ARM). Один из вариантов - надстройка над SPF.
Где их лучше разместить:
[list][*]отдельным проектом[*]отдельными ветками в OpenForth[*]отдельной веткой в OpenForth[*]в общую кучу[/list]

[quote="in4"]Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.[/quote]
А зачем? Чтобы точно не было компиляции? :) В x86 есть понятие алиаса - дескриптор сегмента данных, полностью совпадающего по адресу и размера с дескриптором кода. В fasm достаточно поставить writeable.

[quote="in4"]Как я понял, пишем на С и оптимизацией занимается компилятор?
"Ручная" кодогенерация не предусматривается, или возможны варианты?[/quote]
Это уж кто как захочет. Я не собираюсь - у меня для такого есть кварк.

[quote="Hishnik"][quote="in4"]Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.[/quote]
Разумеется, логическое. x86 не имеет физического разделения.[/quote]Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.

Как я понял, пишем на С и оптимизацией занимается компилятор?
"Ручная" кодогенерация не предусматривается, или возможны варианты?
Тут есть про борьбу с компиляторами: [url=http://habrahabr.ru/company/intel/blog/261665/]Семь видов интерпретаторов виртуальной машины. В поисках самого быстрого[/url]

[quote="mOleg"]У меня заходят шарики за ролики от написанного 8)[/quote]
Отвечу, пожалуй, в свежую тему...

[quote="in4"]Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?[/quote]
Мы уже приняли решение писать на Си. Да, NEXT - это интересно, остроумно и т.д., но стоит написать так, как проще

[code]void Step()
{
void(*fword)();
fword = (void(*)())ReadCode(pc);
pc += sizeof(int);
fword();
}

void Execute()
{
int RdepthOnEntry = Rdepth;
do
{
Step();
}
while (RdepthOnEntry <= Rdepth) ;
}[/code]

Я не вижу смысла при таком коде выделять NEXT.
[quote="in4"]Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.
Разумеется, логическое. x86 не имеет физического разделения.
[/quote]

[quote="Hishnik"][quote="in4"]Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?[/quote]Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.[/quote]Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?

[quote="Hishnik"]Раздельные области памяти для кода, данных и стеков.[quote="in4"]Гарвардская архитектура? Отказываемся от динамической компиляции?[/quote]Не понял утверждения.[/quote]В "обычной" реализации Форта код и данные были в одной области - можно было компилировать теми же средствами, что и размещать данные. Ну и делать модификацию кода во время работы. И докомпилировать программу в процессе работы(то, что я имею ввиду под "динамической компиляцией").
В гарвардской архитектуре код и данные тоже разделены. Соответственно вопрос - такое разделение это следствие ориентирования на гарвардскую архитектуру в том числе?
Но разделение областей кода и данных приведет к некоторому усложнению компиляции (как минимум исходников - понадобится больше специализированных слов).

Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.

[quote="Hishnik"]Система должна быть стандартной постольку, поскольку это требуется в наших реалиях.[/quote]
[quote="Hishnik"]Поэтому я предполагаю в своей работе игнорировать существование ANSI и не считать совместимость (или же антисовместимость) с ним аргументом за или против.[/quote]
У меня заходят шарики за ролики от написанного 8)

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

[quote="in4"]Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?[/quote]
Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.

[quote="in4"]Чем лучше варианта - специальное слово для вызова планировщика многозадачности?[/quote]
Тем, что никакого планировщика многозадачности не предполагается. Зачем нужен этот суррогат в современных многозадачных ОС?

[quote="in4"]Гарвардская архитектура? Отказываемся от динамической компиляции?[/quote]
Не понял утверждения.

[quote="Hishnik"]Ранние публикации по Форту рассматривали многопоточное выполнение форт-программ, реализуемое на базе адресного интерпретатора с переключением потоков при выполнении NEXT[/quote]Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Чем лучше варианта - специальное слово для вызова планировщика многозадачности?

[quote="Hishnik"]Раздельные области памяти для кода, данных и стеков.[/quote]Гарвардская архитектура? Отказываемся от динамической компиляции?

Ну вот я и приехал из отпуска, поэтому можно со вкусом поработать :)
[quote="mOleg"]на сколько стандартной должна быть система (совместимость с ANSI и т.п.)[/quote]
Система должна быть стандартной постольку, поскольку это требуется в [b]наших[/b] реалиях. ANSI не имеет силы на территории Российской Федерации, и не находится в списке стандартов, рекомендуемых к рассмотрению. Мало того, что текущая версия давно устарела, так ANSI-форты еще и не могут похвастаться какими-то значимыми продуктами. Поэтому я предполагаю в своей работе игнорировать существование ANSI и не считать совместимость (или же антисовместимость) с ним аргументом за или против.

[quote="mOleg"]на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек)[/quote]
Поскольку то, что разработано, будет описано в своем стандарте, то получается, что она будет обеспечена сразу.

[quote="mOleg"]для чего предназначается система[/quote]
Если говорить о моих потребностях, то для встраивания интерпретатора/компилятора в более сложные системы. Я не ожидаю от такого Форта сверхвысокой производительности или поддержки широкого спектра оборудования или библиотек. Это может быть обеспечено другими инструментами, которые, однако, надо еще связывать между собой, а порядок действий может задаваться скриптом на Форте. Поэтому первые тесты, которые я планирую производить - это как раз взаимодействие с другими компонентами проекта. Например, динамическое переназначение скриптов, выполняемых при активизации объектов интерфейса, написанного на Qt. В целом главным приоритетом для меня является возможность добавления форт-машины в любой проект на Си простым #include.

[quote="mOleg"]на какие составные части должна быть разделена (что включать в ядро системы)[/quote]
По признаку зависимости от платформы. То, что поддерживается не везде, выносится в отдельный модуль.

[quote="mOleg"]какие платформы должна поддерживать (процессор, разрядность данных)[/quote]
x86, по возможности ARM. Разрядность данных 32, оставить задел для 64 бит.

[quote="mOleg"]какие инструменты использовать при создании (форт, си, ассемблер, другое)[/quote]
Си. В вариантах сборки в Qt и gcc-mb (адаптация gcc для Microblaze).

[quote="mOleg"]поддержка многозадачности (на каком уровне обеспечивать: в ядре или в библиотеке, какой тип использовать)[/quote]
Ранние публикации по Форту рассматривали многопоточное выполнение форт-программ, реализуемое на базе адресного интерпретатора с переключением потоков при выполнении NEXT. Это актуально, если нет других средств разделения ресурсов, к тому же является наглядной демонстрацией простого решения задачи - появление многопоточности в однозадачной системе. Поддержка многозадачности обеспечивается современными ОС, поэтому реализация ее в Форте выглядит дублированием, отвлекая силы и создавая лишний информационный шум.

[quote="mOleg"]структура памяти системы (количество областей, предназначение)[/quote]
Раздельные области памяти для кода, данных и стеков.

[quote="mOleg"]сколько основных стеков в системе[/quote]
Возвратов, данных, стек с плавающей точкой, control-flow, дополнительные: стек циклов, стек фреймов данных, стек локальных областей определений.

[quote="mOleg"]как тестировать систему на работоспособность после изменений (наборы тестов и методик, последовательность действий)[/quote]
Не пуская этот процесс на самотек :) Как минимум - набор Assert на каждое слово с обеспечением good path и bad path, хотя бы по разу. Интеграционные тесты на уровне выполнения простых алгоритмов с хорошо известным поведением.

[quote="mOleg"]каковой должна быть разрядность проектируемой системы (обязательно обосновать!)[/quote]
32, позже 64.

Почему так. Разрядности, меньшие 32, существенно осложняют жизнь программиста. Они актуальны для 8 и 16-разрядных МК, и то в случаях, когда из них надо выжать максимум производительности и занять минимальное место в памяти. Эмуляция 32-разрядного кода для таких МК ухудшит и то, и другое. Однако сейчас даже для этих МК часто можно писать 32-разрядный код, и от них может требоваться скорее поддержка нужной разработчику периферии, чем возможность уложиться в минимальную память. Решить проблемы производительности и памяти для выполнения 32-разрядного кода часто можно решить простым продвижением вперед по линейке МК.

Почему 32/64. Общепринятая разрядность - 32. Такие программы без проблем запускаются на 64-битных ОС. В рамках перехода к 64 разрядам я предполагаю максимально тщательно поддерживать независимость от разрядности данных внутри Форта. Обязательно использовать typedef cell для обозначения типа "число на стеке данных", со всеми вытекающими.

Я не считаю значимым для распространения Форта аргумент "зато он поддерживает 64 бита". В конце концов, для достижения такого эффекта будут использованы компиляторы других языков, которые-то уж точно поддерживают 64 бита.

[quote="mOleg"]обеспечение работы на многопроцессорных системах, удаленное выполнение кода[/quote]
Не вижу здесь ничего специального. Две программы на Форте могут быть запущены штатными средствами ОС и ими же распределены по двум процессорным ядрам.

[quote="mOleg"]каким образом выполнять (забить?) безопасное выполнение кода, то бишь, надежность[/quote]
Никаким специальным. Защита памяти осуществляется опять-таки штатными средствами многозадачной ОС. Возможно встраивание базовых проверок в слова, например, запрет выполнения VECT, если он указывает на 0 (не инициализирован). Проверка переполнения/исчерпания стека и прочие проверки подобного рода. В остальном, скажем так, Форт вряд ли может быть доведен до такого состояния, чтобы позиционироваться как "язык для надежных систем".

добавляю [url=http://fforum.winglion.ru/viewtopic.php?p=41245#p41245]несколько вопросов[/url]

[quote="mgw"]Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.[/quote]
Вопросы так или иначе возникнут и на них придется отвечать, только в ряде случаев непродуманность в начале может привести к переписыванию всего почти с нуля, хотелось бы без переделывания с нуля обойтись, именно для этого необходимо планирование. Если хочется сразу сесть писать код, то не вижу никакого смысла собирать для этого группу - лучше самому сесть и начать писать код.

[quote="mgw"]на каком языке делаем ядро?[/quote]
это интересный вопрос, вполне возможно, что под каждую систему ядро будет писаться на другом языке (это не выглядит неразрешимой проблемой).

[quote="VoidVolker"]Делать к каждому слову дополнительный комментарий или несколько для автотеста:[/quote]
такой подход сильно загромождает текст, но проблема не только в этом, ведь речь идет о многоплатформенной системе - где уверенность, что изменение в коде не приведет к поломке в сборке для какого-либо из вариантов?

Кстати, в форке у меня сделано следующим образом: в конце текста добавляется тестовая секция следующего вида:

[code]
?ABSENT test{ \EOF -- тестовая секция ---------------------------------------
test{
0 -IF 24542857 ELSE 67029874 THEN 67029874 <> THROW THROW
10 -IF 24542857 ELSE 67029874 THEN 67029874 <> THROW 10 <> THROW
-1 -IF 24542857 ELSE 67029874 THEN 24542857 <> THROW 1 + THROW

0 *IF 24542857 ELSE 67029874 THEN 67029874 <> THROW THROW
-1 DUP *IF 24542857 ELSE 67029874 THEN 24542857 <> THROW <> THROW
123 DUP *IF 24542857 ELSE 67029874 THEN 24542857 <> THROW <> THROW

3 BEGIN *WHILE 1 - REPEAT THROW
3 BEGIN 1 - *UNTIL 2 <> THROW
}test
[/code]
и тесты прогоняются при каждой пересборке системы.

Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.

Как можно обсуждать структуру каталогов, если так и не понятно, на каком языке делаем ядро? Если это не D, то что? Если это C++ (C) то реализовать подпрограммный вариант VM просто так не удастся, особенно на Linux. Или мы для Linux не делаем? Может быть ассемблер? А как быть с тем же Linux? Изучать синтаксис AT&T?

Я рассматриваю D как универсальный кроссплатформенный ассемблер с C++ вставками.

Если это D то может быть рассмотрим "forthd.d" и обсудим его архитектуру?

Все эти мои рассуждения касаются платформы x86 (32/64).

Если цель сделать ядро для ARM архитектуры, то тогда не понятно как совместить его с архитектурой x86. Может быть есть смысл решить на чём и какого типа ядро пишем для какой архитектуры:

Пример:
----------
x86 (32/64) Windows/Linux --> подпрограммная VM --> реализация на D
x86 (32/64) Windows/Linux --> косвенная шитая VM --> реализация на MinGw C++
ARM Linux 32 --> ??????????? VM --> MinGw C++ (какие ещё варианты для ARM архитектуры я просто не знаю)