gateware floating point instructions on the kernel CPU

[sbourdeauducq]

#529 (comment)

[dhslichter]

Awesome, thanks for adding this. Can you post this on the m-labs website in the ARTIQ extensions list as well?

[sbourdeauducq]

I intend to remove this page at some point and replace it with a link to https://github.com/m-labs/artiq/issues?utf8=%E2%9C%93&q=label%3Atype%3Afor-contract%20

[sbourdeauducq]

@dhslichter mentioned basic math functions (sin, cos, log, exp). Should those be gateware-accelerated, or are slower software implementations (using gateware FP for floating addition, multiplication, etc.) OK?

[jordens]

I would really prefer not to stray to far of the beaten path here, i.e. for hard FP and vectorization (which is an extremely complicated thing to reinvent) we should concentrate on the corresponding openrisc instruction sets and implement them, instead of inventing new instruction sets. Also accelerated trigonometry is of similar complexity as vectorization.
Since hard FP and trigonometry have a multiplicative impact on performance, focusing on "standard" hard FP first seems prudent.

[dhslichter]

I agree with @jordens; the most important thing to do here would be to implement a "standard" hard FP instruction set. Basically the thing to do would be to implement all the instructions defined in the openrisc standard (ORFPX32) but not actually implemented in mor1kx. The sin/cos/log/exp functions could then be constructed from these with (hopefully) reasonable performance, and we can decide later if they truly require hardware acceleration themselves.

[jordens]

@whitequark could you add a short assessment of the state/quality/existence of support for or1k FP in the toolchain and the biggest roadblocks to this issue?

• artiq compiler
• llvm-or1k
• llvmlite/new-pyllvm
• compiler-rt
• artiq runtime (probably need nothing specific here)
• testbenches

[whitequark]

artiq compiler
llvmlite/new-pyllvm
artiq runtime
testbenches

No changes required as the LLVM instructions are the same for soft or hard FP.

compiler-rt

No changes needed as we will be using less compiler-rt code afterwards.

llvm-or1k

The OR1K backend supports the complete OR1K FPU single-precision instruction set except the MAC instruction. Extending to double precision (which we use) is trivial. Ditto for MAC.

[jordens]

@sbourdeauducq would we use the mor1kx FPU or port some other FPU or write ourselves a new one or go some completely different route?

[sbourdeauducq]

Take the usable parts of the mor1kx FPU (e.g. its interface into the CPU), rewrite the others.

[sbourdeauducq]

Seems VexRiscV has a FPU now and I would expect high quality.

[sbourdeauducq]

Funded by Duke.

[sbourdeauducq]

speedup: #1777 (comment)