Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 12:23

...
Google Search
Forth-FAQ Spy Grafic

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




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

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

Обзор темы - поговорим о ТЗ
Автор Сообщение
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
KPG писал(а):
И, что мне даёт знание сего факта?

Что существует прецедент :) А значит, делать обобщающие выводы не следует. С обобщениями легко - "раз ни у кого нет, то ничего страшного, что у меня тоже нет".

KPG писал(а):
Может кому то он будет интересен

Бесполезно просто по исходной постановке. Кому конкретно интересен? Зачем разбираться с ворохом кода, не имея на руках концепции?

KPG писал(а):
по формату понимаемых файлов и какой то функциональности

1. У ТЗ как такового нет цели. Цель есть у проекта.
2. Что это за формулировка - "какой-то функциональности?".
- Сделайте что-нибудь.
- Что-нибудь сделано.

KPG писал(а):
"proof of concept"

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

Делается все не так:
1. "Кому-то нужно" заменяется на список тех, кому действительно нужно (конкретно - названия организаций или фамилии), или, что не так конкретно, на описание образа той организации или человека, который может этим заинтересоваться.
2. Почему конкретно он может этим заинтересоваться? Какие конкретно характеристики программного обеспечения будут лучше, если применить Форт? Чем их можно будет измерить и как?
3. Проект должен быть ограниченным во времени - какие контрольные точки установлены? Когда это должно быть сделано - завтра, через неделю, через месяц? Будет ли это интересно через 10 лет (видимо, нет). К какому интервалу ближе сроки реализации - 1 день или 10 лет?
Сообщение Добавлено: Ср июл 15, 2020 03:30
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Hishnik писал(а):
KPG писал(а):
Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ.

Нет так нет. У меня вот есть, полно.

И, что мне даёт знание сего факта? :)
Возвращаясь к "теме" - "Не делайте берите моё" (@Михаил) и к употреблению гнусного слова "Рабы" в другом треде.
Предлагаю для затравки к ознакомлению (ради любопытства:) одного недоделанного "быдло-кода" проекта - (где то была и тема по нему на местном форуме) - Простого редактора узлов.
Может кому то он будет интересен и он сделает дальнейший свой вариант без тех "косяков" присутствующих в текущем исполнении. :)


http://sendfile.su/1568990 (какой то вариант снимка данного проекта, если код не соберётся под SPF4 пишите здесь)

P.S. Одной из целей "ТЗ" была идея совместить по формату понимаемых файлов и какой то функциональности c Yed (решение последней мили) и "расширенного" пользовательского интерфейса для дальнейшего развития (поэтому есть и какой то "мусорный" код в нём), но многое не получилось и проект остался пока в текущем варианте "proof of concept"
так что строго судить о данном исполнении не имеет особого смысла поэтому. :)
(есть, конечно, мысли по улучшению дизайна-функциональности данного проекта, если не лень будет для его дальнейшего улучшения т.к. есть и какие другие "Форт-проекты" для переосмысления)
Сообщение Добавлено: Ср июл 15, 2020 02:54
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
KPG писал(а):
Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ.

Нет так нет. У меня вот есть, полно.
Сообщение Добавлено: Пн июл 13, 2020 19:05
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Hishnik писал(а):
К ТЗ приходят после формулирования целей проекта и необходимых для достижения этих целей задач. Никакое волшебное ТЗ не может обеспечить какое-либо "продвижение Форта". Банально, вопрос "какой будет ШК?" вызывает встречный вопрос - "а вам какие показатели необходимо обеспечить и для чего нужны эти показатели?".

Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ. :)
Сообщение Добавлено: Пн июл 13, 2020 18:23
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
К ТЗ приходят после формулирования целей проекта и необходимых для достижения этих целей задач. Никакое волшебное ТЗ не может обеспечить какое-либо "продвижение Форта". Банально, вопрос "какой будет ШК?" вызывает встречный вопрос - "а вам какие показатели необходимо обеспечить и для чего нужны эти показатели?".
Сообщение Добавлено: Пн июл 13, 2020 02:37
  Заголовок сообщения:  Re: поговорим о ТЗ  Ответить с цитатой
Sorry, тема, конечно, 5-ти летней давности.
кто к какому ТЗ пришёл? :) (Хищника?)

P.S. Попробовал скомпилировать, в частности такиe Форт-системы на Си языке, yforth, pforth - вполне собрались, но актуальность сих Форт-систем остаётся под вопросом.
Сообщение Добавлено: Сб июл 11, 2020 21:38
  Заголовок сообщения:  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

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


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