I was working on something like that a while back. I reasoned that functional languages without side-effects (like Haskell) make it straightforward to convert programs into dataflow diagrams. Dataflow diagrams would be relatively straightforward to convert into Verilog code that could be converted to logic. A well-designed functional language could then be made to compile to machine code or to FPGA hardware as needed for the purposes of optimizing hotspots in supercomputing applications. (Assuming the communication overhead and latency are not a problem.)
Of course, I didn't want my first pass to require some massive AI to "understand" some Scheme-like code in order to figure out what and how to convert something, so I wanted language concepts that would make these things more explicit. There are two major features that I felt would be necessary to make this work well: (1) Distinguish between lists (which are to be pipelined and processed sequentially) from vector (whose members are intended to be processed in parallel). (Function input and output arguments would ultimately be treated as vectors of something.) (2) Move from a single anonymous return value to multiple named return values. This way, arbitrary dataflows could be more easily described where we don't need compiler smarts to figure out that a list or vector returned by some function is actually just a container for multiple return values that may go different places. On top of that, I felt the need to give compiler hints (or formal language constructs) regarding common pipelined processes blocks that would be implemented in hardware. This led me to a generalization of the map/reduce paradigm. The map paradigm takes one or more lists and/or lists of vectors and computes on them in some pipelined way. The reduce paradigm summarizes some larger collection of numbers into fewer numbers. So for instance, a dot product function would be given two lists. The lists would have corresponding members pairwise multiplied in a map fashion (but also somewhat of a reduction), and then those results would be passed to a reduce unit that sums them. These things would easily map to pipeline segments. BTW, I'm not in love with the recent Google push towards map/reduce as cloud computing paradigm. But the concepts are a useful conceptual foundation for more workable stuff. (Although I'm not an expert on their paradigm; but my friends in high-performance computing criticize it.) On Mon, Feb 9, 2009 at 4:00 PM, Petter Urkedal <[email protected]> wrote: > On 2009-02-08, Viktor Pracht wrote: >> The reason I can't wait to get my hands on an OGD1 is to play with >> architectures with a functional (as opposed to imperative) machine >> language. Even though our FPGA is not partially reprogrammable, it's big >> enough to simulate a smaller FPGA with any custom architecture. > > On a related but different topic, there was a paper posted to Lambda > the Ultimate half a year ago about using functional languages for > hardware design: > > http://lambda-the-ultimate.org/node/2880 > > Apparently the use of functional languages for hardware design was > explored in the early 1980s, before VHDL and Verilog. The reason it > didn't catch on probably has more to do with the success of the latter > languages than with the infeasibility of the functional approach. I > haven't read the paper carefully, but the author makes an interesting > case of how FP can express classes of circuits parametrically, and > select optimal circuits from a set based an some metric. The metric > can then depend on the context in which the element is placed, so that > the element is specialised for the context in which they are > instantiated. > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
