Люди добрые,

подскажите, насколько нужен MMU, если хотелось бы писать программу на нормальном C++ (не EC++) и использовать простые выделения памяти типа new delete?

Совершенно не нужен, если не планируется использовать Linux или WinCE.

Linux, WinCE не нужен.
Т.е., если будет подключена внешняя SDRAM, к примеру, то я смогу спокойно писать на С++ что-то типа:
TMyArray* arr = new TMyArray(1000);
...
delete arr;
и всё будет спокойно выделяться во внешней памяти и освобождаться (при соответствующих настройках проекта)?

Да, для этого достаточно просто heap правильно прописать.

Понял. Спасибо.

Только учтите, что это 'счастье' до поры до времени, ведь никто не будет дефрагментировать память после Ваших фокусов с new/delete, да и сам new будет в случае нехватки памяти ждать ее до опупения....

Как-то сразу об этом не подумал..
Т.е. в случае чего прийдется писать свой аллокатор для мелких объектов по типу, как у Александреску, или просто разумно использовать new.

Если мне не изменяет память, то new/delete работают через стандартные аллокаторы, которые основаны на вызовах malloc/free, т.е. фрагментация памяти будет зависеть от того, как эти функции реализованы в стандартной библиотеке. Ну или на худой конец можно будет просто написать свои аллокаторы.

Несомнено и с точки зрения дефрагментации использование malloc не лучше.
А вот то, что из new не предусмотрен возврат в случае отсутствия памяти, это дополнительный
прикол :-)

Слишком мало смайликов на мой взгляд добавлено....
И как быть в этом случае с бесполезностью MMU???

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

Без дефрагментатора - аналогичные.
Но ведь дефрагментатор предлагалось писать? Ну и как без аппаратной поддержки реализовать "перемещение" памяти да так, что-бы тот, кто этой памятью пользуется не догадался об этом?

Я просто не очень понял слова "бесполезностью MMU".. Просто я не до конца понимаю силу слов MMU.
А без аппаратной поддержки перемещение, наверное, можно было бы софтово обеспечить: каждый класc в обязательном порядке наследуется от какого-нибудь THeapObject, который внутри себя хранил бы уже реальный указатель, число ссылок и т.п., а про new и указатели забываем совсем.

есть uClinux, он именно для работы без MMU и придуман.

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

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

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

А как будет в этом случае выглядет дефрагментация?

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

MMU нужен инициализыровать если для ARM9 хочется включить Data-Cache.

Т.е., в приципе, можно и не производить дефрагментацию?

Zltigo - не пугайте людей.
new в случае неуспеха вернет нулл. 1) "If unsuccessful, new returns zero or throws an exception"
2) " specified in the C++ standard, which is to throw a std::bad_alloc exception if the memory allocation fails"

В принципе да, но многое будет зависеть от особенностей MMU.

Господь с авторм приведенной Вами цитаты, но ни при каких условиях new не может возвращать NULL. В 'нормальном' варианте cо свопами и прочими наворотами просто циклится в ожидании появления памяти и в случае если и это не удается - система может просто прибить задачу. В мелких системах, где более-менее сразу ясно, что памяти скорее всего не появится - exeption. В самых примитивных реализациях - просто вечный цикл. Но никак не NULL'.
Ну а то, что автору, цитаты, что NULL, что 'zero' все едино - еще раз указывает на его некомпетентность.




Ага битик включил и "само работать будет" - не будет :-(. Это только механизм, которым можно воспользоваться в менеджере памяти для РЕАЛИЗАЦИИ компенсации фрагментированости.

ну это я с переводом лопухнулся. По умолчанию генерируется исключение bad_alloc. Вызовом set_new_handler() мы можем назначить иное поведение. Это по Страуструпу. Ну уж если он некомпетентен.... Вот из MSDN "If unsuccessful, new returns zero or throws an exception; see The new and delete Operators for more information. You can change this default behavior by writing a custom exception-handling routine and calling the _set_new_handler run-time library function with your function name as its argument"

С этим согласен. Если установить new_handler возвращающий NULL, то new() возвратит результат
NULL. Вопросы:
1.Вы когда-нибудь его переустанавливали?
2.Мы обсуждаем поведение new() или того что МОЖНО сделать из new() установкой new_handler,
перегрузкой или написанием макроса new ???


А вот на это "MS" ссылаться не надо. Из того, что у них в Windows на 32 разрядном x86
#define NULL 0
никоем образом не следует, то NULL являющийся абстрактным нулевым _указателем_ может всегда, везде и на всех платформах использоваться как попало и его физическое представление 0.
Не говоря о том, что размеры указателя могут ОТЛИЧАТЬСЯ от разрядности ЧИСЛА.
И в любом случае писать, что функция которая по определению возвращает УКАЗАТЕЛИ
вернула не УКАЗАТЕЛЬ а число 0 (или три или любое другое) некорректно в принципе.

Что касается путаницы и самой возможности использовать 0 как NULL, то за это отдельное спасибо
авторам С, которые вместо отдельного ключевого слова для нулевого указателя типа паскалевского "nil" использовали ключевое слово "0" :-(. Потом ANSI выкрутились через макрос NULL,
который всетаки был в С определен как УКАЗАТЕЛЬ.

хорошо, если не переустанавливать set_new_handler, то какие пакеты вызовут зацикливание в new а не выброс исключения ? Приведите пожалуйста список, дабы я (а может и еще кто) никогда их (эти пакеты) не использовали

Разбираться как ведет себя new() в конкретной библиотеке это задача того, кто решил его использовать.
Я лично - не использую. Мне лет 15-17 назад хватило BCC, дабы отбить сие желание.
Лет пять назад копался в ЧУЖОМ линуксовом приложении которое аккуратно периодически
молча отстреливалось системой как зависшее. Догадались что там было?
Ну и самое главное - чем Вам "exception" буде он реализован во EMBEDDED приложении сильно поможет? А? Типа "перезагрузимся и сделаем вид, что ни ничего не случилось".

new() практически во всех ранних C++ компиллерах умел возращать NULL.

Многие нынешние компиляторы/библиотеки поддерживают конструкцию:

О чем и речь :-(, что кто-то, где-то, как-то...
Посему, либо разбираться конкретно :-( и не забывать о повторных разборках при портировании,
либо устанавливать свой new_handler(), причем единственным разумным вариантом
new_handler() для embedded предстваляется возвращение им NULL для возможности максимально безболезненого выхода из каждого конкретной ситуации.
Либо не использовать new() в принципе.

А вот тут zltigo не прав. Цитирую Страуструпа:

Так что ноль вполне законен и даже очень правилен. Кстати, IAR 4.30 после вызова new проверяет R0 на ноль и если не ноль вызывает конструктор. Глубже не копал, но интуитивно понял что new таки в случае неудачи возвращает ноль. Счас отловлю другие ошибки и попробую организовать нехватку памяти.

Это всего лишь личное мнение Страуструпа :-)))) который и затвердил :-( его в своей реализации ++.
Я не слишком слежу за процессом стандартизации C++, но похоже комитет пока еще не родил
стандарта :-(.
В моей полной цитате речь шла о проблеме более широко:
- не только по отношению к C++, но и к C (более того это был именно кусок по С );
- по отношению к разным платформам, как например должен выглядеть Страуструповский
0 на платформе типа Cray-Cyber с кольцевыми указателями?
Короче в С++ болезнь вместо лечения ( введением ключевого слова, как в Паскале) была загнана вовнутрь наложением исскуственного требования иметь внутреннее представление нулевых указателей нулевым. И с легкостью необыкновенной считать, что ключевое слово для нулевого указателя это "0".

Личное мнение Страуструпа является стандартом - он автор.


Стандарт давно принят - аж в 1998 году. Уже приличное время ходят обсуждения следующей версии.


Какая болезнь? Отказ от определения NULL, как (void*)0? Сказано же, что объектов по нулевому адресу быть не может, поэтому указатель с адресом 0 невалиден. И 0 вполне однозначно определяет ситуацию благодаря стандартному преобразованию типа. Зачем тут плодить лишние сущности языка?

А разве в С есть operator new?
Про Cray не знаю ничего кроме "Цыпленок Cray перебежит дорогу быстрее всех, но если перед стартом его не окунуть в жидкий азот, то на той стороне дороги он появится в уже зажаренном виде" :-) На другой платформе int 0 будет стандартно преобразован к принятому на той платформе битовому представлению указателя который никуда не указывает. По-моему так! (с) Винни-Пух.

Нет, отсутствие ключевого слова для нулевого указателя.

Так папа сказал. Аминь.
А нежели кому в железе чего такого захочется сотворить:

Ну не "int 0" а ключевое слово "0", которое выглядит как "0", но должно быть преобразовано к
"принятому на той платформе битовому представлению"... И пусть со всем этим компилятор разбирается и не ошибается... И программист пусть не думает, поскольку за него компилятор постарается
разобраться. Не по душе мне такой уровень абстракции :-(

Интересно, а физически что же из себя будет представлять это ключевое слово ? 0 или какое-нибудь 0xFFFF... ? Уровень языка (достаточно низкий) и подразумевает изпользование константы. И большое спасибо, а то бы получился очередной паскаль.

Какая разница какое( ну NIL ). Любое, главное не строились мутные на мой взгляд преобразования типа "ничего не возвратили" поскольку вообще-то оттуда возвращают указатели, то будем считать,
что возвратили "никакой указатель" далее считаем, что по никакому указателю лежит "ничего"
ну а дальше просто пусть это ничего будет "0" - так и запишем :-(

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

Если так хоцца слово, то Вы можете его сами себе сотворить по вкусу - Сергей Борщ приводил цитату, там как раз было именно это. Заодно снимаются вопросы о самом слове - какое хоцца, такое и используйте. Вполне гибко и демократично. А в языке слова нет просто потому, что оно реально не нужно. Это лишняя сущность. Язык С++ и без этого достаточно сложен и чрезвычайно перегружен, поэтому сделано по минимуму. Все логично. А для принципиальных любителей слов оставлена лазейка. "И овцы сыты, и волки целы" (с)


Ну, если папа - Деннис Ричи, то да.


Мни кажется, что Вы все-таки излишне драматизируете ситуацию. Все там вполне однозначно. И физическое представление нулевого указателя вполне конкретно, просто оно определяется не Стандартом, а реализацией, только и всего, что опять же вполне логично. На всех платформах, с которым пришлось более-менее плотно поработать с С++, нулевой указатель имел физическое значение 0. Наличие специального ключевого слова совершенно ничего не меняет.

И я ей пользуюсь :-) Ибо, как минимум, не люблю веспорядочно расскиданные по тексту "0" :-)
А вообще сыр-бор с уходом в сторону от темы new() в тему NULL начался с моей фразы:

При этом имелось ввиду отнюдь не способность компилятора разобраться в контексте, а покоробившее меня поминание именно "0" вместо "нулевого указателя" в качестве значения возврашаемого функцией для которой возврашаемым значением является указатель. Я понимаю,
что в данной MS инструкции (а это именно четкая фраза от MS - можете поиском воспользоваться) указывается прямое действие пользователю - "пиши 0 и не парься", но тем не менее, подмена физической сущности в инструкции мне не нравится.


Да нет, так - шероховатость, просто это привлекло неожиданно для меня самого повышенное внимание и понеслось....


Аналогично :-). Нынеживущие платформы наверное все такие. Ну а в будующем? Не знаю даже.
Ведь всяких архитектур с ненулевыми нулевыми указателями и с указателями разных размеров для
разных типов указателей было немало. Это было в эпоху, когда за счет архитектурных ухищрений
добивались упрощения и/или увеличения производительности. Потом настали времена когда
"патронов не жалеть" (в смысле транзисторов) и мегагерцы гнались легко. Сейчас лафа кончается -
мегагерцы на исходе и пожалуй опять начнутся архитектурные гонки. И каким будет физическое представление нулевого указателя - это вопрос :-). Компиляторы конечно разберутся с "0" и в этом
случае, но не красиво это как-то. Вот собственно пожалуй и все по теме "0" и "нулевой указатель"
неожиданно вылезшей в теме по MMU.

А вот мои 5 рублей.
Мне вот тоже не нравится такое неуважительное отношение к нулевому указателю. В Паскале, с которого я начинал это сделано более чем идеально. Ну а стандарт С++ из-за этого какой-то "кривой". (редко я соглашаюсь с zltigo)

Писал как-то свой менеджер памяти на 486 системе. Да ещё в защищенном 32-битном режиме. Так вот было два сегмента - один для данных, другой для служебной информации. И мне было ну очень удобно выделять память данных с самого нуля. Тогда же я условился считать пустым указателем 0xFFFFFFFF. Ну и с тех пор пытаюсь даже на СИ не путать указатели с числами и использовать NULL. Короче, смысл в этом есть.