> On Aug 3, 2015, at 7:07 AM, Steve Richfield <[email protected]> wrote: > On Mon, Aug 3, 2015 at 2:37 AM, Duncan Murray <[email protected] > <mailto:[email protected]>> wrote: > Hi Steve, > when I first saw the heading I was interested, but seeing the words > BASIC, COBOL and Fortran made me a little uneasy. I honestly don't think > you'd get much traction or interest in a language syntactically similar to > those - it should use modern techniques where valid, for example even Json > would be easily / more accessible than the COBOL PICTURE clause. > > I don't see how Json could specify the minimal word sizes and modes needed to > conserve gates in an FPGA. Perhaps you see something I missed? Explain?
While I agree with Duncan that COBOL/BASIC style syntax is an anathema to most programmers, JSON/Javascript are pretty badly broken and won’t do what you are trying to do. Have you looked at LLVM IR? Not only does it support the feature you are looking for above (integers can be defined to have an arbitrary number of bits) but the Static Single Assignment programming model makes it suitable for conversion on FPGAs. In fact, I believe a number of IR-to-FPGA engines have been designed for it already. Lots of software knows how to emit LLVM IR these days; it is a compiler lingua franca. > I love the idea of having SQL commands built into the language. > > Yea, SQL is my favorite AI language - but not suitable as an implementation > language, or inside of FPGAs, though an FPGA might be programmed in this > language to become an SQL engine. I’ve actually designed and built massively parallel SQL databases from scratch that, as it happens, takes SQL and compile it down to LLVM IR for ultra-fast execution. SQL would be a terrible language for this. The language design assumes things about the hardware and software architecture that are nonsensical for a modern use case or impossible to implement correctly. Assumptions from the 1970s are hardcoded into the language. When people have implemented SQL in FPGAs, it is only a small, well-behaved subset. The larger language is quite poorly designed for parsing, dynamic compilation, or parallelism which is a problem for modern use cases. > The speed increase using the FPGA is the biggest selling point in my mind, > > YES. For many things, FPGAs are not much (if any) faster than highly optimized CPU code. There are certain code patterns for which they do offer excellent performance but those cases are more limited than I think many people assume. However, I can see a few use cases for the CPU+FPGA hybrids that Intel is building. Most codes today are limited by memory bandwidth and latency, which an FPGA does not address. ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
