Hacker News Reader

Comment by jstewartmobile | Hacker News Reader

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.

View on HN

It's not outside the compiler's scope at all. See for example http://www.clash-lang.org/.

It 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.

How 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.

Oh 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.

Not 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.

Reply on news.ycombinator.com