mips内存管理
如何手动管理 mips 程序集中的堆，特别是 SPIM 模拟器？
当使用 sbrk 系统调用时，我发现堆从 0x10040000 开始，例如
li $t0, 1
li $s0, 9
syscall
< code>sw $t0, ($s0) # 1 located at 0x10040000
所以，调用 sbrk 并不能保证你会得到下一个空闲内存插槽？例如，如果我为单个 4 字节空间调用 sbrk，SPIM 可能会分配地址：0x10040000-0x10040003。但是，对另一个 4 字节空间的第二次调用可能与之前的 4 字节分配无关？因此，需要一个数据结构来跟踪哪些内存槽已被分配？最后，内存管理器是否尝试通过确定特定数据结构跟踪的地址之间的可用空间来减少对 sbrk 的调用次数？
how do you manually manage the heap in mips assembly, specifically the SPIM simulator?
the heap, i've found begins at 0x10040000 when using the sbrk syscall, e.g.
li $t0, 1
li $s0, 9
syscall
sw $t0, ($s0) # 1 located at 0x10040000
so, does a call to sbrk NOT guarantee that you will get back the next free memory slot? for instance, if i called sbrk for a single 4 byte space, SPIM might allocate addresses: 0x10040000-0x10040003. however, a second call for another 4 byte space might be unrelated to the prior 4 byte allocation? thus, a data structure is required to keep track of which memory slots have been allocated? finally, do memory managers try to reduce the number of calls to sbrk by determining free space that lies between the addresses that are tracked by the particular data structure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在真实系统上，sbrk 返回页面粒度分配。我不确定 SPIM 模拟器是否这样做（微薄的在线文档意味着它将返回任何面向字节的粒度）。
一般来说，sbrk系统调用只是设置“堆尾”指针。底层操作系统所知道的只是堆的开头（sbrk 在程序开头开始的地方）和当前的堆结束指针。该范围内的所有内存都被视为（从操作系统的角度来看）程序正在使用的堆内存。
（注意，在你的情况下，我相信 SPIM 模拟器需要一个整数来碰撞指针，因此隐式地所有内存都是连续的，并且我认为中断总是在增加？）
通常构建在 sbrk 上的“malloc”API 提供了更多而不是一个简单的、连续的、不断增长的内存区域。一个好的 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.htmlOn real systems, sbrk returns page-granularity allocations. I'm not sure if the SPIM simulator does (the meagre online docs imply it will return any byte-oriented granularity).
Generally, the sbrk system call just sets the "end-of-heap" pointer. All the underlying OS knows is the beginning of the heap (where sbrk started at the beginning of the program), and the current end-of-heap pointer. All the memory in that bound is considered (from the OS point of view) heap memory in use by the program.
(Note, in your case I believe the SPIM simulator takes an integer to bump the pointer by, so implicitly all the memory is contiguous and I think the break is always increasing?)
The "malloc" API that is generally built on sbrk provides more than a simple contiguous, growing memory region. A good malloc library generally lets you mark a region of memory as "free" (so it can be used to satisfy a subsequent malloc call). Note that OS generally doesn't know about this "free". Malloc keeps track of the memory that is free or not. In general malloc cannot return this arbitrary region of the heap to the OS, because the heap is a single contiguous region from the OS point of view.
Real malloc implementations have to deal with the mis-match between allocation requests and page-size (normal sbrk only returns multiples of page-aligned, page-sized allocations). Your simulator case doesn't have this problem because sbrk is fine-grained.
Note that tracking which memory is in use or not requires memory, so malloc has some overhead. Some implementations are designed to store most of this bookkeeping in the "free" memory (reducing the apparent cost to the client). There are lots of other strategies for matching malloc to sbrk.... (In your case mapping malloc to sbrk, and making free a no-op will 'work' as long as you don't allocate too much memory ...)
Here's an overview of how
mallocandsbrkrelate that draws some ASCII art I don't have the patience to transcribe: http://web.eecs.utk.edu/~huangj/cs360/360/notes/Malloc1/lecture.html