<whitequark>
cr1901_modern: no; i'm still focusing on cxxrtl
<whitequark>
though the end is in sight
<cr1901_modern>
Ack, keep going :)!
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
emeb_mac has quit [Read error: Connection reset by peer]
emeb_mac has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
lkcl has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
lkcl has quit [Ping timeout: 240 seconds]
Felkin has joined #nmigen
<Felkin>
Yo, yo. Am I right to assume that the only way to get cordic up and running would be by using migen-soc's implementation and fixing up for nmigen?
<whitequark>
i think someone might have implemented cordic for nmigen?
<whitequark>
but in any case, since it's a pure compute module, you should be able to get it working in no time with nmigen.compat
lkcl has joined #nmigen
<Felkin>
Gotcha, will probably give it a go later in the week then. Thanks~
<Felkin>
Will try implementing MUSIC using it. Lack of docs on cordic as a whole is killing me. Everyone has a cordic implementation, but no one does anything more than a sin(x) example.
Felkin has quit [Remote host closed the connection]
<whitequark>
i know essentially nothing about cordic
<tpw_rules>
oh he left
<tpw_rules>
i wrote some cordic math routines for avr once
<tpw_rules>
they're base 10 but
<tpw_rules>
they did implement tan and ln and inverse of those (and the rest of the trig functions through identities)
Felkin has joined #nmigen
<Felkin>
Oh I'm here! Just on phone so in/out
<tpw_rules>
how did you see my messages then :P
<Felkin>
Those notes on cordic would be invaluable
<d1b2>
<Darius> I saw some in FPGAs for doing DDS
<d1b2>
<TiltMeSenpai> cordic hurts my brain. For some reason, I could never really understand trig
<whitequark>
tpw_rules: we have a logger!
<Felkin>
Yep, quark's logger
<d1b2>
<Darius> Xilinx have a DDS compiler which uses it but I guess that's not relevant to nmigen 😄
<tpw_rules>
oh i remembered trying to find it, failing, and assuming you preferred to keep it private
<tpw_rules>
all i really have is source code with some block comments
<Felkin>
Any examples are helpful
<tpw_rules>
let me see if i have the document i wrote on it easily available
<whitequark>
tpw_rules: it's literally in the topic
<tpw_rules>
i was trying to look because i couldn't access the channel at the time :D
<whitequark>
because freenode guidelines require that
<whitequark>
oh
<tpw_rules>
Felkin: are you a code or a words type of person
<Felkin>
Code, for sure
<tpw_rules>
alright. the license on what follows is "please don't broadcast the code far and wide"
<tpw_rules>
the cordic stuff starts in the first file around line 431. the second file generates the "math_consts.h" which encodes the CORDIC lookup tables
<Felkin>
Great, thank you so much! This will be invaluable
<tpw_rules>
for base 2, really just replace all the 10s with 2s
<Felkin>
Will check it out. Cordic blew my mind when I learned about it a week or so.
<tpw_rules>
it's really neat. and yeah it seems to me (along with anything math >_>) to be very over and yet under explained
<Felkin>
Ago* while learning MUSIC. I feel like with nmigen it could be used well for some neat small footprint designs
<tpw_rules>
what is MUSIC?
lkcl has quit [Ping timeout: 260 seconds]
<Felkin>
It's a direction of arrival estimation algorithm
<tpw_rules>
ah
<Felkin>
Based on eigen decomposition, very neat too I'm how simple it is.
<Felkin>
I got this drone dataset for my DSP class, pitched to use MUSIC on it, check performance. Then implement via cordic, compare.
<Felkin>
I'm working on a sort of review of the current state of FPGA design for machine learning workloads. A core part of it is taking a set of algorithms and implementing em using HLS, xilinx block diagrams and then a newer HDL, going with nmigen. I'm thinking of covering cordic as part of the set, since LUT utilization will be an important point if
<zignig>
is anyone awake? apart from the sleepless.
<Sarayan>
wq: doesn't it has the exact same issues than clang?
<Sarayan>
I mean, you could say "clang version > n has to be in the path" and just call the programs?
<zignig>
Sarayan: what are you building nmigen at the moment?
<Sarayan>
I tend not to use nmigen as whitequark intends, e.g. I use it to generate the rtlil and I call yosys/clang/etc myself
<whitequark>
that's actually intended use of nmigen (back.rtlil is a public API)
<whitequark>
it's just that most people don't really care for that, and i recognize that it is valid for them to not care
<Sarayan>
Yeah, you're rather open on how to use your tools, and that's really cool
lkcl has quit [Ping timeout: 240 seconds]
Stary has quit [Ping timeout: 260 seconds]
FFY00 has joined #nmigen
lkcl has joined #nmigen
<whitequark>
Sarayan: re zig: what it does is it also drags along a working standard library, even on "weird" systems like alpine or windows
<whitequark>
so this potentially reduces the amount of additional things that have to be installed to use cxxrtl to... zero
<whitequark>
(pip install nmigen[builtin-yosys,builtin-cxx], and that's it)
<Sarayan>
ah, that's nice
<Sarayan>
personally I'd say "you need a working clang" and not do any technical dependencies
<Sarayan>
but that's just me
<whitequark>
thing is it's not just "working clang" but more like "working clang abi-compatible with your python"
<sorear>
only 45MB according to that blog post? wow
<whitequark>
oh and the other thing it provides is a ccache equivalent
Stary has joined #nmigen
<Sarayan>
Since cxxrtl is not embedding anything from python I'm not sure how you can not be abi-compatible... or worse if there's a possible abi-compatibility issue whether something you provide doesn't have a bigger chance to be incompatible with the python you don't provide
<Sarayan>
Urgh, reading the thread what you want is libtool, or more precisely what libtool sohuld have been
<whitequark>
oh and *another* thing it does is it embeds some target-specific knowledge about flags so that i don't have to e.g. think about -fPIC
<whitequark>
or, hm, let me recheck
<whitequark>
that might be another part of zig
<whitequark>
yup, it does handle that
<Sarayan>
yeah, -fPIC and stuff is a pain
<whitequark>
so i can't really fall back to bare clang from zig c++
<whitequark>
i'd have to fall back to cmake, which knows about the -fPIC stuff
<whitequark>
or meson or w/e
<Sarayan>
and that information is not in python-config either, sadly
<whitequark>
it's sort of in `sysconfig`
<Sarayan>
what is sysconfig?
<whitequark>
but not really in a way that's usable outside of concatenating random parts of sysconfig together
<whitequark>
try `import sysconfig`
<Sarayan>
CCSHARED = "-fPIC"
<Sarayan>
CFLAGSFORSHARED = "-fPIC"
<Sarayan>
LDCXXSHARED = "g++ -pthread -shared"
<Sarayan>
yeah, there's some stuff in there, but it looks fragile
<whitequark>
it is very much fragile
<whitequark>
when it works, it really is to a large extent by chance
<whitequark>
e.g. pypy doesn't have LDCXXSHARED, because LDCXXSHARED is an accident of how cpython build process works
<Sarayan>
ouch
<Sarayan>
pretty much what I meant with fragile indeed
<Sarayan>
mwahahaha
<Sarayan>
libtool is a Python library for creating a Python library, and also manages versions and uploading to PyPi with twine
<Sarayan>
libtool runs in Python 3+ and only in Windows.
<whitequark>
so on pypy i glue CXX with LDCXXSHARED.split()[1:]
<whitequark>
which is horrifying
<Sarayan>
by now, is there any linux where -shared -fPIC doesn't work? I wonder if it's not just 3 sets of very similar flags, one for each system
<Sarayan>
I doubt you care that much about hpux
<Sarayan>
and sysconfig should get you the platform reliably at least
<whitequark>
i care about windows and macos too
<Sarayan>
sure, but are there multiple sets of flags for those?
<Sarayan>
or can you just have a 3-entries table?
<whitequark>
for windows, yes, definitely
<whitequark>
well
<Sarayan>
damn
<whitequark>
at the very least you have mingw python and vc++ python
<whitequark>
it's *mostly* the latter but people use the former too
<whitequark>
horrifyingly, people also use cygwin python, which is something i actually refuse to actively support
<whitequark>
because you gotta draw a line somewhere
<Sarayan>
does anything from python tell you which it is? Can sysconfig tell you?
<cr1901_modern>
upstream python wants to pretend mingw/GNU ABI not to exist
<cr1901_modern>
whitequark: If it makes things easier, I'm happy for you to NOT support mingw python in this case
<whitequark>
well zig cc makes that a no-brainer
<cr1901_modern>
I'm doing something not-recommended; I accept the consequences
<whitequark>
i'm slightly more worried about msvc python actually
<cr1901_modern>
zig proper supports msvc abi better than mingw; I don't know if that extends to "zig cc"
<Sarayan>
ah damn, I don't have nmigen installed anymore
* Sarayan
fixes that
<whitequark>
there's `zig cl`
<whitequark>
i'm not sure if `zig c++` supports msvc abi
<cr1901_modern>
msvc and mingw are both "tier 2" targets on the zig matrix IIRC, but the focus is getting msvc working
<cr1901_modern>
msvc might even be "tier 1". Anyways, I don't have a native zig for Windows- I can't be arsed to compile the correct clang version for it :P.
<whitequark>
i'm honestly not sure if this even matters for nmigen's purposes
<whitequark>
like Sarayan mentioned, getting an ABI incompatibility with cxxrtl is not trivial because cxxrtl's C API is so simple
<Sarayan>
and python does not use any c++ system lib
<whitequark>
python does use msvcrt though
<Sarayan>
and cxxrtl doesn't use much of libc I think
<whitequark>
so suppose i print from cxxrtl code
<whitequark>
yeah... that's not gonna work so well
<Sarayan>
yeah, there's danger there
<daveshah>
yeah, I think we've hit stuff like that with nextpnr
<Sarayan>
well, mingw and vc c++ abi are fully incompatible
<Sarayan>
I mean the C abis
<cr1901_modern>
The C ABIs are compatible
<whitequark>
vc++ doesn't even have a (stable) c++ abi
<Sarayan>
cr1901: reaaaaaaaaaaaally?
<whitequark>
they have to be compatible to some extent or you couldn't use windows dlls from mingw code
<Sarayan>
or well, it's the linux (itanium) and windows ones that are incompatible then
<cr1901_modern>
I can link against a *.lib compiled with msvc with a gcc application :)
<Sarayan>
ah, I guess mingw uses the windows aby then
<whitequark>
itanium in this context would be only the c++ abi
<cr1901_modern>
and it doesn't crash
<cr1901_modern>
That's my definition of compatible :)
<whitequark>
i'm not really sure wtf happens with SEH and what are the exact implications of it
<Sarayan>
there's using different registers for function parameters, that's hitting C too afaict
<whitequark>
c parameter passing abi *has* to be compatible or you couldn't use any winapi
<Sarayan>
yeah, makes sense
<whitequark>
(well, you should be able to opt into having it compatible)
<Sarayan>
they must have gcc/clang generate windows-type parameters
<whitequark>
yep
<cr1901_modern>
whitequark: Anyways, I haven't been following this convo/what you're trying to accomplish closely. I commented b/c I anticipated mingw python to be brought up and how me using it has caused you woes in the past. >>
<Sarayan>
then c++ is another layer of crap on top of that of course
<Sarayan>
in particular C++ method pointer encoding, that's a bad one
<whitequark>
not me
<whitequark>
wasmtime folks
<cr1901_modern>
And my initial SSH impl that you told me to drastically simplify :P
<whitequark>
wait, was mingw somehow involved there?
<cr1901_modern>
I tried making logic to customize where paramiko looked for keys
<cr1901_modern>
b/c the only default is %USERPROFILE%/.ssh on Windows
<cr1901_modern>
And mine are under my bash $HOME/.ssh
<cr1901_modern>
You told me to "symlink %USERPROFILE%/.ssh to $HOME/.ssh" rather than customize nmigen. That's fine.
<d1b2>
<DX-MON> GCC has support for the windows calling conventions and uses the MSVC ABI on windows when you say __attribute__((dllexport)) and __attribute__((dllimport)) at the very least, hence why it doesn't 'splode
<cr1901_modern>
If I used a msvc python this would've been a non-issue
<whitequark>
oh right
<d1b2>
<DX-MON> it also supports __cdecl and friends
<cr1901_modern>
So if "whatever you're doing w/ cxxrtl" would cause problems w/ mingw, I don't have a problem w/ considering "whatever you're doing w/ cxxrtl" out-of-scope for mingw
<cr1901_modern>
That's all
<Sarayan>
what is "adopt" supposed to be in a cxxrtl context?
<whitequark>
Sarayan: grab black boxes from the argument
<Sarayan>
oh, fucked my install
<whitequark>
so like a move constructor but only move black boxes
<whitequark>
open to better naming
<Sarayan>
it's more that it explodes on that when you have a version mismatch between headers and generator
<Sarayan>
compiles now, cool
<whitequark>
oh yeah
<whitequark>
see, with builtin-yosys that's not possible :p
<Sarayan>
huhuhu
<Sarayan>
tried just for kicks, clang++ -O3 -shared -fPIC -I/people/galibert/share/yosys/include m68000.cc -o m68000.so gives me a .so that links and works correctly with other c++ code
<Sarayan>
m68000.cc being cxxrtl-generated
<whitequark>
yeah, that's the normal way to build on x86_64
<Sarayan>
fucking cyclone v
<whitequark>
oh?
<Sarayan>
wq: there's a list of "default bits to set" in the tables that are just derivable from the default values of the muxes and/or routers
<Sarayan>
except for, oh, 100 bits or so that are coming from who knows where
<Sarayan>
so there's the eternal question, did I miss something or did they just add a pile of bits in there just because?
<lkcl>
tpw_rules, aw doh, we've been planning to use CORDIC for just about all of the transcendentals because of the huge coverage
<lkcl>
we've an IEEE754 FP sin/cos now, using them, and the plan is to add log2, exp, expm1, log1p, atan2, acos etc. next
m4ssi has quit [Remote host closed the connection]
<lkcl>
whitequark: although i do appreciate that you wanted a full range of interoperability by using ctypes, and eliminated all other options, perhaps it might be time to re-evaluate the idea of code-generating python c-based module source code? although it would be a pain for pypy, i did not recommend the python c-based module as a mutually-exclusive option *instead* of the use of ctypes, i raised it for consideration as a multiply-redundant
<lkcl>
(faster) alternative
<lkcl>
which, it seems, given abi issues, might actually provide better interoperability (except on pypy)
* lkcl
wonders if they have an equivalent of c-based modules
<lkcl>
interesting. there does exist something called cppyy which eliminates the JIT overhead
<lkcl>
and apparently it works with cpython as well
jeanthom has quit [Ping timeout: 265 seconds]
jeanthom has joined #nmigen
_whitelogger has joined #nmigen
<whitequark>
lkcl: i do not generate python c-based modules
<whitequark>
er, sorry, i misread
<whitequark>
ok, so the issue with that suggestion is that it doesn't actually solve much
<whitequark>
distutils' CXXFLAGS is such that the CXXRTL code is significantly slower than it could be
<whitequark>
no matter what i do, i can't use distutils, so what kind of interface code there is, is besides the point
<whitequark>
to elaborate, if i cannot ship a solution that is effectively "turnkey", it's not that i do not have a solution. it's that i request the end user to provide a compiler command line
<whitequark>
if CXXRTL code is too slow with the "turnkey" solution, that is also exactly what they would have to do
chipmuenk has quit [Remote host closed the connection]
emeb_mac has joined #nmigen
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 260 seconds]
<lkcl>
whitequark: interesting. i always thought that "python setup.py build" with c-based modules worked all the time, every time, i mean, that was the whole point
<lkcl>
arg not being able to rely on python-distutils, got it. that messes things up.