MMU

Thu Feb 22 2007 23:07, Sergey Sobolev wrote to Nickita A Startcev:

SS>>> ðÏÄÓËÁÖÉÔÅ, ÐÌÚ, ÄÌÑ ÞÅÍ ÐÏÌÅÚÅÎ MMU? SS>>> ëÁËÉÅ ÐÌÀÓÙ Ñ ÕÐÕÓÔÉÌ? NS>> ðÒÉ ÓÂÏÅ ÔÒÕÄÎÏ ÎÁÇÁÄÉÔØ ÄÒÕÇÏÍÕ ÐÒÏÃÅÓÓÕ.

SS> ó ÏÄÎÏÊ ÓÔÏÒÏÎÙ, ÏÎÏ, ËÏÎÅÞÎÏ, ÍÏÖÅÔ ÂÙÔØ, ÎÏ Ó ÄÒÕÇÏÊ - ÐÒÉ ÂÅÚ×ÒÅÍÅÎÎÏÊ SS> ËÏÎÞÉÎÅ ËÕÓËÁ embedded ÕÓÔÒÏÊÓÔ×Á ÕÔÅÛÅÎÉÅ ÏÔ ÎÁÌÉÞÉÑ ÏÓÔÁ×ÛÉÈÓÑ ËÕÓËÏ× SS> ÍÏÖÅÔ ÂÙÔØ ÎÅ ÂÏÌØÛÉÍ. ) HÁÐÒÉÍÅÒ, ÒÕÌØ ÏÔËÁÚÁÌ, ÎÏ ËỊ̈ÓÁ Åݣ ËÒÕÔÑÔÓÑ.. SS> ;)

NS>> ps: HÉËÏÇÄÁ ÎÅ ÏÔÌÁÖÉ×ÁÌ ×ÓÑÞÅÓËÉÅ ÕÔÅÞËÉ ÉÌÉ ÚÁÐÉÓÉ ÐÏ NS>> ÎÅ×ÁÌÉÄÎÏÍÕ ÕËÁÚÁÔÅÌÀ? ÂÅÚ ííõ - ÜÔÏ ÔÁ ÅÝÅ ËÁÍÁÓÕÔÒÁ.

SS> èÏÒÏÛÁÑ ÉÄÅÑ, ÓÐÁÓÉÂÏ.

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

"Liberalism is a mental disorder"

Hello, Yuriy! You wrote to Sergey Sobolev on Fri, 23 Feb 2007 00:52:41 +0300: 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 YK> free. There is a whole range of unspecified, undefined and YK> implementation-defined behaviour associated with dynamic memory YK> allocation, as well as a number of other potential pitfalls. Dynamic YK> heap memory allocation may lead to memory leaks, data inconsistency, YK> memory exhaustion, non-deterministic behaviour. Note that some YK> implementations may use dynamic heap memory allocation to implement YK> other functions (for example functions in the library string.h). If YK> this is the case then these functions shall also be avoided.

WBR, AVB

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

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

Fri Feb 23 2007 10:30, Alexey V Bugrov wrote to Yuriy K:

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 YK>> free. There is a whole range of unspecified, undefined and YK>> implementation-defined behaviour associated with dynamic memory YK>> allocation, as well as a number of other potential pitfalls. Dynamic YK>> heap memory allocation may lead to memory leaks, data inconsistency, YK>> memory exhaustion, non-deterministic behaviour. Note that some YK>> implementations may use dynamic heap memory allocation to implement YK>> other functions (for example functions in the library string.h). If YK>> this is the case then these functions shall also be avoided.

AVB> òÁÚÕÍÎÏÅ ÚÅÒÎÏ ÅÓÔØ, ÎÏ ÎÁÐÉÓÁÎÏ ÞÅÒÅÚ ÞÕÒ ÐÁÒÁÎÏÉÄÁÌØÎÏ. ó ÔÁËÉÍ AVB> ÐÏÄÈÏÄÏÍ ÎÅÌØÚÑ ×ÏÏÂÝÅ ÎÉËÁËÉÅ ÓÒÅÄÓÔ×Á ÑÚÙËÁ ó É ÔÅÍ ÂÏÌÅÅ ïó AVB> ÉÓÐÏÌØÚÏ×ÁÔØ, Ô.Ë. ÞÒÅ×ÁÔÏ "...unspecified, undefined and AVB> implementation-defined behaviour..." AVB> É "...a number of other potential pitfalls".

MISRA C ËÁË ÒÁÚ É ÒÁÓÓÞÉÔÁÎÁ ÎÁ ÐÁÒÁÎÏÉËÏ×. BTW ÐÒÏÇÎÁ× ÏÄÉÎ ÉÚ ÐÒÏÅËÔÏ× ÞÅÒÅÚ IAR MISRA checker, ÎÁÛÅÌ ÐÁÒÕ-ÔÒÏÊËÕ ÓËÏÌØÚËÉÈ ÍÏÍÅÎÔÏ×.

AVB> HÁ ÓÁÍÏÍ ÄÅÌÅ ÅÓÔØ ÄÏÓÔÁÔÏÞÎÏ ÞÅÔËÁÑ ÔÅÏÒÉÑ (ÅÓÌÉ ÍÏÖÎÏ ÔÁË ÓËÁÚÁÔØ :) AVB> ÉÓÐÏÌØÚÏ×ÁÎÉÑ É ÍÅÎÅÄÖÍÅÎÔÁ ÄÉÎÁÍÉÞÅÓËÏÊ ÐÁÍÑÔÉ. ðÒÉ ×ÙÐÏÌÎÅÎÉÉ ÒÑÄÁ AVB> ÕÓÌÏ×ÉÊ ÎÉ ÕÔÅÞËÉ, ÎÉ ÆÒÁÇÍÅÎÔÁÃÉÑ ÎÅ ÂÕÄÕÔ ÉÍÅÔØ ÍÅÓÔÏ. ïÄÎÏ ÉÚ AVB> ËÌÀÞÅ×ÙÈ ÕÓÌÏ×ÉÊ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÏÂßÅÍÁ ÄÉÎÁÍÉÞÅÓËÏÊ ÐÁÍÑÔÉ ÎÅ ÂÏÌÅÅ AVB> ÏÐÒÅÄÅÌÅÎÎÏÇÏ ÏÂßÅÍÁ (× % ÏÔ ÄÏÓÔÕÐÎÏÇÏ) É ×ÙÄÅÌÅÎÉÅ ÂÌÏËÏ× ËÒÁÔÎÏÇÏ AVB> ÏÂßÅÍÁ ÎÁ ÏÄÉÎ ÚÁÐÒÏÓ (Ó ÏÇÒÁÎÉÞÅÎÉÅÍ ÍÁËÓÉÍÁÌØÎÏ ÄÏÐÕÓÔÉÍÏÇÏ ÒÁÚÍÅÒÁ AVB> ÂÌÏËÁ). äÌÑ ÐÕÝÅÊ Õ×ÅÒÅÎÎÏÓÔÉ malloc/free ÄÏÌÖÎÙ ÂÙÔØ ÓÁÍÏÐÉÓÎÙÅ (Ô.Å. AVB> ÉÓÐÏÌØÚÏ×ÁÔØ ÉÚ×ÅÓÔÎÙÅ ÁÌÇÏÒÉÔÍÙ).

"Liberalism is a mental disorder"

22 Feb 07 23:07, Sergey Sobolev ÐÉÓÁÌ Nickita A Startcev:

SS> ó ÏÄÎÏÊ ÓÔÏÒÏÎÙ, ÏÎÏ, ËÏÎÅÞÎÏ, ÍÏÖÅÔ ÂÙÔØ, ÎÏ Ó ÄÒÕÇÏÊ - ÐÒÉ SS> ÂÅÚ×ÒÅÍÅÎÎÏÊ ËÏÎÞÉÎÅ ËÕÓËÁ embedded ÕÓÔÒÏÊÓÔ×Á ÕÔÅÛÅÎÉÅ ÏÔ ÎÁÌÉÞÉÑ SS> ÏÓÔÁ×ÛÉÈÓÑ ËÕÓËÏ× ÍÏÖÅÔ ÂÙÔØ ÎÅ ÂÏÌØÛÉÍ. ) HÁÐÒÉÍÅÒ, ÒÕÌØ ÏÔËÁÚÁÌ, ÎÏ SS> ËỊ̈ÓÁ Åݣ ËÒÕÔÑÔÓÑ.. ;)

Sergey Sobolev пишет:

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

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

Ivan,

You wrote to Sergey Sobolev:

úÁÞÅÍ ÔÁË ÔÒÁÇÉÞÎÏ? òÅÁÌØÎÏ Õ "ËÒÕÔÙÈ" ÍÁÛÉÎ ÐÒÉ ÓÒÁÂÁÔÙ×ÁÎÉÉ ÁÉÒÂÁÇÁ Á×ÔÏÍÁÔÉÞÅÓËÉ ×ÙÚÙ×ÁÅÔÓÑ ÓËÏÒÁÑ ÐÏÍÏÝØ.

Andrey

Ivan,

You wrote to Andrey Arnold:

IM> ÷ ÜÔÉÈ ÚÁÄÁÞÁÈ MMU ËÁË ÍÉÎÉÍÕÍ ÎÅ ÍÅÛÁÅÔ =)

Andrey

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) не могут быть реализованы в сколько-нибудь значительном объеме без использования кучи.

22 Feb 07 , 23:07 Sergey Sobolev ÐÉÓÁÌ Ë Nickita A Startcev:

SS>>> ðÏÄÓËÁÖÉÔÅ, ÐÌÚ, ÄÌÑ ÞÅÍ ÐÏÌÅÚÅÎ MMU? SS>>> ëÁËÉÅ ÐÌÀÓÙ Ñ ÕÐÕÓÔÉÌ? NS>> ðÒÉ ÓÂÏÅ ÔÒÕÄÎÏ ÎÁÇÁÄÉÔØ ÄÒÕÇÏÍÕ ÐÒÏÃÅÓÓÕ.

SS> ó ÏÄÎÏÊ ÓÔÏÒÏÎÙ, ÏÎÏ, ËÏÎÅÞÎÏ, ÍÏÖÅÔ ÂÙÔØ, ÎÏ Ó ÄÒÕÇÏÊ - ÐÒÉ SS> ÂÅÚ×ÒÅÍÅÎÎÏÊ ËÏÎÞÉÎÅ ËÕÓËÁ embedded ÕÓÔÒÏÊÓÔ×Á ÕÔÅÛÅÎÉÅ ÏÔ ÎÁÌÉÞÉÑ SS> ÏÓÔÁ×ÛÉÈÓÑ ËÕÓËÏ× ÍÏÖÅÔ ÂÙÔØ ÎÅ ÂÏÌØÛÉÍ. )

SS> HÁÐÒÉÍÅÒ, ÒÕÌØ ÏÔËÁÚÁÌ, ÎÏ SS> ËỊ̈ÓÁ Åݣ ËÒÕÔÑÔÓÑ.. ;)

. ó Õ×ÁÖÅÎÉÅÍ, HÉËÉÔÁ. ... "HÁÔÑÎÕÔØ ÏÂÏÌÏÞËÕ ÎÁ ÐÏÒÏÖÄÁÀÝÕÀ ÓÉÓÔÅÍÕ"(c)õÞÅÂÎÉË ÐÏ ÌÉÎ.ÁÌÇ.

никакая вменяемая реализация 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.

26 Feb 07 10:56, Basil Burtakov ÐÉÓÁÌ Yuriy K:

BB> òÅËÏÍÅÎÄÁÃÉÑ ÎÅÓËÏÌØËÏ ÓÐÏÒÎÁÑ, ÔÁË ËÁË ÎÅËÏÔÏÒÙÅ ÁÌÇÏÒÉÔÍÙ (ÎÁÐÒÉÍÅÒ BB> ×ÓÅÍÉ ÌÀÂÉÍÙÊ TCP/IP) ÎÅ ÍÏÇÕÔ ÂÙÔØ ÒÅÁÌÉÚÏ×ÁÎÙ × ÓËÏÌØËÏ-ÎÉÂÕÄØ BB> ÚÎÁÞÉÔÅÌØÎÏÍ ÏÂßÅÍÅ ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ËÕÞÉ.

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> ... Посетители должны общаться по сети.

26 Feb 07 15:09, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

BB> HÕ É ËÁË ÐÒÅÄÌÁÇÁÅÔÓÑ ÒÅÁÌÉÚÏ×Ù×ÁÔØ, ÎÁÐÒÉÍÅÒ, ÓÂÏÒËÕ BB> ÆÒÁÇÍÅÎÔÉÒÏ×ÁÎÎÙÈ ÐÁËÅÔÏ× ÄÌÑ ÎÅËÏÔÏÒÏÇÏ (ÐÒÏÉÚ×ÏÌØÎÏÇÏ) ËÏÌÉÞÅÓÔ×Á BB> ÏÄÎÏ×ÒÅÍÅÎÎÏ ÏÔËÒÙÔÙÈ ÓÏÅÄÉÎÅÎÉÊ ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ËÕÞÉ? ó ÕÞÅÔÏÍ BB> ÔÏÇÏ, ÞÔÏ ÆÒÁÇÍÅÎÔÙ × ÏÂÝÅÍ ×ÉÄÅ:

BB> 3. ÅÓÌÉ ×ÙÄÅÌÑÔØ ÓÔÁÔÉÞÅÓËÉ BB> "ÐÏ ÍÁËÓÉÍÕÍÕ" ÂÕÆÅÒÁ ÄÌÑ ËÁÖÄÏÇÏ ÐÁËÅÔÁ, ÔÏ × ÌÀÂÏÊ ÆÉÚÉÞÅÓËÉ BB> ÐÒÅÄÓÔÁ×ÉÍÏÊ ÓÉÓÔÅÍÅ ÒÅÓÕÒÓÙ ÏÞÅÎØ ÂÙÓÔÒÏ ÚÁËÏÎÞÁÔÓÑ

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

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

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

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

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