-8

I know that the basic C program layout in memory is code/text, data, heap and stack. The C program memory layout does correspond to the more general layout of a process in memory.

My questions are :

  1. Where does the "C program layout = General process layout" association stem from ? ( If we consider all the computer science literature out there...)

  2. If I were to write a compiler for a programming language that I create ( let's call it "ONE" ) what are the main rules that I should comply with ( let's say that we are in a Linux OS with intel x86_64 ) ?

20
  • 1
    iso.org/standard/74528.html I only care if it runs or not. Haha. And to know what standard it is, perhaps you have to read the book Commented Aug 8, 2023 at 12:34
  • 1
    re: question 1: Let me ask you, where are you getting the terms "C program layout" and "General process layout" from? ...because it sounds like nonsense to me (googling for the term "C program layout" returns nothing but low-value content-farm websites like geeksforgeeks repeating the same thing over...) Commented Aug 8, 2023 at 12:34
  • 1
    @alessiosolari I know you meant that, and that doesn't change my response: that it isn't a meaningful term in the first place, and despite being meaningless it's being repeated by other people (content-farms, etc) who don't know what they're writing about. Commented Aug 8, 2023 at 12:37
  • 1
    @alessiosolari They're using an imprecise terminology. In the olden days, a fairly common executable format was "a.out". Now Linux uses "ELF", on Mac it's "Mach-O" and on Windows it's "COFF". All three OSes have differences in linking and executing dynamic programs, the C standard does not mandate implementation. Commented Aug 8, 2023 at 12:43
  • 3
    "99% of books" -- citation needed. Commented Aug 8, 2023 at 13:46

1 Answer 1

5

Where does the "C program layout = General process layout" association stem from ? ( If we consider all the computer science literature out there...)

Each operating system has a method (or methods) of loading programs and starting their execution. This includes formats of executable files that it can read and load. An executable file format typically contains some header that describes what program sections are in the file and then information that describes each program section. Program sections may contain data to be loaded into memory as initial values for objects or may contain instructions to be loaded into memory to be executed. Or a program section may simply be an amount of space that needs to be made available in memory.

There is no C program layout. A compiler is a translator. It translates from the C language into machine language. (This process typically involves multiple steps: Translating C into an internal representation, perform optimization and other operations on the internal representation, translating the internal representation into assembly or a representation of it, translation assembly into machine language, writing machine language and data into object modules, and linking object modules into an executable program.)

In the C source code, an abstract model of computing is used, as described in the C standard. No specific hardware stack is specified (although stack semantics are specified because parameters and automatic objects have last-in first-out behavior in function calls). No specific program layout is specified. The compiler translates C source code to an executable program of the target platform, and that is what gives the program its process layout.

If I were to write a compiler for a programming language that I create ( let's call it "ONE" ) what are the main rules that I should comply with ( let's say that we are in a Linux OS with intel x86_64 ) ?

Write files in the formats expected by the linker and the program loader. Conform to the Application Binary Interface specified by the operating system.

Sign up to request clarification or add additional context in comments.

6 Comments

+1, but could you clarify what you mean by "stack semantics are specified"? The word "stack" does not appear even once in the C17 or C23 spec.
I don't know what you mean by "parameters have first-in first-out behavior". Parameters don't do anything, so describing their behaviour doesn't make any sense. /// And then there's the issue that a FIFO is a queue, not a stack. So how did you jump from "first-in first-out behavior" to "stack semantics"? /// Please clarify what you mean. by that parenthetical.
@ikegami: “first-in first-out” was supposed to be “last-in first-out”. I corrected that. Parameters and automatic objects and a record of program control exist in multiple instances when a function is called recursively (directly or indirectly), and the behavior is last-in first-out: The most recent instance that has not been popped by a function return (or termination via longjmp etc.) is the instance that is used, and popping reveals the most recent instance before that.
So it's recursion that implies stack semantics.
@ikegami: The C standard specifies recursion is supported. C 2018 6.5.2.2 11 says recursive calls shall be permitted, and other parts of the standard specify the semantics of parameters and automatic objects, and those form stack semantics, and therefore the standard specifies stack semantics.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.