Rust is based on LLVM so it can only support the architectures that are supported there (save maybe a reimplementation like sibling comment mentioned).

What I don't understand is this whole thing about bootstrapping a new arch by building a whole new compiler on it, then compiling the source of an existing compiler on it (twice). Bytes of machine code don't have color, it's just a regular pile of bytes like everything else. Why does the compiler even have to run on the new arch? Just build a new backend for an existing compiler, then cross compile. It makes no sense to me why the machine code of a system must be assembled on that system.

I don't mean to sound adversarial, I'm just very confused.

> It makes no sense to me why the machine code of a system must be assembled on that system.

Assembling the machine code of a system on itself means it's independent of its "parent" system. If I can't run the compiler on my new architecture (including compiling itself), I'll forever depend on having another machine with a different architecture to compile things. Yes, usually it's done by writing a new backend for an existing compiler, then using the new backend to cross-compile the compiler itself, and finally running the resulting compiler on the new architecture; you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks.

In the same way, when compiling a new version of a compiler, having the recently-built compiler build itself again makes sure it's independent of its "parent" compiler.

"Assembling the machine code of a system on itself means it's independent of its "parent" system."

Far as a compiler, that doesn't really matter for most systems (esp embedded). You can cross-compile to any architecture you want with portable code and a new backend. The only tools you need for each architecture's CPU's/MCU's are something to load and test the code. Those already exist in embedded sector. Instrumentation for Rust code would be necessary but this doesn't involve doing the whole compiler on, say, an 8-bitter.

"you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks."

That's an SCM security problem. You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically. In any case, that's barely relevant to the discussion of using Rust on a new architecture as almost nobody will every be hit by that & most people wanting Rust backends aren't doing high-assurance security for stopping nation-states or something. Those people hand-verify the assembly anyway.

> You'd need to trust every compiler developer, the repo it's stored in, the transmission process, and whatever you used to build it. Most supposed solutions focus on the last one almost exclusively when the first three were the source of most attacks historically.

The first three aren't a "trusting trust" attack. With the first three, any attack is visible in the code that you eventually compile. The whole point of "trusting trust" is no amount of source code inspection will ever uncover the problem.

As infogulch noted, the reason I counter mentions of Paul Karger's attack (MULTICS early 70's) that Thompson wrote about is that is has to be a social fad/meme to mention it when it's happened only twice on record. Millions of attacks, countless vulnerabilities by compiler errors, many repos compromised, and 2 instances of a compiler-induced subversion. Yet, you brought up Trusting Trust instead of the other stuff we really need to worry about. That's typical do I always point it out.

Plus, Karger pointed out solution shortly after the problem: verified compiler, safe languages, repo security (esp paper in safes), crypto/courier distribution, and designed to build locally from source using onsite tools rerunning all tests, proofs, etc. Mitigates the need for worrying about Trusting Trust most of the time plus knocks out majority of attacks. Better to mention that if worried about subversion. Or Myer's landmark work that defined in detail problems and solutions.

Trusting Trust meme just misdirects focus from important issues.

I wasn't the one who brought up Trusting Trust.

But the person who did said

> you don't have to write a whole new compiler from scratch, unless you're worried about "trusting trust" attacks.

The point of that comment (at least, as I read it) isn't that you have to be worried about "trusting trust", but rather that there's no point in writing a new compiler from scratch unless you already are worried about "trusting trust" (with the implication being that most people aren't and so writing a new compiler from scratch isn't necessary).

SCM security issues (as you mentioned) are irrelevant at this point, because they really have no bearing on whether you have to write a new compiler from scratch.

Didn't look at the name. Too much of a hurry. My bad.

I think nickpsecurity's point is that there are many more lucrative targets to attack than compiler binaries. More lucrative in both effort/reward payoff and also difficulty of detection. For example: Analog Malicious Hardware [1], that would allow a single component added to the chip mask to compromise the entire chip only by the attacker and be undetectable and maintain plausible deniability. Other targets like BIOS, Intel AMT, etc would also be better.

[1]: https://www.ieee-security.org/TC/SP2016/papers/0824a018.pdf

The "trusting trust" argument is wholly unconvincing for the reasons nickpsecurity mentioned. There are too many moving pieces in this equation already, and piling on "moving to a new architecture" on top of everything else just doesn't make sense.

So that leaves just independence, which you solved right in your comment: use an existing compiler with a new backend to cross-compile itself. If your compiler is portable this still means the only thing you need to write is the new backend.

[1]: https://www.dwheeler.com/trusting-trust/

It would be interesting to see other compiler implementations.

Maybe one written in C89 that has its own backends for various archs. It would be less-focused on optimization and more on portability.

You'd think this is the case but in practice it's actually pretty solid. Right now I've got a nontrivial(opengl + vm language + ssl + http) project with a mix of C/Rust I'm bringing up that runs on:

  x86_64-mscv
  x86_64-osx
  x86_64-linux
  armv7-android
  i686-android
  arm-linux-hf
  armv7-linux-hf

Aside from needing a linker per-platform rustup takes care of all the LLVM stuff, it's really much simpler that I thought it would be.

Rust is also 32bit/64bit. That's totally fine (obviously) for PC-like situations and servers and more powerful embedded systems, etc.

But there are literally billions of 8bit and 16bit embedded systems out there, many of which have a C compiler.

There is some limited 16-bit support happening.

And AVR too: https://github.com/rust-lang/rust/issues/42450

Are 8-bit systems still being used for new development?

There's 8-bit MCU's all over the place. I tried to find some numbers for you with a quick Google. This 2014 Amtel report puts 8-bitters at $6+ billion a year. Even the 4-bitters are still making hundreds of millions a year. I include a bonus link on that if it perplexes you.

http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen...

http://www.embeddedinsights.com/channels/2010/12/10/consider...

Far as future, Jack Ganssle of The Embedded Muse has a nice assessment of it summarizing various sides:

http://www.ganssle.com/rants/is8bitsdying.htm

Oh, absolutely. The most familiar to software engineers is the AVR used in Arduino but there are so many 8 Bit micros out there (literally 10's of thousands different device) and new ones are coming out every month. So plenty of new development going on.

There are a couple of orders of magnitudes more Intel 8051 derivatives out there than there will ever be AVRs, and they still have yearly sales in the 100s of millions.

And how many percent of this is for new development?

There are still 24-bit systems used for new development.

Microcontrollers? Absolutely.

Yes but those are unlikely to be networked. The nasty stuff is something that is powerful enough to be connected to the internet and too weak to run modern languages. Fertile fields for Rust.

Worth pointing out an approach that Julia took, compiling LLVM to C might also work for Rust:

https://juliacomputing.com/blog/2016/03/10/j2c-announcement....

I agree, and this is the only thing stopping me from putting rust into production.

I have high hopes for something like https://github.com/thepowersgang/mrustc

What architectures matter to you?

Of all the architectures I contract for, I think AIX is the one furthest behind as far as LLVM and Rust support goes.

Cool thanks, always trying to hear what we need to work on.

Is there an ISA call AIX or did you mean platform support for AIX operating system on POWER?

I mean AIX on Power (BE).

In 2017.

C wasn't that portable in the 80's and 90's, with all its flavous across CP/M, MS-DOS, 8-bit home micros, mainframes, ...

The difference is that one could reasonably write a C compiler in assembly, and use that to bootstrap a better C compiler if desired.

Writing a rust compiler in assembly might be challenging.