From e03af526e9b024dc7574329004ffaf77e587f119 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 2 Oct 2021 21:04:45 +0100 Subject: [PATCH] --- 3d_gpu/architecture/dynamic_simd.mdwn | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/3d_gpu/architecture/dynamic_simd.mdwn b/3d_gpu/architecture/dynamic_simd.mdwn index ad124adeb..f7c0320c3 100644 --- a/3d_gpu/architecture/dynamic_simd.mdwn +++ b/3d_gpu/architecture/dynamic_simd.mdwn @@ -150,7 +150,7 @@ raised. one technique for creating SIMD variants of the required code would be to use macro substitution or crude compilers to autogenerate the dynamic SIMD from VHDL / Verilog templates, why not do exactly the same thing. - Design a SIMD langusge, write python in that, and have it output + Design a SIMD HDL language, write python in that, and have it output nmigen HDL. All of these ideas, unfortunately, are extremely costly in many different ways: @@ -191,6 +191,13 @@ All of these ideas, unfortunately, are extremely costly in many different ways: that, unless actually included *in* nmigen, the underlying AST modules that they use might change, or be deprecated, or have bugs fixed which break the replacement. +8. "Compilers". It is very well known that any python program that outputs + another python program as an ASCII output may then immediately read that ASCII output + from within the very program that created it, `eval` it, and then + execute it. That being the case, you might as well skip the + output to ASCII and the eval part, and create classes that + dynamically and directly instantiate the desired target behaviour. + This saves months of effort but is a common mistake, frequently made. Bottom line is that all the alternatives are really quite harmful, costly, and unmaintainable, and in some cases actively damage nmigen's reputation -- 2.30.2