Re: FPGA C Compiler on sourceforge.net (TMCC derivative)

Jim Granville wrote:
> I like this oxymoron, on p5 :
> " * Companies create proprietary ANSI C-based language
> * Languages do not have all ANSI C features

I don't think that's an oxymoron. Just because a language is proprietary,
it does not mean it can't be based on ANSI C.

Sure it might read a bit funny - but we've all tried to cram too much onto
slides before.

> and this very important point
> * Must adhere to specific programming ?style? for maximum optimization

Yes. That's a very important point.

> The benchmarks are usefull - and show the choice is very much a lottery.
> One benchmark they did not give, was just what results were if Generic
> C, from a generic graduate, was thrown at these tools.

I think you've got the wrong end of the stick there.

This isn't about taking arbitrary C code and compiling it to an FPGA.
You simply can't do that.

Reason: It's possible to write architecture specific code (that is, code
specific to a particular ISA) in C. Self-modifying code and dynamic code
generation are examples of this.

For example, linkers and JIT compilers modify code which is then executed.
You couldn't compile that efficiently to an FPGA - it would need the
re-synthesis every time code was modified..

Another reason is that a compiler can't guess which inner loops are program
'hot-spots', and thus good candidates for synthesis. Such information is
application-domain specific.

Concisely: the aim isn't to be able to take a program written by someone
who knows nothing about hardware (at least, not yet). The aim is to be
able to develop hardware acceleration for a given algorithm.

One advantage of C-based languages is that when trying to accelerate an
algorithm, it might not be clear which parts to synthesise - this requiring
some trial-and-error for difficult problems, and also being dependent on
some rather arbitrary parameters. It's easier to move a computation unit
from software to hardware, or vice-versa, if the languages are similar.
There's also a whole raft of software based optimisations that can be
applied before the hardware optimisations even get a look in.

Another, is that for some projects, a C simulation is developed to check the
algorithms anyway. For example, Timothy Miller did a software model for
the OpenGraphics project. The practise isn't uncommon.

> Source snippets are important, because these solutions are not C, but
> C-based. The devil is in the details....

For the reasons above, it is - in general - necessary to provide a compiler
with some pragmas or other hints that describe what code would be a good
candidate for synthesis.

However, the solutions are often close enough to C that it's possible to
execute the program entirely in software, as well as compile to a
object code/bitstream target. That's useful for the intended applications.

Nobody's pretending C-based synthesis is a complete replacement for HDL,
only that for some applications/projects it's a very compelling
alternative.

Martin

.

Relevant Pages

  • Re: Not enough parallelism in programming
    ... >> Trying to model this in occam and I suspect in most any SW par language ... SW languages don't want or need the ... Funnily enough nor do some hardware projects if some simplifying ... simulation trades speed and simplicity for the event driven simulator ...
    (comp.arch)
  • Re: Term Rewriting vs. Functional Programming
    ... > general-purpose programs in FPLs than in TRSs. ... > in imperative languages, millions in functional languages and hundreds of ... >> optimise TRSs than FPs? ... > compile OCaml source that run at roughly the same speed. ...
    (comp.lang.functional)
  • Re: Syntax directed compilation
    ... seems to be "too much power, users write their own languages and then ... The declaration statements are executed ... compile time. ... is also a statement which is executed at compile time. ...
    (comp.compilers)
  • Re: language and program nostalgia
    ... As languages, I'd bet most of them are still running on ... "contemporaneous" hardware, either inside virtual machines, ... I'd bet sources running on some unix are often ... The creation of emulators & virtual machines is almost as old as ...
    (comp.lang.lisp)
  • Re: Not quite getting it.
    ... static typed languages have a problem finding logical ... But so does Ruby since it doesnt even have compiletime. ... Ruby cant fint logical flaws at compile time either (due to lack of ...
    (comp.lang.ruby)