Управление памятью mips

Question

Как вы вручную управляете кучей в сборке mips, в частности, симулятором SPIM?

куча, которую я нашел, начинается с 0x10040000 при использовании sysck syscall, например.

li $t0, 1

li $s0, 9

syscall

sw $t0, ($s0) # 1 located at 0x10040000

так, то вызов sbrk не гарантирует, что вы получите обратно следующий свободный слот памяти? например, если я назвал sbrk для одного 4-байтового пространства, SPIM мог бы выделять адреса: 0x10040000-0x10040003. однако второй вызов другого 4-байтового пространства может быть не связан с предыдущим распределением 4 байтов? таким образом, требуется структура данных, чтобы отслеживать, какие слоты памяти были выделены? наконец, ли руководители памяти пытаются уменьшить количество вызовов на sbrk, определяя свободное пространство, которое находится между адресами, которые отслеживаются конкретной структурой данных?

Answer 1

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

Как правило, системный вызов sbrk просто устанавливает указатель «конец кучи». Вся базовая ОС знает, что это начало кучи (где sbrk запущен в начале программы) и текущий указатель конца кучи. Вся память в этой связи считается (с точки зрения ОС) кучей памяти, используемой программой.

(Обратите внимание, в вашем случае, я считаю, что SPIM Тренажер занимает целое врезаться указатель на, так неявно вся память является непрерывным, и я думаю, что разрыв постоянно растет?)

«таНос» API который, как правило, построен на sbrk, обеспечивает более чем просто непрерывную, растущую область памяти. Хорошая библиотека malloc обычно позволяет отмечать область памяти как «свободную» (поэтому ее можно использовать для удовлетворения последующего вызова malloc). Обратите внимание, что ОС обычно не знает об этом «свободном». Malloc отслеживает свободную или свободную память. В общем случае malloc не может вернуть эту произвольную область кучи в ОС, потому что куча является одной смежной областью с точки зрения ОС.

Реальные реализации malloc должны иметь дело с неправильным совпадением между запросами на распределение и размером страницы (обычный sbrk возвращает только кратность вычисленных по страницам, размер страниц). У вашего симулятора нет этой проблемы, потому что sbrk мелкозернистый.

Обратите внимание, что для отслеживания, какая память используется или нет, требуется память, поэтому malloc имеет некоторые накладные расходы. Некоторые реализации предназначены для хранения большей части этой бухгалтерской отчетности в «свободной» памяти (уменьшая очевидную стоимость для клиента). Существует множество других стратегий для сопоставления malloc с sbrk .... (В вашем случае сопоставление malloc с sbrk и освобождение no-op будет «работать», если вы не выделяете слишком много памяти ...)

Вот краткий обзор того, как malloc и sbrk связаны, что привлекает некоторые ASCII искусство не хватает терпения, чтобы расшифровать: http://web.eecs.utk.edu/~huangj/cs360/360/notes/Malloc1/lecture.html