LINUX.ORG.RU

Вышла Amiga OS4.0 Classic


0

0

Компания ACube Systems Srl выпустила новую версию Amiga OS для классических компьютеров Amiga 1200, 3000(T) или 4000(T) с процессорами PowerPC, разработанных Hyperion Entertainment VOF. Теперь можно насладиться новыми возможностями операционной системы, известной своей эффективностью и нетребовательностью к ресурсам компьютера. Она спокойно работает даже на машине с частотой процессора 160 МГц, демонстрируя все свои возможности, включая мультимедию и юзабилити.

Как известно, эта ОС была очень популярна в конце 80х, и оказала огромное влияние на развитие компьютерной индустрии. Например, именно там зародилась технология Plug&Play. Компьютеры Amiga использовались в основном как домашние игровые станции. Ветка с PowerPC ведет отсчет с 2002 года.

>>> Подробности

★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

> Предлагается использовать распределение памяти как в L4: есть ядро, владеет всей памятью, выделяет почти память всю кроме ядерных структур (сигма-0) процессу init. Процесс init запускает подпроцессы, выделяя каждому непересекающиеся блоки памяти. При этом обратиться подпроцес к не своему блоку памяти не может: указатель в другой подпроцесс вызовет GPF

Еще раз без обид, но ты, похоже, не понимаешь, как работает MMU.

>> Справедливости ради, JIT в процессор засунула фирма Интел -

> Вроде IBM пыталась делать что-то подобное с памятью, Infini-чего-то там

Я _совсем_ не о том.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Еще раз без обид, но ты, похоже, не понимаешь, как работает MMU.

А чего именно я не понимаю? Если не секрет.

вот в x86 есть виртуальное адресное пространство страниц, которые лежат в записях PTE и кешируются в TLB. В записях PTE записано соответствие вирт. адреса и физического + биты статуса + отображена ли страница. Есть несколько уровней в таблице страниц.

1) то есть, ядро работает с виртуальными адресами, не физическими?

Что происходит при переключении контекста, конкретные записи из PTE/TLB вытесняются записями активного процесса? Поэтому -- переключение -- дорогая операция? Что происходит когда разные процессы отображены по одинаковым вирт. адресам?

Если вместо этого отображать разные процессы по разным вирт. адресам, чтобы упаковать в TLB как можно больше разных процессов, мы ведь минимизируем количество "дорогих операций", ускорим переключение процессов?

ps. Да, наверно то что я пытался сформулировать с GUIDами, звучит как "inverted page table", точно.

anonymous
()
Ответ на: комментарий от anonymous

угу. просто где-то прочитал что в MorphOSи в Quark'e в Q-Box с полной защитой памяти переключение контекстов процессов работает сильно быстрее чем в x86, потому что она работает на PPC. Вот и стало интересно, что это за миф про "дорогое переключение контекстов процессов при полной защите памяти", и что из-за этого микроядра обязательно тормозят. То ли это фирменные грабли x86, то ли неэффективное управление MMU.

anonymous
()
Ответ на: комментарий от tailgunner

Ради ясности. Как, по-моему, должна работать система управления памятью.

Память выделяется не из памяти ядра, а из памяти порождающего процеса. Самый первый процесс порождается ядром (ну или сервером-менеджером ресурсов). То есть, память всегда имеет владельца-процесс, и указатели на эту память всегда учитываются в контексте этого процесса. Указатель на память в другом процессе невалиден, если этот процесс не отображен (mmap) на текущий.

Операции вроде "записать байты по адресу" (ты имел в виду kmemmove или между процессами?) по идее быть не должно. Но если процесс отображен, то указатели допустимы и операция разрешена.

Если далее развить идею с "типизированными указателями, принадлежащими контексту процесса", прийдем к чему-то в духе Cyclone. Можно довертеться до чего-то вроде персистентных объектов в духе SOM.

Если просто не усложнять, существенно, что указатель имеет процесс-владельца, область видимости в которой он имеет смысл. И этим обеспечивать защиту памяти процессов друг от друга.

Ну в общем в духе L4.

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

anonymous
()
Ответ на: комментарий от anonymous

Ну и чем это отличается от схемы управления памятью в любой нормальной ОС? Что вообще нового в этой схеме? Каким образом это всё эффективнее использует ресурсы вроде TLB или шины "память-кэш"?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Если два процесса грузятся в по одному и тому же вирт. адресу (в контексте процесса), каким записям в TLB соответствуют их страницы? Возникает ли в этом хеше коллизия?

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

> Что вообще нового в этой схеме?

типизированные указатели, со ссылкой на область действия указателя. Менеджер памяти выделяет её из пула и раздает указатели. Указатель на невыделенную память или в другой процесс блокируется MMU (в другой процесс, отображенный mmap'ом -- можно, отображать mmap'ом можно при наличии прав).

Ядро, или сервер-менеджер ресурсов должно защищать процессы друг от друга путем простого контроля корректных прав на указатели. MMU просто должно защищать границы процессов (отображением в процесс только его страниц, или разрешенных других процессов), и контролировать допустимость указателей, учитывая контексты процессов, из какого к какому обратились (допустимым будет указатель только в тот же процесс, или в отображенный mmap'ом (при наличии прав на mmap)). Указатель должен содержать ссылку на контекст (нити, процесса, ядра) в котором он работает.

Становится возможным контролировать семантику совместного доступа из разных процессов (если этот тег также засунуть в указатель). Контролировать выделена память или нет. Контролировать доступ к одному адресу указателями разных типов.

Для старого C/C++ кода по умолчанию указатели автоматически создаются в контексте соотв. процесса и поэтому не могут указывать на другой процесс.

В общем случае указатель должен содержать ссылку на область действия указателя и может дополнительно содержать тип (с учетом совместимости по иерархиям классов), режим совместного доступа, ссылку на аллокатор памяти, ссылку на сборщик мусора.

> Каким образом это всё эффективнее использует ресурсы вроде TLB

процессы можно грузить по разным виртуальным адресам, чтобы минимизировать коллизии в TLB. Чтобы как можно плотнее набить карту распределения страниц уровня системы, чтобы в TLB сидело максимальное количество одновременно работающий процессов. Контекст защиты не нужно менять, не нужно сбрасывать TLB -- роль контекста защиты выполняет область действия указателя.

Как-то так. Интересно, какие слабые места в этой схеме.

anonymous
()
Ответ на: комментарий от tailgunner

>Каким образом это всё эффективнее использует ресурсы

Это я, тот анонимус. Есть мысли по архитектуре трансляции адресов/управления памятью, но получаются "былинные посты", которые тут наверно не всем интересны. Основаная мысль -- что "долгое переключение контекста MMU" это фирменные грабли x86, и как это можно обойти. Если есть интерес, давай обсудим мылом tweak (эт) pisem дот net , ну или давай своё мыло.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.