Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
А как насчёт реализации стека потока управления? Отдельный стек? Или всё же стек данных? А может стек возвратов? А может лучше под каждый вид свой стек? Для условий один, для циклов другой? Всё равно многим, в моём лице  , требуются "нестандартные" структуры управления
А как насчёт реализации стека потока управления? Отдельный стек? Или всё же стек данных? А может стек возвратов? А может лучше под каждый вид свой стек? Для условий один, для циклов другой? Всё равно многим, в моём лице :D , требуются "нестандартные" структуры управления
|
|
|
 |
Добавлено: Пт дек 23, 2016 19:10 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
Хочу попробовать сделать несколько вариантов реализации ColorLessColorForth с разными ВМ и для разных архитектур(x86, ARM). Один из вариантов - надстройка над SPF. Где их лучше разместить: - отдельным проектом
- отдельными ветками в OpenForth
- отдельной веткой в OpenForth
- в общую кучу
Хочу попробовать сделать несколько вариантов реализации ColorLessColorForth с разными ВМ и для разных архитектур(x86, ARM). Один из вариантов - надстройка над SPF. Где их лучше разместить: [list][*]отдельным проектом[*]отдельными ветками в OpenForth[*]отдельной веткой в OpenForth[*]в общую кучу[/list]
|
|
|
 |
Добавлено: Вт июл 28, 2015 03:15 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
in4 писал(а): Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа. А зачем? Чтобы точно не было компиляции?  В x86 есть понятие алиаса - дескриптор сегмента данных, полностью совпадающего по адресу и размера с дескриптором кода. В fasm достаточно поставить writeable. in4 писал(а): Как я понял, пишем на С и оптимизацией занимается компилятор? "Ручная" кодогенерация не предусматривается, или возможны варианты? Это уж кто как захочет. Я не собираюсь - у меня для такого есть кварк.
[quote="in4"]Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.[/quote] А зачем? Чтобы точно не было компиляции? :) В x86 есть понятие алиаса - дескриптор сегмента данных, полностью совпадающего по адресу и размера с дескриптором кода. В fasm достаточно поставить writeable.
[quote="in4"]Как я понял, пишем на С и оптимизацией занимается компилятор? "Ручная" кодогенерация не предусматривается, или возможны варианты?[/quote] Это уж кто как захочет. Я не собираюсь - у меня для такого есть кварк.
|
|
|
 |
Добавлено: Вс июл 26, 2015 01:46 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
Hishnik писал(а): in4 писал(а): Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей. Разумеется, логическое. x86 не имеет физического разделения. Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа. Как я понял, пишем на С и оптимизацией занимается компилятор? "Ручная" кодогенерация не предусматривается, или возможны варианты? Тут есть про борьбу с компиляторами: Семь видов интерпретаторов виртуальной машины. В поисках самого быстрого
[quote="Hishnik"][quote="in4"]Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.[/quote] Разумеется, логическое. x86 не имеет физического разделения.[/quote]Ну, можно разместить части в областях, доступных по разным селекторам и с разными правами доступа.
Как я понял, пишем на С и оптимизацией занимается компилятор? "Ручная" кодогенерация не предусматривается, или возможны варианты? Тут есть про борьбу с компиляторами: [url=http://habrahabr.ru/company/intel/blog/261665/]Семь видов интерпретаторов виртуальной машины. В поисках самого быстрого[/url]
|
|
|
 |
Добавлено: Вс июл 26, 2015 01:12 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
mOleg писал(а): У меня заходят шарики за ролики от написанного  Отвечу, пожалуй, в свежую тему...
[quote="mOleg"]У меня заходят шарики за ролики от написанного 8)[/quote] Отвечу, пожалуй, в свежую тему...
|
|
|
 |
Добавлено: Сб июл 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 не имеет физического разделения.
[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]
|
|
|
 |
Добавлено: Сб июл 25, 2015 22:23 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
Hishnik писал(а): in4 писал(а): Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)? Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код. Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT? Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация. Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше. А как в ARM реализован АИ? Hishnik писал(а): Раздельные области памяти для кода, данных и стеков. in4 писал(а): Гарвардская архитектура? Отказываемся от динамической компиляции? Не понял утверждения. В "обычной" реализации Форта код и данные были в одной области - можно было компилировать теми же средствами, что и размещать данные. Ну и делать модификацию кода во время работы. И докомпилировать программу в процессе работы(то, что я имею ввиду под "динамической компиляцией"). В гарвардской архитектуре код и данные тоже разделены. Соответственно вопрос - такое разделение это следствие ориентирования на гарвардскую архитектуру в том числе? Но разделение областей кода и данных приведет к некоторому усложнению компиляции (как минимум исходников - понадобится больше специализированных слов). Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.
[quote="Hishnik"][quote="in4"]Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?[/quote]Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.[/quote]Чем переход на точку NEXT адресного интерпретатора лучше инлайна кода NEXT? Если не ошибаюсь, в одном из вариантов Адресного Интерпретатора(АИ) (вроде так и в SPF) NEXT выражается одной машинной командой. В этих случаях, IMHO, лучше "размазанная"(инлайновая) реализация. Если реализация NEXT слишком длинная (в командах или в байтах) то, конечно переход через выделенную точку лучше. А как в ARM реализован АИ?
[quote="Hishnik"]Раздельные области памяти для кода, данных и стеков.[quote="in4"]Гарвардская архитектура? Отказываемся от динамической компиляции?[/quote]Не понял утверждения.[/quote]В "обычной" реализации Форта код и данные были в одной области - можно было компилировать теми же средствами, что и размещать данные. Ну и делать модификацию кода во время работы. И докомпилировать программу в процессе работы(то, что я имею ввиду под "динамической компиляцией"). В гарвардской архитектуре код и данные тоже разделены. Соответственно вопрос - такое разделение это следствие ориентирования на гарвардскую архитектуру в том числе? Но разделение областей кода и данных приведет к некоторому усложнению компиляции (как минимум исходников - понадобится больше специализированных слов).
Или это не физическое, а логическое разделение областей в одном адресном пространстве? Хотелось бы подробностей.
|
|
|
 |
Добавлено: Сб июл 25, 2015 21:43 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
Hishnik писал(а): Система должна быть стандартной постольку, поскольку это требуется в наших реалиях. Hishnik писал(а): Поэтому я предполагаю в своей работе игнорировать существование ANSI и не считать совместимость (или же антисовместимость) с ним аргументом за или против. У меня заходят шарики за ролики от написанного 8) ?Таки что тогда понимать под стандартностью! (просто мысли вслух:) практическое большинство форт-систем написано таким образом, чтобы соответствовать одному из двух возможных стандартов(или как из поточнее обозвать-то): 83 и 94. Все остальное пока что в практику не вошло по факту. Использование стандарта помогает с одной стороны сделать ее более понятной для других пользователей, т.к. меньше надо учить нового, а с другой стороны упростить разработку (потому что сразу понятно что должно и как выглядеть). Попытки подойти к стандарту отечественному (из того, в чем я таки маленько участвовал) не дали ощутимых результатов, увы. Причем, проблема на сколько я помню стала за мотивацией необходимости такого документа вообще (и в частностях).
[quote="Hishnik"]Система должна быть стандартной постольку, поскольку это требуется в наших реалиях.[/quote] [quote="Hishnik"]Поэтому я предполагаю в своей работе игнорировать существование ANSI и не считать совместимость (или же антисовместимость) с ним аргументом за или против.[/quote] У меня заходят шарики за ролики от написанного 8)
?Таки что тогда понимать под стандартностью! (просто мысли вслух:) практическое большинство форт-систем написано таким образом, чтобы соответствовать одному из двух возможных стандартов(или как из поточнее обозвать-то): 83 и 94. Все остальное пока что в практику не вошло по факту. Использование стандарта помогает с одной стороны сделать ее более понятной для других пользователей, т.к. меньше надо учить нового, а с другой стороны упростить разработку (потому что сразу понятно что должно и как выглядеть). Попытки подойти к стандарту отечественному (из того, в чем я таки маленько участвовал) не дали ощутимых результатов, увы. Причем, проблема на сколько я помню стала за мотивацией необходимости такого документа вообще (и в частностях).
|
|
|
 |
Добавлено: Сб июл 25, 2015 16:38 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
in4 писал(а): Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)? Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код. in4 писал(а): Чем лучше варианта - специальное слово для вызова планировщика многозадачности? Тем, что никакого планировщика многозадачности не предполагается. Зачем нужен этот суррогат в современных многозадачных ОС? in4 писал(а): Гарвардская архитектура? Отказываемся от динамической компиляции? Не понял утверждения.
[quote="in4"]Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)?[/quote] Через адресный интерпретатор (с учетом необходимости поддержки ARM). У меня это высокоуровневый код.
[quote="in4"]Чем лучше варианта - специальное слово для вызова планировщика многозадачности?[/quote] Тем, что никакого планировщика многозадачности не предполагается. Зачем нужен этот суррогат в современных многозадачных ОС?
[quote="in4"]Гарвардская архитектура? Отказываемся от динамической компиляции?[/quote] Не понял утверждения.
|
|
|
 |
Добавлено: Сб июл 25, 2015 14:24 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
Hishnik писал(а): Ранние публикации по Форту рассматривали многопоточное выполнение форт-программ, реализуемое на базе адресного интерпретатора с переключением потоков при выполнении NEXT Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)? Чем лучше варианта - специальное слово для вызова планировщика многозадачности? Hishnik писал(а): Раздельные области памяти для кода, данных и стеков. Гарвардская архитектура? Отказываемся от динамической компиляции?
[quote="Hishnik"]Ранние публикации по Форту рассматривали многопоточное выполнение форт-программ, реализуемое на базе адресного интерпретатора с переключением потоков при выполнении NEXT[/quote]Выполнение всегда должно идти через выделенную точку NEXT (JMP NEXT)? Чем лучше варианта - специальное слово для вызова планировщика многозадачности?
[quote="Hishnik"]Раздельные области памяти для кода, данных и стеков.[/quote]Гарвардская архитектура? Отказываемся от динамической компиляции?
|
|
|
 |
Добавлено: Сб июл 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 (не инициализирован). Проверка переполнения/исчерпания стека и прочие проверки подобного рода. В остальном, скажем так, Форт вряд ли может быть доведен до такого состояния, чтобы позиционироваться как "язык для надежных систем".
Ну вот я и приехал из отпуска, поэтому можно со вкусом поработать :) [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 (не инициализирован). Проверка переполнения/исчерпания стека и прочие проверки подобного рода. В остальном, скажем так, Форт вряд ли может быть доведен до такого состояния, чтобы позиционироваться как "язык для надежных систем".
|
|
|
 |
Добавлено: Пт июл 24, 2015 19:56 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
добавляю [url=http://fforum.winglion.ru/viewtopic.php?p=41245#p41245]несколько вопросов[/url]
|
|
|
 |
Добавлено: Вс июл 12, 2015 07:39 |
|
|
 |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
 |
|
mgw писал(а): Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал. Вопросы так или иначе возникнут и на них придется отвечать, только в ряде случаев непродуманность в начале может привести к переписыванию всего почти с нуля, хотелось бы без переделывания с нуля обойтись, именно для этого необходимо планирование. Если хочется сразу сесть писать код, то не вижу никакого смысла собирать для этого группу - лучше самому сесть и начать писать код. mgw писал(а): на каком языке делаем ядро? это интересный вопрос, вполне возможно, что под каждую систему ядро будет писаться на другом языке (это не выглядит неразрешимой проблемой).
[quote="mgw"]Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.[/quote] Вопросы так или иначе возникнут и на них придется отвечать, только в ряде случаев непродуманность в начале может привести к переписыванию всего почти с нуля, хотелось бы без переделывания с нуля обойтись, именно для этого необходимо планирование. Если хочется сразу сесть писать код, то не вижу никакого смысла собирать для этого группу - лучше самому сесть и начать писать код.
[quote="mgw"]на каком языке делаем ядро?[/quote] это интересный вопрос, вполне возможно, что под каждую систему ядро будет писаться на другом языке (это не выглядит неразрешимой проблемой).
|
|
|
 |
Добавлено: Сб июн 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
и тесты прогоняются при каждой пересборке системы.
[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] и тесты прогоняются при каждой пересборке системы.
|
|
|
 |
Добавлено: Сб июн 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 архитектуры я просто не знаю)
Скорее всего я чего то не понимаю :( "Нельзя объять необъятное ...." - Кажись Козьма Прутков сказал.
Как можно обсуждать структуру каталогов, если так и не понятно, на каком языке делаем ядро? Если это не 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 |
|
|
 |
|