0

Context: I'm designing my own processor and instruction set as a learning exercise.

I'm trying to understand how a low-level assembly program knows which memory addresses it can access. Even if we assume we're running without virtual memory or OS protection and all of RAM is freely-writeable, we must make sure we don't accidentally overwrite our own instructions, as the program the data it manipulates are stored in the same address space.

As I see it, we have three types of memory at this level.

  • Static memory: This would be declared symbolically in the DATA section of the assembly program. Somehow this gets magically transformed into usable addresses.
  • Stack memory: Once the stack registers are set, we can happily push and pop. But how do we know where to initially put the base of the stack?
  • Heap memory: User-mode programs will request this via a syscall, and the OS will handle all the difficult stuff. We just get an address in the return value and use it. However, if we're writing the kernel rather than a user-mode program, no such concept exists.

My questions boil down to the following:

  1. How and when do static data declarations get translated into actual addresses?
  2. For a user-mode program that will be loaded by an OS, how does it know where to put the stack?
  3. For a kernel-mode program that is the OS, how does it know which memory it can use for kernel data structures, allocating to processes etc? Must everything be declared static up-front?

Feel free to give examples from any architecture/OS implementation, I'm just trying to get my head round how this is possible at all.

Christopher Riches
  • 769
  • 6
  • 21
  • 1) Usually link time 2) Depends on OS and address space size. A well known layout is to put the stack at the top of the memory growing down 3) Available memory depends on environment. Memory map may be provided by firmware or it may be known statically. For the dynamic stuff obviously the kernel maintains memory accounting metadata so it knows what it has already allocated and what is free. – Jester Apr 12 '20 at 21:49
  • 1
    For (1): read up on what linker and loader do. For (2): the kernel puts it somewhere into the address space where there's enough space to put it. On some systems, the executable format can specify where to put the stack instead. For (3): you as the kernel developer must decide this. The linker can help you. – fuz Apr 12 '20 at 21:49
  • Also, as per Stack Overflow rules: please try to avoid multiple distinct questions in one question post. Instead, make separate posts for each question or narrow it down to a single question. – fuz Apr 12 '20 at 21:50
  • The programming language has nothing to do with this you are talking about system design issues and programmer responsibility. Once you have a set of rules then the programmer should follow them independent of the language. Some languages and some systems prevent the programs (independent of language) from venturing off out of their own space. If they write over their own program that is called a bug. – old_timer Apr 12 '20 at 21:51
  • 1) link or runtime 2) part of the OS design 3) part of the OS design – old_timer Apr 12 '20 at 21:52
  • These seem rather like answers rather than comments; if you post an actual answer I can mark accepted. – Christopher Riches Apr 12 '20 at 21:55

0 Answers0