?на сколько стандартной должна быть система (совместимость с ANSI и т.п.)
?на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек)
?для чего предназначается система
?на какие составные части должна быть разделена (что включать в ядро системы)
?какие платформы должна поддерживать (процессор, разрядность данных)
?какие инструменты использовать при создании (форт, си, ассемблер, другое)
?какой тип ВМ использовать, если несколько, как обеспечивать совместимость высокоуровневого кода
?какие средства настройки сборки проекта использовать
?каким образом оформлять исходные тексты (соглашения по оформлению и документированию) обсуджение
?какая структура проекта: каталоги, файлы (иерархия, структурирование) обсуждение
?поддержка многозадачности (на каком уровне обеспечивать: в ядре или в библиотеке, какой тип использовать)
?структура памяти системы (количество областей, предназначение)
?какой должна быть организация поиска лексем и распознавания чисел (интерфейсы, структура)
?какой должна быть работа с символами (нужна ли поддержка различных кодировок)
?сколько основных стеков в системе
?порядок запуска системы, настройки и инициализации
?интерфейсы с кодом на других языках (АПИ, т.п.)
?как внутри системы отражать текущие тип хранения данных(BE\LE), поддерживаемые кодировки символов, тип и разрядность чисел, окружение и т.п.
? как тестировать систему на работоспособность после изменений (наборы тестов и методик, последовательность действий)
? каковой должна быть разрядность проектируемой системы (обязательно обосновать!)
? обеспечение работы на многопроцессорных системах, удаленное выполнение кода
? каким образом выполнять (забить?) безопасное выполнение кода, то бишь, надежность

Прошу добавлять возникающие вопросы и предлагать ответы на поставленные в этой теме.

Вопросы постараюсь копировать в первое сообщение темы, чтобы можно было окинуть перечень.

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

"Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС
Обследование объекта и обоснование необходимости создания АС
Формирование требований пользователя к АС
Оформление отчета о выполнении работ и заявки на разработку АС
2. Разработка концепции АС
Изучение объекта
Проведение необходимых научно-исследовательских работ
Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
Оформление отчета о проделанной работе
3. Техническое задание
Разработка и утверждение технического задания на создание АС"

Если сейчас начать формулировать ТЗ, оно имеет все шансы стать сборной солянкой из быстрого, совместимого, кросс-платформенного и надежного Форта Самый важный момент сейчас - "формирование требований пользователя". Пользователь в данном случае категорически не совпадает с исполнителем ТЗ. Пользователь - это человек, который говорит "а я бы на вашем Форте хотел попробовать написать программку по обработке данных с фитнес-трекера". И вот тут и надо подумать, что ему для этого нужно. Так что важнейший момент - сценарии использования. Можно на примере предыдущих наработок.

За отсылку к ЕСПД спасибо.

Требования должны быть сформированы и согласованы перед кодированием.
Свои вопросы я задал.

Прошу подключаться желающих участвовать (важно не только мнение уважаемого сидящего_на_пеньке) 8)

Пишу ответы только на те вопросы а которые могу ответить, или вернее хотелось бы их так реализовать. На которые не ответил, то готов присоединится к обществу.

?на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек) - думаю на уровне библиотек. Сам стандарт старый и будет тянуть нас вниз, ну а кому надо, то загрузил библиотеку - вот тебе и стандарт.

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

?какие платформы должна поддерживать (процессор, разрядность данных) - (windows + linux) 32 - обязательно, (windows + linux) 64 в ближайшей перспективе.

?какие инструменты использовать при создании (форт, си, ассемблер, другое) - я за D в качестве разработки ядра. Штука реально крутая. Библиотеки на форте. Для интеграции с другими библиотеками (промежуточные DLL) возможны любые языки.

?какой тип ВМ использовать, - подпрограммный, как наиболее быстрый и проработанный в Форке и SPF

?какой должна быть работа с символами (нужна ли поддержка различных кодировок) - обязательна поддержка Utf-8

?сколько основных стеков в системе - я за Форк вариант. 3 стека. Удобно!

?порядок запуска системы, настройки и инициализации - в виде DLL на первом этапе, возможно с статическими константами определяющими размеры стеков, областей и т.д.

?интерфейсы с кодом на других языках (АПИ, т.п.) - нужно максимально полное API причем в разных вариантах типа cdecl, winapi и т.д. Я пытался прикрутить фортД к Excel и столкнулся с тем, что Excel нужен winapi для внешних вызовов.

• на сколько стандартной должна быть система (совместимость с ANSI и т.п.)
• на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек)
  — Совместимость не нужна, т.к. стандарт устаревший.
• для чего предназначается система
  — Для эффективной разработки быстрого и компактного ПО (лично я не намерен менять производительность и компактность на "сахар"). Производительность именного самого процесса разработки считаю важнейшим фактором.
• на какие составные части должна быть разделена (что включать в ядро системы)
  — Низкоуровневое ядро <-> Система управления словарями/лексикомами/областями видимости <-> Внешние интерфейсы к ядру <-> Библиотеки/плагины/расширения <-> Библиотеки конкретного экземпляра программы <-> Конфигурация взаимодействия этих библиотек (т.е. сама логика программы)
• какие платформы должна поддерживать (процессор, разрядность данных)
  — Windows/Linux/OSX и х86_32/_х86_64/(и хорошо бы учесть на будущее, что может быть 128/256/ХХХХ), и, возможно, АРМ (лично мне сейчас оно без надобности)
• какие инструменты использовать при создании (форт, си, ассемблер, другое)
  — А мне FASM нравится. Но вообще, надо сделать так, чтобы можно было разные инструменты использовать.
• какой тип ВМ использовать, если несколько, как обеспечивать совместимость высокоуровневого кода
  — Изоляцией высокого уровня от нижнего. Высокоуровневый код на то и высокоуровневый, чтобы не знать, что лежит ниже него.
• какие средства настройки сборки проекта использовать
  — Те, которые предоставляют инструменты разработки, очевидно. Или тут имелось ввиду нечто другое? Что-то типа мастера конфигураций?
• каким образом оформлять исходные тексты (соглашения по оформлению и документированию)
  — Документирование - в вики на гитхабе. Базовое описание файла с ихсодником - в начале файла. Дополнительная/рабочая информация по библиотеке - в вики. Например рисунки и блок-схемы алгоритмов и т.п.
• поддержка многозадачности (на каком уровне обеспечивать: в ядре или в библиотеке)
  — В ядре.
• структура памяти системы (количество областей, предназначение)
  — Код системы отдельным блоком только на чтение, пользовательский код и пользовательские даннные тоже отдельно, стеки отдельными блоками. При этом надо учитывать, что размеры могут быть любые. Т.е. вот хочу стек в гигабайт - ставлю циферку и все работает.
• какой должна быть организация поиска лексем и распознавания чисел (интерфейсы, структура)
  — В основе структуры - дерево, но возможны и любые более сложные схемы.
• какой должна быть работа с символами (нужна ли поддержка различных кодировок)
  — UTF-8 - основная кодировкаб UTF-16/32, 1251, 866 - дополнительные.
• сколько основных стеков в системе
  — Стек данных, стек возвратов, стек циклов со счетчиком, стек структур управления, стек локальных переменных/фреймов/<любое другое название>, стек входного потока (ну а почему бы и нет? например разбирать входной поток конвеером: сначала рабиваем строку на лексемы и находим нужные процедуры, а затем их выполняем, но тогда надо заранее знать поведение процедур, которые работают с входным потоком либо разбирать до таких процедур, а потом уже им передавать управление)
• порядок запуска системы, настройки и инициализации
  — Инициализация ядра, проверка доступных интерфейсов, затем доступных ресурсов, поиск конфигурации (файл, командная строка, сетевой запрос, переменная окружения), применение конфигурации/выбор стратегии поведения, далее - от конфига зависит. Загрузить и выполнить программу, ожидать ввода и т.п.
• интерфейсы с кодом на других языках (АПИ, т.п.)
  — В рамках доступных АПИ системы: dll, so или просто сетевой интерфейс.
• как внутри системы отражать текущие тип хранения данных(BE\LE), поддерживаемые кодировки символов, тип и разрядность чисел, окружение и т.п.
  — В конфигурации системы.
  
  Код:
  Sys config endian/bit/env

Отдельно хочется сказать в тему словарей. Лично я считаю, что эта древняя система словарей устарела и надо придумать что-то новое, более продвинутое и универсальное. Мне видится нечто вроде гибкой и открытой системы хранения связанных блоков данных, т.е. чтобы можно было не просто связать слово без пробела и кусок кода в памяти, а связывать например блоки текста или бинарных данных. Например прочитать в словарь Values бинарный файл объемом 64 байта блоками по 8 байт и сопоставить эти блоки восьми блокам из словаря Variables. Ну, это чисто гипотетический пример взятый с потолка. Чуть более реальный пример: создание списков/деревьев каких-либо данных и работа с ними естественным для системы образом, а не изобретение велосипедов.


А каким образом? Вот тут отличный ман по аддонам к экселю: http://habrahabr.ru/post/130084/

Система должна быть или стандартной, или иметь четкое описание ее отличий от стандарта.

Я вижу пока 2 основных вида систем.
Развитый форт со всеми прибамбасами
Простой форт (для скриптинга итд)
И от выбора системы будут разные ответы на последущие поставленные вопросы.

Для меня, реальная головная боль, совмещать код на ява, работающие ВМ, основная причина
запутанности кода, которая у меня получилась. Для себя, решил представлять процессы, как
работающие модули, что то вроде виртуальной ОС, но если есть у кого-то решения лучше, с
удовольствием воспользуюсь.( Решения, написать все на яве или другие, предполагающие
перекомпилиляцию проекта, не предлагать)

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

думать надо

?сколько основных стеков в системе

должно быть бесконечно, стек, это всего лишь указатель и счетчик.

?порядок запуска системы, настройки и инициализации
?интерфейсы с кодом на других языках (АПИ, т.п.)
?как внутри системы отражать текущие тип хранения данных(BE\LE), поддерживаемые кодировки символов, тип и разрядность чисел, окружение и т.п.

За ответы спасибо, только все понято не совсем правильно 8)
Ответы должны быть не в общем плане, а конкретными, например:


должны существовать следующие каталоги:

kernel  
      arch
         16bit      
             Z80
             Cortex
             TF16
             ...
          32bit 
             ix86
             Cortex
             ...
          64bit
             ix86
      compiler
      os
 lib  
      native
          io
              uart
              usb
              ...
      win  
      nix
 doc

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

и так по каждому из вопросов, именно поэтому я просил на каждый вопрос отвечать одним сообщением, а не сваливать в кучу, как все сделали 8)


Именно так 8)

ну, и, главное, я не заметил ваших вопросов (что я упустил из виду?)
На какие вопросы необходимо подробно ответить, прежде чем садиться за написание кода?

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

P.S.
добавил вопрос: ? как тестировать систему на работоспособность после изменений (наборы тестов и методик, последовательность действий).

Делать к каждому слову дополнительный комментарий или несколько для автотеста:

И после компиляции всей программы идет выполнение тестов (в зависимости от флага настроек Sys/dev/debug).

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

Как можно обсуждать структуру каталогов, если так и не понятно, на каком языке делаем ядро? Если это не 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 архитектуры я просто не знаю)

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

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


и тесты прогоняются при каждой пересборке системы.

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


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

добавляю несколько вопросов

Ну вот я и приехал из отпуска, поэтому можно со вкусом поработать

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


Поскольку то, что разработано, будет описано в своем стандарте, то получается, что она будет обеспечена сразу.


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


По признаку зависимости от платформы. То, что поддерживается не везде, выносится в отдельный модуль.


x86, по возможности ARM. Разрядность данных 32, оставить задел для 64 бит.


Си. В вариантах сборки в Qt и gcc-mb (адаптация gcc для Microblaze).


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


Раздельные области памяти для кода, данных и стеков.


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


Не пуская этот процесс на самотек Как минимум - набор Assert на каждое слово с обеспечением good path и bad path, хотя бы по разу. Интеграционные тесты на уровне выполнения простых алгоритмов с хорошо известным поведением.


32, позже 64.

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

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

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


Не вижу здесь ничего специального. Две программы на Форте могут быть запущены штатными средствами ОС и ими же распределены по двум процессорным ядрам.


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

Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Чем лучше варианта - специальное слово для вызова планировщика многозадачности?

Гарвардская архитектура? Отказываемся от динамической компиляции?