Why General-Purpose Programming Languages Suck For Hardware Design

https://blog.synflow.com/why-general-purpose-programming-languages-suck-for-hardware-design/

by jcr • 12 years ago

23 16 12 years ago

blog.synflow.com

lumpypua• 12 years ago

This blog post sets up a huge strawman. If you're trying to translate an arbitrary high level program into hardware, that's gonna be a pain in the ass. OTOH there's projects that allow you to use the composition tools of high level languages and still emit RTL code.

Haskell has:

- CλaSH: http://clash.ewi.utwente.nl

- Lava: http://raintown.org/lava/

- Chortl: http://wiki.cs.pdx.edu/forge/chortl.html

jcr2• 12 years ago

And in the Haskell-Inspired department, we also have Idris:

http://www.idris-lang.org/

I read something about getting Idris to emit RTL, but unfortunately, I can't find a link to it.

Of course, synflow.com wants to promote it's own "C~" language (I haven't looked at C~ yet, so I've got no opinion on it).

Calling the blog post a "strawman" is a bit too harsh. Instead, I'd call it "simplistic" or a "simple example" of the well known issues with the more "commonly used" general purpose languages --As much as we love Haskell, its use is far less prevalent than C or C++. The blog post would have been much better if it went into more detail on the more difficult issues of parallelism.

MootWoop5• 12 years ago

Well I did not want to promote C~ that much in that article :-) (there is not even a reference in the post). And yes the post is a bit simplistic, but I wrote this in response to hardware designers who believed that any sequential code (mostly C/C++) could be transformed to hardware given the proper tools.

I guess I could have been more precise, because indeed Haskell would not have the limitations of sequential languages (such as parallelism limited because of explicit memory references). Maybe I'll talk about parallelism in another article!

MootWoop5• 12 years ago

If you're trying to translate an arbitrary high level program into hardware, that's gonna be a pain in the ass.

What I'm trying to show in this post (and obviously I failed, sorry!) is that transforming a program written in a high-level sequential language to hardware is indeed a pain in the ass, but even more it just leads to inefficient hardware. Of course I took a somewhat extreme example with C++ and STL :D

MootWoop5• 12 years ago

I would add that as a matter of fact Haskell seems to me like a much better starting point to create efficient hardware, especially because side effects are well isolated, compared to C/C++ and others. But then probably over 90% of people (me included) don't necessarily want to use Haskell. We're designing C~ with the goal of making it mainstream rather than perfect.

Guvante• 12 years ago

We'll make the assumption that there exists a system than can transform any simple program

But then

Before you answer, note that including a class from the STL means that behind the scenes your program actually includes a huge bunch of code.

Either your sample hardware translation can handle STL natively or you do not have a simple program.

a dynamic memory allocator, a virtual memory system (or dozens of gigabytes of RAM, just in case), and a very complex Finite State Machine to implement the behavior of all the methods that are called directly and indirectly (so this includes methods from "list", "reverse_iterator", "allocator", etc.)

Assuming you are allowing the full powered standard STL library. You could provide a simplified one that avoided a lot of those problems (for instance having a maximum size of 256 and having some different underlying guarentees about time).

It seems the only point made is that no program could possibly take an arbitrary program and create an efficient hardware implementation of it. And I don't think anyone thinks that is possible.

MootWoop5• 12 years ago

You could provide a simplified [STL] Yes, and what if they use Boost? What I was trying to show here was that even a small amount of C++ code can be actually very complex, and that makes it impossible to transform to efficient hardware.
And I don't think anyone thinks that is possible. Well, you'd be surprised! Some fans of High-Level Synthesis seem to think that it is just that powerful...

oso2k2• 12 years ago

The blog post is flat out wrong makes some huge, errant assumptions.

To create hardware that implements the same behavior as this program, you would need:

a dynamic memory allocator

Wrong.

a virtual memory system (or dozens of gigabytes of RAM, just in case)

Why would this problem need a VM?

and a very complex Finite State Machine to implement the behavior of all the methods that are called directly and indirectly (so this includes methods from "list", "reverse_iterator", "allocator", etc.).

Again, wrong.

If the problem is to do

We'll make the assumption that there exists a system than can transform any simple program written in a general-purpose programming language to an efficient hardware implementation. This means that if I write a simple program, for example one that creates a list of random numbers and outputs them in reverse order

That is not a very hard problem and one could very well write a compiler that does that efficiently on FPGA or otherwise. Heck even designing a circuit would be doable for many EE BS grads.

In general, I believe the author attacked the proof wrong. The things he believes are necessary (malloc, VM, FSM) are inventions to circumvent hardware limitation, not language expressiveness or other issue with the general purpose language. Humans invented programming languages not because the hardware is impossible to create, but because it is impossible for most wetware (humans) to create that hardware (and/or software).

kd0amg• 12 years ago

More broadly, it's important to distinguish what things are aspects of the actual program semantics and what things are just common implementation strategies. Linking in lots of STL implementation code is not strictly necessary to get the behavior of a structure where one can push_back and walk over with an iterator. A similar argument to the article's would say that a compiler for a language with first-class functions cannot target a system with memory protection.

That said, most general-purpose languages are designed with the expectation that they'll be implemented on a conventional target machine. Compiling something like C++ to efficient hardware is probably far into "sufficiently smart compiler" territory. So I'm inclined to believe the conclusion even if the proof is faulty.

oso2k2• 12 years ago

I'd almost buy your conclusion if C to HDL/Verilog compilers didn't exist [1].

[1] http://en.wikipedia.org/wiki/C_to_HDL

etep2• 12 years ago

In a general purpose language, every line of code is implicitly sequenced, until told otherwise (e.g. for each in parallel, do...)

In a hardware description language, every line of code is executed in parallel, unless explicitly sequenced.

QED

I think it would be interesting, or at least instructive, to try and teach the HDL version of thinking to an untainted student.

Tyr42• 12 years ago

Note that that's not quite true for Haskell.

In Haskell, each line is not sequenced implicitly, though there are useful patterns (monads) which do specify the evaluation order. IO, State, and Writer are all sequenced, [] is depth first search, and Par is in parallel. We've got patterns for them all.

etep2• 12 years ago

A good point, and I would agree that Haskell is a good candidate for HDL. The following project nicely captures what I think of as a good direction (except for dependence on the JVM which is cross platform torture): https://chisel.eecs.berkeley.edu

fn• 12 years ago

Well yes, that's why VHDL, Verilog, and the like exists.

In those languages, when you "include" a module that is "unsynthesizable", for example the stdio library, then the entire program is rendered unsynthesizable and unable to be compiled into logic gates -- but can still be run for simulation purposes.

Why General-Purpose Programming Languages Suck For Hardware Design

Related Stories