3 ms·
might be like OpenCL: a subset of C99 with some extensions works for parallel hardware including FPGAs already so why not a subset of Go targeting FPGAs?
by marmaduke 9y ago
might be like OpenCL: a subset of C99 with some extensions works for parallel hardware including FPGAs already so why not a subset of Go targeting FPGAs?
- jerf 9y ago"A subset of Go" is certainly one sensible option, but I don't see it documented. The obvious subset that one could get with the least effort is a rather brutally cut down subset of Go, to the point that I'd consider claiming it to be "Go running on an FPGA" to be nearly a lie. On the other extreme, you've got a full FPGA on hand, so nothing stops them from bringing up a simple ARM CPU die and putting a bit of general-purpose RAM there, so it's theoretically possible that you could write general-purpose FPGA code and have that FPGA-CPU gloss over any runtime issues, but that's where I get my question about how a programmer would be expected to model the costs incurred by given constructs sensibly. (Presumably, if performance is not a big deal to the programmer, they're not using FPGAs at all, so I'm going in assuming performance is at least in the top 3 concerns of anyone who might use this, if not #1.) (Also I'm not 100% sure about the intersection of what ARM cores might be available vs. what Go runs on; IIRC Go does ARM but only very high-end ones. So, take the principle of my point rather than the literal text. With enough work they can do "anything" with the FPGA code.)