NSF Center for High-Performance Reconfigurable Computing (CHREC)
This is a long-term sort of project idea for us. The holy grail would
be to convert arbitrary C or Fortran code into FPGA logic. (This
would be especially good for Cray computers that arrange Opterons with
Xilinx FPGAs.) A more realistic goal, however, would be to convert a
restricted subset of C into gates.
One idea I had was to define stylistic requirements on C functions
where a function takes a single struct as input and returns a single
struct as a result. The structs can contain any primitive data items.
This would be relatively easy to parse and convert to Verilog, which
we would synthesize for the FPGA.
The next way in which we make this realistic is to not try to get
optimal FPGA performance. We just try to get whatever performance we
can. If the logic is used properly, we can always get a performance
win.
I have thought a lot about this problem, and it seems to me that the
best solutions are to use one of the following:
1) Best, use a purely functional language. Haskell is the most common
of these, and you could probably force a Lisp dialect into this mold.
2) Use stream programming, as in BrookGPU. This leads to C-like code,
but has the advantage of running really fast. It does have a few
restrictions, but BrookGPU is based on OpenGL, which basically means
we just need to support the right subset of OpenGL and we have
distributed computing for free.
3) Use nasty semaphore/lock based code, except with Software
Transactional Memory (http://en.wikipedia.org/wiki/
Software_Transactional_Memory) so that you can actually write code
that does stuff instead of just writing code to prevent locks.
Purely functional languages are the best option because a) they exist
today in concurrent form, b) they often have good exemplatory
materials (e.g. A Gentle Introduction to Haskell), and c) while they
are a different methodology than imperative languages like C, they do
not have restrictions like BrookGPU.
I suggest we should support a portion of OpenGL that allows BrookGPU
to run fully in Hardware, and later on write some sort of functional
language to support the chips. Once that is done, we can attempt a
Software Transactional Memory based C-like language, or something
along those lines.
nick
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
