Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
смотря что.
Для того, чтобы отладить ФВМ, и менеджер памяти можно использовать СПФ.
Собственно, прелестью предложенной модели является возможность отлаживать практически всю многозадачку без привлечения большого количества инструментов - достаточно СПФа
смотря что.
Для того, чтобы отладить ФВМ, и менеджер памяти можно использовать СПФ.
Собственно, прелестью предложенной модели является возможность отлаживать практически всю многозадачку без привлечения большого количества инструментов - достаточно СПФа
|
|
|
|
Добавлено: Пн июн 09, 2008 07:40 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): что понимать под инструментами?
На чем писать будем код.
[quote="mOleg"] что понимать под инструментами? [/quote]
На чем писать будем код.
|
|
|
|
Добавлено: Пн июн 09, 2008 06:01 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Pretorian писал(а): Это все хорошо, что дошли до памяти, но надо же с инструментами для форт ос определится.
что понимать под инструментами?
Начинать НЕОБХОДИМО с модели памяти - это база, остальное частично вытекает из того, как система видит память.
[quote="Pretorian"]Это все хорошо, что дошли до памяти, но надо же с инструментами для форт ос определится.[/quote]
что понимать под инструментами?
Начинать НЕОБХОДИМО с модели памяти - это база, остальное частично вытекает из того, как система видит память.
|
|
|
|
Добавлено: Сб июн 07, 2008 17:45 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Это все хорошо, что дошли до памяти, но надо же с инструментами для форт ос определится.
Это все хорошо, что дошли до памяти, но надо же с инструментами для форт ос определится.
|
|
|
|
Добавлено: Сб июн 07, 2008 07:04 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Глобальная таблица трансляции адреса, локальная таблица трансляции адреса, а они не перекроются?
эффективный адрес относителен по отношению к локальной таблице, а адрес последней относителен по отношению глобальной, т.е. для вычисления адреса надо два сложения применить.
Правильно?!
Глобальная таблица трансляции адреса, локальная таблица трансляции адреса, а они не перекроются?
эффективный адрес относителен по отношению к локальной таблице, а адрес последней относителен по отношению глобальной, т.е. для вычисления адреса надо два сложения применить.
Правильно?!
|
|
|
|
Добавлено: Пт июн 06, 2008 19:01 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
короче, таблиц трансляции адресов (или как их лучше обозвать? ) будет столько, сколько у нас пользовательских процессов + количество процессов ядра (их может быть много, так как это зависит в частности от того, как устроено ядро).
короче, таблиц трансляции адресов (или как их лучше обозвать? ) будет столько, сколько у нас пользовательских процессов + количество процессов ядра (их может быть много, так как это зависит в частности от того, как устроено ядро).
|
|
|
|
Добавлено: Пт июн 06, 2008 18:54 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Alexander писал(а): А насчет памяти мыслится так: конечно плоская модель уступает модели с сегментацией, только вот что понимать под сегментом? еще раз, не сегментная, а ТИПА СЕГМЕНТНАЯ, в данном случае есть некая ячека в памяти, которая содержит базовый адрес, блока памяти, а мы адресуем память относительно содержимого этой ячейки и смещения внутри блока. Читайте про селекторы в ix86 архитектуре. Alexander писал(а): Предлагаю под сегментом понимать адресное пространство выделенное для процесса. НЕТ! для каждого процесса будет потенциально 2^32 селекторов (понятно, что не все их придется в реальности использовать). Alexander писал(а): По поводу ID:DISP, тут мне мыслится, что под ID надо понимать идентификатор процесса,
нет, ID - это точка входа, а DISP смещение при доступе к памяти по записи и чтению.
[quote="Alexander"]А насчет памяти мыслится так: конечно плоская модель уступает модели с сегментацией, только вот что понимать под сегментом?[/quote] еще раз, не сегментная, а ТИПА СЕГМЕНТНАЯ, в данном случае есть некая ячека в памяти, которая содержит базовый адрес, блока памяти, а мы адресуем память относительно содержимого этой ячейки и смещения внутри блока. Читайте про селекторы в ix86 архитектуре.
[quote="Alexander"]Предлагаю под сегментом понимать адресное пространство выделенное для процесса.[/quote] НЕТ! для каждого процесса будет потенциально 2^32 селекторов (понятно, что не все их придется в реальности использовать). [quote="Alexander"]По поводу ID:DISP, тут мне мыслится, что под ID надо понимать идентификатор процесса,[/quote]
нет, ID - это точка входа, а DISP смещение при доступе к памяти по записи и чтению.
|
|
|
|
Добавлено: Пт июн 06, 2008 18:52 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А насчет памяти мыслится так: конечно плоская модель уступает модели с сегментацией, только вот что понимать под сегментом?
Предлагаю под сегментом понимать адресное пространство выделенное для процесса. Следовательно в ядре должна быть некая таблица для хранения инфы.
По поводу ID:DISP, тут мне мыслится, что под ID надо понимать идентификатор процесса, а под DISP точки входа в функции, к которым можно обращаться из вне, по началу из ядра.
А насчет памяти мыслится так: конечно плоская модель уступает модели с сегментацией, только вот что понимать под сегментом?
Предлагаю под сегментом понимать адресное пространство выделенное для процесса. Следовательно в ядре должна быть некая таблица для хранения инфы.
По поводу ID:DISP, тут мне мыслится, что под ID надо понимать идентификатор процесса, а под DISP точки входа в функции, к которым можно обращаться из вне, по началу из ядра.
|
|
|
|
Добавлено: Пт июн 06, 2008 18:44 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): а это уже было, можно сравнительно быстро.
правда там, я пошел еще дальше, и предложил вариант ФВМ который может быть и другим
[quote="mOleg"]а это уже было, можно сравнительно быстро.[/quote]
правда там, я пошел еще дальше, и предложил вариант ФВМ ;) который может быть и другим
|
|
|
|
Добавлено: Пт июн 06, 2008 18:37 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Теперь спросим - как это реализуется на процессорах, не поддерживающих аппаратно интеловские механизмы ?
а это уже было, можно сравнительно быстро. В любом случае переключение между кольцами задач будут больше времени жрать. А тут можно на любой проц, даже без поддержки многозадачности, даже на 16битный один и тот же алгоритм работы
кроме того, критичный по времени код можно перетаскивать в область ядра без нарушения защиты.
[quote="вопрос"]Теперь спросим - как это реализуется на процессорах, не поддерживающих аппаратно интеловские механизмы ?[/quote]
[url=http://fforum.winglion.ru/viewtopic.php?t=1277]а это уже было[/url], можно сравнительно быстро. В любом случае переключение между кольцами задач будут больше времени жрать. А тут можно на любой проц, даже без поддержки многозадачности, даже на 16битный один и тот же алгоритм работы ;)
кроме того, критичный по времени код можно перетаскивать в область ядра без нарушения защиты.
|
|
|
|
Добавлено: Пт июн 06, 2008 18:25 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: Я предлагаю использовать модель памяти по типу сегментной, точнее, механизма, аналогичного селекторам, которые поддерживает ix86 архитектура. А именно, любой адрес в памяти ОС представлять парой чисел: id:disp - идентификатор блока и смещение внутри него. Это должно бы значить: инженеры Интел хорошо думали, предлагая модель. И, пожалуй, это правда.
Теперь спросим - как это реализуется на процессорах, не поддерживающих аппаратно интеловские механизмы ?
[quote]Я предлагаю использовать модель памяти по типу сегментной, точнее, механизма, аналогичного селекторам, которые поддерживает ix86 архитектура. А именно, любой адрес в памяти ОС представлять парой чисел: id:disp - идентификатор блока и смещение внутри него.[/quote] Это должно бы значить: инженеры Интел хорошо думали, предлагая модель. И, пожалуй, это правда.
Теперь спросим - как это реализуется на процессорах, не поддерживающих аппаратно интеловские механизмы ?
|
|
|
|
Добавлено: Пт июн 06, 2008 18:12 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Alexander писал(а): Так и не долго до организации базы данных... Идея не нова. я не утверждал, что идея нова;) я уверено, что она лучше всего подходит для решения поставленной задачи. Alexander писал(а): Надо в ядре организовать менеджер динамической памяти, потом немного механизмов из создания баз даных, тогда любой процесс есть таблица с полями одно из которых надо исполнить.
а вот это перебор. Не надо одно из полей исполнять
но менеджер динамической памяти должен быть в ядре, об этом я уже давно говорю
[quote="Alexander"]Так и не долго до организации базы данных... Идея не нова.[/quote] я не утверждал, что идея нова;) я уверено, что она лучше всего подходит для решения поставленной задачи.
[quote="Alexander"]Надо в ядре организовать менеджер динамической памяти, потом немного механизмов из создания баз даных, тогда любой процесс есть таблица с полями одно из которых надо исполнить.[/quote]
а вот это перебор. Не надо одно из полей исполнять ;)
но менеджер динамической памяти должен быть в ядре, об этом я уже давно говорю
|
|
|
|
Добавлено: Пт июн 06, 2008 18:00 |
|
|
|
|