Forth http://fforum.winglion.ru/ |
|
Какие бывают ОС и что там делать Форту http://fforum.winglion.ru/viewtopic.php?f=16&t=685 |
Страница 21 из 22 |
Автор: | вопрос [ Пт июн 06, 2008 09:22 ] |
Заголовок сообщения: | |
Kamikaze писал(а): А вот и не! ПАТАМУШТА ФОРТ!
Спорим - каждый из участников уже над своей ОСью задумался! тем не менее очень желдателен общий проект - нужно поработать не над осью а над собой - чтобы получилась ось |
Автор: | Владимир [ Пт июн 06, 2008 11:42 ] |
Заголовок сообщения: | |
Kamikaze писал(а): Спорим - каждый из участников уже над своей ОСью задумался!
Ну если честно, то есть малЕнько... Видимо, действительно, "патамушта Форт". |
Автор: | Mihail [ Сб июн 07, 2008 18:04 ] |
Заголовок сообщения: | |
Kamikaze писал(а): с тупого копирования готовых чужих решений (с асма Колибри, с Си Минукса, или что мы там в конце концов выберем за образец)
Кому что ближе. При отработки методик встраивания, эту процедуру легко можно применить для разных ОС. Внедрение Форта в ОС можно выдать за правило хорошего тона. При этом следует обеспечить максимальную совместимость на уровне исходных текстов. Сомневаюсь, что кто-то мне поможет с Колибри (на данном этапе). Для внедрения Форта в ОС на GCC: Можно воспользоваться http://fpauk.narod.ru/linuxspf.10.tar.bz2 Для представления всех процедур ядра в виде словарных статей можно интерпретировать мап-файл в рантайме. Пример интерпретатора мап-файл можно найти в кросс-компиляторе для MSP: http://fpauk.narod.ru/spmfor.1.rar ключевое слово Warning[w6]: (которое просто присутствует в начале мап-файла) используется в качестве запуска интерпретатора. Смотри: devel\~mak\MSP430\SRC\tc.f Чтобы систему собрать с помощью ЦК Фора можно: 1. заставить Форт воспринимать листинги. 2. Дизассемблировать ядро средствами Форта в ядре. За тем можно постепенно заменить старые функции ядра на любые эквивалентные форт-определения. Вообще, кого к кому добавили, будет иметь чисто историческое значение. Не вижу сдесь особых проблем. Самое сложное (по моему) это заставить видеть ядро ОС из приложений (доступ на чтение и передачи управления, но с защитой от записи) Но это самое вкусное. Ради этого все и делалось. Ядро с фортом становится частью каждого приложения. |
Автор: | Kamikaze [ Чт июн 12, 2008 22:27 ] |
Заголовок сообщения: | |
А не кажется ли вам, что в вопросе о Форт-ОС мы сделали ошибку, слишком рано разбежавшись по персональным задумкам? Код: Одно слово в предостережение руководителям проектов: если Вы наблюдаете за любым опытным Форт-программистом, то не надо беспокоиться насчет того, что он тратит слишком много времени на планирование... СОВЕТ ... Для приверженцев Форта (без "традиционной" подготовки): Воздерживайтесь от кодирования столь долго, сколько сможете выдержать. Л.БРОУДИ. СПОСОБ МЫШЛЕНИЯ - ФОРТ. PS И там еще много про это - читайте первоисточники!!! PPS Предлагаю создать две отдельных темы для совместных неспешных размышлений в заданном направлении - "Концепция ОСи" и "Технические детали" (как оно должно выглядеть и что будет там у него внутри). Код: Концептуальная модель - это воображаемое решение проблемы. Это - взгляд на то, как система `должна` работать. Это - ответ на все требования и ограничения.
|
Автор: | Kamikaze [ Пт июн 13, 2008 03:08 ] |
Заголовок сообщения: | |
Информация к размышлениям (c подачи полуночного IRC): [00:43] <in4> http://www.ru2.halfos.ru/core/articles/core003.html см. также: http://www.ru2.halfos.ru/core/articles/core001.html http://www.ru2.halfos.ru/core/articles/core002.html и: Код: K42 — исследовательская операционная система с открытым исходным кодом. Предназначена для работы на 64-разрядных многопроцессорных системах с когерентностью кеш-памяти. Разрабатывается в Исследовательском центре IBM имени TJ Watson. Основное внимание в этой ОС уделяется производительности и масштабируемости системного ПО на крупномасштабные NUMA многопроцессорные компьютеры с разделением памяти.
K42 использует микроядерную архитектуру. K42 состоит из маленьких компонентов — обработчиков исключительных ситуаций, которые обслуживают микроядро, быстрого механизма межпроцессорного взаимодействия (IPC) называемого защищённым вызовом процедур (PPC), и серверов для всех остальных компонентов ОС. Эти серверы существуют в отдельных адресных пространствах и зависят от скорости механизма IPC. http://ru.wikipedia.org/wiki/K42 http://domino.research.ibm.com/comm/research_projects.nsf/pages/k42.index.html |
Автор: | Kamikaze [ Пт июн 13, 2008 03:38 ] |
Заголовок сообщения: | |
И маленькое замечание в догонку к ранее предложенной идее о "WORD-ориентированной" OS: Если присмотреться в каком направлении продвигается ОСестроение, то складывается впечатление, что ОСи "мельчают". Причем это не только множественность ЛИНУКС-клонов, но и все более многочисленные сборки ВИНДЫ. Ну так мог бы здесь ФОРТ сказать свое СЛОВО? И к чему бы это привело? Думаю как раз к той цели, которую ОСестроение еще даже не осознало: к индивидуальной пользовательской операционной системе Долой конвеерную сборку! Хочу самозатачиваемую ОСь, уникальную, как РПГ-аватар! |
Автор: | in4 [ Пт июн 13, 2008 11:26 ] |
Заголовок сообщения: | |
Kamikaze писал(а): к индивидуальной пользовательской операционной системе В индивидуальной ОС есть свои несомненные плюсы, но есть и существенный минус - несовместимость. Прийдешь на другой комп - и всё. На нем же всё другое!
Должно быть, лучше говорить об индивидуальном интерфейсе ОС. Но и какой-то общий стандарт (для гостей/друзей) тоже желательно поддерживать... |
Автор: | Kamikaze [ Пт июн 13, 2008 11:59 ] |
Заголовок сообщения: | |
in4 писал(а): ...существенный минус - несовместимость. Не-а - это "несовместимость" как у либ от разных авторов. Речь о том, что Windows Media Player всегда тот же, и IE, и др. и пр. - все версии программ "дискретны". Да и при сборке Линукса "под себя" картина аналогичная - разве что разные версии... либ. У нас же заменой какого-нибудь слова будет достигаться эффект индивидуальной сборки: хочу - либу от Черезова, хочу - от Якимова. Просто, как смена скинов в Winamp. Правда индивидуальность ядра ОС - уже, конечно, дело опытных фортеров. in4 писал(а): Прийдешь на другой комп - и всё.
Инет нужен... |
Автор: | Mihail [ Пт июн 13, 2008 13:23 ] |
Заголовок сообщения: | |
in4 писал(а): существенный минус - несовместимость. Это на первом этапе. Далее можно прийти к общим стандартам в результате заимствования, адаптации и отсеивания морально устаревшего. Дело в том, что у нас все равно другого пути нет. Не верю я, что мы все зарание продумаем так, что останется только тупо кодировать гениальные замыслы. in4 писал(а): Должно быть, лучше говорить об индивидуальном интерфейсе ОС.
Для пользователя, желательно чтобы совместимость была на более высоком уровне работы системы. Однако, проще производить замену мелких процедур (типа общего назначения). |
Автор: | in4 [ Пт июн 13, 2008 16:52 ] |
Заголовок сообщения: | |
Kamikaze писал(а): Не-а - это "несовместимость" как у либ от разных авторов. К сожалению - проблема намного глубже...
Попробуй поработай на компе, где пререназначены горячие клавиши обычных программ (это если ты пользуешься клавиатурой) или названы по-другому и переставлены пункты в меню. Удобно будет? А если вместо Windows Media Player стоит Проигрыватель-Только-Wav ? Удобно? А чел просто под себя настроил. Ему остальное не надо... И насчет либ. В Линуксе это ИМХО даже более серьезная проблема, чем в SPF. В первую очередь из-за количества и сложности программ. Да что я говорю - ты ж сам статью постил о Линуксе и несовместимости версий либ - программ. Итак - надо поддерживать минимум две ветки набора либ/программ - одну пользовательскую, а другую - стандартную. Хотя последней на специализированных системах может и не быть. А где два набора - там можно добавить еще один! Вот в этом и будет одна из особенностей ОС и ее следование современным тенденциям в работе с компами. |
Автор: | Kamikaze [ Пт июн 13, 2008 17:55 ] |
Заголовок сообщения: | |
in4 писал(а): К сожалению - проблема намного глубже...
Всё, не выдержал я и собрал фантазии о Форт-ОС до-кучи! Если определимся, что стоит их развивать дальше, то попросим перенести в отдельную ветку, а пока выложу здесь: |
Автор: | Kamikaze [ Пт июн 13, 2008 17:55 ] |
Заголовок сообщения: | |
Кому нужен еще один клон операционки в стиле "Пингвиндовс"? Только не нам! Начнем с того, что связи со спецификой языка Форт, вопрос о проектировании Форт-ОС следует рассматривать на двух взаимосвязанных, но совершенно различных по целям и задачам уровнях. Это: Уровень I. Оболочка ОС (интерфейс) Уровень II. Форт-ядро ("API") Уровень I. "Что снаружи?": Оболочка обеспечивает концептуальный пользовательский интерфейс. Задачи: п.1 Широкий диапазон стиля работы (от пользователя до программиста): Допускаются все варианта исполнения слов: 1) исполнение готового библиотечного кода (тип шитого кода?) 2) компиляция "на лету" из форт-исходников 3) режим консольного ввода п.2а Отсутствие файловой системы в среде ОС: 1) СЛОВО вместо файла (аналогия не прямая!!!) 2) СЛОВАРЬ вместо директории/каталога (аналогия не прямая!!!) Т.е. ФС отсутствует логически,- работая на физическом уровне ядра ОС (и оставаясь реально доступной, напр., при загрузке HDD из-под под другой операционки) При этом ядро ОС предоставляет Форт-API единый "логический файл" (можно сказать - процесс, обратный работе утилит DriveSpace и Stacker) "Попадая внутрь" Форт-ОС, каждый файл получает свой заголовок словарной статьи. Но только это не стандартная словарная статья форта, а аналогичная (прописываемая "поверх") структура, одного из четырех типов: 1а) SWAP-блоки, подготовленные для загрузки в ОЗУ 1б) специальные словари уже откомпилированных либ 2) обычные либы со словами-исходниками (СЛОВАРИ:\СЛОВА) 3) единая БД (специальный словарь) - база текстовых данных и стороннего "не форт" кода (jpg, mp3, xls...) п.2б Особая логическая среда для работы в системе, основанная на идеологии языка Форт: NB Чтобы не путаться, далее обозначим эти "бывшие" файлы, "заключенные" в оболочку словарной статьи 4-го типа, как "ФАЙЛИКИ" (мнемообраз: прозрачные пакетики-файлики для бумаг) Причем словарная статья файлика содержит два дополнительных специальных поля: 1) поле типа файлика (аналог файлового расширения, но получаемый непосредственно из заголовка самого файла) 2) поле адреса слова-обработчика файлика Кроме того все четыре типа словарных статей-оболочек имеют единые специальные поля: 1) поле даты_время создания/модернизации слова(словаря) + его уникального числового_идентификатора Со стороны ФС ядра это поле является: а) дата_время == имя каталога файла б) числовой_идентификатор == некий технический индекс данного файла (напр. его начальный адрес в FAT) Единое именование директорий по дате_времени призвано не только стандартизовать однозначное соответствие файлика (словаря, бинарного кода или текста-исходника) его реальному имени и месту в ФС, но и позволит организовать бесконечный откат к "предыдущей рабочей конфигурации" самой ОС. 2) поле стековой нотации слова: (стек до исполнения слова --> стек после исполнения слова). В идеале данное поле могло бы вычисляться и подставляться специальной программой-отладчиком (конечно, увы, только количество) 3) поле размера сегмента ОЗУ, выделяемого слову форт-ядром ОС (?) 4) поле связи с иконкой/цветом_отображения/дополнительными_эффектами (звук,флеш...) 5) поле "иерархии свертки", определяющее режим просмотра словаря (аналогичный применению фильтров у вьювера). Имеется в виду разные уровни просмотра словарей: так, к примеру, если в либе основное (рабочее) слово RUN будет иметь значение данного поля True, а все остальные, вспомогательные,- False, то по желанию пользователя при просмотре словаря, содержащего это слово, все остальные слова либы могут не отображаться. 6) поле профиля пользователя,- задающее уровень доступа к словам (root, guest...), а также множественные профили работы в системе (аналог виртуальных рабочих столов). Сочетание полей 5 и 6 дает также дополнительные возможности: В отличии от обычных операционок (с "визуализацией ФС") пользователь Форт-ОС имеет свою персональную "область видимости" системы. Точнее даже не одну, а несколько таких областей - несколько точек зрения скрывающих не нужную пользователю информацию. (Примерно как если вместо фотографии местности со спутника использовать специализированные карты, составленные по этой фотографии) п.3 "Либа-фундамент" для "эксплорера" - простая "базовая" библиотека вывода на экран, задающая стиль графического Drag & Drop IDE. Собственно, заложенные в Форт-ОС вышеперечисленные принципы уже определяют функциональность рабочего стола (т.е. эксплорера), как: 1) системного проводника 2) диспетчера базы данных, основанной на словарях уровня оболочки, и поддерживающей множественные вложения (DataBase 3D !) 3) редактора простых скриптов, автоматизирующих работу в системе (nnCron!!!) - пользовательский уровень программирования 4) форт-редактора-IDE (!) - профессиональный уровень программирования Причем ничто не запрещает проводнику раскрывать вложенность слов вплоть до слов из ядра форт-системы ("там, аж до самого низа - одни белые слоны!") При этом, для определяющих циклы и ветвления "низкоуровневых" слов задается графическая реализация по типу "блок-схем" (отдельный класс символики в поле связи с иконкой) Правда сам дизайн рабочего стола лучше "по-умолчанию" оставить лаконично-функциональным - предоставив возможность сторонним программистам-скинописателям добавлять всяческие красивости. п.4 "ФОРТочки" Увы, от привычных окон, уже никуда не денешься. Тем не менее хотелось бы перемен. Так, для окна, используемого программистом в режиме редактора, хотелось бы видеть панельки, показывающие текущее состояние стека (стеков). Кстати, а как насчет отдельного стека строк, как в либах Якимова? Однако заранее определять внешний вид ФОРТочек, пожалуй, преждевременно - в процессе реализации оптимальное решение само проявится... Здесь должен быть п.5 - но пока не ясно о чем... Уровень II. "Что внутри?": API (форт-ядро) встраивается поверх готового моно-ядра от операционной системы ...(?) К нему же прикручиваются и драйвера, не вошедшие в моно-ядро. При этом само форт-ядро - модульное, с предусмотренной возможностью выбора "на ходу" конфигурации подключаемых модулей. В задачи данного "консольного" режима, доступного на этапе загрузки входит: 1) выбор диапазона функциональности ОС (от "облегченного" до "полнофункционального") 2) выбор профиля пользователя (напр. "детский", с запретом на редактирование исходников) 3) "бесконечный" откат назад по времени на требуемую дату Задачи форт-ядра: п.1 "Базовый набор задач" - драйверы/железо, память, многозадачка и т.д. (опустим подробности по данным вопросам поскольку они уже получили развитие в других ветках) п.2 Механизм "подмены" файловой системы носителя (HDD, Flash, CD) концепцией словарей форт-системы. п.3 Стандартизация механизмов работы из среды ОС с периферией, файловой системой, локальными сетями(Ethernet,USB) и Интернет - упрощенный универсальный интерфейс ввода-вывода через подключенные "службы"(программы обработки). К примеру вариант некоего тройного "синхронизированного" (т.е. с единым идентификатором для отправляемой/принимаемой порции данных) буфера: 1) буфер адреса_параметров (источник/приемник_команда) 2) буфер данных 3) буфер управления_состояния (флаги??) Типа: (1) Принтер_печатай (2) (йцукен) (3) {return} (ОК) (1) Почта_ВасьяПупкин@фортхос.ру (2) (Я уже все распечатал. Вася) (3) {return} (письмо отправлено) п.4 Задачи совместимости - эмуляторы Вин/Линукса/Мака, языков программирования и пр. Однако это уже, естественно, относится не к первым релизам ОС, и само ТЗ на их разработку пока не рассматриваетcя. Просто о вопросе совместимости следует помнить... NB1 А дальше, похоже, пошла одна НФ ... п.5 "Псевдонейросеть" Как бы не повышалось быстродействие процессоров, скорость доступа и объемы винчестеров, но обработка больших массивов информации по-прежнему остается сложной задачей. Нет, речь не конкретно о базах данных, а просто "о больших объемах чего-бы-то-ни-было" (например: толстеющий реестр Windows, поиск в папках с mp3-файлами...). А что мешает, взяв за образец работу нескольких ОС под VMWare, изначально поставить задачу МНОГОЯДЕРНОЙ ОС? Т.е. поверх единого моно-ядра операционки загружать (одновременно!) несколько форт-ядер ОС и их оболочек ? При этом искусственное ограничение объема доступных данных в каждой из параллельно работающих операционок можно компенсировать "межъядерным взаимодействием" между получившимися "кластерами" (наподобии нейросети)... NB2 ...и чистое фэнтези: п.6 "Виртуальный форт-процессор" А все-таки: нельзя ли одно из ядер современных многоядерных процессоров программно "оптимизировать" и загрузить исключительно на работу со стеками Форт-ОС? |
Автор: | in4 [ Пт июн 13, 2008 18:50 ] |
Заголовок сообщения: | |
Идеи хорошие... Посматривать буду обязательно. Но буду делать свое. Кстати, есть некоторые пересечения идей. Так что будет чем обменяться! |
Автор: | Kamikaze [ Сб июн 14, 2008 01:33 ] |
Заголовок сообщения: | |
in4 писал(а): ...Но буду делать свое.
Хм... А что - есть прецеденты создания ОПЕРАЦИОННОЙ СИСТЕМЫ в одиночку? Или КОННЕЧНОГО ПРОДУКТА на форте? Хотя в последнем случае - SPF & nnCron. Что ж: "патамушта форт" шанс имеется - только почему им до сих пор никто не воспользовался? |
Автор: | in4 [ Сб июн 14, 2008 01:59 ] |
Заголовок сообщения: | |
Kamikaze писал(а): А что - есть прецеденты создания ОПЕРАЦИОННОЙ СИСТЕМЫ в одиночку? Да. colorForth Мура. Kamikaze писал(а): Или КОННЕЧНОГО ПРОДУКТА на форте? Тут побольше будет. Даже у меня была пара готовых программ. Для внутреннего использования, но все-таки!
Главное - начать! Если людям понравится - они потянутся... |
Страница 21 из 22 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |