On Tue, Mar 3, 2009 at 2:34 PM, Jecel Assumpcao Jr <je...@merlintec.com>wrote:
> The key thing is to have some model of parallelism which is used by the > source code. If you try to extract automatically parallelism from > "normal" application code you will just make things needlessly > complicated for yourself. > > -- Jecel > > Precisely. You've hit the nail on the head. Most of the world is trying to shoehorn imperative specification into a mixed imperative/combinatorial environment, usually a heterogeneous one at that (cpu+fpga or cpu+gpu or even cpu+OtherArchCpu), and wondering why they are running into a semantics mismatch. The only real win here so far has been cpu+cpu (same arch) where the combinatorial nature is self evident, and maps naturally to "simple" abstraction. (SIMD, etc.) However, FONC stands out as somewhat "blessed" here, as the base fundamental abstraction (is/ometa) on which everything else is to be built (and the gist of it seems to be that "everything" here is end to end, from the cpu to the os to the userspace to the network and beyond...) already contains a natural separation of the sequential and the parallel... it even relies on it.... in fact it is the "whole point" so to speak. Traditional HDLs do their "best" by composing abstractions of both behavioral (imperative/sequential) and structural (combinatorial/parallel) specification, but to the best of my knowledge this project is unique in having a single abstraction mechanism covering both domains in tandem. Atom, bluespec, et al come close by hiding the sequential abstractions behind a rule scheduler, effectively allowing the human designer into a mindset that the sequencing is not a design concern. I suppose it is debatable which is a better approach, but I know which camp I'd be in... --Nate
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
