Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
|
|
KPG писал(а): И, что мне даёт знание сего факта? Что существует прецедент А значит, делать обобщающие выводы не следует. С обобщениями легко - "раз ни у кого нет, то ничего страшного, что у меня тоже нет". KPG писал(а): Может кому то он будет интересен Бесполезно просто по исходной постановке. Кому конкретно интересен? Зачем разбираться с ворохом кода, не имея на руках концепции? KPG писал(а): по формату понимаемых файлов и какой то функциональности 1. У ТЗ как такового нет цели. Цель есть у проекта. 2. Что это за формулировка - "какой-то функциональности?". - Сделайте что-нибудь. - Что-нибудь сделано. KPG писал(а): "proof of concept" Тогда это должна быть реализация ключевого элемента проекта, которая давала бы понять, что тут еще нужно дописать только очевидно реализуемый код. Делается все не так: 1. "Кому-то нужно" заменяется на список тех, кому действительно нужно (конкретно - названия организаций или фамилии), или, что не так конкретно, на описание образа той организации или человека, который может этим заинтересоваться. 2. Почему конкретно он может этим заинтересоваться? Какие конкретно характеристики программного обеспечения будут лучше, если применить Форт? Чем их можно будет измерить и как? 3. Проект должен быть ограниченным во времени - какие контрольные точки установлены? Когда это должно быть сделано - завтра, через неделю, через месяц? Будет ли это интересно через 10 лет (видимо, нет). К какому интервалу ближе сроки реализации - 1 день или 10 лет?
[quote="KPG"]И, что мне даёт знание сего факта? [/quote] Что существует прецедент :) А значит, делать обобщающие выводы не следует. С обобщениями легко - "раз ни у кого нет, то ничего страшного, что у меня тоже нет".
[quote="KPG"]Может кому то он будет интересен [/quote] Бесполезно просто по исходной постановке. Кому конкретно интересен? Зачем разбираться с ворохом кода, не имея на руках концепции?
[quote="KPG"]по формату понимаемых файлов и какой то функциональности[/quote] 1. У ТЗ как такового нет цели. Цель есть у проекта. 2. Что это за формулировка - "какой-то функциональности?". - Сделайте что-нибудь. - Что-нибудь сделано.
[quote="KPG"]"proof of concept"[/quote] Тогда это должна быть реализация ключевого элемента проекта, которая давала бы понять, что тут еще нужно дописать только очевидно реализуемый код.
Делается все не так: 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" так что строго судить о данном исполнении не имеет особого смысла поэтому. (есть, конечно, мысли по улучшению дизайна-функциональности данного проекта, если не лень будет для его дальнейшего улучшения т.к. есть и какие другие "Форт-проекты" для переосмысления)
[quote="Hishnik"][quote="KPG"]Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ. [/quote] Нет так нет. У меня вот есть, полно.[/quote] И, что мне даёт знание сего факта? :) Возвращаясь к "теме" - "Не делайте берите моё" (@Михаил) и к употреблению гнусного слова "Рабы" в другом треде. Предлагаю для затравки к ознакомлению (ради любопытства:) одного недоделанного "быдло-кода" проекта - (где то была и тема по нему на местном форуме) - [url=http://fforum.winglion.ru/viewtopic.php?f=18&t=813]Простого редактора узлов[/url]. Может кому то он будет интересен и он сделает дальнейший свой вариант без тех "косяков" присутствующих в текущем исполнении. :)
http://sendfile.su/1568990 (какой то вариант снимка данного проекта, если код не соберётся под SPF4 пишите здесь)
P.S. Одной из целей "ТЗ" была идея совместить по формату понимаемых файлов и какой то функциональности c [url=https://www.yworks.com/products/yed]Yed[/url] (решение последней мили) и "расширенного" пользовательского интерфейса для дальнейшего развития (поэтому есть и какой то "мусорный" код в нём), но многое не получилось и проект остался пока в текущем варианте "proof of concept" так что строго судить о данном исполнении не имеет особого смысла поэтому. :) (есть, конечно, мысли по улучшению дизайна-функциональности данного проекта, если не лень будет для его дальнейшего улучшения т.к. есть и какие другие "Форт-проекты" для переосмысления)
|
|
|
|
Добавлено: Ср июл 15, 2020 02:54 |
|
|
|
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
|
|
KPG писал(а): Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ.
Нет так нет. У меня вот есть, полно.
[quote="KPG"]Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ. [/quote] Нет так нет. У меня вот есть, полно.
|
|
|
|
Добавлено: Пн июл 13, 2020 19:05 |
|
|
|
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
|
|
Hishnik писал(а): К ТЗ приходят после формулирования целей проекта и необходимых для достижения этих целей задач. Никакое волшебное ТЗ не может обеспечить какое-либо "продвижение Форта". Банально, вопрос "какой будет ШК?" вызывает встречный вопрос - "а вам какие показатели необходимо обеспечить и для чего нужны эти показатели?". Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ.
[quote="Hishnik"]К ТЗ приходят после формулирования целей проекта и необходимых для достижения этих целей задач. Никакое волшебное ТЗ не может обеспечить какое-либо "продвижение Форта". Банально, вопрос "какой будет ШК?" вызывает встречный вопрос - "а вам какие показатели необходимо обеспечить и для чего нужны эти показатели?".[/quote] Нет интересных проектов в реализации с Форт, и не будет дальнейшего возможного ТЗ. :)
|
|
|
|
Добавлено: Пн июл 13, 2020 18:23 |
|
|
|
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
|
|
К ТЗ приходят после формулирования целей проекта и необходимых для достижения этих целей задач. Никакое волшебное ТЗ не может обеспечить какое-либо "продвижение Форта". Банально, вопрос "какой будет ШК?" вызывает встречный вопрос - "а вам какие показатели необходимо обеспечить и для чего нужны эти показатели?".
К ТЗ приходят после формулирования целей проекта и необходимых для достижения этих целей задач. Никакое волшебное ТЗ не может обеспечить какое-либо "продвижение Форта". Банально, вопрос "какой будет ШК?" вызывает встречный вопрос - "а вам какие показатели необходимо обеспечить и для чего нужны эти показатели?".
|
|
|
|
Добавлено: Пн июл 13, 2020 02:37 |
|
|
|
|
|
Заголовок сообщения: |
Re: поговорим о ТЗ |
|
|
Sorry, тема, конечно, 5-ти летней давности. кто к какому ТЗ пришёл? (Хищника?) P.S. Попробовал скомпилировать, в частности такиe Форт-системы на Си языке, yforth, pforth - вполне собрались, но актуальность сих Форт-систем остаётся под вопросом.
Sorry, тема, конечно, 5-ти летней давности. кто к какому ТЗ пришёл? :) (Хищника?)
P.S. Попробовал скомпилировать, в частности такиe Форт-системы на Си языке, yforth, pforth - вполне собрались, но актуальность сих Форт-систем остаётся под вопросом.
|
|
|
|
Добавлено: Сб июл 11, 2020 21:38 |
|
|
|
|
|
Заголовок сообщения: |
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 |
|
|
|
|