MMU

Есть ещё одно соображение. В эхотаге разнообразие структур данных строго ограничено. Можно предвыделить несколько пулов блоков нужных размеров и выделять из них.

Активное использование MMU может иметь смысл, если у ЦП есть хорошо развитая абсолютная адресация, а шаг распределения у MMU достаточно мелкий. Тогда можно подсовывать ему разные куски данных, а в подпрограммах оперировать только смещениями полей. Если-же речь идёт о RISK'е (например, об ARM'е), то он всё равно будет загонять базовый адрес в регистр и складывать со смещением. В таком случае даже выгоднее получить этот базовый адрес как аргумент (сазу в регистре), а не грузить его каждый раз константой...

Sergey Sobolev пишет:

А если руль отказал, но машина смогла безопасно "сложиться"? Или хотя-бы самомтоятельно вызвать похоронную бригаду? =>;->

Про переполнение пепельницы уже написали =)

Andrey Arnold пишет:

Я образно =) Имелось в виду, что при отказе части устройства, программном или аппаратном, было бы желательно (в порядке уменьшения последствий): а) восстановить работу, например, перезапустив программный компонент б) продолжить работу без отказавшего компонента, если возможно в) остановить работу устройства с минимальными последствиями для объекта управления (если мы управляем чем-то силовым, желательно это что-то выключить/припарковать) г) собрать какой-нибудь некролог (как минимум - название отказавшего компонента, как максимум - подобие юниксовой корки).

В этих задачах MMU как минимум не мешает =)

SS>>>> Подскажите, плз, для чем полезен MMU? SS>>>> Какие плюсы я упустил? NS>>> При сбое трудно нагадить другому процессу.

SS>> С одной стороны, оно, конечно, может быть, но с другой - при SS>> безвременной кончине куска embedded устройства утешение от наличия SS>> оставшихся кусков может быть не большим. ) Hапример, руль отказал, но SS>> колёса ещё крутятся.. ;)

YK> Именно.

NS>>> ps: Hикогда не отлаживал всяческие утечки или записи по NS>>> невалидному указателю? без ММУ - это та еще камасутра.

SS>> Хорошая идея, спасибо.

YK> Использование динамической памяти в более-менее ответственных системах YK> надо запрещать на...

YK> MISRA C Rule 20.4 (required): Dynamic heap memory allocation YK> shall not be used.

YK> [Unspecified 19; Undefined 91, 92; Implementation 69; Koenig 32] YK> This precludes the use of the functions calloc, malloc, realloc and free. YK> There is a whole range of unspecified, undefined and YK> implementation-defined behaviour associated with dynamic memory YK> allocation, as well as a number YK> of other potential pitfalls. Dynamic heap memory allocation may lead YK> to memory leaks, data inconsistency, memory exhaustion, non-deterministic YK> behaviour. Note that some implementations may use dynamic heap memory YK> allocation to implement other functions (for example functions in the YK> library string.h). If this is the case then these functions shall also YK> be avoided.

Рекомендация несколько спорная, так как некоторые алгоритмы (например всеми любимый TCP/IP) не могут быть реализованы в сколько-нибудь значительном объеме без использования кучи.

никакая вменяемая реализация tcp/ip стека (а отнюдь не "алгоритма") не использует кучу (в смысле стандартных malloc/realloc/free) а использует фиксированного размера пулы элементов фиксированной длины. вообще вменяемые реализации ядер не используют "настоящие" malloc/free сколь нибудь интенсивно и уж тем более не используют их из clib.

AS> никакая вменяемая реализация tcp/ip стека (а отнюдь не "алгоритма") не

??? Какая разница между словами "стек" и "алгоритм" в этом контексте? Чтобы реализовать протокол TCP/IP нужно совершить некоторые действия с приходящими/уходящими данными. Последовательность этих (и вообще любых) действий по определению называется алгоритмом.

AS> использует кучу (в смысле стандартных malloc/realloc/free) а использует AS> фиксированного размера пулы элементов фиксированной длины. вообще AS> вменяемые реализации ядер не используют "настоящие" malloc/free сколь AS> нибудь интенсивно и уж тем более не используют их из clib.

Куча она всегда куча. :-) То есть некоторый массив памяти с определенными на нем (минимально) операциями "получить" и "отдать" кусок памяти. А реализация это дело глубоко десятое. Все равно это куча. Да, бывают "более реалтаймовские" и "менее реалтаймовские" реализации. Бывают реализации с дополнительными операциями типа объединения фрагментированных кусков и т.д. Но все это никак не отменяет того факта, что некоторые алгоритмы полноценно реализуются только с использованием кучи.

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

Возвращаясь же к исходному вопросу о полезности MMU для встроенных систем можно сказать, что:

1. Деление на встроенные и невстроенные системы достаточно условное и определяется в основном количеством допущений, которые может себе позволить разработчик. Если производители ОС и софта для офиса имеют возможность в любой момент нажать сброс и перезагрузиться, то производители софта для пилотирования Боинга такой роскоши позволить себе не могут.

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

Mon Feb 26 2007 15:02, Alex Mogilnikov wrote to Basil Burtakov:

AM> Привет Basil!

AM> 26 Feb 07 10:56, Basil Burtakov писал Yuriy K:

BB>> Рекомендация несколько спорная, так как некоторые алгоритмы (например BB>> всеми любимый TCP/IP) не могут быть реализованы в сколько-нибудь BB>> значительном объеме без использования кучи.

AM> Вторая часть утверждения (после "так как") неверна.

Ну и как предлагается реализовывать, например, сборку фрагментированных пакетов для некоторого (произвольного) количества одновременно открытых соединений без использования кучи? С учетом того, что фрагменты в общем виде:

1. разного размера
2. конец приходит раньше начала и поэтому истинный размер пакета не известен до принятия последнего фрагмента
3. если выделять статически "по максимуму" буфера для каждого пакета, то в любой физически представимой системе ресурсы очень быстро закончатся
4. ну и так далее

BB>> Hу и как предлагается реализовывать, например, сборку BB>> фрагментированных пакетов для некоторого (произвольного) количества BB>> одновременно открытых соединений без использования кучи? С учетом BB>> того, что фрагменты в общем виде:

AM> [...]

BB>> 3. если выделять статически BB>> "по максимуму" буфера для каждого пакета, то в любой физически BB>> представимой системе ресурсы очень быстро закончатся

AM> При такой постановке задачи ресурсы и в куче закончатся.

Это наиболее полная постановка задачи создания TCP/IP. Ее решение с помощью кучи позволяет гибко манипулировать ресурсами вычислительной системы, в каждый момент времени выделяя именно столько памяти, сколько требует задача связи.

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Посетители должны общаться по сети.

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

ну то есть что такое алгоритм ты представляешь, но не знаешь

некоторые алгоритмы требуют "динамического выделения памяти", алогитмов требующих кучи (которая есть один из способов динамического выделения) я никогда не видел. куча - это именно реализация.

короче что такое динамическое выделение памяти ты тоже не в курсе.

куча никаким образом не предполагает и не требует мму. болнн того - мму никоим образом не помогает куче (в отличии от пулов которым таки помогает).