Какие причины заставляют разработчиков отказываться от MMU?

1) ниасилили 2) не нужно 3) сэкономить немножко кремния

Каким образом Linux может работать на архитектурах, не поддерживающих виртуальную память?

Работает подмножество без защиты памяти (т.е. никакого mmap и CoW); man ucLinux

Какие причины заставляют разработчиков отказываться от MMU?

Ненужно. Ты не поверишь, оно действительно в некоторых случаях не нужно.

нет MMU в микроконтроллерах, там в принципе не предусмотрено выполнение многих разных программ, только то, что зашито программистом во флеш. т.е. невозможна ситуация, когда одна программа гадит в оперативке другой. потому что другой нет и быть не может
типа-RTOS для микроконтроллеров здесь тоже не в тему, т.к. формально процесс один и поток один, только в разные его части передается управление. Даже сам диспетчер РТОС - и тот часть все того же потока

Верю. В некоторых электросчётчиках стоит «российский» ARM, в нём нет MMU и, наверное, он там не нужен. Хотя, тут вопрос нужен ли вообще микропроцессор в электросчётчиках.

Не поверишь, нужен. Как минимум надо считать и хранить не только конечные циферки. Есть ещё такая штука как профиль нагрузки - счётчик держит у себя инфу о потреблении энергии за последний месяц(или другой период) по часам.

Современные счётчики штука умная, много чего умеет.

Какие причины заставляют разработчиков отказываться от MMU?

размер кристалла и назначение чипа.

Каким образом Linux может работать на архитектурах, не поддерживающих виртуальную память?

man uClinux

Какова сложность подсистемы MMU на кристалле и разбирался ли кто-нибудь с принципами её работы?

Тебе хватит, чтобы закопаться с ее реализацией.

Хотелось бы услышать мнение о возможности сделать MMU, поддерживающий несколько размеров страниц. Например - 1Кб, 2Кб, 4Кб, 8Кб, 16Кб, 32Кб, 64Кб, 128Кб, 256Кб, 512Кб, 1Мб, 2Мб, 4Мб, 16Мб. Т.е. процессор должен поддерживать одновременно все перечисленные размеры страниц.

Сомневаюсь что выйдет такое сделать в рантайме, будут проблемы с софтом.

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

Все зависит от того, как организован hdl + сложность самой команды.

Наконец, прошу ссылок на различные реализации CPU, вне зависимости от архитектур и лицензий.

man opencores.org

Какие причины заставляют разработчиков отказываться от MMU?

это весьма сложная штуковина, на мой взгляд.

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

Арм, кстати, на это и напирает, дескать их решения по всем параметрам (в том числе и цене) уже превосходят традиционные контроллеры от atmel и microchip. Есть ли в этих решениях mmu не знаю. Наверно, всё же нет.

Наверно, всё же нет.

На M/R0-4 нету. MPU разве.

Ну из самых убогих MMU есть на Cortex-F*, но по-моему это чистый маркетинг, не так уж сложно реализовать page-based MMU, особенно тот, который используется в армах и мипсах. Просто на стоимости системы это практически никак не отражается, а на времени разработки экономит. А у нас обычно разработку считают бесплатной, поэтому не включают в себестоимость, а на проце экономят $1 -> прибыль.

Стандартный армовый MMU поддерживает страницы разнообразнейших размеров, причем одновременно, почитай на него доку.

но по-моему это чистый маркетинг, не так уж сложно реализовать page-based MMU, особенно тот, который используется в армах и мипсах

Трансляция адресов не бесплатна в плане производительности.

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

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

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

В общем, страничная память граблей добавляет изрядно. Потому и делают её не всегда.

Просто когда для архитектуры у железяки уже устоявшиеся стандарты - не включение MMU является чисто маркетинговым разделением классов устройств. Мелкие армы без MMU совсем не быстрее таких же армов с MMU (на той же частоте, вспомним например ARM7TDMI, тот что в тегре запускающим процом, или ARM926 vs ARM946), при обращении к памяти, да и в мелкие армы кэши вообще забыли повключать. Так что маркетинг это. Просто отделение микроконтроллеров от процессоров, искусственное такое.

Хотелось бы услышать мнение о возможности сделать MMU, поддерживающий несколько размеров страниц.

а чем это лучше сегментной памяти?

а чем это лучше сегментной памяти?

Довольно простая реализация malloc в многозадачной среде.

Довольно простая реализация malloc в многозадачной среде.

А зачем для этого страницы разных размеров?

Все зависит от того, как организован hdl + сложность самой команды.

Немного размыслив, я понял что одной командой не обойтись. Хотелось бы реализовать ABI микроядра в железе. Для этого необходимо добавить девять команд и аппаратный планировщик задач. Задача по сложности сопоставима с разработкой микропроцессора.

А зачем для этого страницы разных размеров?

Для malloc не нужны.

С помощью страниц разного размера очень удобно описывать сегменты - любой выравненный сегмент можно описать набором страниц. Например, сегмент 96 килобайт - две страницы - 64 и 32. В случае «стандартных» 4Кб страниц - их понадобится 24 штуки.

Немного размыслив, я понял что одной командой не обойтись. Хотелось бы реализовать ABI микроядра в железе. Для этого необходимо добавить девять команд и аппаратный планировщик задач. Задача по сложности сопоставима с разработкой микропроцессора.

Нахрена?

нет MMU в микроконтроллерах, там в принципе не предусмотрено выполнение многих разных программ, только то, что зашито программистом во флеш. т.е. невозможна ситуация, когда одна программа гадит в оперативке другой. потому что другой нет и быть не может

да прям. Вполне себе многозадачные почти-ОС и на PIC и на AVR-ках делают. Просто в идеале программы гадят друг другу в память в процессе отладки, дальше программист находит все баги, и в производство идёт уже идеально работающая прошивка :)

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

Лучше сделай периферийное устройство с DMA. Такая команда в архитектуре risc будет лютым костылём, к тому же тормозящим весь конвеер на время своего исполнения (очевидно, немаленькое).

я в том же комменте написал, псевдо-ОС на PIC/AVR/Cortex - по сути один процесс, который время от времени кидает управление в другую свою же часть

> 1. Какие причины заставляют разработчиков отказываться от MMU?

для ЦА данных микроконтроллеров/микропроцессоров они не только бесполезны, но и вредны (увеличение площади кристалла/цены/энергопотребления за ненужные фичи мало кому понравится).

я в том же комменте написал, псевдо-ОС на PIC/AVR/Cortex - по сути один процесс

типа-RTOS для микроконтроллеров здесь тоже не в тему, т.к. формально процесс один и поток один

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

Плюс к этому, старшие модели AVR умеют писать себе во флэш, значит они могут подгружать новые программы из внешней среды. Либо во флэш память может быть прошит какой-нибудь интерпретатор, а в оперативную память можно подгружать внешние программы на интерпретируемом языке.

В AVR есть таймер и прерывания от него, этого уже вполне достаточно для создания многозадачной ОС

я всегда пользовался примерно таким определением процеса:

Часто процессом называют выполняющуюся программу и все её элементы: адресное пространство, глобальные переменные, регистры, стек, открытые файлы и т. д.

с этой точки зрения прошивка МК это один процесс.

Хотя если задуматься, то не совсем понятно, нет MMU, потому что прошивка это один процесс, или прошивка это один процесс, потому что нет MMU?

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

Спасибо за opencores.org - очень интересно. Однако, реализаций MMU я там не нашёл.

Например, сегмент 96 килобайт - две страницы - 64 и 32. В случае «стандартных» 4Кб страниц - их понадобится 24 штуки.

Страница - это еще и квант своппинга. По закону Парето может оказаться, что из всего 96к сегмента в оперативе достаточно держать пяток 4к страниц.

И что же именно ты собрался в железо переносить?

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

Этим занимались. Всерьез. Дальше вайтпейперов не взлетело.

если взять определение «процесс - это экземпляр выполняющейся программы», то всё выглядит по-другому :)

а так и содержимое жесткого диска PC целиком, c линуксами и виндами, можно считать одной большой программой-прошивкой

команда, которая выполняет микропрограмму

Э-ээ, программное прерывание?

которая меняет значение многих регистров, может копировать блоки памяти и осуществляет синхронизацию

Я бы не стал надеяться, что аппаратная реализация такой штуки окажется сильно быстрее софтовой. Скорее, в системе команд могут быть полезны какие-то примитивы, специфичные для микроядер. Если ты такие примитивы сможешь вычленить и убедить интел/амд/арм их к себе втянуть.

Страница - это еще и квант своппинга. По закону Парето может оказаться, что из всего 96к сегмента в оперативе достаточно пяток 4к страниц.

В первом приблежении предлагаю никогда не свопить сегмент кода. Есть ли аргументы против такого подхода?

В первом приблежении предлагаю никогда не свопить сегмент кода.

А я предлагаю не подгружать сегмент кода раньше времени. mmap-нуть его в виртуальное адресное пространство, а фактически считывать с диска только те странички, которые на деле получают page miss.

Есть ли аргументы против такого подхода?

Кода много, львиная доля его никогда не будет выполнена (ибо посвящена обработке ошибок и просто всяких редких ситуаций), а оперативку лучше потратить на что-нибудь более востребованное. Например, на кэш ФС.

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

ABI микроядра в железе - это логичный шаг в развитии микропроцессоров.

Я уверен, что ты не анализировал ни Intel iAPX432 (ABI микроядра, как назвали бы это сегодня), ни INMOS T414 (аппаратный планировщик).

Пока что никто этим всерьёз не занимался

Инженерная разработка начинается с анализа существующих решений, а не с заявления «этого до меня никто не делал». iAPX432 едва не стоил Intel банкротства, настолько серьезно им занимались.

И что же именно ты собрался в железо переносить?

Собрался - это громко сказано, просто рассматриваю возможность. Конечно же микроядро L4 X2 и прежде всего вызов IPC в виде команды процессора. Этот вызов отдалённо похож на CALL, но вместо перехода по адресу происходит обмен сигналами с получателем.

Если проводить аналогию, то где-то в памяти последовательно размещены Task Control Blocks, описывающие свойства задачи. Адрес TCB - является идентификатором процесса. В регистры заносятся TCB адрес, два таймаута (таймаут передачи и передачи), само сообщение. Команда блокируется до завершения циклов приёма и передачи, или по таймауту. Помимо этого команда IPC служит маркером для аппаратного планировщика. БОльшая часть переключений задач планировщиком происходит именно при выполнении IPC.

iAPX432

Круто. Не знал о такой вундервафле.

Этим занимались. Всерьез. Дальше вайтпейперов не взлетело.

Давно, наверное, занимались? А какое микроядро собирались переносить? Небось Mach? Если да, то мне кажется не взлетело из-за перегруженности Mach.

А еще был BiiN, да много прикольных комбинаций ОС и железа было на рубеже 70-80-х.

Я уверен, что ты не анализировал ни Intel iAPX432 (ABI микроядра, как назвали бы это сегодня), ни INMOS T414 (аппаратный планировщик).

Да я даже не слышал о iAPX432. Спасибо за информацию. Тут только одно можно сказать - процессор на 20 лет опередил своё время. Сейчас он был бы востребован по меньше мере Макосью.

Инженерная разработка начинается с анализа существующих решений,

Так я и не брался за разработку.

процессор на 20 лет опередил своё время. Сейчас он был бы востребован по меньше мере Макосью.

Долго объяснять, но нет, не был бы. И вообще есть мнение, что для эффективной реализации микроядер либо уже вообще ничего не нужно (потому что разработаны способы реализации, пригодные для существующих процессоров), либо нужны относительно небольшие доработки TLB (сброс кэша по ASID).

не только его, были и отдельные проекты ориентированных на это микроядер. Не взлетел ни один. Да и захардкоживать кусок API в аппаратуру это маразм. Теряется гибкость решения. При кстати почти отсутствующем выигрыше в быстродействии.

L4 X2

я просто оставлю это здесь: http://www.cse.unsw.edu.au/~cs9242/12/lectures/05-ukinternalsx4.pdf

Долго объяснять, но нет, не был бы.

Несколько лет назад в толксах мы уже спорили о микроядрах. И аргумент о TLB кеше звучал и в том споре :)

Прошло время, и жизнеспособность микроядерного решения доказала Mac OS X. Таки я немало покопалсы в сырцах L4 Pistachio и некоторые вещи мечтаю увидеть реализованными в железе. Тем более что L4 не настолько громоздок как Mach, чтобы его нельзя было реализовть в железе. Уйду на пенсию - обязательно сделаю (если доживу).

аргумент о TLB кеше звучал и в том споре :)

Ну так аргументу уже лет 20.

Прошло время, и жизнеспособность микроядерного решения доказала Mac OS X

Его доказала OSF/1 :)

Уйду на пенсию - обязательно сделаю (если доживу).

К тому времени всё займут ядра на безопасных языках.

Да и захардкоживать кусок API в аппаратуру это маразм.

Тут как бы не API, а ABI. Весь API строится на основе и поверх Inter-Process Communication System Call.

К тому времени всё займут ядра на безопасных языках.

Да тут осталось-то немногим больше 20 лет - не успеют.

Безопасные языки требуют виртуальную машину. А виртуальную машину можно запустить поверх микроядра. Т.ч. одно другого не исключает.

Безопасные языки требуют виртуальную машину.

Во-первых, не требуют (см. Singularity); во-вторых, это будут другие языки - последыши Cyclone и Rust.

я просто оставлю это здесь: http://www.cse.unsw.edu.au/~cs9242/12/lectures/05-ukinternalsx4.pdf

А почему бы своё мнение не выразить?

А я предлагаю не подгружать сегмент кода раньше времени. mmap-нуть его в виртуальное адресное пространство, а фактически считывать с диска только те странички, которые на деле получают page miss.

Этот способ даст высокую латентность на загруженной операциями ввода/вывода системе.

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

Этот код обычно помещается в одной странице. Стоит ли городить огород ради экономии 4 килобайт?

Во-первых, не требуют (см. Singularity)

Последнее обновление несколько лет назад. Singularity настолько идеальна, что развивать больше нет смысла? :)

во-вторых, это будут другие языки - последыши Cyclone и Rust.

Cyclone показался интересным. Но...

checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc

..поскипано..

checking size of long... 8
ERROR: cannot build because sizeof(long) == 8 != 4

Нашёл 32-х битный Debian

/home/alman/cyclone/bin/cyclone  -c -Ibuild/i686-pc-linux-gnu/include -Iinclude -Ilib/xml -B/home/alman/cyclone/bin/lib/cyc-lib  -O -o build/i686-pc-linux-gnu/include/cycstubs.o build/i686-pc-linux-gnu/include/cycstubs.cyc
make: *** [build/i686-pc-linux-gnu/include/cycstubs.o] Segmentation fault

Ну вот, само себя собрать не может. Сырое.

и Rust.

Страшный зверь. Для сборки требует Интернет чтобы скачать snapshot.

Since the Rust compiler is written in Rust, it must be built by
a precompiled "snapshot" version of itself (made in an earlier state
of development). As such, source builds require a connection to
the Internet, to fetch snapshots, and an OS that can execute the
available snapshot binaries.

В 23 мегабайтном архиве не нашли места для бинарника. :(

P.S. Я могу представить на этих языках реализацию файловой системы или TCP/IP стека - достаточно обмениваться сообщениями с драйверами блочных и сетевых устройств, но как с помощью этих языков можно управлять задачами и памятью - не понимаю.

http://opencores.org/or1k/OR1K:Community_portal

Последнее обновление несколько лет назад. Singularity настолько идеальна, что развивать больше нет смысла? :)

Ы? Singularity была написана на управляемом языке и не требовала никакой VM.

Ну вот, само себя собрать не может. Сырое.

Оно не сырое, а мертвое. И я не говорил, что будущие ядра будут на Cyclone - они будут на его наследниках. На Cyclone и Rust отрабатываются идеи.

Я могу представить на этих языках реализацию файловой системы или TCP/IP стека - достаточно обмениваться сообщениями

В Cyclone нет сообщенией на уровне языка.

но как с помощью этих языков можно управлять задачами и памятью - не понимаю.

А в чем проблема?