5 ms·

>Firstly, bare metal here means this stack can create an img with an executable that will be run with nothing more the uboot? I.e. No OS, no kernel, not even a

>Firstly, bare metal here means this stack can create an img with an executable that will be run with nothing more the uboot? I.e. No OS, no kernel, not even a Rust runtime (hence, presumably, no std in the example)? Yes, that is correct. No OS, no kernel, no runtime. Now, Rust is isolating a core library (called libcore) that can be used without runtime support (and hence in projects like this one).

pjmlp 12y ago
To be pedantic, from compiler design point of view, that is also a runtime.
- eric_bullington 12y ago
  Well, it uses the libc runtime [This is actually mostly incorrect, see comment below by dbaupp], which obliges me to invoke the old quote, "the greatest trick C ever played was to convince the world it has no runtime". I wish I could track down the originator of that quote, but I have no idea. I'm sure someone here will know.
  - dbaupp 12y ago
    Libcore doesn't use the (entire) libc runtime; IIRC, it essentially just needs the memcpy and memset symbols to be defined.
    - heinrich5991 12y ago
      Couldn't it use librlibc then?
      - dbaupp 12y ago
        Yes, that's exactly what librlibc is for and what is used.
    - andrewflnr 12y ago
      Why not just implement those in Rust too? It seems like you could break the dependency entirely.
      - pcwalton 12y ago
        You can implement those in Rust if you want.
      - dbaupp 12y ago
        Yes, you can, and they are even provided in pure Rust for exactly that reason: http://doc.rust-lang.org/master/rlibc/ http://doc.rust-lang.org/master/rlibc/ (Seems there were 2 more mem* symbols required than I remembered.)
  - pjmlp 12y ago
    Yes, now we have to make the world understand what a lie it was.
  - pjc50 12y ago
    The runtime really isn't mandatory, though. It's entirely feasible to have an embedded system where the only code that runs is your own. I'll agree that glibc is a much larger iceberg than people think, though.

pjmlp 12y ago

To be pedantic, from compiler design point of view, that is also a runtime.

eric_bullington 12y ago
Well, it uses the libc runtime [This is actually mostly incorrect, see comment below by dbaupp], which obliges me to invoke the old quote, "the greatest trick C ever played was to convince the world it has no runtime". I wish I could track down the originator of that quote, but I have no idea. I'm sure someone here will know.
- dbaupp 12y ago
  Libcore doesn't use the (entire) libc runtime; IIRC, it essentially just needs the memcpy and memset symbols to be defined.
  - heinrich5991 12y ago
    Couldn't it use librlibc then?
    - dbaupp 12y ago
      Yes, that's exactly what librlibc is for and what is used.
  - andrewflnr 12y ago
    Why not just implement those in Rust too? It seems like you could break the dependency entirely.
    - pcwalton 12y ago
      You can implement those in Rust if you want.
    - dbaupp 12y ago
      Yes, you can, and they are even provided in pure Rust for exactly that reason: http://doc.rust-lang.org/master/rlibc/ http://doc.rust-lang.org/master/rlibc/ (Seems there were 2 more mem* symbols required than I remembered.)
- pjmlp 12y ago
  Yes, now we have to make the world understand what a lie it was.
- pjc50 12y ago
  The runtime really isn't mandatory, though. It's entirely feasible to have an embedded system where the only code that runs is your own. I'll agree that glibc is a much larger iceberg than people think, though.