3 ms·

Putting multiple Erlang functions into a single C function to avoid using C’s stack sounds awesome but also horrifying.

chrisseaton 6y ago
> Putting multiple Erlang functions into a single C function to avoid using C’s stack sounds awesome but also horrifying. Why's that horrifying? Isn't inlining a super-basic and well-understood optimisation that any serious compiler would be doing?
- azhenley 6y ago
  No, this isn't inlining. They're managing their own call stack and relying on undefined behavior. See the quote from the article: > BEAM/C generated a single C function for each Erlang module. Local calls within the module were made by explicitly pushing the return address to the Erlang stack followed by a goto to the label of the called function. (Strictly speaking, the calling function stores the return address to BEAM register and the called function pushes that register to the stack.) > Calls to other modules were done similarly by using the GCC extension that makes it possible to take the address of a label and later jumping to it. Thus an external call was made by pushing the return address to the stack followed by a goto to the address of a label in another C function. > Isn’t that undefined behavior? > Yes, it is undefined behavior even in GCC.
  - chrisseaton 6y ago
    Ah sorry I see.
  - jpcooper 6y ago
    Why is it undefined behaviour?
    - IainIreland 6y ago
      You aren't allowed to goto a label in a different function. From the C standard: > The identifier in a goto statement shall name a label located somewhere in the enclosing function. `Shall` is a term of art here: > If a "shall" or "shall not" requirement that appears outside of a constraint is violated, the behavior is undefined. (Sections 6.8.6.1.1 and 4.2, respectively: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
      - jpcooper 6y ago
        Appreciated.
      - jhoechtl 6y ago
        It's undefined in the C standard. That doesn't mean its insecure or undefined as seen from the machine code. nothin is hilding you back to do your own code generation and clearly define this behaviour.
        MaxBarraclough 6y ago
        They weren't doing their own code-generation, BEAM/C treated C as the target language, and then relied on a standard C compiler. From the article: > it is undefined behavior even in GCC. It happened to work with GCC on Sparc, but not on GCC for X86.
        deleted 6y ago
        [deleted]
  - dnautics 6y ago
    over in zigland in private we're saying that one of the endgoals of zig should be to reimplement the BEAM. One of the most active users of zig is doing some really neat things with task-stealing, allocation-free, lock-free schedulers that are a lot like the BEAM's techniques, except super performant: (watch this for till the benchmarks demos ~ finishing 1h:17min https://www.youtube.com/watch?v=UaF6-5BmX2I&t=1h9m https://www.youtube.com/watch?v=UaF6-5BmX2I&t=1h9m)
shiny 6y ago
To anyone just reading comments, this is referring to the old BEAM/C compiler, not the new JIT.

> Putting multiple Erlang functions into a single C function to avoid using C’s stack sounds awesome but also horrifying. Why's that horrifying? Isn't inlining a super-basic and well-understood optimisation that any serious compiler would be doing?

azhenley 6y ago
No, this isn't inlining. They're managing their own call stack and relying on undefined behavior. See the quote from the article: > BEAM/C generated a single C function for each Erlang module. Local calls within the module were made by explicitly pushing the return address to the Erlang stack followed by a goto to the label of the called function. (Strictly speaking, the calling function stores the return address to BEAM register and the called function pushes that register to the stack.) > Calls to other modules were done similarly by using the GCC extension that makes it possible to take the address of a label and later jumping to it. Thus an external call was made by pushing the return address to the stack followed by a goto to the address of a label in another C function. > Isn’t that undefined behavior? > Yes, it is undefined behavior even in GCC.
- chrisseaton 6y ago
  Ah sorry I see.
- jpcooper 6y ago
  Why is it undefined behaviour?
  - IainIreland 6y ago
    You aren't allowed to goto a label in a different function. From the C standard: > The identifier in a goto statement shall name a label located somewhere in the enclosing function. `Shall` is a term of art here: > If a "shall" or "shall not" requirement that appears outside of a constraint is violated, the behavior is undefined. (Sections 6.8.6.1.1 and 4.2, respectively: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
    - jpcooper 6y ago
      Appreciated.
    - jhoechtl 6y ago
      It's undefined in the C standard. That doesn't mean its insecure or undefined as seen from the machine code. nothin is hilding you back to do your own code generation and clearly define this behaviour.
      - MaxBarraclough 6y ago
        They weren't doing their own code-generation, BEAM/C treated C as the target language, and then relied on a standard C compiler. From the article: > it is undefined behavior even in GCC. It happened to work with GCC on Sparc, but not on GCC for X86.
      - deleted 6y ago
        [deleted]
- dnautics 6y ago
  over in zigland in private we're saying that one of the endgoals of zig should be to reimplement the BEAM. One of the most active users of zig is doing some really neat things with task-stealing, allocation-free, lock-free schedulers that are a lot like the BEAM's techniques, except super performant: (watch this for till the benchmarks demos ~ finishing 1h:17min https://www.youtube.com/watch?v=UaF6-5BmX2I&t=1h9m https://www.youtube.com/watch?v=UaF6-5BmX2I&t=1h9m)

shiny 6y ago

To anyone just reading comments, this is referring to the old BEAM/C compiler, not the new JIT.