| Forth http://fforum.winglion.ru/ |
|
| ForthOS. Для чего оно надо? http://fforum.winglion.ru/viewtopic.php?f=16&t=651 |
Страница 4 из 15 |
| Автор: | Pretorian [ Пт апр 13, 2007 14:26 ] |
| Заголовок сообщения: | |
Mihail писал(а): mOleg писал(а): Mihail писал(а): Хотелось-бы чтобы в ядре системы логическое адресное пространство совпадало с физическом. ??? зачем ??? Чтобы иметь простой доступ к физической памяти. Кстати с форт ос как раз это может запросто проканать, отсюда и скорость будет, ведь не нужно будет оси хлопать страницами. Форту же побарабану, он компилирует приложение в свой словарь. |
|
| Автор: | mOleg [ Сб апр 14, 2007 23:34 ] |
| Заголовок сообщения: | |
Mihail писал(а): mOleg писал(а): Mihail писал(а): Хотелось-бы чтобы в ядре системы логическое адресное пространство совпадало с физическом. ??? зачем ??? Чтобы иметь простой доступ к физической памяти. не вижу смысла. Вообще тут нужен просто нормальный менеджер памяти Mihail писал(а): Базовый уровень интеллектуальной загрузки, это не прикладная форт-система.
Достаточно того, что она загрузит все что надо по средствам команды INCLUDED. Если хочется ускорить загрузку системы можно сделать сохранение загруженного образа рабочей системы в памяти на диск и затем загружать его. Вообще, это базовая часть ФортОС должна располагаться в биосе. Еще там могут быть некие возможности для исследования аппаратных средств. не понимаю. Дело в том, что уже для простой инициализации устройств нужно будет достаточно много кода, на фоне которого многозадачность не будет занимать много места |
|
| Автор: | mOleg [ Сб апр 14, 2007 23:36 ] |
| Заголовок сообщения: | |
Pretorian писал(а): Кстати с форт ос как раз это может запросто проканать, отсюда и скорость будет, ведь не нужно будет оси хлопать страницами. Форту же побарабану, он компилирует приложение в свой словарь.
ОС должна быть стабильной, по-сути неубиваемой 
если ядро будет доступно прикладным программам .. Вобщем нужно таки определиться что такое ОС и чего от нее хочется. Для обсуждаемых ранее вещее есть понятия там "монитор" - помните для Радио86-РК или БИОС. Но не ОС! |
|
| Автор: | Hishnik [ Сб апр 14, 2007 23:43 ] |
| Заголовок сообщения: | |
/me вспоминает запуск системы месячной давности. Форт-процессор, имеющий аппаратную защиту от переполнения/исчерпания стека, нарвался-таки на переполнение - каждым проходом по циклу работы программы оставалось одно число. Замечено было не сразу - долгое время процессор обнаруживал (аппаратно) переполнение, падал в исключение, обрабатывал его сбросом стека (аппаратно же) и переходом на вектор инициализации. Сам факт наличия ошибки был обнаружен случайно. А тут - неубиваемость, неубиваемость... назвать его Маклаудом, что ли? 
|
|
| Автор: | in4 [ Вс апр 15, 2007 19:51 ] |
| Заголовок сообщения: | |
В виртуалке надо отлаживать... Потом на инструменталке запускать!!
А сам-то я так и не делаю...  ...Но хочу, хочу!
|
|
| Автор: | Hishnik [ Вс апр 15, 2007 20:03 ] |
| Заголовок сообщения: | |
Все теория! В рабочем проекте часто нет места тестированиям моделей, особенно на завершающих этапах.
|
|
| Автор: | in4 [ Вс апр 15, 2007 20:15 ] |
| Заголовок сообщения: | |
Значит - защита на уровне задач и системный отладчик...
|
|
| Автор: | Hishnik [ Вс апр 15, 2007 20:24 ] |
| Заголовок сообщения: | |
Я к тому, что устойчивость обеспечивается на разных уровнях и разными способами. В x86 все тянется опять-таки с 8086, потому что программы реального режима все еще запускаются. Надо защитить задачу при полной свободе в аппаратуре? Легким движением руки шины памяти разносятся по разным выводам ПЛИС - и вопрос решен раз и навсегда. |
|
| Автор: | in4 [ Пн апр 16, 2007 03:01 ] |
| Заголовок сообщения: | |
А если нужно взаимодействие параллельных процессов? Часть кристалла ждет другую. Надо это хотя бы отследить и желательно откорректировать! Похоже, в интерактивной системе всегда должен быть процесс(неприбиваемый), взаимодействующий с оператором и позволяющий восстанавливать работоспособность системы. В тривиальном случае это ресет. В более продвинутом, но тоже тривиальном - watchdog... 
Хотелось бы такой процесс иметь и в нашей ОС. Чтоб можно было любую задачу перезапустить в тех же или похожих условиях. И желательно иметь удобные средства отладки на уровне системы. Просмотр и эмуляцию всех событий, просмотр и редактирование всех ресурсов программы... Поскольку отладка тесно связана с программой, а программа на Форте - вот ответ на эхотаг...
|
|
| Автор: | Mihail [ Пн апр 16, 2007 14:23 ] |
| Заголовок сообщения: | |
mOleg писал(а): Вообще тут нужен просто нормальный менеджер памяти Чтобы загрузить менеджер памяти достаточно ALLOC. Что мы выигрываем от несовпадения логической и физической памяти? Менеджер памяти должен знать о физической памяти? Цитата: Дело в том, что уже для простой инициализации устройств нужно будет достаточно много кода, на фоне которого многозадачность не будет занимать много места
Нужно только винчестер и клавиатура. В bootos28 это где-то 5K исходного кода. Во первых многозадачность может быть разной. Комуто быдет достаточно корпоративной, комуто нужно с вытеснением, с приоритетами или без и т.д. Во вторых дело принципа. По мелочам можно понадобовлять столько, что примитивный загрузчик превратится в монстра. |
|
| Автор: | Hishnik [ Вт апр 17, 2007 01:06 ] |
| Заголовок сообщения: | |
in4 писал(а): А если нужно взаимодействие параллельных процессов? Часть кристалла ждет другую. Надо это хотя бы отследить и желательно откорректировать!
Такие вещи лучше отслеживать аппаратно. А еще лучше - архитектурно. Кстати, потенциальные электрические конфликты просто не дадут развести такой кристалл. |
|
| Автор: | mOleg [ Вт апр 17, 2007 01:29 ] |
| Заголовок сообщения: | |
Mihail писал(а): Чтобы загрузить менеджер памяти достаточно ALLOC. под операционной системой достаточно - но если хотеть работать в самостоятельном режиме полета нужен собственный менеджерMihail писал(а): Что мы выигрываем от несовпадения логической и физической памяти? 1) разделяются адресные пространства работающих под ОС задач 2) увеличивается размер виртуального адресного пространства системы 3) увеличивается надежность работы системы Вообще сейчас говорить о полноценной ОС без менеджера памяти просто не серьезно. Это вообще основа операционной системы. Mihail писал(а): Менеджер памяти должен знать о физической памяти? он ее должен распределять. Вообще менеджер памяти видит физическую память, а предоставляет виртуальную ( в плане адресов и места хранения данных ) Mihail писал(а): Цитата: Дело в том, что уже для простой инициализации устройств нужно будет достаточно много кода, на фоне которого многозадачность не будет занимать много места Нужно только винчестер и клавиатура. В bootos28 это где-то 5K исходного кода. код коду рознь. Но все-таки не стоит забывать о DMA и обработке хотя бы базовых прерываний. К тому же видиосистема есть еще. Mihail писал(а): Во-первых, многозадачность может быть разной. речь шла как минимум о многопоточности Но более распространенной сейчас является вытесняющая и на нее надо ориентироваться.Mihail писал(а): По мелочам можно понадобовлять столько, что примитивный загрузчик превратится в монстра.
речь идет о СИСТЕМЕ а не о ее загрузчике. |
|
| Автор: | вопрос [ Вт апр 17, 2007 09:10 ] |
| Заголовок сообщения: | |
mOleg писал(а): Вообще сейчас говорить о полноценной ОС без менеджера памяти просто не серьезно. Это вообще основа операционной системы.
Основа Виндоуз - менеджер виртуальных машин 
|
|
| Автор: | Mihail [ Вт апр 17, 2007 13:38 ] |
| Заголовок сообщения: | |
mOleg писал(а): Mihail писал(а): Чтобы загрузить менеджер памяти достаточно ALLOC. под операционной системой достаточно - но если хотеть работать в самостоятельном режиме полета нужен собственный менеджерЧто за самостоятельном режиме полета? И что за собственный менеджер? Цитата: Mihail писал(а): Что мы выигрываем от несовпадения логической и физической памяти? 1) разделяются адресные пространства работающих под ОС задач Адресные пространства работающих под ОС задач не зависят от адресные пространства ядра ОС. Цитата: 2) увеличивается размер виртуального адресного пространства системы Ядру системы со всеми загруженными компонентами 1M, как говорится, за глаза и за уши. Цитата: 3) увеличивается надежность работы системы Если в ядре ошибка, то работать не будет в любом случае. Цитата: Mihail писал(а): По мелочам можно понадобовлять столько, что примитивный загрузчик превратится в монстра. речь идет о СИСТЕМЕ а не о ее загрузчике. Смысл Форта в том и заключается, что у него нет четкой грани между системной и прикладной частями. Компанеты системы должны загружаться как приложения соответственно и отлаживаться могут как приложения. Загрузчик нам придает гибкость. Мы можем сразу загрузить приложение, а можем СИСТЕМУ более высокого уровня, причем любую, хоть Linux. А главное, у нас нет другого пути. Монолит на все случаи жизни, мы реализовать не в состоянии. СИСТЕМОЙ которую этот загрузчик загружает может быть ситемой виртуальных форт-машин. Эти форт-машины уже располагаются в виртуальном адресном пространстве, но имеют условную совместимость с загрузчиком и разделяют с ним единое подмножество процедур. |
|
| Автор: | in4 [ Вт апр 17, 2007 15:22 ] |
| Заголовок сообщения: | |
Хищник писал(а): Надо защитить задачу при полной свободе в аппаратуре? Легким движением руки шины памяти разносятся по разным выводам ПЛИС - и вопрос решен раз и навсегда. in4 писал(а): А если нужно взаимодействие параллельных процессов? Т.е. твои раздельные части должны быть связаны. И аппаратно и логически. Хищник писал(а): Такие вещи лучше отслеживать аппаратно. А еще лучше - архитектурно. Кстати, потенциальные электрические конфликты просто не дадут развести такой кристалл.
Считаем систему сложной и программно-аппаратной. Даже если обнаружил аппаратно конфликт программных процессов(скорее всего, следствие ошибки при разработке ПО), может быть несколько вариантов его устранения. Конечно, хорошо иметь безошибочную программу/аппаратуру, которая правильно восстанавливается от ошибок! А реально? В многозадачке можно(и, похоже, нужно) выделить задачу для взаимодействия с пользователем, который решает конфликты. Это я и предлагаю заложить в дизайн ФортОС. Кроме этого, программу/аппаратуру, получается, надо изначально делать без ошибок.
А как? Общей методики мне почему-то не попадалось. Каждый старается, как может!
Многообещающий подход сводить программирование к КА. Еще отдельная сказка - обработка ошибок и исключительных ситуаций... Скоро снова тему такую заведу! Порывался несколько раз, но обсуждения быстро утихали, не достигнув конструктивного решения... |
|
| Страница 4 из 15 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|