http://www.xda-developers.com/risc-v-cores-and-why-they-matt...
http://hackaday.com/2014/08/19/open-source-gpu-released/
http://hackaday.com/2014/08/19/open-source-gpu-released/
Some compelling projects (GPU) failed for lack of interest. The concepts behind those projects did not fail because most of the projects were isolated. The best time for open hardware is yet to come. Redox could accelerate that.
The point I'm trying to make is that open hardware could also be programmed in Rust, reducing the number of "unsafe" blocks in user applications. Software for proprietary hardware is usually written in unsafe C/C++.
See: http://doc.rust-lang.org/book/unsafe.html#unsafe-superpowers
This is truly awful. It means you need to carry around a C compiler for the low-level parts. You could also use assembly, but then you're forced to write whole functions in assembly.
Arbitrary pointer arithmetic is also supported.
There is something else missing AFAIK. It's not quite as critical, but it sure helps: bitfields
This was done rather badly in C, reducing portability by not letting the programmer fully specify the layout. Normally we mostly ignore portability; for x86 gcc and Visual Studio are compatible.
Imagine writing an x86 emulator which might run on hardware of either endianness. In theory, bitfields are perfect for implementing the GDT, LDT, and IDT. Bitfields are also great for pulling fields out of opcodes. Unfortunately, bitfield layout in C is undefined. The same trouble hits when parsing a file, for example a flash animation file.
One should be able to specify spans of bytes with chosen endianness and bit order, then subdivide each span into fields. Normally each bit should belong to exactly one field, with an error if violated, but it should be possible to define overlapping fields if the programmer insists. Fields should then be able to be joined into larger fields, even if they come from different byte spans. This allows handling split fields such as the x86 descriptor's base and limit or the PowerPC opcode SPR encoding.
Lack of bitfield support and lack of a "restrict" keyword are probably the two biggest things holding me back from rust now.
> Lack of bitfield support and lack of a "restrict" keyword
Rust automatically adds the appropriate 'restrict' annotations to `&mut T` pointers, or well, does generally, but I think an LLVM bug made us take it off temporarily. Point is, this isn't something that you annotate in Rust like you do in C, you use the type system and the compiler handles it where appropriate. (It's more than just &mut T, like, UnsafeCell will also cause the annotation to _not_ happen, for example.)