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

...
Google Search
Forth-FAQ Spy Grafic

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




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - поговорим о ТЗ
Автор Сообщение
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
А как насчёт реализации стека потока управления?
Отдельный стек?
Или всё же стек данных?
А может стек возвратов?
А может лучше под каждый вид свой стек? Для условий один, для циклов другой? Всё равно многим, в моём лице :D , требуются "нестандартные" структуры управления
Сообщение Добавлено: Пт дек 23, 2016 19:10
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Хочу попробовать сделать несколько вариантов реализации ColorLessColorForth с разными ВМ и для разных архитектур(x86, ARM). Один из вариантов - надстройка над SPF.
Где их лучше разместить:
  • отдельным проектом
  • отдельными ветками в OpenForth
  • отдельной веткой в OpenForth
  • в общую кучу
Сообщение Добавлено: Вт июл 28, 2015 03:15
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
in4 писал(а):
Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.

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

in4 писал(а):
Как я понял, пишем на С и оптимизацией занимается компилятор?
"Ручная" кодогенерация не предусматривается, или возможны варианты?

Это уж кто как захочет. Я не собираюсь - у меня для такого есть кварк.
Сообщение Добавлено: Вс июл 26, 2015 01:46
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Hishnik писал(а):
in4 писал(а):
Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.

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

Как я понял, пишем на С и оптимизацией занимается компилятор?
"Ручная" кодогенерация не предусматривается, или возможны варианты?
Тут есть про борьбу с компиляторами: Семь видов интерпретаторов виртуальной машины. В поисках самого быстрого
Сообщение Добавлено: Вс июл 26, 2015 01:12
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
mOleg писал(а):
У меня заходят шарики за ролики от написанного 8)

Отвечу, пожалуй, в свежую тему...
Сообщение Добавлено: Сб июл 25, 2015 22:26
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
in4 писал(а):
Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?

Мы уже приняли решение писать на Си. Да, NEXT - это интересно, остроумно и т.д., но стоит написать так, как проще

Код:
void Step()
{
    void(*fword)();
    fword = (void(*)())ReadCode(pc);
    pc += sizeof(int);
    fword();
}

void Execute()
{
    int RdepthOnEntry = Rdepth;
    do
    {
        Step();
    }
    while (RdepthOnEntry <= Rdepth) ;
}


Я не вижу смысла при таком коде выделять NEXT.
in4 писал(а):
Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.
Разумеется, логическое. x86 не имеет физического разделения.
Сообщение Добавлено: Сб июл 25, 2015 22:23
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Hishnik писал(а):
in4 писал(а):
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.
Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT?
Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация.
Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше.
А как в ARM реализован АИ?

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

Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.
Сообщение Добавлено: Сб июл 25, 2015 21:43
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Hishnik писал(а):
Система должна быть стандартной постольку, поскольку это требуется в наших реалиях.

Hishnik писал(а):
Поэтому я предполагаю в своей работе игнорировать существование ANSI и не считать совместимость (или же антисовместимость) с ним аргументом за или против.

У меня заходят шарики за ролики от написанного 8)

?Таки что тогда понимать под стандартностью!
(просто мысли вслух:) практическое большинство форт-систем написано таким образом, чтобы соответствовать одному из двух возможных стандартов(или как из поточнее обозвать-то): 83 и 94. Все остальное пока что в практику не вошло по факту.
Использование стандарта помогает с одной стороны сделать ее более понятной для других пользователей, т.к. меньше надо учить нового, а с другой стороны упростить разработку (потому что сразу понятно что должно и как выглядеть).
Попытки подойти к стандарту отечественному (из того, в чем я таки маленько участвовал) не дали ощутимых результатов, увы. Причем, проблема на сколько я помню стала за мотивацией необходимости такого документа вообще (и в частностях).
Сообщение Добавлено: Сб июл 25, 2015 16:38
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
in4 писал(а):
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?

Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.

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

Тем, что никакого планировщика многозадачности не предполагается. Зачем нужен этот суррогат в современных многозадачных ОС?

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

Не понял утверждения.
Сообщение Добавлено: Сб июл 25, 2015 14:24
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Hishnik писал(а):
Ранние публикации по Форту рассматривали многопоточное выполнение форт-программ, реализуемое на базе адресного интерпретатора с переключением потоков при выполнении NEXT
Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?
Чем лучше варианта - специальное слово для вызова планировщика многозадачности?

Hishnik писал(а):
Раздельные области памяти для кода, данных и стеков.
Гарвардская архитектура? Отказываемся от динамической компиляции?
Сообщение Добавлено: Сб июл 25, 2015 03:45
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Ну вот я и приехал из отпуска, поэтому можно со вкусом поработать :)
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 (не инициализирован). Проверка переполнения/исчерпания стека и прочие проверки подобного рода. В остальном, скажем так, Форт вряд ли может быть доведен до такого состояния, чтобы позиционироваться как "язык для надежных систем".
Сообщение Добавлено: Пт июл 24, 2015 19:56
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
добавляю несколько вопросов
Сообщение Добавлено: Вс июл 12, 2015 07:39
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
mgw писал(а):
Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.

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

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

это интересный вопрос, вполне возможно, что под каждую систему ядро будет писаться на другом языке (это не выглядит неразрешимой проблемой).
Сообщение Добавлено: Сб июн 27, 2015 19:48
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
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

и тесты прогоняются при каждой пересборке системы.
Сообщение Добавлено: Сб июн 27, 2015 19:41
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.

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

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


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