Что не хватает Форту?

Gudleifr> Вопрос темы: Что не хватает Форту?
Gudleifr> Ответ:
Kopa>> проводится опрос возрастной категории участников форума
Gudleifr> Браво!
Это больше для Balancera или местных "читателей" данного форума, если они зарегистрированны на fforum и захотят проголосовать.

P.S. А так да Форт не хватает пользователей языка

Veden12> Форт в качестве ОС - интересная задача. К сожалению, чётко формализовать такую постоянно развиваемую по всем направлениям систему вряд ли получится. Как без этого создать грамотные, хорошо продуманные API и интерфейсы пользователя (удобные для человека, по Раскину)?
Прежде чем изобретать велосипед надо разобраться с тем, что используется на данный
момент. Форт внедренный в ядро ОС является средством исследования этой ОС.
Можно на "живье" посмотреть значение всех переменных и вызвать на исполнение
любую процедуру с заданными параметрами. Удалив из ОС всё кроме того, поддерживает
Форт мы ее упрощаем для поэтапного освоения. Можно сопоставить между собой то,
как разные ОС поддерживают единственную форт-систему. Загружать удаленную часть
можно тоже поэтапно выясняя что и за-что отвечает. Все тело ядра ОС
(кроме секретной части в многопользовательской системы)
предоставляется пользователю в качестве библиотеки подпрограмм.
Для кого-то это наскальные рисунки, а кот-то наедет этому применение.
Для одной задачи можно использовать разные библиотеки.
Для ОС можно использовать такую библиотеку, которая с большей вероятностью
может пригодится для прикладной программы. Не возможно все заранее
предусмотреть. Программное обеспечение давно развивается эволюционным образом.
За каждым реально используемым продуктом тянется длинная цепочка прототипов.
Система микроплатежей позволит разбить развитие продуктов на более мелкие
этапы и снизить требование к квалификации разработчиков.

mak44> Прежде чем изобретать велосипед надо разобраться с тем, что используется на данный момент.
Как-то странно после данной фразы читать чисто фантастические последующие.

Совершенно не понимаю Вашей терминологии.
"FORTH внедренный в ядро ОС", "разные ОС поддерживают единственную FORTH-систему", "удалив из ОС", "поэтапное освоение ОС"...
Непонятно. Я боюсь, Вы сами придумываете язык, на котором говорите.

mak44> позволит ... снизить требование к квалификации разработчиков.
Куда уж дальше-то?!

Gudleifr> Совершенно не понимаю Вашей терминологии.
Gudleifr> "FORTH внедренный в ядро ОС",
Подбираем исходники форт-системы на том-же языке что и исходники ОС. Например на Си.
Рекомендую мою http://fpauk.narod.ru/linuxspf.10.tar.bz2.
Добавляем исходники форт-системы к проекту ядра ОС, выражается
ввод/вывод для Форта средствами ядра ОС. Начиная с терминала.
Примеры для EMIT и TYPE можно найти по сообщениям на экран во время запуска системы.
Пример опроса клавиатуры можно по ключу типа "y/n".
Как правило, для работы с файлами в ядре ОС используются стандартные Си функции.
Заработает INCLUDED - форт в ядре есть.

Gudleifr> "разные ОС поддерживают единственную FORTH-систему", "удалив из ОС"
На данном этапе, от ОС нас интересует только работа FORTH-системы.
Вызов FORTH-системы ставим как можно раньше, проверяя работоспособность.
Все последующее удаляем. Потом удаляем все, что явно не участвует в работе Форта
(типа работу с сетью). Для изощренной чистки, неиспользуемые функции выявляются
добавив к ним счетчик вызовов.

mak44>> позволит ... снизить требование к квалификации разработчиков.
Gudleifr> Куда уж дальше-то?!
Вплоть до детского сада и дурдома. Далее счетчик случайных чисел
http://ru.wikipedia.org/wiki/Генетические_алгоритмы

mak44> Подбираем исходники форт-системы на том-же языке что и исходники ОС...
Возьмем, для простоты, MS DOS (допустим, поперли у Билла исходники).
Добавляем к ним интерпретатор FORTH.
Запускаем.
DOS при старте проходит следующие стадии (очень грубо):

• Грузит образ ядра с фиксированного места диска.
• Устанавливает туда вектора прерываний.
• Инициализирует файловую систему.
• Читает список драйверов и грузит их на правах файлов.
• Запускает консоль и скармливает ей список команд начала сеанса.
• Отдает консоль пользователю.

И есть ли смысл загружать наш FORTH-интерпретатор иначе, как вместо консоли пользователя?
Доступ к ядру DOS из консоли? Таки - пожалуйста (если бы DOS его нам давать не хотела, она бы еще при старте ядра об этом позаботилась).
Драйвера на FORTH? Я думаю, если я могу написать на FORTH драйвер, я могу его и откомпилировать на нем же.
Выигрыш за счет использования в драйвере FORTH-словаря и FORTH-стека? Ну, последнее точно невозможно в многозадачных системах (стек сопрограммы не поддерживает). А первое? Львиная доля работы драйвера - обращения к DOS, BIOS и железу напрямую. Я не думаю, что у них будет настолько большая общая часть, что это окупится да еще при запрете на использование стека.
Т.е. я не вижу в данном случае преимуществ "встраивания" по сравнению с "просто наличия в системе FORTH-интерпретатора".

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

Допустим, я могу так переписать исходники MS DOS, что FORTH будет запускаться сразу после BIOS, 21h-е прерывание будет вести прямо в словарь (как и имена драйверов)?
И что это даст пользователю FORTH? Будет ли для него эта ситуация отлична от "обычного FORTH под DOS"? Ему не придется читать справочник системных функций?
И есть ли смысл FORTH-у запускать DOS вообще? Ему и BIOS-а хватит.

Допускаю, что Вы ориентировались на определенный класс ОС. Но, тогда, пожалуйста, укажите, насколько глубоко Вам удалось "встроиться" и, главное, что это дало по сравнению с запуском обычного FORTH. Только, пожалуйста, без "я могу отключить". Я и в Linux могу собрать минимальное ядро и поверх зафигачить FORTH. (Если Вы отрежете все что поверх FORTH, то какой смысл встраивать его так глубоко? Ведь можно, было бы и так отрезать).

mak44> Вплоть до детского сада и дурдома.
Представьте себе посетителе социальных сетей, имеющих доступ к перепрограммированию своей ОС.

Gudleifr> Выигрыш за счет использования в драйвере FORTH-словаря и FORTH-стека? Ну, последнее точно невозможно в многозадачных системах (стек сопрограммы не поддерживает).
На каждое ядро процессора можно повесить по очереди задач (закольцованный шитый код с их вызовами). Каждой очереди - свой стек данных и свой стек возвратов. Обработчик прерываний от других ядер может либо поддерживать семафоры (доступ к данным), либо зарегистрировать прерывание, но обработать по завершении текущей задачи. На одно ядро можно даже повесить интерпретатор. Проблема лишь одна: зачем всё это нужно? Не очень себе представляю такую систему без конкретной задачи, в режиме отладки. Уж очень легко её уронить.

Veden12> На каждое ядро процессора...
Ну это уже никак не подходит под термин "встраивание". Это уже будет целиком своя ОС.

Да, кстати, вопрос встраивания содержит любопытную ловушку:
mak44> Как правило, для работы с файлами в ядре ОС используются стандартные Си функции.
Это неверно. Стандартные Си функции идут через файловую систему и, очевидно, в ядре использованы быть не могут. (В ядре Linux, например, вместо обычной printf() используется специальная ядреная kprintf()).
Очень часто в подобных рассуждениях встречается замкнутый круг: FORTH вызывает низкоуровневую (как он думает) функцию, а та - снова FORTH. Любой, писавший свой FORTH, вспомнит, как при развертывании системы хотелось использовать еще не определенное слово.

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

Veden12> Ни в коем случае.
Ну, я пытался провести границы между писанием ОС, внедрением (тьфу, встраиванием) в ОС и писанием под ОС. Вопрос отсутствия ОС не рассматривался.

Veden12> ОС - конструктор, не имеющий своей цели.
Почему же? "Оболочка железа", которая должна обладать требуемыми параметрами.
Этак, любая "программа с вводом" (по Муру) "не имеет цели".

Gudleifr> Вопрос отсутствия ОС не рассматривался.
Некогда это было нормой. Мне кажется, изменились лишь наши знания о железе, не в лучшую сторону, увы.
Gudleifr> Этак, любая "программа с вводом" (по Муру) "не имеет цели".
Справочная система имеет цель. Её можно сформулировать. Её нужно сформулировать до начала разработки. Это программа, работающая для человека. ОС - программа для программ. Поэтому простой и понятной человеческой цели у неё нет. Я не прав?

Veden12> Некогда это [отсутствие ОС] было нормой... ОС - программа для программ. Поэтому простой и понятной человеческой цели у неё нет.
Все зависит от определения ОС... Нет, вру, от качества. Хорошей ОС любой источник/приемник сигналов/данных/команд - пользователь. (Например 'nix-ам и устройства, и программы, и пользователи кажутся файлами).
С другой стороны, за каждым документом, программой и устройством стоит человек, который рассчитывает, что ОС правильно поймет то, что он сделал. И считать, что "на том" конце программа, а не человек, ее написавший, это одна из самых больших ошибок, которую может сделать программист.
В общем, как говаривал классик, программы (тьфу, машины) прибавочной стоимости не производят.

Gudleifr> для простоты, MS DOS (допустим, поперли у Билла исходники).
Зи-за реального режима, не так проста. Вроде, был 32-х разрядная DOS.

Gudleifr> Доступ к ядру DOS из консоли? Таки - пожалуйста (если бы DOS его нам давать не хотела, она бы еще при старте ядра об этом позаботилась).
Если разработчики ядра DOS не представляют зачем пользователям может понадобятся
недокументированный доступ, это не значит, что сами пользователи не найдут ему применения.
Тем более, с возможностью его подправить. Среди интерпретаторов тоже только
Форт предоставляет свое тело в качестве библиотеки и буквально все пригодилось пользователям.

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

Gudleifr> Ну, последнее точно невозможно в многозадачных системах (стек сопрограммы не поддерживает).
С сопрограммами в Форте все в порядке. Это типа корпоративной многозадачности
которая в Форте давно применяется. Проблема при написании обработчика прерываний
на форте, при прерывании программы, которая не имеет стека данных.
Во первых, то стека данных может избавить оптимизатор. Мой оптимизатор
заменяет хранение данных на стеке на хранение в регистрах. В принципе, можно
заставить оптимизатор полностью исключить использование стека данных.
Си компилятор, примерно так и делает. Промежуточным этапом Си компиляции является
постфиксная запись. До реализации такого оптимизатора, придется создавать
механизм условного выделения стека данных в обработчиках прерываний.

Gudleifr> Допускаю, что Вы ориентировались на определенный класс ОС. Но, тогда, пожалуйста, укажите, насколько глубоко Вам удалось "встроиться" и, главное, что это дало по сравнению с запуском обычного FORTH.
Удалив все кроме поддержки FORTHа мы и получаем ОС уровня DOS-32. Но по моему,
значительно проще для освоения.

Gudleifr> Стандартные Си функции идут через файловую систему и, очевидно, в ядре использованы быть не могут.
Ну можно посмотреть, как в ядре просматриваются конфигурационные файлы.

Gudleifr> Хорошей ОС любой источник/приемник сигналов/данных/команд - пользователь. (Например 'nix-ам и устройства, и программы, и пользователи кажутся файлами).
Совершенно верно. С учётом того, что Мур предостерегал от унификации интерфейсов и лишнего кода, хорошая ОС и близко не лежит к Форту. Но из этого утверждения вовсе не следует, что целевая Форт-система (не ОС) менее эффективна как решение задачи, чем прикладная программа ОС.

Gudleifr> С другой стороны, за каждым документом, программой и устройством стоит человек, который рассчитывает, что ОС правильно поймет то, что он сделал.
Безусловно поймёт, но по своему - через призму взглядов тех, кто её написал.
Gudleifr> И считать, что "на том" конце программа, а не человек, ее написавший, это одна из самых больших ошибок, которую может сделать программист.
Если не самая большая. Не видя человека за кодом, нельзя понять чужую программу, что серьёзно препятствует развитию собственных навыков.

mak44> Зи-за реального режима, не так проста. Вроде, был 32-х разрядная DOS.
Это каким местом защищенный режим проще реального?

mak44> Если разработчики ядра DOS не представляют зачем пользователям может понадобятся недокументированный доступ, это не значит, что сами пользователи не найдут ему применения.
Речь не о документировании, а о закрытии.

mak44> Среди интерпретаторов тоже только Форт предоставляет свое тело в качестве библиотеки
Неверно. Это всегда было нормой. Например, входные точки BASIC-библиотек Спектрума были широко известны.

mak44> Словарь нужен не драйверу, а компилятору с помощью которого он создается. Причем любому, и Си в том числе. Имена меток где-то хранить надо.
Эти замечательные фразы сводят на нет все "FORTH-своеобразие". Если "словари" у всех одинаковые, в чем FORTH-бонус? (И, понятно, FORTH, компилирующий драйвер, не нуждается ни в каком "встраиваниии").

mak44> Только Си не предоставляет прямого доступа к своему словарю.
Это как это? Я не могу в программе использовать адреса функций и метки?
Доступ к процедурам компилятора? Но ведь на момент исполнения его в памяти нет, а на момент компиляции он и так все компилирует...

mak44> С сопрограммами в Форте все в порядке.
С пользовательскими сопрограммами. В ОС все немного не так.

mak44> Проблема при написании обработчика прерываний на форте, при прерывании программы, которая не имеет стека данных.
В чем проблема, если программа не может испортить стек? Вот, если может... см. предыдущий абзац.

mak44> [оптимизатор] заменяет хранение данных на стеке на хранение в регистрах.
Т.е. оптимизированная Вами FORTH-ОС будет работать только немного хуже, чем обычная. За счет удаления из FORTH-ОС FORTH-а. Логично.

mak44> Удалив все кроме поддержки FORTHа мы и получаем ОС уровня DOS-32.
Мы получаем фигню. Систему, которую, с одной стороны, очень трудно исследовать, т.к. ко всем интересностям все равно нет доступа (FORTH о них все равно ничего не знает), а во-вторых, все, что можно легко исследовать (что лежало бы выше), Вы отрезали. И, как я писал ранее, нет никакой нужды во "встраивании". Обрезаете ОС. Пишете под этот обрубок FORTH - и получаете тоже самое.

mak44> Ну можно посмотреть, как в ядре просматриваются конфигурационные файлы.
Никак, но они тут не при чем. Ввод-вывод Си работает по-другому.

P.S. Боюсь, что, Ваш эксперимент по встраиванию того, что Вы плохо понимаете, в то, что Вы тоже плохо понимаете, приведет к тому, что у Вас самого начнут требовать микроплатежи за объяснение матчасти. Извините.

mak44> Проблема при написании обработчика прерываний на форте, при прерывании программы, которая не имеет стека данных.
Интересный момент. Прерывания совершенно прозрачны если программа не хранит данные над вершиной стека. Чем же вызвана проблема?

mak44> Удалив все кроме поддержки FORTHа мы и получаем ОС уровня DOS-32. Но по моему, значительно проще для освоения.
Что осталось (или должно остаться) между Форт-системой (с компилятором, если я правильно понимаю) и железом? Драйверы нулевого уровня на Форте, продвинутые драйверы на нём же, драйверы BIOS'а или продвинутые драйверы от производителей железа под известную ОС?

Veden12> Что осталось (или должно остаться) между Форт-системой (с компилятором, если я правильно понимаю) и железом?
Практически, вся ОС, т.к.
1. данная методика сама по себе не дает возможности понять, как устроена ОС
2. попытка собрать FORTH из готовых кусков не дает возможности обеспечить его нормальным доступом к железу без ОС

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

mak44> ...
Все. Следующие разъяснения Ваших ошибок только за микроплатежи...

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

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

Kopa> Если невозможно, то тогда зачем руки и голова?
Голова, в данном случае - думать! Что является в "потрошении" ОС проблемой? Нужно ли для этого "встраивать" туда FORTH? Может, его надо грузить "до", как отладчик SoftICE? Или, даже, прошивать в BIOS? Будет ли это FORTH в привычном для нас виде? (Или уже есть готовый EFI-BIOS с готовой FORTH-оболочкой?)
А здесь - именно сугубо вредное: сделаю, что могу (понимаю), остальное либо само сделается, либо какие-нибудь дураки денег заплатят и это будет их проблемой... И FORTH, к сожалению, такой подход поощряет.
В итоге имеем вечное: делается не то, что нужно, а то, что легко.

Gudleifr> Может, его надо грузить "до", как отладчик SoftICE? Или, даже, прошивать в BIOS?
Нет, нет, только не в BIOS!
Gudleifr> Будет ли это FORTH в привычном для нас виде?
Поначалу – конечно, да.

Gudleifr> (Или уже есть готовый EFI-BIOS с готовой FORTH-оболочкой?)
Вы говорите про EFI, соответствующий стандарту EFI 2.0+? Не встречал таких. А то, что ныне подают под этим соусом, хоть и поддерживает HID, но в остальном хорошо умеет лишь то, без чего Вы не сможете запустить Ваше приложение. (Рекламу – в печь.) Впрочем, этого уже достаточно для развёртывания Форт-системы.

На мой взгляд, гораздо интереснее сама по себе та среда, в которой окажется запущенное EFI-приложение. Слово "сегмент" удаляем из своего словаря сразу. Ну нет их. Совсем. Получаем сколько есть гигабайт линейной памяти. Любые порты, регистры контроллеров - без ограничений. Процессор x86-64 с 16-тью 64-битными регистрами (можно и SSE). Кто-то на пробу уже начал писать простенькие игры... Я – инструментальный монитор. Куда мы без паяльника и плоскогубцев?

Veden12> Кто-то на пробу уже начал писать... Я...
Т.е. имется некое сообщество с некоторой политической программой?

Veden12>> Кто-то на пробу уже начал писать... Я...
Gudleifr> Т.е. имется некое сообщество с некоторой политической программой?
Какая была политическая программа у людей, в своё удовольствие осваивавших i8080, Z80, i86x86? Очень простая: "Сделай сам". Нет никакого организованного сообщества и, надеюсь, не будет.

Veden12> Какая была политическая программа у людей, в своё удовольствие осваивавших i8080, Z80, i86x86?
Пардон, забыл бугагашеньку поставить.

А, с другой стороны, вот все плохо и кончилось... Любой прорыв заканчивался переуступкой прав и закрытием проекта в пользу маркетоидов. Где Canon Cat, NeXT, Радио-86РК..?
ИМХО, нужно не просто что-то делать, но и вовремя отрезать труднореализуемые в домашних условиях фичи, регулярно выкладывая остальное на всеобщее обозрение.