Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вс дек 17, 2017 00:41

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 17:17 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
?на сколько стандартной должна быть система (совместимость с ANSI и т.п.)
?на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек)
?для чего предназначается система
?на какие составные части должна быть разделена (что включать в ядро системы)
?какие платформы должна поддерживать (процессор, разрядность данных)
?какие инструменты использовать при создании (форт, си, ассемблер, другое)
?какой тип ВМ использовать, если несколько, как обеспечивать совместимость высокоуровневого кода
?какие средства настройки сборки проекта использовать
?каким образом оформлять исходные тексты (соглашения по оформлению и документированию) обсуджение
?какая структура проекта: каталоги, файлы (иерархия, структурирование) обсуждение
?поддержка многозадачности (на каком уровне обеспечивать: в ядре или в библиотеке, какой тип использовать)
?структура памяти системы (количество областей, предназначение)
?какой должна быть организация поиска лексем и распознавания чисел (интерфейсы, структура)
?какой должна быть работа с символами (нужна ли поддержка различных кодировок)
?сколько основных стеков в системе
?порядок запуска системы, настройки и инициализации
?интерфейсы с кодом на других языках (АПИ, т.п.)
?как внутри системы отражать текущие тип хранения данных(BE\LE), поддерживаемые кодировки символов, тип и разрядность чисел, окружение и т.п.
? как тестировать систему на работоспособность после изменений (наборы тестов и методик, последовательность действий)
? каковой должна быть разрядность проектируемой системы (обязательно обосновать!)
? обеспечение работы на многопроцессорных системах, удаленное выполнение кода
? каким образом выполнять (забить?) безопасное выполнение кода, то бишь, надежность

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 17:20 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
Прошу добавлять возникающие вопросы и предлагать ответы на поставленные в этой теме.

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

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 18:23 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6100
Благодарил (а): 14 раз.
Поблагодарили: 96 раз.
"Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 18:49 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
За отсылку к ЕСПД спасибо.

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

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 19:56 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 322
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 10 раз.
Пишу ответы только на те вопросы а которые могу ответить, или вернее хотелось бы их так реализовать. На которые не ответил, то готов присоединится к обществу.

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

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

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

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

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

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

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 21:30 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1252
Благодарил (а): 3 раз.
Поблагодарили: 16 раз.
  • на сколько стандартной должна быть система (совместимость с 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. Ну, это чисто гипотетический пример взятый с потолка. Чуть более реальный пример: создание списков/деревьев каких-либо данных и работа с ними естественным для системы образом, а не изобретение велосипедов.

mgw писал(а):
Я пытался прикрутить фортД к Excel и столкнулся с тем, что Excel нужен winapi для внешних вызовов.

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

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Последний раз редактировалось VoidVolker Вс июн 28, 2015 09:28, всего редактировалось 1 раз.

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июн 26, 2015 21:46 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 12, 2008 03:18
Сообщения: 205
Откуда: Москва
Благодарил (а): 24 раз.
Поблагодарили: 2 раз.
mOleg писал(а):
?на сколько стандартной должна быть система (совместимость с ANSI и т.п.)
?на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек)

Система должна быть или стандартной, или иметь четкое описание ее отличий от стандарта.
mOleg писал(а):
?для чего предназначается система

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

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

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

думать надо

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

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

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

_________________
Линукс решает, винда глотает.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июн 27, 2015 06:04 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
За ответы спасибо, только все понято не совсем правильно 8)
Ответы должны быть не в общем плане, а конкретными, например:

mOleg писал(а):
?какая структура проекта: каталоги, файлы (иерархия, структурирование)

должны существовать следующие каталоги:
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.
добавил вопрос: ? как тестировать систему на работоспособность после изменений (наборы тестов и методик, последовательность действий).

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июн 27, 2015 10:47 
Не в сети
Аватара пользователя

Зарегистрирован: Вт мар 20, 2007 23:39
Сообщения: 1252
Благодарил (а): 3 раз.
Поблагодарили: 16 раз.
mOleg писал(а):
как тестировать систему на работоспособность после изменений (наборы тестов и методик, последовательность действий).

Делать к каждому слову дополнительный комментарий или несколько для автотеста:
Код:
: word-name   \ ( a b c -- d e ) \ Commment
    \test 1 2 3 -- 4 5 \ Тест 1
    \test 0 0 0 -- 0 0 \ Тест крайнего случая
   + DUP ROT SWAP -
;

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

_________________
Cтоимость сопровождения программного обеспечения пропорциональна квадрату творческих способностей программиста.
Роберт Д. Блисc


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июн 27, 2015 12:50 
Не в сети

Зарегистрирован: Ср фев 17, 2010 18:10
Сообщения: 322
Откуда: Тверь
Благодарил (а): 13 раз.
Поблагодарили: 10 раз.
Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июн 27, 2015 19:41 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
VoidVolker писал(а):
Делать к каждому слову дополнительный комментарий или несколько для автотеста:

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

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

Код:
?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

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июн 27, 2015 19:48 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
mgw писал(а):
Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.

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

mgw писал(а):
на каком языке делаем ядро?

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Вс июл 12, 2015 07:39 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 4832
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 18 раз.
Поблагодарили: 52 раз.
добавляю несколько вопросов

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Пт июл 24, 2015 19:56 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6100
Благодарил (а): 14 раз.
Поблагодарили: 96 раз.
Ну вот я и приехал из отпуска, поэтому можно со вкусом поработать :)
mOleg писал(а):
на сколько стандартной должна быть система (совместимость с ANSI и т.п.)

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

mOleg писал(а):
на каком уровне должна обеспечиваться совместимость со стандартом (сразу/с помощью библиотек)

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

mOleg писал(а):
для чего предназначается система

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

mOleg писал(а):
на какие составные части должна быть разделена (что включать в ядро системы)

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

mOleg писал(а):
какие платформы должна поддерживать (процессор, разрядность данных)

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

mOleg писал(а):
какие инструменты использовать при создании (форт, си, ассемблер, другое)

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

mOleg писал(а):
поддержка многозадачности (на каком уровне обеспечивать: в ядре или в библиотеке, какой тип использовать)

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

mOleg писал(а):
структура памяти системы (количество областей, предназначение)

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

mOleg писал(а):
сколько основных стеков в системе

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

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

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

mOleg писал(а):
каковой должна быть разрядность проектируемой системы (обязательно обосновать!)

32, позже 64.

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

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

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

mOleg писал(а):
обеспечение работы на многопроцессорных системах, удаленное выполнение кода

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

mOleg писал(а):
каким образом выполнять (забить?) безопасное выполнение кода, то бишь, надежность

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: поговорим о ТЗ
СообщениеДобавлено: Сб июл 25, 2015 03:45 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Hishnik писал(а):
Ранние публикации по Форту рассматривали многопоточное выполнение форт-программ, реализуемое на базе адресного интерпретатора с переключением потоков при выполнении NEXT
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Чем лучше варианта - специальное слово для вызова планировщика многозадачности?

Hishnik писал(а):
Раздельные области памяти для кода, данных и стеков.
Гарвардская архитектура? Отказываемся от динамической компиляции?

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB