Непонимание...

Veden12>> по Турчину
Gudleifr> Почитать, что ли?
Мне понравился его "Феномен науки". Рекомендую.
Gudleifr> И Forth-решение - язык интерфейса - тут работало еще когда и Forth не было - тот же язык системных вызовов. Forth - это, если угодно, попытка поставить пользователя в один ряд с программами и устройствами.
Собственно, так и получается если системные вызовы - это вызовы Форт-системы. Однако, сегодняшние графические интерфейсы сюда плохо вписываются.

Какие из следующих вариантов приемлемы?
1. Приложения, как и систему, образует шитый код. При этом никаких системных API не требуется - Форт-система предоставляет лексикон сразу со всех своих уровней детализации (Мур, Броуди).
2. Система поддерживает для приложений язык скинов, определяющих внешний вид, но не функционал приложений. Скины разных приложений могут иметь что-то общее - то, что называется "тема".
3. Для приложений поддерживается скриптовый язык, описывающий логику. Так, вместо шитого кода, поведение определяет иной предметно-ориентированный интерпретируемый язык - быть может, со своим шитым кодом. Цель - удобство программируещего пользователя и при этом глухая защита Форт-системы. Пример - Питон.

Veden12> Мне понравился его "Феномен науки". Рекомендую.
Спасибо, скачал.
Veden12> Однако, сегодняшние графические интерфейсы сюда плохо вписываются.
Графические системы вписываются ровно наполовину - пользовательский ввод прекрасно интерпретируется как поток ввода. Какая разница, пишет пользователь слова, разделенные пробелом, или жмет кнопки, посылающие сообщения wnd-msg-wpar-lpar?
А, вот, описать словами окошки достаточно сложно. Смысл - пожалуйста, а форму - фиг!
Veden12> Какие из следующих вариантов приемлемы?
Не понял, при чем тут Forth? Вы мечтаете создать супер-пупер-Forth компьютер? Forth, исторически, средство выживания программиста в неблагоприятной среде. Средство создания языков. Но не новая "клетка" для диких программеров.

Gudleifr> Какая разница, пишет пользователь слова, разделенные пробелом, или жмет кнопки, посылающие сообщения wnd-msg-wpar-lpar?
Согласен, никакой.
Gudleifr> А, вот, описать словами окошки достаточно сложно. Смысл - пожалуйста, а форму - фиг!
XML (BML) с этим великолепно справляется, даже с плавающими, вычисляемыми, заимствованными координатами и другими параметрами окон.
Veden12>> Какие из следующих вариантов приемлемы?
Gudleifr> Не понял, при чем тут Forth? Вы мечтаете создать супер-пупер-Forth компьютер?
Это несерьёзно. Компьютер - средство, а не цель. Реальная задача конечно же не имеет отношения ни к компьютерам, ни к программированию, а потому - оффтопик.
То, что я делаю сейчас, можно рассматривать как НИР, некоммерческую даже в отдалённой перспективе. Исходники - не секрет, но очень сомневаюсь что Вам нужен инструментальный монитор под UEFI.
Gudleifr> Forth, исторически, средство выживания программиста в неблагоприятной среде. Средство создания языков. Но не новая "клетка" для диких программеров.
Любой язык - клетка. Даже естественный. "Средство создания языков" - средство создания таких клеток. Вопрос лишь в характере "клетки". Клетку-интерпретатор можно открыть только снаружи. Клетку-компилятор легко открыть изнутри.

Veden12> XML (BML) с этим великолепно справляется, даже с плавающими, вычисляемыми, заимствованными координатами и другими параметрами окон.
Это как? Обычное дерево может обеспечить только одну связь - "part-of", "is-a" или "хозяин"... Использование атрибутов или замена дерева лесом для параллельного отслеживания других связей моментально приводит к полной путанице.
Как и язык диалогов-ресурсов, XML дает нечто полностью неуправляемое. Тупое перечисление всего того, что нужно передать функциям, создающих окна. Это, как считать описанием интерфейса фрагмент C-программы, его создающий.
XML, вообще, вещь жутко избыточная и двусмысленная.
Veden12> Любой язык - клетка.
А почему не гекс? Или, наоборот, монада? (Блин, не понял, что клетка здесь в том смысле, который я сам и придал. Но тут все просто. Forth - не клетка, потому, что он не язык).
И каким местом мы перешли к интерпретаторам и компиляторам, если речь о Forth?

Gudleifr> XML, вообще, вещь жутко избыточная и двусмысленная.
До недавних пор я был убеждён в том же. XML-файлы описания интерфейса, с которыми работает Eclipse - отличная иллюстрация этого. Человек не может с ними работать, - только программа, которая всегда готова порушить путаную структуру.

Для нового проекта была нужна основательно проработанная библиотека графического интерфейса, однообразная под Linux/Windows, с разборчивыми исходными текстами. Работа в реальном времени не позволяла использовать Java AWT/Swing. Я взял CEGUI. Для описания интерфейса в ней используется так называемая Falagard skin system. Два разных XML-описания - виджеты и раскладка на экране. Вручную правятся очень быстро, путаницы не возникает. Несмотря на то, что функции доступны сразу на всех уровнях. Оказывается, если захотеть - можно сделать и по уму.

Veden12>> Любой язык - клетка.
Gudleifr> А почему не гекс? Или, наоборот, монада? И каким местом мы перешли к интерпретаторам и компиляторам, если речь о Forth?
Да, Форт - средство создания языков. Но кто сказал что только компилируемых (естественным образом, в шитый код Форта)? С тем же успехом это может быть и интерпретатор совсем другого, предметно-ориентированного языка, написанный на Форте. Для скорости - со своим собственным байт-кодом (косвенная адрасация того же шитого кода). Что препятствует этому? Чем не "клетка для диких программеров"?

Veden12> Оказывается, если захотеть - можно сделать и по уму.
А это, часом не следствие Вашей нетребовательности? Т.е. схема Visual Basic - эвенты-пропертя - тоже прекрасно работает на простых случаях...

Veden12> Да, Форт - средство создания языков. Но кто сказал что только компилируемых (естественным образом, в шитый код Форта)? С тем же успехом это может быть и интерпретатор...
Исторически, речь обычно и идет об интерпретаторах.

Veden12> Чем не "клетка для диких программеров"?
Какая же это клетка, когда каждый может написать и F, и P полностью на свой вкус?

Veden12> Falagard skin system
Для очистки совести посмотрел. Честно говоря, не понял кайфа. Чем это отличается от Борландовских форм? Наличием значений по умолчанию?

Veden12>> Falagard skin system
Gudleifr> Для очистки совести посмотрел. Честно говоря, не понял кайфа. Чем это отличается от Борландовских форм? Наличием значений по умолчанию? Включением Tk-элементов?

Veden12>> Оказывается, если захотеть - можно сделать и по уму.
Gudleifr> А это, часом не следствие Вашей нетребовательности?
Оценивая степень проработки деталей интерфейса - скорее, наоборот.
Gudleifr> Т.е. схема Visual Basic - эвенты-пропертя - тоже прекрасно работает на простых случаях...
В сложных случаях без предопределённых схем поведения никуда. Но вот верно выбрать границу между жёстко заданными и задаваемыми свойствами - это искусство.

Veden12>> Да, Форт - средство создания языков. Но кто сказал что только компилируемых (естественным образом, в шитый код Форта)? С тем же успехом это может быть и интерпретатор...
Gudleifr> Исторически, речь обычно и идет об интерпретаторах.
Если я правильно понимаю, речь идёт об интерпретаторах непосредственного ввода пользователя, без промежуточной генерации проблемно-ориентированного псевдо-кода.
Veden12>> Чем не "клетка для диких программеров"?
Gudleifr> Какая же это клетка, когда каждый может написать и F, и P полностью на свой вкус?
А если, в целях самозащиты, полученная виртуальная машина P не допускает прямого обращения к F, оставляя доступным лишь ограниченный предметной областью собственный набор команд?

Veden12> В сложных случаях без предопределённых схем поведения никуда. Но вот верно выбрать границу между жёстко заданными и задаваемыми свойствами - это искусство.
Детальное описание графики конкретного интерфейса - это как чертеж паровоза. Во-первых, конкретный чертеж не дает никакого понятия о паровозах в целом - что тут обязательно, а что - дань моде. Во-вторых, из чертежа не следует, что паровоз должен ходить по рельсам и жрать уголь...
А пользователя и программиста волнует именно последнее... Программист хочет писать "введи строку по шаблону" или "уведоми о потребности сохранения", а не "отступи от края и выведи набор радио-кнопок во фрейме..."
Я неоднократно встречал (да и писал) программы, структура которых диктовалась не потребностями ввода/вывода и логикой управления, а только - дизайнерскими фичами и багами.
Даже способ борьбы придумал - нарисуй в окне внешний вид того, что моделируешь - план гостинницы, переднюю панель прибора, блок-схему процесса... и только потом начинай думать, где там "кнопочки" ставить. Потом с удивлением прочел, что Раскин это возвел в абсолют.

Veden12> Если я правильно понимаю, речь идёт об интерпретаторах непосредственного ввода пользователя, без промежуточной генерации проблемно-ориентированного псевдо-кода.
Почему? Это вопрос сложности P и оптимизации F.

Veden12> А если, в целях самозащиты, полученная виртуальная машина P не допускает прямого обращения к F, оставляя доступным лишь ограниченный предметной областью собственный набор команд?
Тысяча и один способ это решить. Спрятать опасные лексиконы. Породить дочерний интерпретатор. Перекрыть опасные лексиконы безопасными. Обрезать все, кроме нужного функционала целевой компиляцией...

Gudleifr> Для очистки совести посмотрел.
Я с этим не один месяц разбирался. Мне этот вариант остался после исключения прочих. Не думаю, что он подойдёт для простых применений - при отсутствии наработок точно.
Gudleifr> Честно говоря, не понял кайфа.
Туда легко даже шейдеры интегрировать (с учётом наложения окон), хоть и ни к чему мне это. А вот ловить глобальные события и правда удобно.
Gudleifr> Чем это отличается от Борландовских форм?
Тем, что здесь детальное описание сложносвязанных виджетов прекрасно себя чувствует в XML. Обработка событий на любом уровне. Это помимо наличия всех исходников и лицензии, конечно.
Gudleifr> Наличием значений по умолчанию?
Точно не этим.
Gudleifr> Включением Tk-элементов?
Tcl/Tk ничем не лучше Java. Также не дружит с реальным временем. Идея была хороша, но погибла из-за общего неприятия Tcl - уж очень от Си отличался. Кроме того, расширять возможности Tk можно лишь на Си. На Tcl, к примеру, нельзя полностью изменить внешний вид виджета. Увы.

Veden12> Я с этим не один месяц разбирался. Мне этот вариант остался после исключения прочих. Не думаю, что он подойдёт для простых применений - при отсутствии наработок точно.
Ну, тогда, в чем проблема? Раз решение подходит, реализовать его на чем угодно, в т.ч. на Forth - не вопрос.

Veden12>> Потом с удивлением прочел, что Раскин это возвел в абсолют.
А ещё он писал что заказчик скорее помешает, чем поможет проектированию интерфейса. И это правда. Грамотный разработчик должен быть и постановщиком задач, и дизайнером, и программистом. Иначе не получается...

Veden12>> А если, в целях самозащиты, полученная виртуальная машина P не допускает прямого обращения к F, оставляя доступным лишь ограниченный предметной областью собственный набор команд?
Gudleifr> Тысяча и один способ это решить. Спрятать опасные лексиконы. Породить дочерний интерпретатор.
А дочерний интерпретатор - виртуальная машина со своим байт-кодом в качестве задачи Форт-системы не нарушает общую идеологию Форта?
Gudleifr> Перекрыть опасные лексиконы безопасными. Обрезать все, кроме нужного функционала целевой компиляцией...
Как это сделать? Насколько я знаю, ни в один стандарт Форта не входят слова для удаления слов и словарей. Как убрать из словаря промежуточные (локальные по сути слова) после компиляции целевых? За рамками Форта - легко. Но что-то мне подсказывает, что проблема эта по меньшей мере неоригинальна. Нужны нестандартные слова для удаления ссылок на имеющиеся в словарях?

Veden12> Грамотный разработчик должен быть и постановщиком задач, и дизайнером, и программистом.
Так не бывает. Не говоря уже о том, что "разработчик" сейчас - это чисто манагер, которого нельзя до дела допускать, как и пользователя... Подробности организации программистского труда хорошо описаны у Брукса в "Мифическом человеко-месяце".

Veden12> А дочерний интерпретатор - виртуальная машина со своим байт-кодом в качестве задачи Форт-системы не нарушает общую идеологию Форта?
Я так понимаю, что наличие двух параллельных Forth-машин в одной системе, это неизбежность.
Самоцитируюсь: там я начал про это писать

Veden12> Как это сделать? Насколько я знаю, ни в один стандарт Форта не входят слова для удаления слов и словарей.
Тут два нюанса:
1. если мы пишем F под P мы можем ВСЕ!
2. "стандарт Форт" - это фикция. Как только F становится чем-то большим, чем написанная за неделю прокладка между A и P - он становится убогим языком без типизации, фигурных скобок и нормальных средств интерфейса.

Veden12>> А дочерний интерпретатор - виртуальная машина со своим байт-кодом в качестве задачи Форт-системы не нарушает общую идеологию Форта?
Gudleifr> Я так понимаю, что наличие двух параллельных Forth-машин в одной системе, это неизбежность.
Gudleifr> Самоцитируюсь: там я начал про это писать
Что такое "вторичная Форт-машина"? Расширенная версия исходной, с новыми словами или это главный цикл интерпретатора проблемно-ориентированного языка?
И почему "параллельные"? Что мешает той же самой Форт-системе после инициализации вызвать главный цикл P-машины, даром что он тоже - насквозь её родной шитый код.
Откуда теперь взяться проблеме генерации Форт-системы? Нет больше сегментной адресации. DOS вообще загнали в BIOS. Скинуть на диск "обученную" Форт-систему со словарями - не проблема.

Veden12>> Как это сделать? Насколько я знаю, ни в один стандарт Форта не входят слова для удаления слов и словарей.
Gudleifr> Тут два нюанса:
Gudleifr> 1. если мы пишем F под P мы можем ВСЕ!
В принципе - да. Но почему тогда в некоторых реализациях хэшируют монструозные словари вместо введения специального слова, удаляющего заданное слово из поиска, оставляя при этом само слово в памяти, занимаемой словарём?
Gudleifr> 2. "стандарт Форт" - это фикция. Как только F становится чем-то большим, чем написанная за неделю прокладка между A и P - он становится убогим языком без типизации, фигурных скобок и нормальных средств интерфейса.
То есть, никого не волнует что словари разбухают от слов местного значения, никогда не используемых при компиляции новых слов? А ничего, что время поиска/компиляции на порядок-другой больше будет?

Veden12> Разработка любой операционной системы начинается с ответа на вопрос "Зачем?"

Правильный вопрос. Но он справедлив для всего, что люди делают.

Veden12> Если, конечно, это не попытка самоутверждения. Нельзя забывать и о том, что сама по себе операционная система никому не нужна. Итак?

Ну, в узком смысле ОС нужна и сама по себе. ОС объединяет то, что люди всё равно пишут для себя т.к. на голой машине ничего нет, а часто повторяющиеся операции (тот же доступ к файлам, управление памятью) иметь надо. Или писать каждый раз с 0-ля.

Veden12> Полный контроль над A средствами F стал возможен сравнительно недавно - когда пали границы сегментов и появился 64-битный Long Mode x86-64, а также UEFI, предельно упрощающий загрузку.

Это как-то совсем плохо. С каких пор архитектура 86 стала единственной в мире. Да и загрузка в сегменты ничего сложного не представляет собой.

Veden12> Интерпретация намного эффективнее разграничивает доступ, чем прямое управление памятью.

Это только кажеться. Те же сегменты, которые были начиная с 286 (на 8086 это просто мера удлиненния адреса) вполне себе обеспечивали приличный уровень (с защитой) от других процессов. На IBM/360 /370 страничная организация памяти с дескриторами вполне обеспечивала разделение даже в линейной модели памяти. В Мотороле 32 битной тоже всё нормально. Как и в различных RISC-ах.

Veden12> Полный 100% отказ от предвосхищения оставляет человека перед голым железом.

С чего бы это? Полный отказ от предвосхищения оставляет человека перед голой природой. Никакого железа.

Veden12> Что такое "вторичная Форт-машина"? Расширенная версия исходной, с новыми словами или это главный цикл интерпретатора проблемно-ориентированного языка?
Второй набор слов "основного цикла": для чтения потока из нестандартного места, потока нестандартного формата, поиска в нестандартных словарях, нестандартной компиляции и/или что-то другое.
Например в FOBOS одна "машина" (обычная) читает исходники системы из текстового файла, а другая (дурная и недописанная) - win-сообщения.
Veden12> И почему "параллельные"? Что мешает той же самой Форт-системе после инициализации вызвать главный цикл P-машины, даром что он тоже - насквозь её родной шитый код.
Язык F работает не только после написания P, но и процессе его создания, т.е. параллельно с ним.
Veden12> Откуда теперь взяться проблеме генерации Форт-системы? Нет больше сегментной адресации. DOS вообще загнали в BIOS.
Какая связь между "генерацией" и "сегментацией"?
Veden12> Скинуть на диск "обученную" Форт-систему со словарями - не проблема.
Проблема состоит в том, что это никому не надо.
Veden12> В принципе - да. Но почему тогда в некоторых реализациях хэшируют монструозные словари вместо введения специального слова, удаляющего заданное слово из поиска, оставляя при этом само слово в памяти, занимаемой словарём?
Это от стремления создать Forth-систему, как нечто самоценное, заслуживающее признания и оплаты.
Veden12> То есть, никого не волнует что словари разбухают от слов местного значения, никогда не используемых при компиляции новых слов?
А зачем писать "лишние" слова?
Veden12> А ничего, что время поиска/компиляции на порядок-другой больше будет?
Чтобы время компиляции ощутимо увеличилось, нужно потратить столько времени на написание ненужных слов, что программиста уволят раньше.

Gudleifr> Например в FOBOS одна "машина" (обычная) читает исходники системы из текстового файла, а другая (дурная и недописанная) - win-сообщения.
Спасибо за пример. Но почему нельзя сначала скормить системе исходники, а уж потом NEXT-NEXT пускать рабочий цикл обработки сообщений? Форт-машина в рабочем цикле - чистая условность, без INTERPRET (FIND) словарный запас по любому будет жёстко ограничен предметной областью.
Veden12>> И почему "параллельные"? Что мешает той же самой Форт-системе после инициализации вызвать главный цикл P-машины, даром что он тоже - насквозь её родной шитый код.
Gudleifr> Язык F работает не только после написания P, но и процессе его создания, т.е. параллельно с ним.
Мне казалось, предметно-ориентированный язык будет иметь свои синтаксические конструкции для выражения свой логики и описания своих структур данных. Расширять его Форт-словами безусловно необходимо, но разве не удобнее это делать до запуска P-машины?

Veden12>> Откуда теперь взяться проблеме генерации Форт-системы? Нет больше сегментной адресации. DOS вообще загнали в BIOS.
Gudleifr> Какая связь между "генерацией" и "сегментацией"?
Форт-система со всеми словарями может занимать один непрерывный участок памяти. Удобно для сохранения и восстановления как есть после целевой компиляции.
Veden12>> Скинуть на диск "обученную" Форт-систему со словарями - не проблема.
Gudleifr> Проблема состоит в том, что это никому не надо.
Не нужна целевая компиляция?

Veden12>> То есть, никого не волнует что словари разбухают от слов местного значения, никогда не используемых при компиляции новых слов?
Gudleifr> А зачем писать "лишние" слова?
В общем, идея ясна. Что касается "лишних" слов, то, например, для слов типа BLOCK/BUFFER нужно вычислять адреса ячеек состояния и самих блоков - но лишь при определении этих слов, впоследствии имена слов, вычисляющих необходимые адреса, уже ни к чему. Отказ от создания вспомогательных слов совершенно недопустим для Форта и для здравого смысла.

Veden12> Спасибо за пример. Но почему нельзя сначала скормить системе исходники, а уж потом NEXT-NEXT пускать рабочий цикл обработки сообщений? Форт-машина в рабочем цикле - чистая условность,
Ну, во-первых, получается, что оконная функция начинает работать раньше, чем заканчивается интерпретация текста,
во-вторых, если я приделаю к FOBOS консоль, классическая Форт-машина опять пригодится,
в-третьих, основная "параллельность" приходится на тот момент, когда я судорожно правлю исходники, пытаясь заставить пример работать.
Veden12> без INTERPRET (FIND) словарный запас по любому будет жёстко ограничен предметной областью.
Ну как бы, всегда полезно и словарь команд иметь (FIND) и регулярные выражения распознавать (NUMBER).
Но если я сразу буду их писать в окончательной P-форме, то какая выгода от F?
Veden12> Форт-система со всеми словарями может занимать один непрерывный участок памяти. Удобно для сохранения и восстановления как есть после целевой компиляции.
Ну, как бы, все ОС стараются этого всеми силами не допустить.
Veden12> Не нужна целевая компиляция?
А, понял. Но производить ее в форме "создания окончательного образа" требуется, разве что, для программирования микроконтроллеров. Я, например, гораздо чаще просто правил A-исходники (и, конечно, F-исходники в "блоковой памяти"). В любом случае, задача "сохрани все, что я тут понаписал в виде Forth-машины" - в общем случае - неразрешима.
Veden12> Отказ от создания вспомогательных слов совершенно недопустим для Форта и для здравого смысла.
В этом и смысл F.
А задача "удали весь мусор" тоже - в общем случае - неразрешима.
Кстати, несмотря на декларируемое быстродействие и компактность, Forth, все-таки, очень много времени и памяти тратит на ненужные операции (вызов слов и стековые манипуляции).
Спасает только то, что осмысленная оптимизация программы, обычно, состоит в правке всего десятка строк в самом узком месте.
Так что, если есть желание удалить F-ядро из P-машины, проще сделать его более P-применимым.
(Как это там? Все хорошие программы юыли написаны после случайной утраты первоначальных исходников).

Mishka> Ну, в узком смысле ОС нужна и сама по себе. ОС объединяет то, что люди всё равно пишут для себя т.к. на голой машине ничего нет, а часто повторяющиеся операции (тот же доступ к файлам, управление памятью) иметь надо. Или писать каждый раз с 0-ля.
То есть, драйверы железа? Парадоксально, но большинство под ОС понимают одно единственное приложение, рисующее окошки - по сути, мутированный файл-менеджер. И драйверы для них хуже любого вируса.
Mishka> С каких пор архитектура 86 стала единственной в мире.
Статистика, структура рынков.
Mishka> Да и загрузка в сегменты ничего сложного не представляет собой.
Какая сегодняшняя операционная система разрешает запись в сегмент кода? Для Форта это обязательно. Да и вообще, зачем отказываться от машины Тьюринга?
Veden12>> Интерпретация намного эффективнее разграничивает доступ, чем прямое управление памятью.
Mishka> Это только кажеться. Те же сегменты, которые были начиная с 286 (на 8086 это просто мера удлиненния адреса) вполне себе обеспечивали приличный уровень (с защитой) от других процессов.
Такая система отлично работает до того момента, когда вас убедительно попросят предоставить интерфейс для драйверов производителей произвольного железа. В ядро, конечно, в нулевое кольцо защиты. Упало? Кто виноват?

Veden12> То есть, драйверы железа? Парадоксально, но большинство под ОС понимают одно единственное приложение, рисующее окошки - по сути, мутированный файл-менеджер. И драйверы для них хуже любого вируса.

У ОС много особенностей. Что понимает большинство — это пофиг, т.к. они и не видят, что взади, и не разбираются. Просто даже наличие многих систем FS об этом говорит. А уж всякие механизмы преемсвтенности в многозадачных/многопотоковых средах — тут за пределы понимания 99.999% вываливается. Про разделение/закрепление ресурсов тоже мало кто знает.


Но, если рассматривать управление памятью, как драйвер железа, то можно сказать и драйверы железа. А FS к драйверам железа отношение имеет очень опосредствованное. Там главное понять блоковое устройство или нет — немного свойства FS меняются. А остальное пофиг, лишь бы читал/писал (если не RO). Потому NFS так хорошо ложиться в идеологию того же UNIX-а, что пофиг, есть носитель или нет, а вместо него сеть или что-то другое.

А X-ы на UNIX-e — вообще пользовательская программа, а не часть ОС.

Veden12> Статистика, структура рынков.

Видать плохо учился. Встроенных управляющих чипов и компов на порядки больше, чем PC-шек. Возьми, к примеру телефоны. Или те же СД\ДВД приводы. А уж всяких других вещей, типа автомобилей, самолётов и поездов... (а так же всех их контроллеров).

Veden12> Какая сегодняшняя операционная система разрешает запись в сегмент кода? Для Форта это обязательно. Да и вообще, зачем отказываться от машины Тьюринга?

В какой сегмент? Ты предстваляешь себе, как это дело организованно на том же Пне? Как разделение задач происходит? Каждая же живёт в своём линейном пространстве. А линейно пространство собирается из страниц реальной памяти и свопа. И тот же дескриптор задачи вполне использует "сегментные регистры" (фактически, указывают на специальную таблицу, из которой и состоит линиейное пространство задачи, а каждый вход в таблицу — такой сегментик — если он 4к, то 32 битныое пространство, а, если побольше, то и больше будет).

Veden12> Такая система отлично работает до того момента, когда вас убедительно попросят предоставить интерфейс для драйверов производителей произвольного железа. В ядро, конечно, в нулевое кольцо защиты. Упало? Кто виноват?
Ы? Драйвера, вообще-то по идеологии Интела не должны крутиться в кольце 0. Это так реализовали мелкомягкие. Бо на большее уже опыта не хватило. А так можно было бы поинтересоваться VM/SP с ОС на них типа CMS, OS/360, OS/370, DOS, UNIX и ещё кучи других. При этом, виртуалька там могла падать сколько ей угодно. Собственно, CP там был единственным, кто крутился в привелегированном режиме. И был по размеру очень маленький. Всего несколько тысяч строк на ассемблере. Всё остальное крутилось в пользовательском режиме. В том числе и все гостевые ОС, перечисленные раньше.

Gudleifr> в-третьих, основная "параллельность" приходится на тот момент, когда я судорожно правлю исходники, пытаясь заставить пример работать.
Понимаю. Действительно, две независимые по времени задачи.
Gudleifr> Ну как бы, всегда полезно и словарь команд иметь (FIND) и регулярные выражения распознавать (NUMBER).
Gudleifr> Но если я сразу буду их писать в окончательной P-форме, то какая выгода от F?
Поскольку это ещё и средство разработки, Ваше решение мне кажется наилучшим или даже единственно возможным.
Veden12>> Форт-система со всеми словарями может занимать один непрерывный участок памяти. Удобно для сохранения и восстановления как есть после целевой компиляции.
Gudleifr> Ну, как бы, все ОС стараются этого всеми силами не допустить.
Увы, это правда. Либо это, либо писать самому все драйверы. Но тогда не останется времени на стоящие задачи.
Впрочем, завтра всё может измениться - разработчики железа начали вешать драйверы на BIOS, а не на операционную систему.
Gudleifr> Я, например, гораздо чаще просто правил A-исходники (и, конечно, F-исходники в "блоковой памяти"). В любом случае, задача "сохрани все, что я тут понаписал в виде Forth-машины" - в общем случае - неразрешима.
Согласен. Эта задача разрешима лишь в частном случае - если зафиксировать А-исходники (с необходимым шитым кодом) и отказаться от разработки в реальном времени. Тогда можно подгружать наборы блоков (я их называю "книгами", нумерованными - чтобы отслеживать прочитанные) и шаг за шагом учить систему. Но для динамичной среды разработки это, конечно, не годится.
Gudleifr> А задача "удали весь мусор" тоже - в общем случае - неразрешима.
Можно ввести специальное слово, удаляющее названное за ним (не само слово, ссылку на него). Но я уже понял что без необходимости этого делать не стоит.
Gudleifr> Кстати, несмотря на декларируемое быстродействие и компактность, Forth, все-таки, очень много времени и памяти тратит на ненужные операции (вызов слов и стековые манипуляции).
Gudleifr> Спасает только то, что осмысленная оптимизация программы, обычно, состоит в правке всего десятка строк в самом узком месте.
Это да. Осмысленная оптимизация даёт огромный выигрыш по быстродействию. Все известные мне компиляторы Си получая "strlen(), strcat()" выдают в коде "strlen(), забыли результат, ещё раз тот же strlen(), strcpy()". С Фортом сложно такое учудить.
Gudleifr> Так что, если есть желание удалить F-ядро из P-машины, проще сделать его более P-применимым.
Да, наверное, так и сделаю. Чтобы компиляция начала тормозить, нужны миллионы слов. Не похоже что их будет столько.
Gudleifr> (Как это там? Все хорошие программы юыли написаны после случайной утраты первоначальных исходников).

Mishka> У ОС много особенностей. Что понимает большинство — это пофиг, т.к. они и не видят, что взади, и не разбираются.
Быть может, всё что Вы написали - полезно и даже необходимо. Как оценивать возможные решения без чёткой формулировки проблемы? Компьютер и программы - лишь инструмент. Какие жизненные задачи он решает? До ответа на вопрос "Зачем?" я не могу судить об эффективности описываемого решения.
Mishka> В какой сегмент? Ты предстваляешь себе, как это дело организованно на том же Пне? Как разделение задач происходит?
Процессор лишь предоставляет механизмы. Разделением задач занимается программное обеспечение. А вот хорошо или плохо - зависит от того, для чего это всё надо.

Veden12>> Такая система отлично работает до того момента, когда вас убедительно попросят предоставить интерфейс для драйверов производителей произвольного железа. В ядро, конечно, в нулевое кольцо защиты. Упало? Кто виноват?
Mishka> Ы? Драйвера, вообще-то по идеологии Интела не должны крутиться в кольце 0. Это так реализовали мелкомягкие.
Не только. Linux теми же кольцами защиты обходится - нулевым и третьим. Вообще, концепция UNIX предполагает лишь два уровня привилегий. И модули ядра (драйверы) могут крутиться лишь в пространстве ядра ОС. Если правда, что MacOS на основе UNIX делали, то два уровня защиты - общепринятое правило, а не исключение.
Никто не тестирует систему со всеми возможными комбинациями постоянно обновляемых драйверов, имеющих прямой доступ к структурам ядра. Что можно при этом сказать о надёжности?

Veden12> Быть может, всё что Вы написали - полезно и даже необходимо. Как оценивать возможные решения без чёткой формулировки проблемы? Компьютер и программы - лишь инструмент. Какие жизненные задачи он решает? До ответа на вопрос "Зачем?" я не могу судить об эффективности описываемого решения.


А не надо зацикливаться на конечной задаче. Есть задача организация процесса. И тут выясняется, что написание той FS или управление памятью и/или процессами (и рессурсами) и есть задача сама по себе. И очень сложная математическая задача. И уже известно, что эти три составляющие (хотя в современной ОС и другие есть). Эта та часть, в которой неспециалисты не просто плавают, а ничего не понимают. Эта часть должна быть достаточно скрыта и видима только на уровне API с некоторым описанием поведения.

При твоём подходе и твоя задача есть лишь только инструмент в ответе на филосовский вопрос "зачем мы живём?".


И я гарантирую, что в области той же преемственности задач 99.9% программистов ничего особого не понимают. Им и не надо. Они решают свои задачи используя инструмент. Задача писателей ОС сделать этот инструмент удобным и местами достаточно универсальным.

Veden12> Процессор лишь предоставляет механизмы. Разделением задач занимается программное обеспечение. А вот хорошо или плохо - зависит от того, для чего это всё надо.

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


Veden12> Не только. Linux теми же кольцами защиты обходится - нулевым и третьим. Вообще, концепция UNIX предполагает лишь два уровня привилегий. И модули ядра (драйверы) могут крутиться лишь в пространстве ядра ОС. Если правда, что MacOS на основе UNIX делали, то два уровня защиты - общепринятое правило, а не исключение.


Да, и многие любят забивать микроскопом гвозди. А потом жаловаться на то, что линзы поцарапанные.

Концепция UNIX такого разделения не предусматривает. Для этого достаточно посмотреть на реализации UNIX по модели Таненбаума. В том же Карнеги-Меллона давно сделано реализация микроядра и модулей к нему (Mach (kernel) - Wikipedia — там же списочек ОС, которые основаны на этом микроядре). Просто Линус не любил концепцию Таненбаума и даже в своих письмах писал, что монолитное ядро позволило исполняться быстрее. Ценой вот тех паник в ядре, если драйвер глючит.

Veden12> Никто не тестирует систему со всеми возможными комбинациями постоянно обновляемых драйверов, имеющих прямой доступ к структурам ядра. Что можно при этом сказать о надёжности?

Никто не тестирует программы со всеми возможными комбинациями данных. Если посмотреть книжки про тестирование и верификацию программ аж родом из 70-х (и далее тоже), то уже тогда было доказана сложность задачи, а так же были придуманы методы по достаточно хорошему её решению.

Не более и не менее, чем о той программе, что пишешь ты или я.