4 ms·

https://news.ycombinator.com/item?id=43673011 https://news.ycombinator.com/item?id=43673011 Some discussion 3 weeks ago

chongli 1y ago
Someone asked on the previous discussion why there's no heap but no one answered and replies are locked out, so I'll answer here: There's no heap on the SNES because the system has only one program running at all times (the game). There's no point using dynamic memory allocation when all of the memory on the system is available to the program, so you can just start writing to any valid, writeable address you want. Some addresses are, of course, not writeable (such as ROM space), and some addresses are not memory (memory-mapped IO) but that's not a problem. The really nice thing about the SNES is that it uses a 24-bit address space instead of the 16-bit address space of the NES. Most NES games needed to use mapper chips to swap between different ROM banks since with 16 bits you can only address 64KB of memory at a time and many NES games were larger than that. Having 24 bits allows you to fit your game into far fewer ROM banks, greatly simplifying the programming model and making it much more realistic to use a high-level language like C#.
- kfuse 1y ago
  Frankly, that doesn't explain much, because that sounds like how modern computing works: every program has its own continuos 32/64 bit address space. With 24 bits you can address 16MB which seems enough to be useful if you throw away reflection and such.
  - chongli 1y ago
    16MB is larger than every single SNES game ever released. Modern programs have dynamic memory allocation. You can't just start writing to any address you want. You have to request memory from the operating system with malloc() and then free() it when you're done. Memory-managed programming languages handle this for you but it's still there under the covers. On the SNES, you simply have all memory available from the beginning. No malloc/free, just start reading and writing.
    - ninkendo 1y ago
      Malloc and free aren’t handled by the operating system, they’re handled in user space. Underneath malloc is mmap(2) (or in older unices, setbrk), which actually requests the memory. And with delayed/lazy allocation in the OS, you can just mmap a huge region up front, and it won’t actually do anything until you write/read to the individual pages. Point is, you only need one up front call to mmap to write to any page you want.
      - chongli 1y ago
        The SNES doesn’t have any concept of user space. Your program has full control of the hardware. You can do whatever you want. There is no operating system at all.
        ninkendo 1y ago
        I was responding to your second paragraph, where you talk about modern programs having to request memory from the OS with malloc and free. This isn’t true, malloc and free are not operating system concepts, they are ways for your program to divide up memory address space that is already mapped to you. To bring this back to the SNES, you could totally use malloc and free on the SNES, but it would be just vending pointers to the address space you can already use. But my point is that this is no different from a modern OS, because malloc and free are just managing the address space you already got from the OS using mmap. And plenty of malloc implementations avoid repeated calls to mmap by mapping a large amount of space up front. My point is, “having full access to the hardware” is completely orthogonal to whether malloc and free are a good idea. You can use malloc/free on a flat address space, just like you can use them on a big fat mmap() region. Instead, the reason you’d generally avoid malloc/free on SNES is that the amount of physical memory is so tiny that it’s generally a bad idea to do any dynamic memory management. Instead you want fixed regions representing in-game entities and logic, and the memory addresses you use should be managed manually in fixed size buffers. (If you’re still not convinced, consider that malloc and free work just fine in DOS, where there’s also no virtual memory and you have total access to the physical memory space in your program. DOS doesn’t have mmap, and malloc implementations on DOS just stick to managing the flat, physical address space. No MMU or virtual memory needed.)

Someone asked on the previous discussion why there's no heap but no one answered and replies are locked out, so I'll answer here: There's no heap on the SNES because the system has only one program running at all times (the game). There's no point using dynamic memory allocation when all of the memory on the system is available to the program, so you can just start writing to any valid, writeable address you want. Some addresses are, of course, not writeable (such as ROM space), and some addresses are not memory (memory-mapped IO) but that's not a problem. The really nice thing about the SNES is that it uses a 24-bit address space instead of the 16-bit address space of the NES. Most NES games needed to use mapper chips to swap between different ROM banks since with 16 bits you can only address 64KB of memory at a time and many NES games were larger than that. Having 24 bits allows you to fit your game into far fewer ROM banks, greatly simplifying the programming model and making it much more realistic to use a high-level language like C#.

kfuse 1y ago
Frankly, that doesn't explain much, because that sounds like how modern computing works: every program has its own continuos 32/64 bit address space. With 24 bits you can address 16MB which seems enough to be useful if you throw away reflection and such.
- chongli 1y ago
  16MB is larger than every single SNES game ever released. Modern programs have dynamic memory allocation. You can't just start writing to any address you want. You have to request memory from the operating system with malloc() and then free() it when you're done. Memory-managed programming languages handle this for you but it's still there under the covers. On the SNES, you simply have all memory available from the beginning. No malloc/free, just start reading and writing.
  - ninkendo 1y ago
    Malloc and free aren’t handled by the operating system, they’re handled in user space. Underneath malloc is mmap(2) (or in older unices, setbrk), which actually requests the memory. And with delayed/lazy allocation in the OS, you can just mmap a huge region up front, and it won’t actually do anything until you write/read to the individual pages. Point is, you only need one up front call to mmap to write to any page you want.
    - chongli 1y ago
      The SNES doesn’t have any concept of user space. Your program has full control of the hardware. You can do whatever you want. There is no operating system at all.
      - ninkendo 1y ago
        I was responding to your second paragraph, where you talk about modern programs having to request memory from the OS with malloc and free. This isn’t true, malloc and free are not operating system concepts, they are ways for your program to divide up memory address space that is already mapped to you. To bring this back to the SNES, you could totally use malloc and free on the SNES, but it would be just vending pointers to the address space you can already use. But my point is that this is no different from a modern OS, because malloc and free are just managing the address space you already got from the OS using mmap. And plenty of malloc implementations avoid repeated calls to mmap by mapping a large amount of space up front. My point is, “having full access to the hardware” is completely orthogonal to whether malloc and free are a good idea. You can use malloc/free on a flat address space, just like you can use them on a big fat mmap() region. Instead, the reason you’d generally avoid malloc/free on SNES is that the amount of physical memory is so tiny that it’s generally a bad idea to do any dynamic memory management. Instead you want fixed regions representing in-game entities and logic, and the memory addresses you use should be managed manually in fixed size buffers. (If you’re still not convinced, consider that malloc and free work just fine in DOS, where there’s also no virtual memory and you have total access to the physical memory space in your program. DOS doesn’t have mmap, and malloc implementations on DOS just stick to managing the flat, physical address space. No MMU or virtual memory needed.)