3 ms·
When it's time to speak directly to hardware, Rust and Haskell aren't exactly silver bullets: so much of the state ends up being in the chips instead of the pro
by jstewartmobile 9y ago
When it's time to speak directly to hardware, Rust and Haskell aren't exactly silver bullets: so much of the state ends up being in the chips instead of the program--thus outside the compiler's scope.
If we want to get away from C-level twiddling, we will also need to get away from C-level hardware.
- tome 9y agoIt's not outside the compiler's scope at all. See for example http://www.clash-lang.org/ http://www.clash-lang.org/.
- nickelbox 9y agoIt looks like something that just gets complied to VHDL and friends? Is there some way to make the description available to user code/GHC? Now that would be interesting.
- jstewartmobile 9y agoHow does an HDL address the limitation of software compilers at the software-hardware boundary? By scope, I mean that the compiler can really only see as far as the source code it is compiling. In something like an OS--especially a non-microkernel--an awful lot ends up having to be read and written across the boundary, and in an unsafe context.
- tome 9y agoOh I see. You were talking about a compiler for software talking to hardware. Well, I don't see why talking to hardware is any different to talking to a CPU or main memory or a disk.
- jstewartmobile 9y agoNot so much "talking" as directly reading/writing memory outside of your source scope that is also mutated by other chips--like a DMA buffer. Or for a traditional kernel, reading/writing directly into the address space of a user process. Wouldn't have to worry so much about race conditions there since the process could be suspended, but there is still an opportunity to fudge the indexing.