[llvm-dev] LLVM Backend for a platform with no (normal) stack

[Mendell, Mark P via llvm-dev]

We have full support for loops

From: Bruce Hoult <brucehoult at sifive.com>
Sent: December 17, 2018 10:06 AM
To: Mendell, Mark P <mark.p.mendell at intel.com>
Cc: jjones at prc-hsv.com; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] LLVM Backend for a platform with no (normal) stack

On Mon, Dec 17, 2018 at 6:31 AM Mendell, Mark P <mark.p.mendell at intel.com<mailto:mark.p.mendell at intel.com>> wrote:
Not only do FPGAs not support recursion, we don’t even support calls!  All user code must be inlined into one kernel/component, which is then used to create HDL for the FPGA.

That's an implementation choice. Verilog allows you to use recursion to generate complex structured circuits. Of course, it's all just inlined and the recursions have to hit bottom during that process.

Do you also insist on no loops, or at least only loops with explicit fixed trip counts? What about AREF?

I've worked on a GPU back end for llvm where we inlined all function calls into each shader/kernel. That was convenient, but only ever as a stop-gap and OpenCL 1.2 lets you get away with that.

On very restricted machines it's often easier to create a simple interpreter using the native features and then target your actual program at the interpreter. It's slower, of course, but much more flexible. This applies equally as much to FPGAs as it did to things like the 6502 forty years ago where most programming was done in either tokenised BASIC or else Pascal compiled to bytecode (or even SWEET16). Every day I use an FPGA programmed to interpret RISC-V opcodes and it supports not only function calls and stacks and recursion, it's running a full Debian Linux as quickly as an early Pentium or PowerPC did.

Depending on the performance needs, an interpreter might be a good option for the OP.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181217/b80c3f1e/attachment.html>