Перейти к содержанию
    

1 час назад, tonyk_av сказал:

Нет, бОльшего. Ведь приходится резервировать память, априори не зная реальную потребность.

Это как это? Вот например: есть у вас интерфейс, через который могут приниматься JSON-ы. Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт. Но только при статическом выделении это и будет 100 байт потрачено, а при динамическом == 100 байт + заголовок блока + потери на фрагментацию. Причём последняя составляющая - почти непредсказуема (без циклов "сборки мусора" и MMU).

 

1 час назад, tonyk_av сказал:

Как раз наоборот, меньшего.

Ну раз у вас получаются затраты памяти при статическом резервировании больше, то значит - мастерства явно не хватает.  :unknw:

28 минут назад, tonyk_av сказал:

С ПЛК работали? Там такая штука не канает.

Почему? Пруфы в студию!

Сдаётся мне, что вы не поняли о чём речь.... Именно благодаря оверлеям, static allocation и выигрывает у dynamic в сложных задачах.

 

PS: Да и при чём тут ПЛК, если тема про FreeRTOS?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

54 минуты назад, tonyk_av сказал:

С ПЛК работали? Там такая штука не канает.

Нет, не работал. А можно, и правда, выдержку из (что это - стандарт?) документа, где явно об этом написано?

Вы же сами понимаете, что это утопия? В рядовой программе даже банальный union с буфером внутри уже, получается, "запрещен"? А placement new в C++?

А неявные оптимизации расхода стека при работе с невстраиваемыми функциями? Ведь они неявно тоже один и тот же кусок памяти юзают...

Это я даже не упоминаю оверлеи на уровне взаимодействия с линкером.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21 minutes ago, jcxz said:

PS: Да и при чём тут ПЛК, если тема про FreeRTOS?

Речь идёт о распределении памяти. В качестве примера привёл вариант решения вопроса распределения памяти в рантаймк ПЛК.

22 minutes ago, jcxz said:

Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт

Смысла в 100 байт как раз и нет. Нужно резервировать столько, сколько может быть максимальный размер запрашиваемого блока. Для понимания того, о чём я говорю, достаточно вспомнить формат хранения строк в нынешних ПЛК S7 от Сименса или старом Паскале.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 минут назад, tonyk_av сказал:

Смысла в 100 байт как раз и нет. Нужно резервировать столько, сколько может быть максимальный размер запрашиваемого блока.

Вы прочитали, что я писал?

34 минуты назад, jcxz сказал:

Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт.

Каким именно образом динамическое выделение в этом случае позволит уменьшить требования по памяти?

Я вам выше исходные условия задачи описал. Спрашивал - каким именно образом динамическое выделение позволит уменьшить требования по ОЗУ.

 

5 минут назад, tonyk_av сказал:

Для понимания того, о чём я говорю, достаточно вспомнить формат хранения строк в нынешних ПЛК S7 от Сименса или старом Паскале.

"Пойди туда, не знаю куда....."

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, Arlleex said:

А можно, и правда, выдержку из (что это - стандарт?) документа, где явно об этом написано?

Это стандарты ГОСТ Р МЭК по функциональной безопасности ПО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, tonyk_av сказал:

Это стандарты ГОСТ Р МЭК по функциональной безопасности ПО.

Это я понял, но я хотел именно выдержку, где написан запрет на использование оверлеев.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, Arlleex сказал:

Это я понял, но я хотел именно выдержку, где написан запрет на использование оверлеев.

Имхо - нас забалтывают...  :unknw:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, Arlleex said:

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

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

9 minutes ago, jcxz said:

"Пойди туда, не знаю куда....."

Н. Вирт, "Алгоритмы+структуры данных= программы". Классика. Раздел 5. Посмотрите, как построена таблица имён и работа с ней.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Только что, tonyk_av сказал:

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

А оверлеи дают недетерминированное поведение? Разумеется, при должном подходе и без них ПО можно сделать недетерминированным.

Лейтмотивы не мыслю, я привык, что в стандартах есть четкие "можно" и "нельзя". А иногда какие-то выкладки носят лишь рекомендательный характер.

  

Только что, jcxz сказал:

Имхо - нас забалтывают...  :unknw:

Ну просто если это правда - я был бы рад об этом узнать. Во многих отраслях с ума сходят по-своему. Но пока что пруфов нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно вместо голых указателей использовать чуть более сложные объекты для доступа к выделенной памяти. Так, чтобы куча знала где лежат ссылки на ее объекты. Это позволит делать дефрагментацию без mmu. На C++ наверно кто-то так делает, но это сложно.

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

Изменено пользователем amaora

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 часов назад, dxp сказал:

Фрагментация кучи на физической памяти — неустранимая проблема.

Сам использую такой метод, например нужно распарсить что-то, обнуляем кучу, затем работаем malloc\free, как завершили работу, снова очищаем кучу для следующего сеанса, фрагментация будет только в локальном сеансе и небольшая. Но конечно, если можно не использовать дин память, лучше так и делать...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21 час назад, tonyk_av сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Коллеги, а причём тут вообще ПЛК или иные контроллеры? Автор темы о них ничего не говорил. Может быть его плата управляет какой-нибудь кофе-машиной. Да и ладно, подождём пару секунд, пока выделится/склеится память. Кофе от этого хуже не станет))) Просто пока сам автор топика не обозначил область своей разработки, вполне можно предлагать любое решение: MMU, оверлеи и т.п. При этом нет смысла говорить о том, что предложенное решение не подходит для блока управления левым передним колесом марсохода. Зато для кофе-машины подходит!)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 minutes ago, dxp said:

На виртуальной памяти в принципе никаких дырок не образовывается.

Да ну! А мужики-то не знают!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я некорректно выразился. Исправил.

Вам известны случаи падения программ, например, на x86 из-за того, что фрагментация "побила" всю память?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...