0

in MIPS, we can allocate memory by using .space of setting $v0 to 9.

.data
arr: .space 12 # array of 12

or


li $v0, 9
li $a0, 12
syscall

I know that both will give me 12 bytes of space, sbrk allocates from heap but I actually do not know what does .space does. Can you explain is there a difference between these two?

hadz
  • 3
  • 1
  • 2
    `.space` just puts that many zeroes into your binary. `sbrk` allocates at runtime, so it can use variable size and it does not enlarge your binary. – Jester Nov 12 '22 at 12:30
  • 1
    `.space` is static allocation, like C global or `static` vs. dynamic allocation like `malloc` or Unix `brk`/`sbrk`. – Peter Cordes Nov 12 '22 at 12:51
  • Correct me if I'm wrong, but does `sbrk` essentially alter the imaginary boundary dividing the stack from the heap? – puppydrum64 Nov 22 '22 at 16:36
  • @puppydrum64: In systems with unlimited stack growth and no `mmap`, yes. In modern systems, the initial "break" is just after the BSS, and yes `sbrk` can grow or shrink a single region. Stack growth is limited to some small size, like 8MiB on Linux by default. "The heap" isn't a single thing really exists at the asm level, in systems where you can do large allocations with `mmap(MAP_ANONYMOUS)` or `VirtualAlloc`. It's only useful as a concept for where dynamic allocations come from, with brk being one way to allocate heap space. – Peter Cordes Nov 30 '22 at 21:43
  • @PeterCordes From what I'm used to, on most CPUs with a relocatable stack pointer, the "heap" and "stack" are the same section of RAM, and nothing is actually separating them or stopping the stack from clobbering the heap. – puppydrum64 Dec 02 '22 at 11:07
  • @puppydrum64: On Linux (and I think most other OSes), the initial stack goes near the top of user virtual address-space. The text/data segments go near the bottom, or in the middle. On Linux, `mmap` picks highish addresses, too, below the 8MiB reserved for stack growth. (Including for file-backed mapping, e.g. for shared libraries which happens in nearly every process). So this would stop the stack from growing all the way to the break, if that's what you're calling the heap. – Peter Cordes Dec 02 '22 at 11:14
  • @puppydrum64: If you mean growing into a random `mmap` in that region, there's at least one guard page below the max stack growth extent, so only large stack arrays or something like that could jump the stack into another mappina, a "stack clash". See [Linux process stack overrun by local variables (stack guarding)](https://stackoverflow.com/q/60058873) re: GCC hardening options to prevent stack clash security vulns by touching intervening pages, so you segfault on the guard page before anything dangerous can happen. Windows always requires stack probes. – Peter Cordes Dec 02 '22 at 11:15
  • I'm used to assembly with no OS (e.g. Game Boy, etc) so I don't have that luxury. – puppydrum64 Dec 02 '22 at 11:15
  • @puppydrum64: If you mean an older simpler system with no mmap, then sure. I did mention modern systems and `mmap` so clearly wasn't talking about that. – Peter Cordes Dec 02 '22 at 11:16

1 Answers1

1

Easiest way to see the difference is by looking at your compiled executable in a hex editor. When using .space n your file size has increased by n bytes. Try assembling the same program with and without the .space 12, you'll see 12 extra zeroes in the hexdump of the version with the .space 12.

puppydrum64
  • 1,598
  • 2
  • 15