3 ms·

Yep. I understand and this is why I could integrate rust right now into my products, module by module or object file by object file. I just need the compiler t

Yep. I understand and this is why I could integrate rust right now into my products, module by module or object file by object file. I just need the compiler to run on my systems. Since it is written in rust, I either need it ported to my systems (too much work) or I need my rust code transpiled to C or C++ so I can build it myself (seems doable).

pcwalton 10y ago
It's not doable. How do you deal with UB from signed overflow? How do you get proper debug info? How do you set the proper EH personality? There are no shortcuts to a proper implementation of Rust. Implement an LLVM backend for your architecture. It doesn't make sense for Rust to maintain a backend that is doomed to be forever broken in various ways.
- jjnoakes 10y ago
  I answered your ub question elsewhere. Exceptions and debug info come from C++. I don't see the issues there yet, but perhaps I just don't have the right knowledge yet. Rust won't have to maintain the backend. Who said they would? They might choose to if it becomes useful - it would give them things they dint have now (C++ interoperability, and new platform support for almost free), but no one here asked them to maintain anything. I am also not sure what you mean by shortcuts or broken forever in various ways.
  - pcwalton 10y ago
    > Rust won't have to maintain the backend. Who said they would? They might choose to if it becomes useful - it would give them things they dint have now (C++ interoperability, and new platform support for almost free), but no one here asked them to maintain anything. If out of tree, the backend will constantly break due to massive compiler churn. You need it in tree.
    - jjnoakes 10y ago
      I don't think so. The backend would simply lag behind major releases a bit. It's not going to use all of the compiler internals, so updating it will only be a little extra work if the HIR (or maybe MIR, depending) changes. If Rust has plans on building a large amount of their internal optimizations on MIR, then I would think MIR would be fairly stable too, which makes this even less of an issue. It's going to be a toy project for now. If it works out, it'll be maintained against a specific version of the Rust compiler (stability is important in industry). And if that works out even more, perhaps Rust will accept patches to put it in-tree. Of course, in-tree would be better. But it isn't a requirement. But none of that is important at this point.
crzwdjk 10y ago
Do you actually need a compiler that runs on those exotic systems, or just one that targets them? Because Rust (thanks to LLVM) is a whole lot better at the latter than the former, and it might well be possible to build something for your obscure UNIX. But for various reasons, Rust is not great at all at cross-compiling itself, so you would likely have to use something more conventional as your build server.
- jjnoakes 10y ago
  That may be something to investigate for sure... I'm not sure how it all works but I may take a closer look. How would it handle my object file, shared library file, and executable file formats? Or my calling conventions?

pcwalton 10y ago

It's not doable. How do you deal with UB from signed overflow? How do you get proper debug info? How do you set the proper EH personality? There are no shortcuts to a proper implementation of Rust. Implement an LLVM backend for your architecture. It doesn't make sense for Rust to maintain a backend that is doomed to be forever broken in various ways.

jjnoakes 10y ago
I answered your ub question elsewhere. Exceptions and debug info come from C++. I don't see the issues there yet, but perhaps I just don't have the right knowledge yet. Rust won't have to maintain the backend. Who said they would? They might choose to if it becomes useful - it would give them things they dint have now (C++ interoperability, and new platform support for almost free), but no one here asked them to maintain anything. I am also not sure what you mean by shortcuts or broken forever in various ways.
- pcwalton 10y ago
  > Rust won't have to maintain the backend. Who said they would? They might choose to if it becomes useful - it would give them things they dint have now (C++ interoperability, and new platform support for almost free), but no one here asked them to maintain anything. If out of tree, the backend will constantly break due to massive compiler churn. You need it in tree.
  - jjnoakes 10y ago
    I don't think so. The backend would simply lag behind major releases a bit. It's not going to use all of the compiler internals, so updating it will only be a little extra work if the HIR (or maybe MIR, depending) changes. If Rust has plans on building a large amount of their internal optimizations on MIR, then I would think MIR would be fairly stable too, which makes this even less of an issue. It's going to be a toy project for now. If it works out, it'll be maintained against a specific version of the Rust compiler (stability is important in industry). And if that works out even more, perhaps Rust will accept patches to put it in-tree. Of course, in-tree would be better. But it isn't a requirement. But none of that is important at this point.

crzwdjk 10y ago

Do you actually need a compiler that runs on those exotic systems, or just one that targets them? Because Rust (thanks to LLVM) is a whole lot better at the latter than the former, and it might well be possible to build something for your obscure UNIX. But for various reasons, Rust is not great at all at cross-compiling itself, so you would likely have to use something more conventional as your build server.

jjnoakes 10y ago
That may be something to investigate for sure... I'm not sure how it all works but I may take a closer look. How would it handle my object file, shared library file, and executable file formats? Or my calling conventions?